17 ms·

Scala – The good, the bad and the very ugly

137 points by bilalhusain 12y ago

BozeWolf 12y ago
Yes, scala. I'm having some fun with it... but i'm also having a lot of arguments with it. I especially recognise the parts of "there is no best/single way of doing things". I can overcome the syntax diabetes. I'd like to do functional programming, I'm doing server/web based stuff mostly. I'd like the language to have a big(large) ecosystem. Clojure is fun and all, but it's more or less a hackernews language. There are only a few serious businesses using it. It also lacks a web framework like Play!. Same goes for Haskell. So besides all the bad stuff of scala, having play and quite a large ecosystem is why i wanted to try it.
- moomin 12y ago
  When the businesses are Twitter, The Guardian, The Daily Mail and Netflix, I wouldn't really worry about it. And seriously, the web story for Clojure is just fine. It's just componentized, it's not missing.
  - bilalhusain 12y ago
    Your way of educating people about Clojure isn't particularly helpful. Don't make sure that people miss out a really good language, instead take this opportunity to share [personal experiences or impressive writeups about] how awesome web frameworks are on this side of the grass.
    - nickik 12y ago
      I dont understand your complaint, he addressed the main complaint about clojure not really beeing used. > how awesome web frameworks are on this side of the grass This is kind of the point he was trying to make, clojure really does not have any major webframeworks. Clojure just does web devlopment diffrently. A hacker news comment is hardly the place for impressive writeups about web devlopment. There have been post like that in lots of blogs.
      - bilalhusain 12y ago
        I read the comment as condescending and as a reply to the parent commenter's lack of knowledge about Clojure and Clojure ecosystem. May be I interpreted it incorrectly and that's why I suggested to shine the light on the real picture. Also, I didn't ask to write about web development, merely share information/links like the other comment (https://news.ycombinator.com/item?id=8420463 https://news.ycombinator.com/item?id=8420463) did.
        moomin 12y ago
        Tbqh, my remark was pretty condescending, because the original comment seemed to be suffering from the DK effect. In fairness, there's a kernel of truth in that almost any article about Clojure seems to get uncritically upvoted, but that's another matter. The fact remains that Clojure, whilst not as popular as Scala, is nonetheless (quietly) in use at a lot of firms. Some more examples: * CitiGroup EU FX derivatives is pure-Clojure * There's at least three different hedge funds using it. * Deutsche Bank are definitely using it too.
  - turar 12y ago
    >> Twitter, The Guardian, The Daily Mail and Netflix Are you talking about Scala or Clojure? I've only seen those names mentioned with their Scala use, what are some of their Clojure projects?
    - moomin 12y ago
      Daily Mail actually serves their website using Clojure and uses it for various other tasks as well. (ElasticSearch backend.) Netflix: they definitely use it for Hadoop stuff, probably elsewhere too. And from this presentation they do a fair bit of Java interop with it: https://speakerdeck.com/daveray/clojure-at-netflix https://speakerdeck.com/daveray/clojure-at-netflix Twitter/BackType produced Apache Storm, which is written in Clojure. Not sure about the Guardian, I should ask, but they're definitely using it.
