4 ms·
Agreed 100%. Go doesn't have a standard library problem, it has a userland language problem. * No sum types / algebraic data types in 2022. * No exhaustive p
by throwaway234566 4y ago
Agreed 100%.
Go doesn't have a standard library problem, it has a userland language problem.
* No sum types / algebraic data types in 2022.
* No exhaustive pattern matching in 2022
* No move semantics / Uses GC
* No borrow checker
* Still suffers from nil problem / No type-safe nil / No type-safe Optionals in 2022 -- (I can show you all the nil panics in kubernetes logs if you like)
Current go users are already sold so they don't expect more, and that's fine, but further evangelism will require a better host language.
- foldr 4y agoSeems a bit odd to criticize Go for using GC rather than a borrow checker to manage memory. There’s surely a place for GCed languages, even if they’re not the right choice for every domain.
- Thaxll 4y agoAnd yet Go has delivered very useful software used by millions of people.
- lijogdfljk 4y agoSo has C, and most other popular languages. Doesn't mean they don't have issues, often dangerous issues.
- throwaway894345 4y agoI don’t mind GC. I think it’s the right choice for the sort of applications Go targets. I wish it had algebraic data types (with exhaustive pattern matching), but the “in 2022” meme is just vapid snark. Notably, despite its shortcomings, Go is still perhaps the most productive programming language for general purpose applications. It turns out that type system features are neat, but tooling, ecosystem, simplicity, etc outrank type system features by quite a lot. Rust does very well here too, but it’s choice of borrow checker over GC amounts to trading off a lot of productivity in the general case (but it makes sense for Rust’s goals!).