Show HN: Borgo – a Rusty language that compiles to Go (opens in new tab)

(borgo-lang.github.io)

18 pointsalpacaaa2y ago8 comments

Hey HN

Borgo is a programming language I've been working on for the past year. It looks like Rust (because I didn't want to write a parser) and compiles to Go.

What I want from a programming language is:

  - Sum types
  - Pattern matching
  - Option/Result types
  - Garbage collected
  - Concurrency without async
  - Good third-party package ecosystem

Borgo is my attempt at filling the gaps in the list above, adding features seen in ML-like languages to Go.

One ambitious goal of this project is to be compatible with existing Go packages. Generating bindings is pretty much automatic (there's an importer tool) and should help massively with adoption. The repo includes bindings to some packages in the stdlib already.

The compiler is in no way complete, but you can definitely build some interesting programs with it.

The online playground runs the compiler as a WASM binary, stitches together the transpiled Go code and sends it off for execution to the official Go playground.

The playground contains quite a few examples and goes more in depth into each feature: https://borgo-lang.github.io/

Would appreciate any feedback! :)

8 comments

xedrac2y ago

I don't mean to state the obvious, but if I was to make a language that looked just like C++ and compiled to Python, people would be scratching their heads. Typically you compile down to a more efficient language, not a less efficient one.

I suppose this is mostly about making Go more expressive. I don't really understand why you wouldn't just use Haskell, OCaml or even Rust, but maybe you have a ton of Go code that you need to play nicely with?

alpacaaaOP2y ago

I'm borrowing (pun intended) Rust syntax so that I can skip the parsing phase and focus on the interesting stuff, like type inference and code generation.

So even if it (currently) looks like Rust, it doesn't have any lifetimes nor borrow checking. It's just syntax, but I understand it can be confusing.

I could type an entire essay on "Why not Haskell". I've used it professionally for a few years and came to the conclusion that sticking to a tiny subset of the language (what I used to call Simple Haskell, I even wrote a book about it :D) is the only way to make it work in a large codebase in a team setting.

I've become weary of type astronauts and I don't want to use a language that allows or even promote certain (ab)use of type system features. In this sense, OCaml or even Elm are more inline with what I think is the sweet spot.

Borgo isn't too far off Ocaml to be fair if you squint a bit. Unfortunately OCaml suffers from years (decades?) of cruft that has accumulated over, to the point that even before you get started you have to pick an stdlib implementation. I know things are improving, but you get my point.

Ultimately I think that if a new language wants to be succesful and see some adoption, it has to integrate in an established ecosystem. See Typescript, but also Swift, Clojure, Scala and others.

I'd wish Borgo could do to Go what Typescript did to JS, bringing in additional type safety and modern features that people are starting to get used to from other less popular languages. Admittedly, TS is a bad comparison because of the madness you can encode at the type level, but the fact that it's been compatible with JS from day one is it's biggest selling point imo.

loosescrews2y ago

The Go toolchain is unique and it has a number of benefits that others that produce more efficient binaries generally lack.

Fast compile times

Pure self-hosted toolchain (no C)

No libc on Linux

For a garbage collected language, Go isn't bad in terms of efficiency. If garbage collection is a core feature of Borgo, one could do a lot worse than Go.

alpacaaaOP2y ago

That's precisely why I'm targeting Go. I think it has a very well thought out toolchain that works really well and I'd pick it any day instead of going for an LLVM backend, which is what most new languages seem to prefer.

DangitBobby2y ago

I haven't actually confirmed this but given that it's GCed, I would imagine it also doesn't use lifetimes so it's probably considerably quicker to write than normal Rust code. Rust without lifetimes sounds wonderful, actually.

alpacaaaOP2y ago

Yes you are correct. In case it isn't clear, I didn't write a GC myself, I'm just transpiling to Go and letting the Go compiler and runtime doing the heavy lifting.

> Rust without lifetimes sounds wonderful

This is the kind of comment I was hoping to see. Borgo is higher level than Rust and can massively benefit from simplifying certain parts of Rust for ease of use and better ergonomics.

pentaphobe2y ago

Cool stuff!

I've been periodically hunting for languages which transpire to Go for a while now, surprisingly silent space. Was not looking forward to trying to make one myself :)

One curiosity: How would you categorise the resulting Go output currently?

Obviously no expectation that a transpired language's output would be _pretty_ but helpful if someone working in Borgo can practically work on alongside a team purely working in Go.

Think: progressive migration, or feasibly having core in Borgo & surface layer in Go (or vice versa)

super_flanker2y ago

Looks very impressive, I've been tinkering with this idea to have a Kotlin type of language which transpiles to Go, but didn't go past writing a parser. Kudos for working on it, I hope it gains some popularity.

j / k navigate · click thread line to collapse

Show HN: Borgo – a Rusty language that compiles to Go (opens in new tab)

(borgo-lang.github.io)

18 pointsalpacaaa2y ago8 comments

Hey HN

Borgo is a programming language I've been working on for the past year. It looks like Rust (because I didn't want to write a parser) and compiles to Go.

What I want from a programming language is:

  - Sum types
  - Pattern matching
  - Option/Result types
  - Garbage collected
  - Concurrency without async
  - Good third-party package ecosystem

Borgo is my attempt at filling the gaps in the list above, adding features seen in ML-like languages to Go.

The compiler is in no way complete, but you can definitely build some interesting programs with it.

The online playground runs the compiler as a WASM binary, stitches together the transpiled Go code and sends it off for execution to the official Go playground.

The playground contains quite a few examples and goes more in depth into each feature: https://borgo-lang.github.io/

Would appreciate any feedback! :)

8 comments

xedrac2y ago

alpacaaaOP2y ago

I'm borrowing (pun intended) Rust syntax so that I can skip the parsing phase and focus on the interesting stuff, like type inference and code generation.

So even if it (currently) looks like Rust, it doesn't have any lifetimes nor borrow checking. It's just syntax, but I understand it can be confusing.

Ultimately I think that if a new language wants to be succesful and see some adoption, it has to integrate in an established ecosystem. See Typescript, but also Swift, Clojure, Scala and others.

loosescrews2y ago

The Go toolchain is unique and it has a number of benefits that others that produce more efficient binaries generally lack.

Fast compile times

Pure self-hosted toolchain (no C)

No libc on Linux

For a garbage collected language, Go isn't bad in terms of efficiency. If garbage collection is a core feature of Borgo, one could do a lot worse than Go.

alpacaaaOP2y ago

DangitBobby2y ago

alpacaaaOP2y ago

Yes you are correct. In case it isn't clear, I didn't write a GC myself, I'm just transpiling to Go and letting the Go compiler and runtime doing the heavy lifting.

> Rust without lifetimes sounds wonderful

This is the kind of comment I was hoping to see. Borgo is higher level than Rust and can massively benefit from simplifying certain parts of Rust for ease of use and better ergonomics.

pentaphobe2y ago

Cool stuff!

I've been periodically hunting for languages which transpire to Go for a while now, surprisingly silent space. Was not looking forward to trying to make one myself :)

One curiosity: How would you categorise the resulting Go output currently?

Obviously no expectation that a transpired language's output would be _pretty_ but helpful if someone working in Borgo can practically work on alongside a team purely working in Go.

Think: progressive migration, or feasibly having core in Borgo & surface layer in Go (or vice versa)

super_flanker2y ago

j / k navigate · click thread line to collapse