undefined | Better HN

0 pointsthrowaway2345663y ago0 comments

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.

0 comments

4 comments · 3 top-level

Thaxll3y ago· 1 in thread

And yet Go has delivered very useful software used by millions of people.

lijogdfljk3y ago

So has C, and most other popular languages. Doesn't mean they don't have issues, often dangerous issues.

foldr3y ago

Seems 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.

throwaway8943453y ago

I 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!).

j / k navigate · click thread line to collapse