
Why Node and Scala will dry up: Go will drink their milkshake - Supermighty
http://devslovebacon.com/conferences/bacon-2013/talks/why-node-and-scala-will-dry-up-go-will-drink-their-milkshake
======
dvt
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).

~~~
pico303
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?

------
mseepgood
I'm a fan of Go, but this is not a very good talk. The first half is
unnecessary trolling, and the second half is based on some code snippets taken
from Rob Pike's "Go Concurrency Patterns", but in this case badly presented.
So I prefer the original: <http://www.youtube.com/watch?v=f6kdp27TYZs>

~~~
pauldix
Fair enough. Better I just focus on the good of Go in the future.

------
VLM
It appears to be a video and I don't do those. I can read about 2 to 5 times
faster than most people make a presentation, I find it annoyingly slow so I
don't watch them. Can anyone summarize solely the facts of the matter and skip
all the milkshake stuff?

~~~
realrocker
He accepts that the milkshake thing was just to get people to come. "Link
Bait". He is also out of his depth during the whole video. Wasted 15 minutes
on it.

------
QEDturtles
The Scala critique could have been titled "Awesome Things about Scala that I
don't Understand Yet"

------
guard-of-terra
Front-end guys (and gals) happily write their middle layer in Node on server.

They won't touch Go with a ten meter pole, so no. Go won't cause Node to dry
up.

~~~
threeseed
I could easily see Node persisting for years to come solely based on the "run
Javascript on client or server" feature. It is pretty compelling and for new
developers why wouldn't you just learn Javascript and skip the server-side
languages.

~~~
Silhouette
If running JavaScript both in-browser and via Node on the server let you write
a distributed application and automatically handled things like marshalling
the data to get from one side to the other, that would be a strong point in
its favour.

As it is, I'm not so sure. Developers having familiarity with JavaScript and
being able to work on both sides is still obviously an advantage, but I
suspect for most projects it's balanced by JavaScript actually being a fairly
nasty language to work with.

I've never found any truly compelling reason to use JavaScript, except for "if
you're writing front-end code for a web app then it's what you've got" (which
is obviously not strictly true, but is close enough for most practical
purposes). That argument doesn't apply on the server-side, though, so I'm not
sure what is going to sustain Node as dedicated server-side languages evolve
or new ones appear over time.

~~~
dccoolgai
Personally, I don't find JS to be a "nasty" language... I think it gets that
reputation because some of the constructs take a while to wrap your head
around (function scoping, closures, 'this', functions as first class objects
and all of callbacks/event-emitter/-type patterns that come along with it.),
but the nice thing is, you can do a lot in JS without coming near those (think
jQuery)... and later, when you get sufficiently advanced, you learn that the
things you thought were ugly, are actually what makes it beautiful and
powerful. - JHMO

------
exabrial
This link and the comments here make me smile.

BTW, COBOL is faster than every single language mentioned here. And it's more
readable. Fact.

------
hythloday
"The idiomatic way in Scala to work with an Option is to call map on it, so
you're treating it as though it's a collection...which it's not...which is
completely weird"

Except that it _is_ a collection, of exactly zero or one elements. I find it
pretty disturbing that someone can work with Scala for 6 months, he says, and
not realize this.

~~~
fluppy
You are treating it as a monad, not as a collection.

~~~
hythloday
I am treating it as a monad, but "not as a collection" is, I think, untrue,
unless you want to also declare that a Java EnumSet is also not necessarily a
collection, which is a bit rigorous for intuition.

------
NhanH
To my understanding, Go is meant to be a replacement for C, while Scala
supposedly would be roughly in the same position on the technology stack as
Ruby/ Python/ Java (and this is a broad generalization as well). I'm not sure
how Go will be competing with either Node or Scala?

One of the appealing of Scala for me to start learning it is the functional
aspect. Although not too pure, it's "functional enough", and is an actual
useful language for working in the industry. Go doesn't even pretend it's
functional (which is a good thing of not trying to half-ass stuff), and while
interface is a really nice idea, it's just barely OOP as well.

~~~
mseepgood
> I'm not sure how Go will be competing with either Node or Scala?

Go is designed as a systems-level programming language in today's context,
which means scalable network service software. So they have definitely similar
scopes of application.

