Maybe I'll wake up tomorrow and the light will shine down on me and I'll understand. But from where I'm sitting right now, the lesson go has for us is:
> Look around, the hell you see... that's about as good as it gets. There's no point in trying to find a better way, so here's the best way to not bother trying.
The author seems to think that the aspirations of more interesting languages are vanities of some sort. Like they're saying "look at me I'm <buzzword>!". But if you study the way people from different language communities behave... it would seem that whatever the buzzword is, it's actually having a significant affect on how they think and how much they enjoy coding. I don't know why you'd withdraw from that.
I’m waiting for it to click but nothing yet. Channels in combination with effortless (uncolored) asynchrony are maybe it. I haven’t reached that point yet though as I’m still struggling with just expressing my domain, without having invalid and primitive values, constructed and passed around by design, all over. I suppose it is not possible. Every time I see “url string” in a function or struct I die a little inside.
But it puts me in this mode where I occasionally want to write a function which doesn't return an err, and I think it ought to be doable, because I've declared a type for this string and I happen to know it's only one of three values, but then the lack of enums means that the type checker doesn't know that it's one of those three values so I've got all this extra runtime code for checking against error cases which could've been caught at compile time.
I think you're right that the concurrency story is the key to making it feel real: go routines, channels, etc. I haven't had occasion to use those things yet though, so it's pretty bland so far. When I hear people talk about them though it seems like they'd be better served by Erlang and have just settled for Go because it's popular.
It was a reskin of Limbo, which they had released at Bell Labs without a lot of traction.
> Most new languages never overcome basic performance issues.
Poor performance is a problem with an implementation. Poor expressiveness is a problem with the grammar and semantics of every implementation, especially when you don't let end users extend the language to their needs.