- simi_ 12y ago
  I don't want to be that guy, but why don't you try Go? It's the perfect server side language IMHO.
  - deleted 12y ago
    [deleted]
  - lmm 12y ago
    With a type system that's weaker than Java's? Look at e.g. the way spray handles HTTP headers; it eliminates a bunch of errors that are in some sense trivial, but almost all bugs are trivial when looked at in the right way. You just couldn't do something like that in Go.
    - grey-area 12y ago
      Look at e.g. the way spray handles HTTP headers... For those of us not familiar with Scala it'd be interesting to see you expand on that statement. Are you talking about the type definitions in this file? https://github.com/spray/spray/blob/release/1.1/spray-http/src/main/scala/spray/http/HttpHeader.scala https://github.com/spray/spray/blob/release/1.1/spray-http/s...
      - lmm 12y ago
        Yeah. It means you can e.g. respondWithHeader(`Content-Encoding`(UTF8)) { ... } and the header and its parameters are typed, and so if you make a typo in the name or the value (or try to pass the value of one header to another) then you'll get a compile-time error.
        grey-area 12y ago
        You could type things like headers in Go too if you want to, by introducing a new type for each header in a similar way, get them to check values are valid on being assigned etc. (std lib does it in a simpler less robust way but it's quite possible). Go could then do compile time checking for those types, e.g. something like: http://play.golang.org/p/GeUgsjitVS http://play.golang.org/p/GeUgsjitVS func respondWithHeader(h HttpContentEncoding) string {...}
- megalomanu 12y ago
  You should try Luminus, which concentrates all the basic libraries for web development. Not as rich as Play! or Django but sufficient for doing a lot of things. It's also a great way to learn Clojure smoothly, it's far more accessible than Pedestal for a beginner.
  - BozeWolf 12y ago
    I actually might give Luminus a go if I give up on scala sometime. Thanks. I did have some fun with clojure, it's much easier to get started with. I know i'm kind of spoiled with features because I do a lot of projects which involve django. I do not expect a framework to be as rich as Django. But i prefer having some things integrated. Some might prefer choosing every component in a framework (ORM, url routing system, form validation etc), but when you work in a team or with freelancers, it comes in handy if theres just a way of doing things.
  - nickik 12y ago
    Pedestal client has been retired. Pedestal server is a high performance server framework that most people probebly want have to use. Pedestal gives you much more power offer use of threads and how you do controll flows between middlewares and such.
- somehnreader 12y ago
  Whats Syntax diabetes referring to by the way? I didn't get it from the presentation, and googling yields, well, diabetes information.
  - moomin 12y ago
    It's a phrase for too much syntactic sugar.
  - rkrzr 12y ago
    It's a play on the term "syntactic sugar": Too much syntactic sugar leads to syntactic diabetes. And syntactic sugar generally refers to language features that allow you to write things in neater ways. It is always possible to "de-sugar" such constructs by writing them in a more basic way, which is usually less neat. Examples would be e.g. list comprehensions, for .. in syntax, x += 1 etc.
  - gamache 12y ago
    It refers to the fact that there are many syntactically-equivalent ways to express the same code. Slide 11 shows expressions that evaluate to the same thing.
    - somehnreader 12y ago
      Thanks, that makes sense, I read the fooN functions but didn't make the connection with "syntactic sugar".
Yuioup 12y ago
Excellent quote: "Concise" doesn't necessarily mean fast to write or easy to read
- weego 12y ago
  Maybe, but it's just a generic statement about programming, it has no real value in a critique of Scala specifically. Part of the beauty of any flexible language is you can go back and refactor it down to a more elegant solution as you learn more. That doesn't mean you have to boil the code down to a point where it is largely impossible to read any more in Scala than any other language. There are real pain points in Scala when you try and scale it from single developers to teams working on a project and most of them are to do with the flexibility of the language. I think all companies working with Scala end up settling on a sub-set of the language that they are happy with. In that sense, the bad is irrelevant: you are never put in a situation where, say, you are forced into using implicits (apart from light use in external libraries like lift-json) so if you don't use them you never suffer their downsides. If you obsess over parts of a language you don't even have to use... then well I'm afraid I have nothing but scorn for people like that. At team-scale then your main pain point is trying to get style of writing that everyone can get behind. Code reviews can be painful when developers with different ideas on how to solve a problem butt heads and pull requests turn into "That's not how I would have written it" instead of critiquing the actual code presented. The tooling and compiling I completely agree with. SBT is a horrific mess. I don't have a single good word to say about it.
  - mercurial 12y ago
    > Maybe, but it's just a generic statement about programming, it has no real value in a critique of Scala specifically. About Scala specifically? No, indeed. About languages which make it possible to create custom ASCII operators? Certainly. I don't know how the Scala culture about this is, but my experience with Haskell is that once people run with it, you get awful ASCII DSLs with cryptic operators all over the place. > I think all companies working with Scala end up settling on a sub-set of the language that they are happy with. So, pretty much like C++, a language that people love to hate. The problem is that, out in the wild, you're going to end up with legacy code made by people who picked a different sub-set.
nrinaudo 12y ago
I feel that most of (not all) the criticisms are fair, but superficial. True, the IDEs are poor, for a certain definition of poor. Had I not used IntelliJ for Java, for example, I'd find IntelliJ for Scala amazing. Knowing how much better it can be spoiled me, but frankly, IntelliJ for Scala is not bad. It just could be better. Also, Emacs has a very robust Scala mode. True, there's a lot to learn before you can consider yourself fully fluent. You do not need to know everything, however. And once you've started on the path, things tend to flow naturally. For example, implicit conversions are easy to grasp. Once you understand them, implicit parameters and type classes are not much more complicated. Once you know type classes, it opens the door to a lot of functional "design patterns" - functors, applicatives, monads... these are not strictly necessary, but they're fun to learn about. And they teach you algebraic data types, which in Scala means case classes, sealed traits, ... it all sort of flows naturally. True, it's easy to write absolutely un-maintainable code. While that's true of any language, Scala makes it rather easier than most. It's also very easy to write highly maintainable, legible code, and to avoid complex, ascii art based operators (or at the very least to offer wordy equivalences at 0 cost through `@inline`). I feel that saying "it can be hard to read, if you don't follow basic guidelines" is a bad reason not to use a language. A good reason to be careful, though. My personal experience is that, once you start feeling comfortable with the language, you get much more productive than with Java. It does require some initial work, though: if all you know is OO, learning how to design your code for composition rather than inheritance takes a while - it takes a while just to realise that it's not a bad idea, let alone embrace it! Also, ScalaCheck. Man, do I wish there was a good Java equivalent for some of my legacy code (that would not require me to rewrite all of my tests).
- bilalhusain 12y ago
  Often the argument is that if languages are superheroes, Scala is trying to be one with all the possible superpowers. When you learn how to use them and have control over when to use them (and for good or bad), everything will be a breeze. But the assumption that everyone will spend time learning the right ways and not use in production before achieving zen is impractical.
  - 12y ago
noelwelsh 12y ago
M'eh. Yes, Scala has flaws but I feel like this talk makes too much of minor annoyances. Ultimately you make an engineering decision about platform. Do you want decent performance, lotsa libraries, and a modern statically typed language? Scala is arguably your best option at present (yes this can be argued with; no that isn't an interesting argument to have). Maybe we'll all be using Rust/Haskell/whatever in 5 years, but in the meantime I got code to write and products to build and I'm using Scala for better or worse. Specifically: - Code on slide 3 has typos. (Yeah, that's minor) - Lambdas are slower than Java 8 -- that's because Scala currently supports Java 6+. Java 8 has been released for 6 months. This is a ridiculous complaint. - Heavy in terms of concepts -- another ridiculous complaint. If you want to keep on writing Java, keep writing Java. If Scala didn't bring new stuff to the table it wouldn't be interesting. - Implicits -- agreed they can be misused. Type classes are the way forward. - I don't understand many of the "very ugly" complaints. Yes, collections have lots of methods. Is this surprising? Yes, library code may be written in an abstract way. So what? Yes, DSLs look like DSLs. Yes, abstracting over arity is a problem in all statically typed languages. etc. There are valid complaints to be made about Scala. I feel this talk demonstrates a lack of understanding of the language, and many of its complaints are in fact misunderstandings. To me the biggest issue this talk reveals is that if you come from an OO background (which I assume the author does) then learning Scala will require a change of mindset. I don't think it is fair to make this a language complaint though. Scala makes it fairly obvious what you're getting yourself into and, as I said above, if you wanted to keep on writing code the way you have in the past it's not clear why you are using Scala in the first place.
- bozho 12y ago
  There is a point in my presentation that says that some of these annoyances are easy to overcome in a real project. But some of them aren't. As for the misunderstandings - the "bad" parts are ..bad. The ugly parts may not be bad, but are ugly (which is subjective, and I think it's implied it's subjective)
  - noelwelsh 12y ago
    Perhaps the issue is that the slides don't really stand on their own. Without hearing what you have to say for many of the slides it is difficult to really get the point you're making. Let me just address the "bad" slides, and what I got from them. Slide 8 - Compiler too slow. A common complaint. Agreed it could be faster. - Ecosystem. Don't really get the point here. Yes, Scala has different idioms to Java, so naturally Java libraries don't make for idiomatic Scala code. There are many mature Scala libraries. Binary incompatibility has not been a problem for me in at least two years, and it is a necessary artifact of Scala compiling a language that is not Java to JVM bytecode. - Lambdas I addressed above. Slide 9 Don't know what point you're making here. Slide 10 Mostly addressed above. Syntax doesn't bother me. There are regular rules and the alternatives are a consequence of those regular rules. Would consider removing eta-expansion. Never had an issue with any of the rules though. Slide 11 See above. Slide 12 See above on type classes. Slide 13 This is very generic. Applies to all languages. Slide 14-15 Don't really get it. You can write code in many different ways. Applies to all languages. Slide 16 This is very generic. Applies to all languages. Slide 17 Don't get the point you're trying to make with this code. Slide 18 This is presumably a slide that summarises this section. Without hearing what you have to say here I can't really interpret this.
DanielBMarkham 12y ago
Saw some Scala at a conference recently. The guy was demonstrating using it to do TDD. I lost track somewhere in the first ten minutes or so, but it looked like he was importing/using multiple DSLs and helper libraries. After I lost track of the exact details, I started scanning for the gist of what he was doing. After an hour, he had what looked like the most massive clusterfuck I've ever seen in a project file -- all to do something that would take a dozen lines or so of simple FP script. Seemed like every functional thing he used was either also an object or had to be bolted into an object graph for it to work. The project file had scores of things in it. This did not leave a good impression. It reminded me of when I saw my first C/Win32 app and realized you needed a couple hundred lines of code and several files just to say "hello world" -- except this was a couple orders of magnitude more complex. It was a god-awful abomination. Hopefully Scala projects are not like this.
- lmm 12y ago
  Not all Scala projects are like this. There's a sect that wants to write tests in "human readable" fashion, e.g. the people who like Cucumber in Ruby; in Scala those same people write their DSLs within the language, something Scala is good at and that I'd argue provides real advantages over an "external" DSL. But you don't have to do that; I write Scala professionally and all my tests are just ordinary JUnit test methods.
  - DanielBMarkham 12y ago
    Whew! I'm okay with using DSLs. Hey, if you have good FP, flaunt it. My concern after watching this, however, was whether or not the JVM development environment itself encourages complicating things beyond the most minimum thing needed to solve a problem when you're using it in a functional manner. (I haven't done Java in a decade). So, for instance, could I have just written a simple 12-line script to solve the problem he was banging around? Or would I have to create some kind of object with a "main" method? Could I just add in a test file and write functional tests from there, aka JUnit, or do I have to bolt something in that then requires a separate project structure and so forth (aka JUnit) There's no right or wrong answer for any of these types of project configurations. Heck, I like my tests in a separate project. It just looked like every time he had a new need, the project got 14 times more complex. The solution to one problem made the entire development environment more complicated for everything else. That's heading in the wrong direction, no? Admittedly I only had a brief glance. Thanks for the answer!
lmm 12y ago
Does the syntactic diabetes really bother people? Like, yes, these are different sequences of characters that mean the same thing, but visually it's very clear that they are the same thing; it's not the perl "there is more than one way to do it" where the ways of doing it are conceptually very different. It seems no different from complaining that I can write f(a, b) or f((a), (b)), which is a choice you get in almost every language. Implicits are dangerous, sure. Typeclasses are vital and extension methods are nice, but it might be better to cover these use cases with something more specific. That said, these days the IDEs flag up implicits so it's not really a problem day-to-day. Concise really helps readability at the function/module level - there's a huge drop in readability when a function reaches the point that you can't fit it on one screen. It may well be that the 1-line scala version of a method takes exactly the same time to read as the 10-line java version - but if it means you can fit your whole class on one screen, that's still a win. Symbolic method names are bad and I wish the community would move away from them. The definition of ++ is perfectly sensible once you stop panicking and start actually reading it. As is the parser; sure, it's a DSL, it uses some short symbols, but I defy you to find a better way to express the parser given. When you're building up a complex parser, it's well worth having a concise notation. jsonFormatX are legacy cruft. In a modern json library you can avoid them by using Shapeless instead; hopefully spray-json will do this too. The .toSet() example is deprecated and will give a warning if you actually try and run it. Java-8 style lambda compilation is already available under an experimental flag, and the next release will have full support.
- oelang 12y ago
  The author seems to think that java 8 lambdas are faster than scala lambdas. This isn't strictly true. Java 8 spins the inner classes for lambdas at first use, this gives them a performance boost at startup (loading tons of tiny classes from a jar is painfull for the jvm) but at runtime they perform the same (it's just invokevirtual). Another optimization that java 8 has is that lambdas that don't capture are cached & reused, scala does the same if you use the -optimize flag.
- bsaul 12y ago
  Syntactic diabetes is to me the best warning sign. It means the focus on orthogonality has been lost somewhere in the evolution of the language. There should be only one way to express a given language operation, and this way should be the simplest and most elegant. Not just because of aesthetic (which is crucial when speaking about readability), but also because it would combine the most harmoniously with other parts of the language. It seems to me that at this point scala should deprecate all non-essential syntactic sugar and features and reduce the language to its "core". Or, at the very least, people should start a fork with that goal. Hell, it could even be just a compilation option.
virtualwhys 12y ago
The IDE story has vastly improved in Scala, certainly nowhere near that of Java but decent nonetheless. The best way to shoot yourself in the foot is to have automatic build turned on in your IDE and to run SBT in a separate terminal; with that approach you get dog slow compilations, blocked UI, and other hair pulling madness. When SBT is boss (i.e. IDE auto build turned off and compile target shared between the two) then you'll have a far saner development experience. The OP hasn't been using Scala for long so many of his gripes boil down to lack of experience. You have to learn the ropes, the (myriad) corner cases, etc. of the language before things start to click. It's like starting out in Haskell, where on earth do you even begin to understand this utterly new paradigm, much less go into production with large scala projects in it? The answer is: you don't, you learn, learn, learn until you're well grounded in the language and its frameworks; then you bet the bank on it because you're sold on its clear-as-day powers. I'll go out on a limb and say that the only viable type safe alternatives to Scala and its ecosystem are C#/F# on .NET, and Haskell. In other words, yes, Scala has its warts, but overall is pretty much unmatched in terms of expressivity, power, and performance.
- the_af 12y ago
  I like Scala, but it gets me that the official IDE, Scala IDE, is so utterly broken. If you let the IDE handle the build, you'll constantly get spurious compilation errors, which in a statically typed language are unacceptable. Letting SBT do the build may work, but come on. This is the official IDE! Is there any acknowledgement in scala-ide.org that you should let SBT to do the build? Do Odersky and the guys at Typesafe use that setup, or do they suffer their IDE silently? I haven't had much luck with IntelliJ either.
  - virtualwhys 12y ago
    Couple things to keep in mind: Java IDEs have had millions of man hours put into them; there's a reason they're rock solid reliable; that and Scala's power is a double edged sword: tooling becomes a more difficult proposition with greater language complexity. As Scala users we're basically guinea pigs in the IDE department. Having suffered from the relative stone ages of 2010 era Scala tooling I can honestly say that if you're considering picking up the language, you've come at a great time ;-) re: sbt running the show, not sure about IntelliJ but the core Scala IDE devs will drop that bit of knowledge when a user moans on the mailing lists about blocked UI, spurious syntax errors, and other bundles of joy.
