I think it's exactly that, it works and that's fine, and why the JVM doesn't do cheap concurrency I don't know. If it did Java might have been the new Java :-)
Thanks for the article with your first impressions of Go anyway - I read another post on your blog while visiting (about leaving C++ for a simpler OO C), and it actually echoes a lot of the motivations of Rob Pike and others at Google in creating Go - frustration at C++ compile times and baroque grammar was a primary factor in the creation of Go, so it feels to me like they went back to C as a basis and built something new...
> What does Go have that C++ lacks? Mandatory garbage collection, memory safety, reflection, faster build times, modest runtime overhead.
> If on the other hand most code in most websites matters a lot for performance, then maybe you want Go
Specifically, seeing only the features (performance) and not the intent in Go. I should have said "misses the point in why Go can be more interesting than other languages".
Now, as you said, if your requirements can't be fullfilled by Go (or any blub), then it's not worth switching.
> If it did Java might have been the new Java :-)
I don't think people avoid Java because of the lack of light concurrency (there are multiple production-ready libraries to do that). I think people avoid it because of Java-the-platform... so Java would have stayed the bloated Java :-)
Please show how he misses the point. His point, it seems to me, is "Things _he_ would miss in Go that Python has". Maybe he doesn't want to write maintainable "softwares" (sic). Maybe his bugs look like open_file();close_file(); read_file(). Static typing can't catch that.
- Automatic memory management -> GC
- Bug catching before the software is run -> Static typing
- Overall simplicity -> few features, added only if it is extremely needed
The thing is, when you start using Go, you already know its features. There is nothing particularly new, and it all fits in your head. It is a bit strict though, so there is some boilerplate (error checking, sort.Sort, ...) but that's going to save you when you edit your software in 5 years.
Here, performance (both compilation and running) is a byproduct of simplicity.
Now, I'm not saying the OP's use cases are invalid, far from it; they're just not what was intended in the process of creating Go. Like OP, I tend to think that Go is the new Java: "boring" (ie no revolutionary features) but it just works for server-side softwares.