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).
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.
I think I'm in love.
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:
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.
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.
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.
Like building out of clay and firing the parts you are happy with.
Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque.
tbrockman ·20 days ago
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 (https://borgo-lang.github.io/#methods), the new syntax for channels and goroutines (https://borgo-lang.github.io/#channels), and the `zeroValue()` built-in (https://borgo-lang.github.io/#zero-values-and-nil) seem a bit out of place. Overall though, if I had a choice, I would still rather write Borgo by the looks of it.
Show replies
lordofgibbons ·20 days ago
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.
I think I'm in love.
Edit: Looks like last commit was 7 months ago. Was this abandoned, or considered feature complete? I hope it's not abandoned!
Show replies
Hasnep ·20 days ago
- braid: https://github.com/joshsharp/braid
- have: https://github.com/vrok/have
- oden: https://oden-lang.github.io/
Show replies
throwaway17_17 ·20 days ago
Show replies
ralegh ·20 days ago
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.
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.
Like building out of clay and firing the parts you are happy with.
Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque.
Show replies