fideloper 12y ago
Is there a book everyone recommends for learning Scala? In the beginner range, not someone coming from Java.
- huehue 12y ago
  `Scala for the Impatient` is really good.
  - thescrewdriver 12y ago
    Scala for the Impatient is really good, but not sure that it's designed entirely for beginners. For more beginner-centric content perhaps check out: Learning Scala: http://shop.oreilly.com/product/0636920030287.do http://shop.oreilly.com/product/0636920030287.do http://chimera.labs.oreilly.com/books/1234000001798/index.html http://chimera.labs.oreilly.com/books/1234000001798/index.ht... ...or Atomic Scala: http://www.atomicscala.com/ http://www.atomicscala.com/
- noelwelsh 12y ago
  I'm writing one. It's almost ready. Drop me an email (noel at underscoreconsulting dot com) if you'd like to try it out.
- ssmoot 12y ago
  I second "Scala for the Impatient", but if you don't have any statically typed background it might be a bit tough. "The Neophyte's Guide to Scala" (http://danielwestheide.com/scala/neophytes.html http://danielwestheide.com/scala/neophytes.html) is hands down the best language introduction I've ever read though.
- jowiar 12y ago
  Odersky's Coursera is excellent. For me, it was vital to jumping the gap from "Here is a language that gives you a million ways to solve problems" to "I want to express this particular concept, so I designed a language well suited for expressing it".
