Comment by xedrac
1 year 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?
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.
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.
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.
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.
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.