Having jumped back into some green field work in Scala in the past few days, I will say I'm quite impressed with the improvements to the SBT, IntelliJ, universe. Compile time seems to be improved considerably (though the project is still quite small so time will certainly tell).<p>One problem, which is also one of the advantages of scala is that the interop with Java often means that all your Option[] etc code can still get NPEed by some offending Java Lib you've decided to use.<p>As the fidelity and ubiquity of pure scala libs improves this will hopefully go away to a some extend.
Scala gets a lot of things right by default. Also it got a lot of flexibility and power. Almost "a framework" to write other languages within the language.<p>Use it every work day for over two years... Like a lot, but sometimes wishes it would be a bit simpler and more aesthetic.
Fair Warning, I worked with the other for some time, and have been having an out of band convo with him.<p>One of the things I absolutely HATE about scala is operator overloading - and the excessive abuse of it. I ran into it just now using some library that used ==.<p>A Case:<p>List(1,2) == List(1,2); true
Array(1,2) == Array(1,2); false<p>The reason for this is obvious, list implements equals and does a deep compare. While Array.equals is a pointer compare (like how java do).<p>This would be obvious in Java because that would look like.<p>ArrayList<> a = ArrayList<Int>();
ArrayList<> b = ArrayList<Int>();
a.equals(b); // equal because it's a value compare<p>versus<p>int[] a = new int[5]
int[] b = new int[5]
a == b; // obviously false because it's a reference compare.<p>The lack of a universal idea about what == means is pretty dangerous IMO.<p>*edited for spelling
I would pay good money to see Paul Philips' reaction to the sentence<p>> "the biggest benefit with Scala is correctness."<p>...before the author goes on to say<p>> "When I say correctness, I mean the ability to easily and consistently write code that works as inteded (not the academic definition of correctness)"
Not mentioned here: pattern matching. It certainly goes a long way to ensure all cases are being handled, since the compiler lets you know when your patterns are non-exhaustive.
I see Scala as an alternative to Java/Go for Ruby web developers who want a statically typed language that feels more dynamic. Yes, you can go crazy with Scala, but if you are responsible, I would say that migrating from Ruby to Scala is easier than to Java or Go. (I use Scala at work commercially for 3 years now and I have my issues with it, but I don't have an alternative, tried Kotlin and Java 8, and some Go, couldn't give up Scala)
Another thing I like about Scala is its support for duck-typing like python, except it is actually enforced at compile time via traits and magic methods.<p>e.g you can define your own methods to sugar and desugar for pattern matches, define an apply method to treat a class like a function, or map() on an Option type - it simply behaves as a list of size 0 or 1 and that is all you need to map.
<p><pre><code> When I say correctness, I mean the ability to easily and
consistently write code that works as inteded (not the academic
definition of correctness).
</code></pre>
I'm curious as to what the author believes the academic definition of 'correctness' actually is. Is it something other than code "working as inteded [sic]"?
Been working with Scala for 1.5 years and loving it. sbt feels easy to work with, compile times have improved (and you can improve it further by modularizing your app). Scala gets a lot right. Type inference makes it <i>feel</i> dynamic while still being safely typed at the compiler. Pattern matching and everything-is-an-expression are really the killer features for me that makes my code much more expressive.<p>The one thing that does bother me, as mentioned elsewhere, is operator overloading. There is a veritable soup of operators and you're never quite sure what an operator is actually doing. Worse, there aren't any plaintext equivalents. scala.collection.List doesn't have any "prepend/unshift" or "append/push" methods... all you have are ::, :::, +:, :+, /:, :\, :::, ++:, :++, ++ and so on.
I don't get the business of marking variables as const in local scope (aka "val" aka "final" for local variables). It's easy for a parser or a person to scan the local scope and see if a variable is ever possibly mutated or not. This is very different from the situation with globals where it's generally intractable to prove that something is never mutated. In local lexical scope you can see all possible mutations by the definition of "lexical scope": a const variable is one that is assigned only once, a non-const variable is one that may be assigned multiple times – this is a straightforward syntactic property. Is there some benefit to marking local lexical variables as constant that I'm missing?
The main issue at the end of the day is compile time. They are working hard to address this, and from the first day we started using Scala to now, it's improved dramatically - but definitely lots of room for improvement where that's concerned.
I totally agree with the author. The one's mentioned in the article are really the key benefits. I really wish scala didn't have implicits. People go crazy with implicits resulting in very difficult to read code. Sometimes I feel like going back to java just for the readability and then I remember these nice features of scala. We need a scala minus implicits.