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?
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.
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.
Rust is a playground, Go at least is above 1.0.
I want a mature language and not this was recently alpha now beta, heavily under construction language for anything production related.
To play around and create hobby projects rust may seem pretty cool. But from what I observed I currently prefer Go over Rust in terms of ready for production.
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.
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.
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
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
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.
> 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.
In practice Go seems to attract python developers. C++ programmers are not really swayed by it. (Though I would say that I was previously a C programmer, and love Go).
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).
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?
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.
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.
"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.
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.
Yeah, and had clearly never come to grips with for expressions. And his coding style was either deliberately chosen to make Scala look weird, or really suboptimal.
In my defense, I pulled the option and tuple examples straight from the scala docs. This was just my experience working with the language for a while. Apparently if I had taken the time to learn Scala better I would have been amazed?
Option is a monad. All monads are functors. The key characteristic of a functor is that you can map over it. So why does it surprise you to be using map with Option?
To be honest, and I'm being a bit snarky here I know, I think you're just fairly ignorant of basic functional programming techniques. That's not a crime, but don't mouth off about functional programming if you know so little about it.
Agreed -- the thought in my head was simply that Paul, while well-intended, fails to understand functional (and category theory) concepts and that Option is best understood and used when treating it as a monad (which it is).
Hey, thanks for commenting, especially when you're getting a bit of a pasting :). I don't want to say what boils down to "if you understood the language better you'd agree with me", but your experience really does not mesh with my experience of learning Scala or with the handful of developers I've mentored. Maybe Scala is just not a good language to strike out on your own on (or at least, Go is better)?
For what it's worth, with your point about pattern matching, yes, pattern matching on an Option is as trivial as an if-else statement. But here's pattern-matching on an Option[List[String]]:
val v: Option[List[String]] = Some(Nil)
v match {
case None => /* List not found or whatever */
case Some(Nil) => /* List is the empty list */
case Some(List("")) => /* List is a 1-length list of the empty string */
case Some(List(a)) => /* List is a 1-length list */
case Some(List(a, b)) => /* List is a 2-length list of strings a and b */
case Some(head :: tail) => /* List is greater than length with a head and a tail*/
}
Hopefully it's a bit more obvious why that's more concise than the equivalent if-else tree would be.
Here's how I'd write the slide I complained about the code style of:
And for what it's worth, this kind of for-expression destructuring is pattern matching, so you can do something like:
val collection: List[List[String]] = List(List("a", "b", "c"), List("d", "e"))
for (List(one, two) <- collection) println(one, two) // will just print d, e with no errors
I guess I just think that - no offence - you wrote beginner Scala while you were working on your own and didn't really level up. It's totally a valid criticism of the language that this is easy to do, but blaming the language when you're writing idiosyncratic Scala and wondering why it's so hard to figure out what to do seems unproductive.
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.
42 comments
[ 4.3 ms ] story [ 121 ms ] threadAn example for a somewhat known open-source project is probably Canonical's JuJu.
Anyway, Go is obsolete since Rust is strictly better than Go.
They won't touch Go with a ten meter pole, so no. Go won't cause Node to dry up.
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.
Sometimes they get to use Python or Ruby but that's less typical.
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.
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.
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).
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?
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.
I personally don't understand the point of Go. If Google wasn't using it then it would have been forgotten by now.
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.
The Scala docs (http://www.scala-lang.org/api/current/index.html#scala.Optio...) tell you this in the second paragraph.
To be honest, and I'm being a bit snarky here I know, I think you're just fairly ignorant of basic functional programming techniques. That's not a crime, but don't mouth off about functional programming if you know so little about it.
For what it's worth, with your point about pattern matching, yes, pattern matching on an Option is as trivial as an if-else statement. But here's pattern-matching on an Option[List[String]]:
Hopefully it's a bit more obvious why that's more concise than the equivalent if-else tree would be.Here's how I'd write the slide I complained about the code style of:
The "tuples are an abomination" slide - it's much more idiomatic to destructure tuples than to address their contents: And for what it's worth, this kind of for-expression destructuring is pattern matching, so you can do something like: I guess I just think that - no offence - you wrote beginner Scala while you were working on your own and didn't really level up. It's totally a valid criticism of the language that this is easy to do, but blaming the language when you're writing idiosyncratic Scala and wondering why it's so hard to figure out what to do seems unproductive.BTW, COBOL is faster than every single language mentioned here. And it's more readable. Fact.
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...