Some thoughts on the presentation:<p>1. the prototype he built in Scala was a single-machine, non-distributed app.<p>2. some of his points are kind of juvenile, like his comment on the book "<i>Javascript, the Good Parts</i>".<p>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.<p>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 <a href="http://maven.bionicspirit.com" rel="nofollow">http://maven.bionicspirit.com</a> (heck, you can even setup a Maven repository using GitHub's pages, which is how I first did it).<p>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.<p>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.<p>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 <i>older</i> 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 <i>requirements.txt</i>, 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.<p>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.<p>4. He complains about Scala binary incompatibilities.<p>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.<p>This is also the reason why I avoided libraries released by Twitter, like Finagle.<p>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 ... <a href="https://github.com/alexandru/shifter/tree/master/cache/src" rel="nofollow">https://github.com/alexandru/shifter/tree/master/cache/src</a><p>5. He says that Option is treated as a collection. That's not exactly true. Option is treated as a <i>Monad</i>, which is another way of saying that it is kind of like a <i>container</i>, or a <i>context</i> that implements filter, map and flatMap and/or flatten with certain properties, operations that allow you to do stuff while still keeping that <i>context</i>. Scala's Option is also more user friendly than Haskell's Maybe, because indeed Option can be <i>viewed</i> as a sequence, which makes it composable with other sequence types, which are also monadic types.<p>There's a ton of literature on the subject and declaring <i>Option</i> to be like a weird collection doesn't really do it justice.<p>It's also worth noting here, that because Go lacks generic types, you can't implement Option in Go.<p>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.<p>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 ... <a href="https://github.com/alexandru/shifter/blob/master/web-sample/src/main/scala/shifter/web/sample/controllers/Urls.scala" rel="nofollow">https://github.com/alexandru/shifter/blob/master/web-sample/...</a><p>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.<p>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.<p>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.<p>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.<p>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.<p>9. The talk seems to be given in April 2013, but it's seriously out of date.<p>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.<p>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.<p>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 <i>profiling</i> and finding the hotspots.<p>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.<p>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.<p>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.