This addresses pretty much all of my least favorite things with writing Go code at work, and I hope--at the very least--the overwhelming positivity (by HN standards -- even considering the typical Rust bias!) of the responses inspires Go maintainers to consider/prioritize some of these features, or renews the authors interest in working on the project (as some have commented, it seems to have gone without activity for a little bit over half a year).<p>Some of the design decisions seem to me to be a bit more driven by being Rust-like than addressing Go's thorns though. In particular, using `impl` to define methods on types (<a href="https://borgo-lang.github.io/#methods" rel="nofollow">https://borgo-lang.github.io/#methods</a>), the new syntax for channels and goroutines (<a href="https://borgo-lang.github.io/#channels" rel="nofollow">https://borgo-lang.github.io/#channels</a>), and the `zeroValue()` built-in (<a href="https://borgo-lang.github.io/#zero-values-and-nil" rel="nofollow">https://borgo-lang.github.io/#zero-values-and-nil</a>) seem a bit out of place. Overall though, if I had a choice, I would still rather write Borgo by the looks of it.
Wow, this is everything I want from a new Go!<p>Having worked on multiple very large Go codebases with many engineers, the lack of actual enums and a built-in optional type instead of nil drive me crazy.<p>I think I'm in love.<p>Edit:
Looks like last commit was 7 months ago. Was this abandoned, or considered feature complete? I hope it's not abandoned!
About a year ago, I tried writing a language that transpiled to Go with many of the same features, in my research I found other attempts at the same idea:<p>- braid: <a href="https://github.com/joshsharp/braid">https://github.com/joshsharp/braid</a><p>- have: <a href="https://github.com/vrok/have">https://github.com/vrok/have</a><p>- oden: <a href="https://oden-lang.github.io/" rel="nofollow">https://oden-lang.github.io/</a>
I am genuinely appreciative that a post like this, a GitHub link to a semi-slow moving, but clearly well considered and sincerely developed programming language, can not only remain on the front page of HN, but can generate a diverse and interesting group of discussions. It’s material like this that keeps me coming back to the site. I’m not sure if anyone needed this comment, but I’m sure my posting it isn’t going to hurt.
Great! Something I've always wanted.<p>I'd love to be able to use a bit more type-y Go such as Borgo, and have a Pythonesque dynamic scripting language that latches onto it effortlessly.<p>Dynamic typing is great for exploratory work, whether that's ML research or developing new features for a web app. But it would be great to be able to morph it over time into a more specified strongly typed language without having to refactor loads of stuff.<p>Like building out of clay and firing the parts you are happy with.<p>Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque.
I like the graph at the top of the readme as a summary.<p>The rest of the readme focuses on the delta between Go and Borgo. It doesn't say much about the delta between Borgo and Rust.<p>I think the delta there is mainly no lifetimes/ownership?
This seems to achieve a similar type safety<->complexity tradeoff as Gleam [1] does. However, Gleam compiles to Erlang or JavaScript, which require a runtime and are not as performant as Go.<p>I wonder if Borgo's compiler messages are as nice as Rust's/Gleam's, though.<p>[1] <a href="https://gleam.run/" rel="nofollow">https://gleam.run/</a>
This looks like an interesting sweet spot. Rust is often praised for the borrow checker, but honestly I really only like rust for the type system and error handling. Go is praised for it's simplicity, but hated for it's error handling.
In the same vein, Go+ is also interesting, and its being actively developed.<p><a href="https://goplus.org/" rel="nofollow">https://goplus.org/</a>
Is it correct to say Borgo "compiles to Go", or should it say "transpiles to Go"<p>It appears to be a transpiler (consumes a Borgo and does the work to convert and emit a Go program as text):<p><a href="https://github.com/borgo-lang/borgo/blob/main/compiler/src/codegen.rs">https://github.com/borgo-lang/borgo/blob/main/compiler/src/c...</a>
Reminds me of this previous effort to build upon Go but add a more flexible type system: <a href="https://github.com/oden-lang/oden">https://github.com/oden-lang/oden</a>
The only language I can think of that has pulled off “compiles to another totaling language” and gained mainstream adoption is typescript, and I’m sure it wouldn’t have done so if it were possible to run in the browser otherwise.<p>Can anyone think of another example?
I'd never let a rando project on GitHub generate my code. Become dependent on their tiny new syntax AND let it generate the Go code that will actually be built from. Asking for things like backdoor insertion trick to be introduced later, after they have enough folks dependent on them and decide reward worth the risk. GitHub is The Jungle and all that entails.
Option instead of nil is amazing. Imo, the biggest flaw in Go's design is having nils instead of optionals.<p>I don't have a strong opinion on Result and Pattern matching - it seems nice, but I don't know if it adds much to the language. It is nice, but it may not be worth the complexity.<p>The error handling with ? is a no for me. I'd rather have something more like the go-errors/errors package in the standard library instead. This has been proposed before, and it was rejected for a good reason: it makes it too easy to be lazy and just bubble up errors instead of properly handling them.
to me the problem is not the language per se but the emerging complexity of a project written in a language. I.e. say I'm familiar with go and a k8s user. Does that mean that I can understand the architecture of k8s project and be meaningfully productive in a short period of time? Far from it.<p>Sometimes I think we focus too much and formalize on the first order tooling we use, language being one of them, while we neglect the layers upon layers of abstractions built on top of them. I wonder whether a meta-language could exist that would be useful in these upper layers. Not a framework that imposes its own logic. More of a DSL that can capture both business logic and architecture.
Why compile to Go rather than less-than-ideal (or even slightly-unsafe) Rust?<p>I find it conceptually compelling, I'm just surprised the target would then be in the GC'd, larger-binary'd direction. Like 'Java expressiveness with C simplicity, transpiles to Java'.<p>Perhaps 'just' because it's a lot simpler to just expand the target language slightly and then you only have to deal with mapping the new bits into implementation, it's less like writing a compiler for a whole new language?
Sum types having zero values seems to be breaking the promise that people hoped out of them.<p><pre><code> use fmt
enum Coin {
Penny,
Nickel,
Dime,
Quarter,
}
fn wtf() -> Coin {
return zeroValue()
}
fn main() {
let coin = wtf()
fmt.Println("zero coin:", coin)
}
</code></pre>
Output:<p><pre><code> zero coin: {0}</code></pre>
It's a little suspicious the example uses math/rand.Seed() which has been deprecated for over a year. That's when I noticed the repo itself hasn't had a single commit in 7 months.<p>Why is this suddenly news, when by all appearances it's abandonware?
This is a fantastic proof of concept project that answers a question I've been asking: what if there was another language that was designed to fit between Go and Rust? Ideas?
I understand that you like some Rust features like Result and Option types, enums, and pattern matching.<p>These features provide for more safety, and at the same time, they reduce productivity by forcing the developer to statically type everything.<p>The question is then why do we need to transpile to Go, a language with GC and slower than Rust?<p>If we already agree on super-safe static typing, why not just use Rust? Are there any libraries in Go that are not available or of worse quality in Rust?
Nice - it uses Rust Try syntax to solve error conditions and Rust style enums!<p>Which of course begs another question but I won't be that Rust fanboy
Rust is not as complicated as the opening graphic indicates. I usually see this meme from less experienced people but I'm frankly surprised to see it from somebody that's capable of writing a compiler <i>in rust</i>.