I think the author misses the point. The number one reason Go was created was to build maintainable softwares, the kind Google uses at large. The easiest way to build these are:
- 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.
Why do I miss the point if, like me, you think Go is the new Java? :-)
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 :-)
> 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 :-)
Concurrency is not the only interesting thing about go. The other choices are also interesting, partly in what they leave out (no inheritance, no headers, explicit errors, implicit interfaces, static binaries with no dependencies, fast compilation, strict style enforced by gofmt). You might not like those choices of course, and you might prefer to use other languages like python or C++ ;), but comparing Go to Java + concurrency is pretty absurd, as the culture, tools and standard library are very different. Maybe superficially some of the syntax looks similar, because of the C heritage.
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...
> I think the author misses the point. The number one reason Go was created was to build maintainable softwares, the kind Google uses at large. The easiest way to build these are:
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.