------
threeseed
Silly guy. There is more to Scala than just the language. It is the JVM
platform with its decades of features and hundreds of thousands of libraries.

I personally don't understand the point of Go. If Google wasn't using it then
it would have been forgotten by now.

------
lmm
Scala will never be defeated by a language with a weaker type system.

------
bad_user
Some thoughts on the presentation:

1\. the prototype he built in Scala was a single-machine, non-distributed app.

2\. some of his points are kind of juvenile, like his comment on the book "
_Javascript, the Good Parts_ ".

3\. he complains about the lack of a central repository of packages for Scala,
with the packages being distributed all over the Internet in Maven
repositories. But that's one of the things I love about working with Scala and
the JVM.

Setting up a Maven repository is as easy as configuring a web server to serve
static files and publishing to a Maven repository is as easy as copying files
to your web server. It's so easy to do, I even have my own Maven repository
setup at my personal <http://maven.bionicspirit.com> (heck, you can even setup
a Maven repository using GitHub's pages, which is how I first did it).

Then, you can find most of the Java libraries in Maven central and most of the
Scala libraries in Typesafe's maven repo. And if one of the big repos fail,
then that's not a problem because you can fallback to other mirrors or other
repositories that host the same packages. Or you can simply mirror Maven
central on your own VPN. Or whatever.

Of all the platforms I worked with, including PHP, Java, Perl, Python, Ruby,
Node and .NET, dealing with dependencies through Maven/SBT has been the least
painful for me. Of course, the viewpoint of a sysops could be different than
mine, but coming to this after years of struggling seemed like a breath of
fresh air.

Just the other day I helped out a newbie get a Python app running on his
localhost, by installing a virtualenv and then installing the dependencies
with pip, but the problem was the app required _older_ versions of Python
libraries that are no longer in the latest Ubuntu, so they had to be compiled
manually, requiring a ton of C libraries and headers as dependencies for the
compilation process, that couldn't be specified in the _requirements.txt_ ,
triggering weird errors and you had to guess what dependency is needed. It's
also fun to discover that some new version of a C library isn't really
compatible, even though it compiled.

This is in fact a recurring problem for all platforms that have a habit of
relying on C libraries and Go is no exception, so even though it has some nice
features in it, I fail to see how it's a real improvement over Maven/SBT and
the JVM.

4\. He complains about Scala binary incompatibilities.

This can indeed be a problem, that I personally solved by simply upgrading
Scala versions as soon as they come out. I then drop all dependencies that
don't work with the newest Scala version. The popular libraries that are
considered reliable, like the Play framework, or Akka, tend to keep up quite
well.

This is also the reason why I avoided libraries released by Twitter, like
Finagle.

He also says he had to resort to using a Java Cassandra client. I don't see
how that's in any way bad. Scala is extremely efficient for writing wrappers,
because there's no point in reinventing the wheel when you've got Java
libraries developed and tweaked for years before they got stable. For
instance, I couldn't see the point in using a Memcached client written in
Scala, when I could write efficient wrappers for SpyMemcached with minimal
effort ... <https://github.com/alexandru/shifter/tree/master/cache/src>

5\. He says that Option is treated as a collection. That's not exactly true.
Option is treated as a _Monad_ , which is another way of saying that it is
kind of like a _container_ , or a _context_ that implements filter, map and
flatMap and/or flatten with certain properties, operations that allow you to
do stuff while still keeping that _context_. Scala's Option is also more user
friendly than Haskell's Maybe, because indeed Option can be _viewed_ as a
sequence, which makes it composable with other sequence types, which are also
monadic types.

There's a ton of literature on the subject and declaring _Option_ to be like a
weird collection doesn't really do it justice.

It's also worth noting here, that because Go lacks generic types, you can't
implement Option in Go.

6\. Pattern matching is an issue of taste, but his examples are way to
simplistic that it kind of baffled me. People have a tendency to declare
features that aren't in their favorite languages, or that they don't
understand, as being useless. I'm on the other extreme and I find it
unacceptable for a high-level static language to not have pattern matching.

We can argue back and forth on this, but for instance to declare URL routes in
a web app I don't need freaking annotations or XML files or other kinds of
magic or special syntax or if branches, when I can just do this ...
[https://github.com/alexandru/shifter/blob/master/web-
sample/...](https://github.com/alexandru/shifter/blob/master/web-
sample/src/main/scala/shifter/web/sample/controllers/Urls.scala)

