Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Go programmer attitude is "do what I said, and trust that I read the library docs before I said it".

I agree and think Go gets unjustly blamed for some things: most of the foot guns people say Go has are clearly laid out in the spec/documentation. Are these surprising behaviors or did you just not read?

Getting a compiler and just typing away is not a great way of going about learning things if that compiler is not as strict.





It's not unjust to blame the tool if it behaves contrary to well established expectation, even if that's documented - it's just poor ergonomics then.

Outside very simple programming techniques there is no such thing as well-established when it comes to PL. If one learns more than a handful of languages they’ll see multiple ways of doing the same thing.

As an example all three of the languages in the article have different error handling techniques, none of which are actually the most popular choice.

Built in data structures in particular, each language does them slightly differently to there’s no escaping learning their peculiarities.


ironically with zig most of the things that violate expectations are keywords. so you run head first into a whole ton of them when you first start (but at least it doesn't compile) and then it you have a very solid mental model of whats going on.

“Clearly it’s your fault for not realising that we embedded razor blades in our hammers! What did you think, that you could safely pick up a tool?”

Another example is the (very recently fixed) documented but unobvious and unenforceable requirements for calling Timer.Reset() [0].

[0] https://pkg.go.dev/time@go1.22.12#Timer.Reset




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: