Hacker News new | ask | show | jobs
by phillipcarter 1342 days ago
> IMO, while Go is nice from a minimalism and resource utilization standpoint, it's simply not fun to write after using much more expressive languages.

It's definitely a blessing and a curse. What I think I'd say about Go is that it's a simple "day 1" language and a complicated "day 2" language. Speaking strictly from an expressivity and language semantics standpoint, as its runtime and standard toolset are simply great, it's just filled with so many head scratchers when you dig into what's going on and why.

Like the go modules import compatibility rules forcing you to create new vX versions of modules. It's not that it's unsound, it's just unlike everything else out there, and so you can't take your knowledge from other packages managers and apply them to Go. Maybe that expands the mind a bit, but in my experience it just confuses teams and forces them to sometimes go back and revert a major version bump because it's easier to just do that.
1 comments
bern4444 1341 days ago
> What I think I'd say about Go is that it's a simple "day 1" language and a complicated "day 2" language.

This resonates. I very much dislike Go's error handling model. Its overly simple and leads to exorbitant

    if err != nil
checks all over the place. It clutters the actual business code and remains a clunky, leaky abstraction.

I think Go is a language designed for engineers who don't care to learn about more elegant solutions that come with more intricate semantics (Option, Either, Try etc).

It's get the job done inspiration is sloppy and poorly conceived.

link
mikedelago 1341 days ago
The big thing too, with the `if err != nil` pattern is that it's _good_ Go practice to do that, but it doesn't feel good to constantly be spamming a 3 line error check on every single statement.

I really don't like hopping into a codebase and seeing a 27-line function (uncommented, of course) with 21 of the lines being `if err != nil` checks

link
bern4444 1340 days ago
Plus go code seems to embrace as short of a name for variables as possible.

Have a parameter for an array of users? Call it ‘u’. Want to have a variable for a config object? Obviously call it ‘c’.

‘Idiomatic’ go code is bad code.

link