Borgo is a statically typed language that compiles to Go
A new language called Borgo aims to combine Go’s runtime, tooling, and ecosystem with Rust-like features such as sum types, Option/Result-based error handling, and pattern matching, by transpiling Borgo code into Go. Commenters debate whether adding this richer type system and syntax meaningfully improves safety and maintainability over idiomatic Go, or simply reintroduces complexity Go was designed to avoid. Others question the viability of “language-on-top-of-language” projects—citing TypeScript as a rare success—and note that Borgo’s apparent inactivity and edge cases (like zero values for sum types) highlight how hard it is to retrofit stronger typing onto an established platform.
What “compiles to Go” means
- Many argue Borgo is a transpiler (source-to-source compiler) since it emits Go code, but note that transpilers are just a subset of compilers.
- Some see the compiler/transpiler distinction as largely useless or fuzzy; others like “transpiler” to signal human-readable target code and the expectation of using another toolchain afterward.
- A meta-discussion emerges about how programmers over-attach to poorly defined terminology.
Why target Go at all
- Main rationale: leverage Go’s strong runtime, GC, standard library, tooling, deployment story, and module ecosystem while improving type safety and language ergonomics.
- Targeting Go lets Borgo interoperate with existing Go packages and ease adoption in Go shops.
- Some ask why not target C++ or Rust instead; responses stress that Go’s runtime and concurrency model are easier to map to, and that many users want “Go, but safer,” not a different systems language.
Type system, enums, and sum types
- Strong interest in Borgo’s Rust-like enums / sum types, Option/Result, and exhaustive pattern matching, which many see as the biggest missing pieces in Go.
- Long debate over what “enums” really are: classic numeric enumerations vs. tagged unions / algebraic data types.
- Several argue Go’s
iota-based constants are only a partial substitute and don’t support exhaustiveness checking or constrained value sets. - Some worry Borgo’s sum types with a zero value (via
zeroValue()) undermine the safety users want from them.
Error handling philosophies
- Go’s
if err != nil { ... }is defended as explicit and good for reliability, but criticized as verbose and visually noisy. - Exceptions / try-catch are both praised (for propagation and stack traces) and condemned (for hiding control flow and encouraging laziness).
- Result/Option with a
?-style operator is widely liked by fans of Rust-like ergonomics; others fear it will encourage thoughtless “bubble up the error” behavior.
Rust vs Go vs “Borgo in the middle”
- Some see Borgo’s niche as “more type-safe than Go, less complex than Rust,” particularly avoiding Rust’s ownership and lifetime system while retaining ADTs and good error handling.
- Others argue Go’s simplicity and minimalism are core virtues, and adding these features risks losing what makes Go effective, especially for teams with many junior developers.
Adoption, tooling, and maturity
- Enthusiasm from Go developers who say Borgo directly addresses their pain points (enums, nil, error handling).
- Skepticism due to stalled development (no commits in months) and lack of clear tooling story (LSP, Treesitter, etc.).
- Broader reflection that many Go-to-X or “X to Go” experiments (Borgo, Oden, others) exist, but none have yet gained mainstream traction.