←back to thread

Go is still not good

(blog.habets.se)
644 points ustad | 2 comments | 22 Aug 25 09:25 UTC | HN request time: 0.434s | source
Show context
827a ◴[22 Aug 25 16:12 UTC] No.44986330[source]▶
Recently I was in a meeting where we were considering adopting Go more widely for our backend services, but a couple of the architect level guys brought up the two-types-of-nil issue and ultimately shot it down. I feel like they were being a little dramatic about it, but it is startling to me that its 2025 and the team still has not fixed it. If the only thing you value in language design is never breaking existing code, even if by any definition that existing code is already broken, eventually the only thing using your language will be existing code.
replies(3): >>44986569 #>>44986646 #>>44990658 #
1. dehrmann ◴[22 Aug 25 16:40 UTC] No.44986646[source]▶
Architect-level is complaining about language quirks? That's low on my priorities for languages. I'd worry more about maturity, tooling support, library support, ease of learning, and availability of developers.
replies(1): >>44986894 #
2. 827a ◴[22 Aug 25 16:59 UTC] No.44986894[source]▶
I think our end-state decision, IIRC, was to just expand our usage of TypeScript; which also has Golang beat on all those verticals you list. More mature, way better tooling, way more libraries, easier to hire for, etc.

Though, thinking back, someone should have brought up TypeScript's at least three different ways to represent nil (undefined, null, NaN, a few others). Its at least a little better in TS, because unlike in Go the type-checker doesn't actively lie to you about how many different states of undefined you might be dealing with.