Hacker News Reader

> what makes someone go such a great length to bash ...

"""

Inherent complexity does not go away if you close your eyes.

When you choose not to care about complexity, you're merely pushing it onto other developers in your org, ops people, your customers, someone. Now they have to work around your assumptions to make sure everything keeps running smoothly.

And nowadays, I'm often that someone, and I'm tired of it.

"""

> [Go] works brilliantly for the projects I've encountered.

Of course, C, C++, PHP and JavaScript works too! Of course many many many things "work" in our world. Of course just adding one more lane works too, of course police states work too!

Yet something else would work even more brilliantly?

That quote sounds like an argument against Rust, not GO. Rust is a complex language and that complexity doesn't go away if you close your eyes to it either. All complexity adds to project complexity.

The implicit argument is that there's some irreducible non-negotiable project complexity in real-world software, and the explicit argument in the post is that you can either put it into the language/compiler or keep it in wetware.

The supporting argument in the text is that even simple things like downloading a file can get hairy very fast. Networks are complex, HTTP, IPv4/v6, DNS - it's always DNS! - filesystems, permissions, running out of space, computer runs out of battery, etc.

Probably a better argument would be to focus only on application logic (type system, error handling, syntactic-semantic ergonomics) and show that a complex piece of Go [like the k8s persistent volume controller] can be written in a nicer, more maintainable, safer way in Rust.

Of course not all Go code achieves Kubernetes-level complexity. And I think it makes sense to pick the right tool for the job, which is whatever the team/programmer is productive with. (And here productivity is measured based on how well the resulting code/software solves the business case. And basically if there's no need for Rust-level safety/quality/maintainability, or if there's an explicit need for Go-level cheaper hackability, then that's a great result business-wise.)

The important corollary of this is that business requirements tend to change, yet software has inertia and that's roughly how we ended up with insert famously bad software that got wildly popular unexpectedly (for example Windows, Macromedia/Adobe Flash and the infamous plugin, random low-level crap in appliances, and adjacent to that the Bluetooth stack that got rewritten in Rust for Android).

So - of course - for society it would be amazing if software would be better from the start. (Duh!)

Also, one more thing I think worth mentioning, is that the argument about the lack of information in code at callsites in Go (is something passed by reference or by value), how hard it is to keep boundaries (immutability) is basically an argument for making this complexity up-front and visible. Hence Rust looks complex. (And again, the argument is that it's there even if Go hides it.)

https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html

https://github.com/kubernetes/kubernetes/blob/60c4c2b2521fb4...

It's just some person's blog and they're having a rant. It's okay, it doesn't have to be that deep.

I would guess the 'why' is because OP feels like they have an opinion that they don't feel is sufficiently represented 'out there'. Indeed, as a not-a-fan-of-go, in 2022 I was confused at go's popularity because it always felt to me to have some pretty glaring shortcomings that were seemingly ignored.

Note that people don't really write big blog posts about PHP being a bad language (anymore?) because that's been done to death.

Speaking a someone who has written Go full time since 2014:

Go is used in a lot of places for unglamorous things where the most important thing is explicitness, and where all these features that the PL nerds want, do nothing but make things more implicit.

It's not perfect, but it's a great language. People who like it, though, like me, are pragmatists. The shortcomings of the language that are apparent in complex code are strengths when writing the simple straightforward code that makes up most Go projects, because all of THAT becomes much simpler than it would be in a fancier language.

The reason I've never bothered to write a response to these kinds of screeds against Go is that usually I'm too busy getting shit done with it.

Perhaps not everyone likes boring clinical reviews and some people like ones that have a bit of passion and humour in them?

Just because this blog post isn't written in a way you like doesn't mean it doesn't have value to others.

One very subjective, very irrational factor for my borderline hate for Go is that for years the Go zealots gaslighted everyone about every single part of Go.

Anything that Go did, no matter if it was the most basic implementation or if other languages already did it (better), was essential, the best and only way to solve that issue.

Anything Go did not do was superfluous and downright a conspiracy by Big Complexity to keep us unenlightened Non-Goers addicted to the Syntax Sugar: Things like sane null handling, sane error handling, less boilerplate, generics, or not creating special cases for everything (generics and tuples) instead of developing one cohesive solution.

Even now, in this thread, the strawmanning continues: Error handling is brought up, and instead of admitting the unmistakable truth that Gos error handling could be much better (s. Rust), people bring up things like JavaScript. As if anyone criticizing Go that JavaScript was the pinnacle of error handling.

Yes, I've also grown tired of this toxic mindset, as well as the whole "idiomatic Go" dogma that is very often an excuse for poor engineering practices.

“Worse is better” has become a justification for pushing out complete garbage instead of the warning against perfectionism it was originally intended as.

Yeah, this was/is a part big part of my frustration with the ecosystem too. It set a LOT of very problematic patterns in place in the beginning, and many of them are still not unwound.

Stuff like "Go doesn't need dependency injection because it's simple". I heard that literally dozens of times. The opposite is true! It's an even bigger pain without DI because the language is so simple! DI everything or make your users suffer!

Or a personal favorite: "Go doesn't need a package manager". We see where that went, and how much insanely better it is now that we have it.

Or errors. Without wrapping. Oh boy we're gonna pay for that for decades.

There's stuff to like in the language, but the zealots (especially early ones) really did not know which parts they were.

Dear christ yes.

“Go is designed as a systems programming language” has been retconned so that “systems” is redefined to mean programs talking over a network?

“Real programs won’t use repetitive error handling, but build on top of it.” I don’t think this one needs further explanation.

“Go doesn’t need xyz.” This is just the slow and painful process of the golang community realizing one at a time why other languages have the features they do.

“Explicit is good.” Explicit and verbose are not the same thing. You can have explicit and terse.

“Golang is simple.” Golang is primitive, not simple. There are tons of footguns and gotchas, not all of which are chronicled in the linked essay, which would have been so easy to avoid. And everyone just collectively internalizes these issues as if “just avoid writing those bugs” is a sane mindset any different than the languages that came before.

“Go doesn’t need a package managers.” Oops, it did. Now we’re like three attempts deep.

Over and over and over I feel like we’ve been gaslit and told we’re crazy, only to later on have the community act like (for example) golang always intended to add generics and of course they’re a good idea.

Bjarne said it best; There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Yet somehow his language meets both criteria somewhat and is only saved by legacy code. Not to say that C++20 or above is not good, I personally think it's one of the best but sadly not every org can afford to upgrade easily.