7\. His point on "too many I/O options" is not true. First of all there is
really only one I/O option in Scala and that is Java's standard library. All
other things, like Netty, Finangle or whatever else he mentions are built on
top. C/C++ developers that have suffered the pain of working on highly
concurrent systems know what I'm talking about.

He talks about how doing blocking I/O in multiple threads kind of sucks. Well,
yes and no. First of all, blocking I/O behaves better in certain contexts,
because sometimes it's useful to block the process rather than to run out of
memory, not to mention that blocking I/O simply delivers more IOPS. There's
also this common misconception that multiple threads don't scale, with the
commonly escaped fact that a blocked thread hardly consumes any resources,
while blocked and what really kills performance is the context-switching,
which is negligible if the app is heavily I/O bound.

Blocking I/O sucks when it comes to apps that are both CPU bound and I/O
bound, because in such an instance you want to use a threadpool with the
number of threads proportional to the number of CPUs you have, so blocking
threads is no longer an option, because you no longer have enough threads to
block. It's worth mentioning here that the original model used by Java servers
of one thread per connection or request was pretty dumb.

Anyway, the main reason for why I picked Scala was the easy handling of non-
blocking I/O by means of Futures/Promises, in combination with awesome
libraries, like Akka, Netty, Jetty, Ning's HTTP Client or SpyMemcached. Our
web services built on top of Scala are fully async and behave extremely well
under huge load.

8\. On "too many options", this is just a symptom of Scala being based on a
mature platform. Personally I like having options. When other platforms will
grow up, people will complain about them too.

9\. The talk seems to be given in April 2013, but it's seriously out of date.

Akka's actors have been integrated in Scala, so you no longer have Scala
actors / Akka actors. And who uses Fingle anyway? Just because a big company
like Twitter released it, it doesn't mean it's well maintained or reliable. If
in doubt, ask others.

10\. I also find Java to be painful, but complaining about mature libraries,
no matter the language they are written in, is kind of childish. I also prefer
dealing with Java code, rather than C.

And even though my code uses many Java libraries directly, it really doesn't
look Java-ish, except in cases where I needed low level optimizations, because
our web services really do need to serve tens of thousands of requests per
second, so sometimes a developer does whatever it needs to do to make it work
well. But such instances happen rarely and are based on actually _profiling_
and finding the hotspots.

11\. Tuples are NOT a collection type. This is yet another one of those
instances where developers come with certain assumptions about how things
should work by their experience with other languages, but then they rant about
it without making an effort to understand the rationale behind the concepts
involved. If you want a collection, use a collection.

12\. On readability and maintainability, the code we write tends to be written
in a functional style and I've found no other technique that works better for
readability and maintainability. Sometimes I look at pieces of code I write
and I just know that it's going to run correctly, before running said pieces
of code or writing tests for them. For referential transparent pieces of code,
many times you can prove it too, by mathematical induction and I wonder how I
lived without it so far.

13\. He talks about Go, but fails to mention its Achilles heal when it comes
to building concurrent / scalable systems ... its garbage collector, that will
never improve to the same level as the ones available for the JVM simply
because Go is lower level than Java in regards to memory usage and it will be
really hard to build a concurrent, precise, generational garbage collector for
it. At some point Go even had problems on 32-bits systems, because it couldn't
distinguish between plain ints and pointers.

------
fluppy
This guy is an idiot.

Anyway, Go is obsolete since Rust is strictly better than Go.

~~~
davidw
One of the guidelines on this site is to write comments as if you were
speaking to the person in question to their face. It makes for a friendlier,
more thoughtful style of discourse compared to many other sites where zipping
off a quick insult is the done thing. In other words, the guy may well be
wrong, so say why, point out the errors, and leave out the insults.

------
CmonNoReg
Node & Scala haven't even defeated their predecessors yet. Another obscure
functional language?

~~~
dscrd
Go is neither obscure nor that functional either.

~~~
CmonNoReg
What are some well-know open source projects/products that are using it?

~~~
mseepgood
Here you can find a list of some commercial organizations / products using Go:
<http://code.google.com/p/go-wiki/wiki/GoUsers>

An example for a somewhat known open-source project is probably Canonical's
JuJu.

