The Borgo Programming Language

Original Article ↗ Hacker News Discussion ↗

A new language called Borgo aims to bring Rust-like features — such as algebraic data types, Result/Option types, pattern matching and immutability — to the Go ecosystem by transpiling to idiomatic Go and interoperating with existing Go libraries. Commenters are intrigued by how it fixes many long‑standing complaints about Go’s type system and error handling, but question its prospects given the lack of a license, minimal tooling, a single maintainer and the general difficulty of bootstrapping a new language. The exchange also highlights broader themes: the trade-offs of source-to-source compilers, how much language “safety” and expressiveness developers really value in practice, and the importance of corporate backing and ecosystem maturity for adoption.

Language design and goals

  • Borgo is a statically typed, Rust‑influenced language that transpiles to Go and aims to “fix” several Go pain points while retaining Go’s runtime and ecosystem.
  • Key features praised: Result<T> instead of (T, error), ?-style error propagation, algebraic/structured enums, Option<T> instead of nil and zero values, pattern matching, immutability by default, removal of if err != nil boilerplate and unsafe nil pointers.
  • Some changes (e.g., let, extra impl syntax, Zig-like dereferencing, expression-oriented returns, Rust-style syntax) are viewed as potentially unnecessary complexity or cosmetic.

Superset vs. new language & interop

  • Debate over whether Borgo should be a strict superset of Go (like TypeScript to JavaScript).
  • Counterargument: being a superset would lock in Go’s problematic features (e.g., nil, zero values), similar to C++ inheriting C’s legacy.
  • Borgo can coexist with Go in the same project and call Go code, but requires declaration files for interop, which some see as a barrier.

Tooling, ecosystem, and adoption

  • Major skepticism that people will adopt it despite liking the design:
    • Source‑to‑source transpilers are seen as fragile for debugging, linting, profiling, coverage, and IDE tooling.
    • Existing Go tools operate on generated Go, making error locations and lints awkward.
    • Network effects: Go’s ecosystem and Google backing are a large moat; Borgo has a single primary developer.
  • Comparisons drawn to TypeScript, Kotlin, Gleam, Elm, Zig, Go+, V, Odin, etc.; history shows some “better front ends” succeed, many stagnate.

Licensing and maturity

  • The compiler repo has no license; several commenters argue this means it’s legally just “source available,” not true open source.
  • Disagreement on whether GitHub’s terms implicitly allow use and execution; overall legal status considered unclear and risky for production.
  • Commit history shows little activity in the past year; status and long‑term maintenance are questioned.

Target audience and use cases

  • Some Go users excited to try Borgo for personal projects or Advent of Code, especially to avoid nil bugs.
  • Others think it may appeal more to Rust fans who want faster builds and Go’s runtime, though some Rust users won’t want a GC.
  • Consensus: interesting design and fills a conceptual niche, but real‑world adoption is doubtful without clearer licensing, active maintenance, and robust tooling.