I believe even the language's own designers would agree with that sentiment. There's just generally a lot of things about Go that are great for low-level microservices but not great for 1M+ line of code business applications maintained by large teams.

I can't speak for others, but personally if I'm writing software with complex business logic, I'd want null safety, better error handling, a richer type system, easier testing/mocking... I've also never liked that a panic in one goroutine crashes the whole application (you can recover if it's your own code, sure, but not if it happened in a goroutine launched by some library).

I'd disagree with most of that, but the panic in goroutines really hits home. It's so annoying to remember implementing recover in every goroutine started to avoid crashing your application. I don't get why there's no global recover option that can recover from panic's in goroutines as well.

Goroutines are expected to communicate on channels. If one goroutine simply vanishes, then its counterparties on any channels will deadlock - either waiting for messages that never come, or trying to send messages to it after channel buffers fill up.

Crash is significantly easier to detect and understand than deadlock.

Too low level and lacks the power to cleanly model the business domain.

"Too low level" "lacks the power" - I don't understand what this means. What are things that are hard to do in Go business applications that other languages do better?

Here is an example. Go let’s structs be passed by value or by reference. The programmer needs to decide, and that adds complexity that is largely irrelevant for modeling complex business logic. Java does not provide a choice, which keeps it simple.

Simple, but with an inherent performance issue and GC load; note also that Java's Valhalla project adds value types with more stack based semantics, so there too you as a developer get a choice.

It lacks modeling capability that you'd find even in languages like Java and C#. Enums, records, pattern matching, switch expressions, and yes even inheritance where it makes sense.

> What are things that are hard to do in Go business applications that other languages do better?

Streams, meta-programming, enums, ‶modern″ switches, generators, portable types in CGo, streamlined error handling, safer concurrency primitives, nil, partial struct initialization, ...

Lacks expressivity is likely what parent meant.

Go has pretty powerful composition, reuse, higher-order functions etc. for dealing with byte arrays and streams. Not so much for business domain entities.