There are only a handful of things that keep me coming back to Go: fast & simple deployment, good tooling and dependency management, and an excellent stdlib and IO/async abstractions.

Those are all the places I spend all my time in other languages. I really don't care about most of the stuff people complain about that they claim is important (like boilerplate/LoC/error-checking, generics, fancy abstractions, etc.). But doing concurrent stream processing with a mix of IO and CPU blocking in most languages is a freaking nightmare compared to Go.

The one Achilles' heel IMO is not any of the nitpicky type/syntax stuff, it's CGo. That's the one place where I'm always worried that a decision to use Go is going to screw my life up.

Mad LoCs, dude, gotta make alotta lines, that’s what productivity is!

> I see even experienced Go programmers constantly wasting time writing unreadable boilerplate

if it is unreadable, in Go, probably the most readable language used today, i would question the aforementioned experience.

What you're doing right now is called "coping".

I don't think a language where for every 1 line of functionality, you need 3 lines of error handling boilerplate gets to be called readable.

Heck, Go went out of it's way to "subvert expectations" more than the last season of Game of Thrones.

99% of decent C-ish languages either do "String thing" or "thing: String", but Go is so fancy and quirky, it does "thing String" for no freaking reason. Don't get me started on the nightmare that is map types.

I like Go's error handling. The reader knows exactly which lines of code can encounter an error, and exactly how the error is handled.

I find that exception-based code is much harder to read. The happy path is clearer, but exceptional code paths are often completely obscured. It's harder to reason about what state the program is in when the exception is handled.

Exceptions have been a mistake, the alternative are Result types, a concept which predates go.

Go doesn't force you to either handle or propagate the error.

And the alternatives are not exceptions, of course, but ADTs.

> Other than fast compiles and easy binary distribution, I don't see any value here, and I see even experienced Go programmers constantly wasting time writing unreadable boilerplate to work around the bad language design. I know I must be missing something because some people much smarter than me like this language, but... what is it?

If you "other than" two huge-for-many-use-cases good things, sure, it might look bad. ;)

But I would add good overall performance and in particular straightforward flexible concurrency support to the list of good things.

And IMO once you're in the set of "things with good perf" there's generally a lot of "boilerplate" of one sort or another anyway.

Yeah that's fair. In terms of "things with good perf" I'd rather be writing C++ or Rust, but there are significant issues with using either of those on a large team.

I'm more comparing it against languages like Kotlin and Swift, or even Scala.

It might be nit picking, but that's more the ecosystem or tooling that's great. The language is mediocre, but it's what everyone gushes about.

I still remember people gaslighting everyone that any feature Go had was ESSENTIAL, and every feature Go didn't have was USELESS or too complicated for mere mortals "delivering value".

And the fast compiles at least are in big parts because the language is so horrendously basic. Can't get hung up on checking type constraints if you barely have any.

> I still remember people gaslighting everyone that any feature Go had was ESSENTIAL, and every feature Go didn't have was USELESS or too complicated for mere mortals "delivering value".

I'd say this is still the norm in discourse around Go, it's just that the goalposts have moved somewhat since it has more features now.

I'm in a similar boat to sbrother (GP) and some of the other sibling commenters: like GP, I don't love the language (honestly, "patronizing" is the word that feels most accurate to describe working in Go for me, if a programming language can even be patronizing); like others, I have been impressed with how well it works when programming in its niche (high-performance network proxies).

I'd add what I think is perhaps its most significant benefit to the list: Go fully solved the function coloring I/O problem in a way few other languages (Erlang/Elixir and ... Bend? Others?) have.

That's adjacent to the concurrency benefits in the parent comment, but a little different: allowing procedural, non-colored code to be efficiently concurrent over I/O without introducing function coloring or requiring people to code specifically to an event loop/IO multiplexer in some other way requires good concurrency support in the language, to be sure. However, getting rid of function coloring while providing efficient concurrent IO also requires: a solid stdlib of IO capabilities; a very very good runtime that can coalesce goroutine-concurrent IO into multiplexing OS primitives in the same way a function-colored event loop would (while pre-empting/scheduling in a reasonable way that mitigates unexpected blocking); a strong "critical mass" of libraries to talk to common IO-ful systems; a strong community convention of "we will generally prefer reimplementing IO drivers in Go rather than binding/Cgo-ing in foreign code".

It's when you combine all of those that Go shines as a platform for concurrent (usually network) IO.

I felt the same way initially, but the language has grown on me. The turning point was writing a lot of Go, like full-time project work for a few months.

But as I've gotten older, I've started striving more and more for simplicity above all else, especially in systems design (disclaimer: I'm an SRE). Go is pretty good at being simple.

There are some things that still annoy me a whole bunch, though. Like - just one example - `fmt.Errorf` not being a first-class syntactic construct (or the difference between `%v` and `%w` in `fmt.Errorf`).

I frequently hear that Go is simple, and I generally take that to mean that it doesn't have a whole lot of features. But doesn't this then force the complexity on the programmer? There is a set amount of complexity in the world, and either your language models it or you model it, but something has to model it for your program to be a faithful representation of the problem in question. It seems that Go has shunted much of that complexity onto the programmer. This article does a good job of summarizing (and indeed helped to shape) my thoughts on the matter: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...