Lies we tell ourselves to keep using Golang (2022)

The article is great. The bigger picture, of course, is that it’s always “pick your poison”.

On one hand, say, I love operator overloading, I love how Python does it (once you satisfy an interface, its operators Just Work).

On the other hand, I can appreciate the choice not to do it at all because half of the ecosystem will do it, and another half won’t. Also, it would require implementing function overloading, and it is a can of worms.

Or generics and rich type systems, which all come with their own tradeoffs. I hear that Rust cajoles you into tinkering with the type system, and wach tweak requires refactoring of more codebase than anyone would like (don’t take my word for it, it’s just what I heard from a few different sources). I know that Nim is so expressive that it can be annoyingly trivial to be too clever and run into a valid edge case that will make the compiler barf and die. Go sidesteps the issue by not wading into that territory, and that may be perfectly okay, albeit verbose.

It’s always picking your poison, so I guess check your tolerances and allergies so it doesn’t kill you before you get the job done…

> I've mentioned "leaving struct fields uninitialized". This happens easily when you make a code change from something like this:

Really? Are you not using gopls? It absolutely will warn you about this. And the mutex case. And a lot of the other similar criticisms.

> Go not letting you do operator overloading, harkening back to the Java days where a == b isn't the same as a.equals(b)

In languages that have it I've never used operator overloading to produce anything good or that was obviously better than just using methods.

> The Go toolchain does not use the assembly language everyone else knows about.

Honestly I've never noticed or had to care. And you can build plenty of things that don't require CGO.

The whole "gnostic" tone in language articles on HN is becoming overbearing. There are parts of the language to criticize but couching it in this "lies _we_ tell ourselves" and somewhat kitchy writing that presents minor matters of taste as fully existential issues makes this an unsatisfying read.

I think this is exactly the right way to understand Go - it's targetted at building servers in environments where having strong consistency of code and a short ramp up time for junior engineers is valuable - i.e. it's perfect for all the big corp scenarios that Java was used for.

I think maybe the more common, but less helpful comparison of go vs rust comes from the fact that they are both part of a new wave of languages and that they both default to producing staticly linked binaries.

Seems like Zig is actually meeting much of the writer's expectations for good language design. Although I'm still not wholly convinced by it's move from LLVM and hell-bent desire for incremental compilation.

I liked the idea of a language with minimal syntax that is easy to learn and easy to understand because the code is forced to be straightforward. It didn't work out that way to me in practice.

It's a bit too low level for many use cases in my opinion, and that does get in the way somewhat. It also works against the "easy to learn" part unless you start with developers familiar with low level programming.

I also found some types of library code surprisingly difficult to read, especially when empty interfaces where used.

The standard library was great though, it covered stuff that others don't and it just worked out of the box.