4 ms·

Why Node and Scala will dry up: Go will drink their milkshake

30 points by Supermighty 13y ago

CmonNoReg 13y ago
Node & Scala haven't even defeated their predecessors yet. Another obscure functional language?
- dscrd 13y ago
  Go is neither obscure nor that functional either.
  - CmonNoReg 13y ago
    What are some well-know open source projects/products that are using it?
    - mseepgood 13y ago
      Here you can find a list of some commercial organizations / products using Go: http://code.google.com/p/go-wiki/wiki/GoUsers http://code.google.com/p/go-wiki/wiki/GoUsers An example for a somewhat known open-source project is probably Canonical's JuJu.
    - dscrd 13y ago
      My sense of 'well-known' might be a bit skewed, but let's say docker and heka.
VLM 13y ago
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?
- CmonNoReg 13y ago
  What do you expect from a title that says "Your language sucks, please just pay some attention to our project"?
- realrocker 13y ago
  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.
- jlgreco 13y ago
  "I like Go. I don't know Node and am uncomfortable with Scala. "
fluppy 13y ago
This guy is an idiot. Anyway, Go is obsolete since Rust is strictly better than Go.
- davidw 13y ago
  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.
- pico303 13y ago
  If Rust had some of the libraries that Go has, I'd be doing all of my development in Rust.
- daemonfire300 13y ago
  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.
guard-of-terra 13y ago
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 13y ago
  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 13y ago
    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.
    - guard-of-terra 13y ago
      Frontend people also use PHP or XSLT, which are equally if not more nasty than (server-side) JS. Sometimes they get to use Python or Ruby but that's less typical.
    - dccoolgai 13y ago
      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
mseepgood 13y ago
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 http://www.youtube.com/watch?v=f6kdp27TYZs
- pauldix 13y ago
  Fair enough. Better I just focus on the good of Go in the future.
NhanH 13y ago
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 13y ago
  > 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.
- jlgreco 13y ago
  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).
dvt 13y ago
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 13y ago
  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?
lmm 13y ago
Scala will never be defeated by a language with a weaker type system.
threeseed 13y ago
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.
hythloday 13y ago
"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 13y ago
  You are treating it as a monad, not as a collection.
  - hythloday 13y ago
    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.
- warfangle 13y ago
  I thought it really weird how he didn't understand how to aptly work with tuples, either.
  - hythloday 13y ago
    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.
    - pauldix 13y ago
      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?
      - mike_mikeson 13y ago
exabrial 13y ago
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.
bad_user 13y ago
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 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 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/src/main/scala/shifter/web/sample/controllers/Urls.scala https://github.com/alexandru/shifter/blob/master/web-sample/... 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.
QEDturtles 13y ago
The Scala critique could have been titled "Awesome Things about Scala that I don't Understand Yet"

30 points by Supermighty 13y ago

CmonNoReg 13y ago

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

dscrd 13y ago
Go is neither obscure nor that functional either.
- CmonNoReg 13y ago
  What are some well-know open source projects/products that are using it?
  - mseepgood 13y ago
    Here you can find a list of some commercial organizations / products using Go: http://code.google.com/p/go-wiki/wiki/GoUsers http://code.google.com/p/go-wiki/wiki/GoUsers An example for a somewhat known open-source project is probably Canonical's JuJu.
  - dscrd 13y ago
    My sense of 'well-known' might be a bit skewed, but let's say docker and heka.

VLM 13y ago

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?

CmonNoReg 13y ago
What do you expect from a title that says "Your language sucks, please just pay some attention to our project"?
realrocker 13y ago
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.
jlgreco 13y ago
"I like Go. I don't know Node and am uncomfortable with Scala. "

fluppy 13y ago

This guy is an idiot. Anyway, Go is obsolete since Rust is strictly better than Go.

davidw 13y ago
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.
pico303 13y ago
If Rust had some of the libraries that Go has, I'd be doing all of my development in Rust.
daemonfire300 13y ago
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.

guard-of-terra 13y ago

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 13y ago
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 13y ago
  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.
  - guard-of-terra 13y ago
    Frontend people also use PHP or XSLT, which are equally if not more nasty than (server-side) JS. Sometimes they get to use Python or Ruby but that's less typical.
  - dccoolgai 13y ago
    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

mseepgood 13y ago

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 http://www.youtube.com/watch?v=f6kdp27TYZs

pauldix 13y ago
Fair enough. Better I just focus on the good of Go in the future.

NhanH 13y ago

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 13y ago
> 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.
jlgreco 13y ago
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).

dvt 13y ago

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 13y ago
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?

lmm 13y ago

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

threeseed 13y ago

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.

hythloday 13y ago

"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 13y ago
You are treating it as a monad, not as a collection.
- hythloday 13y ago
  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.
warfangle 13y ago
I thought it really weird how he didn't understand how to aptly work with tuples, either.
- hythloday 13y ago
  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.
  - pauldix 13y ago
    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?
    - mike_mikeson 13y ago

exabrial 13y ago

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.

bad_user 13y ago

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 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 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/src/main/scala/shifter/web/sample/controllers/Urls.scala https://github.com/alexandru/shifter/blob/master/web-sample/... 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.

QEDturtles 13y ago

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