This is quite beautiful. It hides several ugly warts of Go without necessarily adding more complexity. Result<T> instead of (T, error) and ? for propagation is just so nice. Structured enums is something I find myself needing all the time (and writing less self-explanatory code due to the lack of it). Option<T> instead of nil and zero values (which builds upon structured enum support) is what got me to say "yes please!"
Honestly, some of the things they changed are maybe unnecessary (like the additional impl syntax, the Zig influenced dereferencing, return values from statements, several other Rustisms, etc). One part of me wish Go would get all of this. But another part of me knows it would never happen because this is not a superset (Python 2 -> Python 3 anyone?)
I also wonder if this could even be compared to JavaScript / TypeScript for the same reason, not being a superset means you have to actively make a change to even start to migrate, and the revert path is not as trivial.
Zig is not a superset of C, and Rust is not a superset of C++; does this hinder their adoption a lot
Also, the pain of Python 2 -> 3 migration was that you can't mix py2 and py3 code in one project. This is not the case with Borgo apparently: you can mix it with Go, much like you can mix C++ / Zig / Rust with C, or TS with JS, or even Kotlin with Java.
By having excellent interoperability, Borgo may have a good chance of wider adoption. If I were its maintainer, I'd prioritize interoperability with plain Go and its stdlib highly.
There are various syntax changes, such as let. Of course, if Borgo could be modified to not have let, but that would be a backward incompatible change.
That would be cool; although I don't think that being a superset would be that useful.
I think just being able to use borgo and go files in the same project is more than enough for all practical purposes. Borgo and go living in the same file, or go files running as borgo files would be cool, but would have no practical benefits?
Honestly, some of the things they changed are maybe unnecessary (like the additional impl syntax, the Zig influenced dereferencing, return values from statements, several other Rustisms, etc). One part of me wish Go would get all of this. But another part of me knows it would never happen because this is not a superset (Python 2 -> Python 3 anyone?)
I also wonder if this could even be compared to JavaScript / TypeScript for the same reason, not being a superset means you have to actively make a change to even start to migrate, and the revert path is not as trivial.