Your big application shouldn't be that big first?

So you're saying we shouldn't have operating systems, browsers, video games and all that good stuff?

Most actual engineering is very far from writing a dumb server for yet another CRUD app :)

What I'm saying is Golang is a recent programming language so it works best when used for multi tier/services, not to create a giant monolithic Java app that has a huge number of loc.

What does Java have to do with big monolithic apps? I think you're confusing complex application domains with bloat.

Go is supposed to be a systems programming language. That means a very, very wide range of possible domains, where for many of them even network latency is unacceptable. For example, Photoshop would have a terrible user experience if it wasn't the monolith it is. A game engine wouldn't go above ~20FPS (even 60FPS games have a network loop that is capped around 20FPS).

If I can't do systems-level programming in Go, what's its advantage over real systems languages or higher-level languages then? Especially when you consider what Go offers (CSP) comes in opt-in libraries in many other languages.

I feel like Go should be put in the same category as C# and Java. They're just above systems languages but just below scripting languages; giving you the worst of both worlds. Not bare-metal, but also not that productive.

Java does run bare metal and there are commercial JDKs with real-time GCs.

PTC is one such those vendors,

http://www.ptc.com/developer-tools/perc

Go might eventually be used in such scenarios, but the toolchain is not yet there.

That depends on business needs, not what some programming language designer thinks.