Live data from Hacker News

I Want Off Mr. Golang's Wild Ride (2022)

fasterthanli.me

1–10 of 41 posts

Re: I Want Off Mr. Golang's Wild Ride (2022)

#4
I have created and maintain a 130k SLOC Go codebase over the last four years or so, and there are a number of things about Go that irritate the shit out of me. I still get bitten by taking the address of a loop temporary on a surprising basis, for example, even though I am acutely aware of the issue. Or, I haven't really found any use for generics yet, because (as best I can tell) it's impossible to specialise and pretty much every potential use-case I have found for generics so far seems to boil down to lots of shared functions and a few specialised functions.

None of those real irritations are addressed in this article, which seems to be an extended complaint that Go isn't as portable between Linux and Windows as the author would like it to be. If you're unfamiliar with Go and attempting to evaluate the language, there's not much in here that I could recommend one way or the other. You would be better spending the time on doing the Tour of Go, then reading one of the various "pitfalls" articles.

Re: I Want Off Mr. Golang's Wild Ride (2022)

#8
Like all languages you can make a mess or make something wonderful. It's also really hard to remove your own bias from the project itself and the drama (or lackthereof). I happen to love go, honey moon started in 2016 and hasn't stopped for me yet. Today's commits: https://github.com/andrewarrow/settle-down/tree/main/app

Start at welcome_controller.go and follow the flow. Notice no structs for the sake of structs I make heavy use of map[string]any which serializes to json so nicely without any `json` modifiers.

Re: I Want Off Mr. Golang's Wild Ride (2022)

#9
The April 2022 update at the end of the article has a good short summary:

> If you're looking to reduce the whole discourse to "X vs Y", let it be "serde vs crossing your fingers and hoping user input is well-formed". It is one of the better reductions of the problem: it really is "specifying behavior that should be allowed (and rejecting everything else)" vs "manually checking that everything is fine in a thousand tiny steps", which inevitably results in missed combinations because the human brain is not designed to hold graphs that big.

My pet theory is that this corresponds to the "two cultures" of software engineering: do you value up-front work and abstraction to reduce cognitive load and debugging, or would you rather (try to) pay more attention and spend more time debugging to reduce how much you have to learn and think up-front? Go seems pretty firmly in the latter camp. That's exactly why I am not interested in the language either, despite the various things it gets right.

Post reply on HN