mcv 12y ago
I kinda agree with this. Scala has good bits. Very good bits. Gorgeously beautiful bits, even. But the ugly bits are so terrifyingly ugly that I dare not touch it. Give me the Scala pattern matchers (that can also match by type and even by content of case classes, I believe), with the case classes and the actor concurrency model, but keep the horrendous type system and the confused parts of the syntax.
- frowaway001 12y ago
  > horrendous type system and the confused parts of the syntax Could you expand on that a bit? In my experience, Scala is one of the few languages which don't fight against everything you want to express in a typesafe way. Also, I find the syntax extremely consistent. Easy to remember and almost no special rules.
  - mcv 12y ago
    The article shows some examples where you can choose between regular brackets or curly brackets. There's a lot of different ways to say the exact same thing. Why? Which is best? Are there any cases where one works but the other doesn't, and if so, why does the other exist? But maybe I'm too used to different brackets meaning different things. I'm used to Java and Groovy where brackets are used very consistently. The type safety goes way overboard with extremely arcane, incomprehensible expressions. The excessive power of the type system makes compiling far too slow. And the pattern matchers mean you can easily get your type back when you need it. I really strongly prefer the more dynamic approach of Groovy. Total type safety is a trap.
    - frowaway001 12y ago
      > The article shows some examples where you can choose between regular brackets or curly brackets. There's a lot of different ways to say the exact same thing. Why? Which is best? Are there any cases where one works but the other doesn't, and if so, why does the other exist? Yes, but which one would you remove? If you disallowed the curly ones, developers would suddenly require an additional language feature to define methods which could be used like this: using(someResource) { // do something with ressource } Apart from that {} has semicolon inference, while () doesn't. That's extremely helpful, if you have some expression and really want to make sure that it can't be split into something like { doThing1, doThing2 } by an unaware developer. > Total type safety is a trap. Sure, there are limits on what can be done with a type system, but these options have been growing larger and larger in the last decades. I wouldn't throw away the last 40 years of progress in that area and start doing stuff manually which any decent compiler can figure out for me. > Groovy I haven't heard from Groovy since a long time ago. Is it still actively developed? The last things I saw was that they were struggling to catch up, and work on the new MOP still wasn't finished. On the Gartner PLI, Groovy is way down on position 20. That doesn't look too promising either ...
wiradikusuma 12y ago
I submitted a YouTube video 165 days ago where Martin Odersky explains how to avoid coding the complicated way. https://news.ycombinator.com/item?id=7641626 https://news.ycombinator.com/item?id=7641626
xwowsersx 12y ago
From the looks of it, the author of these slides has written very little Scala. Take slide #7, for example, where he writes def bar() = { "1" } when def bar = "1" is perfectly sufficient. Ironically, I may very well be pointing out the bad parts of scala (i.e. that () is simply a convention for indicating Unit or side-effecting functions, but its just convention and not enforced by the type system in any way). Notwithstanding that, I don't think someone who has written very little Scala is in a great position to offer a reasonable critique. This is a longer discussion, but in the very first slide he points to the object-orientation as a plus. In my opinion, he's already wrong. "There is no such thing as Object-Oriented programming." See: http://blog.higher-order.com/blog/2008/12/04/no-such-thing/ http://blog.higher-order.com/blog/2008/12/04/no-such-thing/
taf2 12y ago
golang
- thescrewdriver 12y ago
  Perhaps you could elaborate on how naming a random language relates to this discussion...
  - throwaway1979 12y ago
    Heh ... it is the other mainstream "hot" language. I was looking for a language to move to post-python. I love python but the 2.7->3 jump has been annoying. More than that, I felt I needed static typing for the next big system I did ... too much pain debugging python. I looked at Scala since it had the JVM behind it. While the language seems decent, it seems too easy to write unreadable code. Multiple ways of doing the same thing ... yada yada. Friends at Google had been espousing Go for a long time and I didn't bother. Seemed like a proprietary language with little adoption. Two things changed for me. I got some exposure to erlang via elixir. This made me think about the whole channel concept. Second, I had to read code in Docker (which is awesome). I learned a bit of the language and was surprised how small the language was. Really reminded me of C, which I love. There seems to be more adoption of Go .. e.g. Cloud Foundry and others. I like Go enough that I will be spending more time learning and investing in it. Just by 2 cents.
eranation 12y ago
I use scala a lot and it did become my go to general purpose language (as well as my workplace adopted it as a first class citizen and used for many new projects) I do have issues with it, but mostly with developers using (abusing) it. (And library authors that are a bit religious about the functional paradigm and simply love their operators... With great power comes great responsibility, the is no better description to this language. Also, I was looking at the CanBuildFrom hell with fear, but Odersky et al's book on Scala surprisingly did a good job getting the pieces in place for me. It even makes sense of the madness. http://www.artima.com/shop/programming_in_scala_2ed http://www.artima.com/shop/programming_in_scala_2ed Finally, Bozho is one of my most respected contributors on stackoverflow. And I can say that his slides actually do justice to Scala, I might disagree on the conclusions, but the facts are absolutely right.

137 points by bilalhusain 12y ago

Yes, scala. I'm having some fun with it... but i'm also having a lot of arguments with it. I especially recognise the parts of "there is no best/single way of doing things". I can overcome the syntax diabetes. I'd like to do functional programming, I'm doing server/web based stuff mostly. I'd like the language to have a big(large) ecosystem. Clojure is fun and all, but it's more or less a hackernews language. There are only a few serious businesses using it. It also lacks a web framework like Play!. Same goes for Haskell. So besides all the bad stuff of scala, having play and quite a large ecosystem is why i wanted to try it.

moomin 12y ago
When the businesses are Twitter, The Guardian, The Daily Mail and Netflix, I wouldn't really worry about it. And seriously, the web story for Clojure is just fine. It's just componentized, it's not missing.
- bilalhusain 12y ago
  Your way of educating people about Clojure isn't particularly helpful. Don't make sure that people miss out a really good language, instead take this opportunity to share [personal experiences or impressive writeups about] how awesome web frameworks are on this side of the grass.
  - nickik 12y ago
    I dont understand your complaint, he addressed the main complaint about clojure not really beeing used. > how awesome web frameworks are on this side of the grass This is kind of the point he was trying to make, clojure really does not have any major webframeworks. Clojure just does web devlopment diffrently. A hacker news comment is hardly the place for impressive writeups about web devlopment. There have been post like that in lots of blogs.
    - bilalhusain 12y ago
      I read the comment as condescending and as a reply to the parent commenter's lack of knowledge about Clojure and Clojure ecosystem. May be I interpreted it incorrectly and that's why I suggested to shine the light on the real picture. Also, I didn't ask to write about web development, merely share information/links like the other comment (https://news.ycombinator.com/item?id=8420463 https://news.ycombinator.com/item?id=8420463) did.
      - moomin 12y ago
        Tbqh, my remark was pretty condescending, because the original comment seemed to be suffering from the DK effect. In fairness, there's a kernel of truth in that almost any article about Clojure seems to get uncritically upvoted, but that's another matter. The fact remains that Clojure, whilst not as popular as Scala, is nonetheless (quietly) in use at a lot of firms. Some more examples: * CitiGroup EU FX derivatives is pure-Clojure * There's at least three different hedge funds using it. * Deutsche Bank are definitely using it too.
- turar 12y ago
  >> Twitter, The Guardian, The Daily Mail and Netflix Are you talking about Scala or Clojure? I've only seen those names mentioned with their Scala use, what are some of their Clojure projects?
  - moomin 12y ago
    Daily Mail actually serves their website using Clojure and uses it for various other tasks as well. (ElasticSearch backend.) Netflix: they definitely use it for Hadoop stuff, probably elsewhere too. And from this presentation they do a fair bit of Java interop with it: https://speakerdeck.com/daveray/clojure-at-netflix https://speakerdeck.com/daveray/clojure-at-netflix Twitter/BackType produced Apache Storm, which is written in Clojure. Not sure about the Guardian, I should ask, but they're definitely using it.
simi_ 12y ago
I don't want to be that guy, but why don't you try Go? It's the perfect server side language IMHO.
- deleted 12y ago
  [deleted]
- lmm 12y ago
  With a type system that's weaker than Java's? Look at e.g. the way spray handles HTTP headers; it eliminates a bunch of errors that are in some sense trivial, but almost all bugs are trivial when looked at in the right way. You just couldn't do something like that in Go.
  - grey-area 12y ago
    Look at e.g. the way spray handles HTTP headers... For those of us not familiar with Scala it'd be interesting to see you expand on that statement. Are you talking about the type definitions in this file? https://github.com/spray/spray/blob/release/1.1/spray-http/src/main/scala/spray/http/HttpHeader.scala https://github.com/spray/spray/blob/release/1.1/spray-http/s...
    - lmm 12y ago
      Yeah. It means you can e.g. respondWithHeader(`Content-Encoding`(UTF8)) { ... } and the header and its parameters are typed, and so if you make a typo in the name or the value (or try to pass the value of one header to another) then you'll get a compile-time error.
      - grey-area 12y ago
        You could type things like headers in Go too if you want to, by introducing a new type for each header in a similar way, get them to check values are valid on being assigned etc. (std lib does it in a simpler less robust way but it's quite possible). Go could then do compile time checking for those types, e.g. something like: http://play.golang.org/p/GeUgsjitVS http://play.golang.org/p/GeUgsjitVS func respondWithHeader(h HttpContentEncoding) string {...}
megalomanu 12y ago
You should try Luminus, which concentrates all the basic libraries for web development. Not as rich as Play! or Django but sufficient for doing a lot of things. It's also a great way to learn Clojure smoothly, it's far more accessible than Pedestal for a beginner.
- BozeWolf 12y ago
  I actually might give Luminus a go if I give up on scala sometime. Thanks. I did have some fun with clojure, it's much easier to get started with. I know i'm kind of spoiled with features because I do a lot of projects which involve django. I do not expect a framework to be as rich as Django. But i prefer having some things integrated. Some might prefer choosing every component in a framework (ORM, url routing system, form validation etc), but when you work in a team or with freelancers, it comes in handy if theres just a way of doing things.
- nickik 12y ago
  Pedestal client has been retired. Pedestal server is a high performance server framework that most people probebly want have to use. Pedestal gives you much more power offer use of threads and how you do controll flows between middlewares and such.
somehnreader 12y ago
Whats Syntax diabetes referring to by the way? I didn't get it from the presentation, and googling yields, well, diabetes information.
- moomin 12y ago
  It's a phrase for too much syntactic sugar.
- rkrzr 12y ago
  It's a play on the term "syntactic sugar": Too much syntactic sugar leads to syntactic diabetes. And syntactic sugar generally refers to language features that allow you to write things in neater ways. It is always possible to "de-sugar" such constructs by writing them in a more basic way, which is usually less neat. Examples would be e.g. list comprehensions, for .. in syntax, x += 1 etc.
- gamache 12y ago
  It refers to the fact that there are many syntactically-equivalent ways to express the same code. Slide 11 shows expressions that evaluate to the same thing.
  - somehnreader 12y ago
    Thanks, that makes sense, I read the fooN functions but didn't make the connection with "syntactic sugar".

Yuioup 12y ago

Excellent quote: "Concise" doesn't necessarily mean fast to write or easy to read

weego 12y ago
Maybe, but it's just a generic statement about programming, it has no real value in a critique of Scala specifically. Part of the beauty of any flexible language is you can go back and refactor it down to a more elegant solution as you learn more. That doesn't mean you have to boil the code down to a point where it is largely impossible to read any more in Scala than any other language. There are real pain points in Scala when you try and scale it from single developers to teams working on a project and most of them are to do with the flexibility of the language. I think all companies working with Scala end up settling on a sub-set of the language that they are happy with. In that sense, the bad is irrelevant: you are never put in a situation where, say, you are forced into using implicits (apart from light use in external libraries like lift-json) so if you don't use them you never suffer their downsides. If you obsess over parts of a language you don't even have to use... then well I'm afraid I have nothing but scorn for people like that. At team-scale then your main pain point is trying to get style of writing that everyone can get behind. Code reviews can be painful when developers with different ideas on how to solve a problem butt heads and pull requests turn into "That's not how I would have written it" instead of critiquing the actual code presented. The tooling and compiling I completely agree with. SBT is a horrific mess. I don't have a single good word to say about it.
- mercurial 12y ago
  > Maybe, but it's just a generic statement about programming, it has no real value in a critique of Scala specifically. About Scala specifically? No, indeed. About languages which make it possible to create custom ASCII operators? Certainly. I don't know how the Scala culture about this is, but my experience with Haskell is that once people run with it, you get awful ASCII DSLs with cryptic operators all over the place. > I think all companies working with Scala end up settling on a sub-set of the language that they are happy with. So, pretty much like C++, a language that people love to hate. The problem is that, out in the wild, you're going to end up with legacy code made by people who picked a different sub-set.

nrinaudo 12y ago

I feel that most of (not all) the criticisms are fair, but superficial. True, the IDEs are poor, for a certain definition of poor. Had I not used IntelliJ for Java, for example, I'd find IntelliJ for Scala amazing. Knowing how much better it can be spoiled me, but frankly, IntelliJ for Scala is not bad. It just could be better. Also, Emacs has a very robust Scala mode. True, there's a lot to learn before you can consider yourself fully fluent. You do not need to know everything, however. And once you've started on the path, things tend to flow naturally. For example, implicit conversions are easy to grasp. Once you understand them, implicit parameters and type classes are not much more complicated. Once you know type classes, it opens the door to a lot of functional "design patterns" - functors, applicatives, monads... these are not strictly necessary, but they're fun to learn about. And they teach you algebraic data types, which in Scala means case classes, sealed traits, ... it all sort of flows naturally. True, it's easy to write absolutely un-maintainable code. While that's true of any language, Scala makes it rather easier than most. It's also very easy to write highly maintainable, legible code, and to avoid complex, ascii art based operators (or at the very least to offer wordy equivalences at 0 cost through `@inline`). I feel that saying "it can be hard to read, if you don't follow basic guidelines" is a bad reason not to use a language. A good reason to be careful, though. My personal experience is that, once you start feeling comfortable with the language, you get much more productive than with Java. It does require some initial work, though: if all you know is OO, learning how to design your code for composition rather than inheritance takes a while - it takes a while just to realise that it's not a bad idea, let alone embrace it! Also, ScalaCheck. Man, do I wish there was a good Java equivalent for some of my legacy code (that would not require me to rewrite all of my tests).

bilalhusain 12y ago
Often the argument is that if languages are superheroes, Scala is trying to be one with all the possible superpowers. When you learn how to use them and have control over when to use them (and for good or bad), everything will be a breeze. But the assumption that everyone will spend time learning the right ways and not use in production before achieving zen is impractical.
- 12y ago

noelwelsh 12y ago

M'eh. Yes, Scala has flaws but I feel like this talk makes too much of minor annoyances. Ultimately you make an engineering decision about platform. Do you want decent performance, lotsa libraries, and a modern statically typed language? Scala is arguably your best option at present (yes this can be argued with; no that isn't an interesting argument to have). Maybe we'll all be using Rust/Haskell/whatever in 5 years, but in the meantime I got code to write and products to build and I'm using Scala for better or worse. Specifically: - Code on slide 3 has typos. (Yeah, that's minor) - Lambdas are slower than Java 8 -- that's because Scala currently supports Java 6+. Java 8 has been released for 6 months. This is a ridiculous complaint. - Heavy in terms of concepts -- another ridiculous complaint. If you want to keep on writing Java, keep writing Java. If Scala didn't bring new stuff to the table it wouldn't be interesting. - Implicits -- agreed they can be misused. Type classes are the way forward. - I don't understand many of the "very ugly" complaints. Yes, collections have lots of methods. Is this surprising? Yes, library code may be written in an abstract way. So what? Yes, DSLs look like DSLs. Yes, abstracting over arity is a problem in all statically typed languages. etc. There are valid complaints to be made about Scala. I feel this talk demonstrates a lack of understanding of the language, and many of its complaints are in fact misunderstandings. To me the biggest issue this talk reveals is that if you come from an OO background (which I assume the author does) then learning Scala will require a change of mindset. I don't think it is fair to make this a language complaint though. Scala makes it fairly obvious what you're getting yourself into and, as I said above, if you wanted to keep on writing code the way you have in the past it's not clear why you are using Scala in the first place.

bozho 12y ago
There is a point in my presentation that says that some of these annoyances are easy to overcome in a real project. But some of them aren't. As for the misunderstandings - the "bad" parts are ..bad. The ugly parts may not be bad, but are ugly (which is subjective, and I think it's implied it's subjective)
- noelwelsh 12y ago
  Perhaps the issue is that the slides don't really stand on their own. Without hearing what you have to say for many of the slides it is difficult to really get the point you're making. Let me just address the "bad" slides, and what I got from them. Slide 8 - Compiler too slow. A common complaint. Agreed it could be faster. - Ecosystem. Don't really get the point here. Yes, Scala has different idioms to Java, so naturally Java libraries don't make for idiomatic Scala code. There are many mature Scala libraries. Binary incompatibility has not been a problem for me in at least two years, and it is a necessary artifact of Scala compiling a language that is not Java to JVM bytecode. - Lambdas I addressed above. Slide 9 Don't know what point you're making here. Slide 10 Mostly addressed above. Syntax doesn't bother me. There are regular rules and the alternatives are a consequence of those regular rules. Would consider removing eta-expansion. Never had an issue with any of the rules though. Slide 11 See above. Slide 12 See above on type classes. Slide 13 This is very generic. Applies to all languages. Slide 14-15 Don't really get it. You can write code in many different ways. Applies to all languages. Slide 16 This is very generic. Applies to all languages. Slide 17 Don't get the point you're trying to make with this code. Slide 18 This is presumably a slide that summarises this section. Without hearing what you have to say here I can't really interpret this.

DanielBMarkham 12y ago

Saw some Scala at a conference recently. The guy was demonstrating using it to do TDD. I lost track somewhere in the first ten minutes or so, but it looked like he was importing/using multiple DSLs and helper libraries. After I lost track of the exact details, I started scanning for the gist of what he was doing. After an hour, he had what looked like the most massive clusterfuck I've ever seen in a project file -- all to do something that would take a dozen lines or so of simple FP script. Seemed like every functional thing he used was either also an object or had to be bolted into an object graph for it to work. The project file had scores of things in it. This did not leave a good impression. It reminded me of when I saw my first C/Win32 app and realized you needed a couple hundred lines of code and several files just to say "hello world" -- except this was a couple orders of magnitude more complex. It was a god-awful abomination. Hopefully Scala projects are not like this.

lmm 12y ago
Not all Scala projects are like this. There's a sect that wants to write tests in "human readable" fashion, e.g. the people who like Cucumber in Ruby; in Scala those same people write their DSLs within the language, something Scala is good at and that I'd argue provides real advantages over an "external" DSL. But you don't have to do that; I write Scala professionally and all my tests are just ordinary JUnit test methods.
- DanielBMarkham 12y ago
  Whew! I'm okay with using DSLs. Hey, if you have good FP, flaunt it. My concern after watching this, however, was whether or not the JVM development environment itself encourages complicating things beyond the most minimum thing needed to solve a problem when you're using it in a functional manner. (I haven't done Java in a decade). So, for instance, could I have just written a simple 12-line script to solve the problem he was banging around? Or would I have to create some kind of object with a "main" method? Could I just add in a test file and write functional tests from there, aka JUnit, or do I have to bolt something in that then requires a separate project structure and so forth (aka JUnit) There's no right or wrong answer for any of these types of project configurations. Heck, I like my tests in a separate project. It just looked like every time he had a new need, the project got 14 times more complex. The solution to one problem made the entire development environment more complicated for everything else. That's heading in the wrong direction, no? Admittedly I only had a brief glance. Thanks for the answer!

lmm 12y ago

Does the syntactic diabetes really bother people? Like, yes, these are different sequences of characters that mean the same thing, but visually it's very clear that they are the same thing; it's not the perl "there is more than one way to do it" where the ways of doing it are conceptually very different. It seems no different from complaining that I can write f(a, b) or f((a), (b)), which is a choice you get in almost every language. Implicits are dangerous, sure. Typeclasses are vital and extension methods are nice, but it might be better to cover these use cases with something more specific. That said, these days the IDEs flag up implicits so it's not really a problem day-to-day. Concise really helps readability at the function/module level - there's a huge drop in readability when a function reaches the point that you can't fit it on one screen. It may well be that the 1-line scala version of a method takes exactly the same time to read as the 10-line java version - but if it means you can fit your whole class on one screen, that's still a win. Symbolic method names are bad and I wish the community would move away from them. The definition of ++ is perfectly sensible once you stop panicking and start actually reading it. As is the parser; sure, it's a DSL, it uses some short symbols, but I defy you to find a better way to express the parser given. When you're building up a complex parser, it's well worth having a concise notation. jsonFormatX are legacy cruft. In a modern json library you can avoid them by using Shapeless instead; hopefully spray-json will do this too. The .toSet() example is deprecated and will give a warning if you actually try and run it. Java-8 style lambda compilation is already available under an experimental flag, and the next release will have full support.

oelang 12y ago
The author seems to think that java 8 lambdas are faster than scala lambdas. This isn't strictly true. Java 8 spins the inner classes for lambdas at first use, this gives them a performance boost at startup (loading tons of tiny classes from a jar is painfull for the jvm) but at runtime they perform the same (it's just invokevirtual). Another optimization that java 8 has is that lambdas that don't capture are cached & reused, scala does the same if you use the -optimize flag.
bsaul 12y ago
Syntactic diabetes is to me the best warning sign. It means the focus on orthogonality has been lost somewhere in the evolution of the language. There should be only one way to express a given language operation, and this way should be the simplest and most elegant. Not just because of aesthetic (which is crucial when speaking about readability), but also because it would combine the most harmoniously with other parts of the language. It seems to me that at this point scala should deprecate all non-essential syntactic sugar and features and reduce the language to its "core". Or, at the very least, people should start a fork with that goal. Hell, it could even be just a compilation option.

virtualwhys 12y ago

The IDE story has vastly improved in Scala, certainly nowhere near that of Java but decent nonetheless. The best way to shoot yourself in the foot is to have automatic build turned on in your IDE and to run SBT in a separate terminal; with that approach you get dog slow compilations, blocked UI, and other hair pulling madness. When SBT is boss (i.e. IDE auto build turned off and compile target shared between the two) then you'll have a far saner development experience. The OP hasn't been using Scala for long so many of his gripes boil down to lack of experience. You have to learn the ropes, the (myriad) corner cases, etc. of the language before things start to click. It's like starting out in Haskell, where on earth do you even begin to understand this utterly new paradigm, much less go into production with large scala projects in it? The answer is: you don't, you learn, learn, learn until you're well grounded in the language and its frameworks; then you bet the bank on it because you're sold on its clear-as-day powers. I'll go out on a limb and say that the only viable type safe alternatives to Scala and its ecosystem are C#/F# on .NET, and Haskell. In other words, yes, Scala has its warts, but overall is pretty much unmatched in terms of expressivity, power, and performance.

the_af 12y ago
I like Scala, but it gets me that the official IDE, Scala IDE, is so utterly broken. If you let the IDE handle the build, you'll constantly get spurious compilation errors, which in a statically typed language are unacceptable. Letting SBT do the build may work, but come on. This is the official IDE! Is there any acknowledgement in scala-ide.org that you should let SBT to do the build? Do Odersky and the guys at Typesafe use that setup, or do they suffer their IDE silently? I haven't had much luck with IntelliJ either.
- virtualwhys 12y ago
  Couple things to keep in mind: Java IDEs have had millions of man hours put into them; there's a reason they're rock solid reliable; that and Scala's power is a double edged sword: tooling becomes a more difficult proposition with greater language complexity. As Scala users we're basically guinea pigs in the IDE department. Having suffered from the relative stone ages of 2010 era Scala tooling I can honestly say that if you're considering picking up the language, you've come at a great time ;-) re: sbt running the show, not sure about IntelliJ but the core Scala IDE devs will drop that bit of knowledge when a user moans on the mailing lists about blocked UI, spurious syntax errors, and other bundles of joy.

fideloper 12y ago

Is there a book everyone recommends for learning Scala? In the beginner range, not someone coming from Java.

huehue 12y ago
`Scala for the Impatient` is really good.
- thescrewdriver 12y ago
  Scala for the Impatient is really good, but not sure that it's designed entirely for beginners. For more beginner-centric content perhaps check out: Learning Scala: http://shop.oreilly.com/product/0636920030287.do http://shop.oreilly.com/product/0636920030287.do http://chimera.labs.oreilly.com/books/1234000001798/index.html http://chimera.labs.oreilly.com/books/1234000001798/index.ht... ...or Atomic Scala: http://www.atomicscala.com/ http://www.atomicscala.com/
noelwelsh 12y ago
I'm writing one. It's almost ready. Drop me an email (noel at underscoreconsulting dot com) if you'd like to try it out.
ssmoot 12y ago
I second "Scala for the Impatient", but if you don't have any statically typed background it might be a bit tough. "The Neophyte's Guide to Scala" (http://danielwestheide.com/scala/neophytes.html http://danielwestheide.com/scala/neophytes.html) is hands down the best language introduction I've ever read though.
jowiar 12y ago
Odersky's Coursera is excellent. For me, it was vital to jumping the gap from "Here is a language that gives you a million ways to solve problems" to "I want to express this particular concept, so I designed a language well suited for expressing it".

mcv 12y ago

I kinda agree with this. Scala has good bits. Very good bits. Gorgeously beautiful bits, even. But the ugly bits are so terrifyingly ugly that I dare not touch it. Give me the Scala pattern matchers (that can also match by type and even by content of case classes, I believe), with the case classes and the actor concurrency model, but keep the horrendous type system and the confused parts of the syntax.

frowaway001 12y ago
> horrendous type system and the confused parts of the syntax Could you expand on that a bit? In my experience, Scala is one of the few languages which don't fight against everything you want to express in a typesafe way. Also, I find the syntax extremely consistent. Easy to remember and almost no special rules.
- mcv 12y ago
  The article shows some examples where you can choose between regular brackets or curly brackets. There's a lot of different ways to say the exact same thing. Why? Which is best? Are there any cases where one works but the other doesn't, and if so, why does the other exist? But maybe I'm too used to different brackets meaning different things. I'm used to Java and Groovy where brackets are used very consistently. The type safety goes way overboard with extremely arcane, incomprehensible expressions. The excessive power of the type system makes compiling far too slow. And the pattern matchers mean you can easily get your type back when you need it. I really strongly prefer the more dynamic approach of Groovy. Total type safety is a trap.
  - frowaway001 12y ago
    > The article shows some examples where you can choose between regular brackets or curly brackets. There's a lot of different ways to say the exact same thing. Why? Which is best? Are there any cases where one works but the other doesn't, and if so, why does the other exist? Yes, but which one would you remove? If you disallowed the curly ones, developers would suddenly require an additional language feature to define methods which could be used like this: using(someResource) { // do something with ressource } Apart from that {} has semicolon inference, while () doesn't. That's extremely helpful, if you have some expression and really want to make sure that it can't be split into something like { doThing1, doThing2 } by an unaware developer. > Total type safety is a trap. Sure, there are limits on what can be done with a type system, but these options have been growing larger and larger in the last decades. I wouldn't throw away the last 40 years of progress in that area and start doing stuff manually which any decent compiler can figure out for me. > Groovy I haven't heard from Groovy since a long time ago. Is it still actively developed? The last things I saw was that they were struggling to catch up, and work on the new MOP still wasn't finished. On the Gartner PLI, Groovy is way down on position 20. That doesn't look too promising either ...

wiradikusuma 12y ago

I submitted a YouTube video 165 days ago where Martin Odersky explains how to avoid coding the complicated way. https://news.ycombinator.com/item?id=7641626 https://news.ycombinator.com/item?id=7641626

xwowsersx 12y ago

From the looks of it, the author of these slides has written very little Scala. Take slide #7, for example, where he writes def bar() = { "1" } when def bar = "1" is perfectly sufficient. Ironically, I may very well be pointing out the bad parts of scala (i.e. that () is simply a convention for indicating Unit or side-effecting functions, but its just convention and not enforced by the type system in any way). Notwithstanding that, I don't think someone who has written very little Scala is in a great position to offer a reasonable critique. This is a longer discussion, but in the very first slide he points to the object-orientation as a plus. In my opinion, he's already wrong. "There is no such thing as Object-Oriented programming." See: http://blog.higher-order.com/blog/2008/12/04/no-such-thing/ http://blog.higher-order.com/blog/2008/12/04/no-such-thing/

taf2 12y ago

golang

thescrewdriver 12y ago
Perhaps you could elaborate on how naming a random language relates to this discussion...
- throwaway1979 12y ago
  Heh ... it is the other mainstream "hot" language. I was looking for a language to move to post-python. I love python but the 2.7->3 jump has been annoying. More than that, I felt I needed static typing for the next big system I did ... too much pain debugging python. I looked at Scala since it had the JVM behind it. While the language seems decent, it seems too easy to write unreadable code. Multiple ways of doing the same thing ... yada yada. Friends at Google had been espousing Go for a long time and I didn't bother. Seemed like a proprietary language with little adoption. Two things changed for me. I got some exposure to erlang via elixir. This made me think about the whole channel concept. Second, I had to read code in Docker (which is awesome). I learned a bit of the language and was surprised how small the language was. Really reminded me of C, which I love. There seems to be more adoption of Go .. e.g. Cloud Foundry and others. I like Go enough that I will be spending more time learning and investing in it. Just by 2 cents.

eranation 12y ago

I use scala a lot and it did become my go to general purpose language (as well as my workplace adopted it as a first class citizen and used for many new projects) I do have issues with it, but mostly with developers using (abusing) it. (And library authors that are a bit religious about the functional paradigm and simply love their operators... With great power comes great responsibility, the is no better description to this language. Also, I was looking at the CanBuildFrom hell with fear, but Odersky et al's book on Scala surprisingly did a good job getting the pieces in place for me. It even makes sense of the madness. http://www.artima.com/shop/programming_in_scala_2ed http://www.artima.com/shop/programming_in_scala_2ed Finally, Bozho is one of my most respected contributors on stackoverflow. And I can say that his slides actually do justice to Scala, I might disagree on the conclusions, but the facts are absolutely right.