I hate presentations like this. First of all, they aren't particularly enlightening. Second of all, they make an already-weak point by using an even weaker method: anecdotal evidence. And third of all, most examples are cherry-picked out of a poisoned well.
It's hard to take anyone doing a talk like this seriously. Truth be told, (and for anyone that hasn't read my Go-related posts on here), I am a pretty harsh critic of Go (even though I contributed to the project). I used Go until 2011 when I decided to turn back to Java (which, in many ways, I think is still my go-to language -- along with an embedded Jetty -- when writing.. just about anything web-related). But my personal bias aside, it's brutally obvious that Node and Scala are at different programmatic levels when compared to Go. Go is, in many ways, the "next C" - especially with the recent architecture additions, the low-levelness of Go is starting to become painfully obvious. Comparing something like Scala (or worse: Node) to Go is, in a very literal way, like comparing apples to oranges.
So lets bust out the checklist. Language zealotry? Check. Comparing apples to oranges? Check. Anecdotal evidence? Check. Using cherry-picked examples to show how X sucks or Y is awesome? Check. Congratulations, you've got your linkbait.
Note how I don't even bother to attack any argument on a technical level; I think it would be profoundly foolish to do so. These three can simply not be compared on a technical level unless we want to do it in incredibly broad strokes (think about comparing a fighter jet with a stapler).
Yep, I'm not in love with Java, but it's turned out to be the language I'm using on a couple of larger projects. And you know what, I'm perfectly productive in it, even though its more verbose. For shorter scripts it is a pain compared to, say Python, and I miss having a REPL to experiment in. But I don't find that to affect productivity though for a larger project.
I just went back to Scala from Go for a personal project I've been working on, and I have to say I don't miss Go. I feel much more productive in Scala, and my code seems just solid that it ever did in Go.
To be specific, six things still bug me about Go.
Error handling: For goodness sake, the solution to error handling in Go is to go back to the C model? I hated how all my Go code was riddled with "if value, err := somefunction(); err != nil". After decades of software development, the best solution for Go seems to be to give up. Scala 2.10, on the other hand, added Try(), which is a beautiful solution for error handling without trashing your happy-path code.
Project management: I don't want to keep all my projects in a single repository. And I don't really trust the master branch of github.com projects to be stable, nor do I want to rely on the fact that I need to update my software right now because someone has changed the interface to their library. This may work for a walled garden like Google, but it strikes me as a bit dangerous long term for the rest of us. Maven, SBT and Gradle aren't perfect, but I like the fact that I have a little more control over my dependencies and build processes.
Concurrency: Go is great for local concurrency, but there doesn't seem to be a good distributed concurrency framework. And the way they've modeled local concurrency, there never will be. You can't use shared memory for distributed concurrency without some really big tricks. Scala + Akka is like the best of Erlang with the libraries of Java, and it can work locally or remotely.
SQL support: It's miserable in Go. No control over pooling (limited to 2 connections?), and the driver has weird restrictions. I think they've fixed it for the next release, but there was a problem where you could only have one prepared statement per connection. That sort of defeats the purpose of prepared statements. I don't think SQL is a big priority at Google, so the effort towards the drivers is nowhere near the Javaland support. I'm no Hibernate fan, but at least the JDBC drivers work extremely well for most databases.
Testing: I feel like the test framework for Go is weak. Maybe it's because not as much testing is required, but I still like to be thorough. For example, no setup and teardown functionality (you have roll your own per method). My test cases in ScalaTest are more far complete and consistent, with solid output and better support for CI.
Third-party libraries: This is somewhat akin to my complaint about SQL support, but the libraries for attaching to other services don't feel as stable in Go, and there are so few of them. I realize this is a short-term problem, but is there any way Go can catch up to Java at this point, particularly with so many companies behind many of these libraries?
How is comparing Scala and Node to Go comparing apples to oranges? My argument is that people are using the three languages to do things in the same space: building backend servers where concurrency, mostly in IO, is a major factor.
Based on the feedback I've received on the talk, I could and should make a better argument next time, and I welcome feedback on what I should be focused on. However, I think it's totally fair to compare the three languages because they're often used for the same purposes.
It's hard to take anyone doing a talk like this seriously. Truth be told, (and for anyone that hasn't read my Go-related posts on here), I am a pretty harsh critic of Go (even though I contributed to the project). I used Go until 2011 when I decided to turn back to Java (which, in many ways, I think is still my go-to language -- along with an embedded Jetty -- when writing.. just about anything web-related). But my personal bias aside, it's brutally obvious that Node and Scala are at different programmatic levels when compared to Go. Go is, in many ways, the "next C" - especially with the recent architecture additions, the low-levelness of Go is starting to become painfully obvious. Comparing something like Scala (or worse: Node) to Go is, in a very literal way, like comparing apples to oranges.
So lets bust out the checklist. Language zealotry? Check. Comparing apples to oranges? Check. Anecdotal evidence? Check. Using cherry-picked examples to show how X sucks or Y is awesome? Check. Congratulations, you've got your linkbait.
Note how I don't even bother to attack any argument on a technical level; I think it would be profoundly foolish to do so. These three can simply not be compared on a technical level unless we want to do it in incredibly broad strokes (think about comparing a fighter jet with a stapler).