I think that's harsh. IME Go excels in a business setting where the focus is on correct, performant, maintainable, business logic in larger organizations, that's easy to integrate with a bunch of other systems. You can't squeeze every last bit of low-level performance out of it but you can get ... 9x% of the way there with concurrent code that is easy to reason about.

What matters is being 100x faster than python, not 5x slower than C++ or 2x slower than Java. Performant enough that IO (or network) rather than CPU is the bottleneck (in my limited experience).

Personally I just far prefer to work in a GCed langauge. Much simpler mental model.

> correct, performant, maintainable, business logic

That's the requirement for 100% if professional software development.

Yikes, language flamebait in 2025?

Flamebait? It's literally what the designers of Golang said publicly about the background of prospective developers, and how that constrained the language design:

"The key point here is our programmers are Googlers, they’re not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

Nowhere in this quote are these fresh grads equated to "lousy programmers", though (which the flamebaity comment did).

And interpreting the quote charitably I'm going to have to agree with it - I don't think many of my coworkers care enough to get to the point where they'd appreciate everything something like Haskell can do for them.

Have you ever worked with fresh grads? They're definitionally lousy programmers, if we take lousy mean "having a propensity to inject bugs into programs".

The more time you spend in software engineering the more you realize that this is actually brilliant and helpful, not bad. And IME, the more expressivity I have fluently at my disposal, the more complexity I tend to create. I’m not saying I don’t enjoy more complex languages, but reducing cognitive load and easing collaboration with more junior engineers are easily the best features of Go, hands down (although I can’t say the new generics necessarily always help with that).

That's one interpretation but I think Pike was using a sarcastic meaning for brilliant. I think he's saying that he wants to mentor people to become programmers, not to learn a difficult, sublime language. It's like when a top scientist tells you they're not smart enough to understand what's going on in some part of his field. It's not necessarily a compliment.

Feel free to listen to the context at https://learn.microsoft.com/en-us/shows/lang-next-2014/from-... around 20:40 to 21:10. It's pretty clear that it's a serious quote and not "sarcastic" at all. Least of all about research languages since Pike mentions CSP at length and how to make concurrency be not "scary" to prospective users - overall, it seems that he's talking about a real constraint he's facing. In the same talk he's even apologetic for not preventing data races in the language, since it would have involved too much complexity.

I don’t like writing golang, but I sure like reading it. It’s nearly impossible not to understand.

Serious being what?

Most programmers are "lousy programmers" because most of the are not researchers and have no interest in theory.

I can write in Go or Rust (or anything else given some time) but I won't ever use Rust to write any kind of business logic for my company - and this is what I do most of the time I actually write code.

Why? Because Rust is terrible for the job (at least if we are talking about real life scenario where the job should be done in hours and not weeks)

I can do business logic, like complex CRUD, in Rust much faster than in other languages. I assume, «lousy programmers» have problems with separation of concerns, which then cause problems with borrow checker, because developers need to perform different things in different ways on different parts of data structures (AKA «god object» anti-pattern).

> separation of concerns

but this would be a problem almost anywhere, no?

This has nothing to do with Rust vs Go vs Ruby or something else. Rust makes this even bigger problem, ok, but I don't think we should call people not using Rust (c\c++ etc) "lousy".

PS: tbh this kind of statements usually (from my experience) come from people who mainly write system level software or work with hardware directly.

There are a lot of those for sure. There are far more in Python and Java. Any popular, simple-enough language will attract a horde of jobseeking mouthbreathers, that’s kind of inevitable and normal really.