On a related note, does anyone else see the Scala logo and confuse it for a symbol representing databases or hard disks? It just doesn't click with me
Well, there are many excuses. Scala is a messy language* and I have Clojure which IMHO is a better alternative for JVM development.
I used both Scala and Clojure and settled with Clojure since it fits functional programming better. Scala is OOP with a bit of FP. Clojure if FP with OOP in case you need it desperately.
* "messy" as in "let's throw every feature we can think of into the language!"
> There's almost no excuse not to use Scala if you're deploying on the JVM.
s/deploying on the JVM/a Java developer/
There's also things like protocols, and Typed Clojure.
The typed module implements a static type annotation system and type checker on top of the dynamic language, which is nice, but that still doesn't mean Clojure is statically typed.
That said, Scala certainly ain't perfect. It's certainly got its warts. And I'm not going to compare it to Clojure, as I haven't played with Clojure enough yet ;)
Your discriminated unions would be "in drag" as case classes, of course. You would want to be aware of the OO parts of the language, but there's little that obligates you to use them.
Personally, if you don't have dependencies on java and if your goal is to do a pure functional application, I would stay away from the JVM as it just wasn't built for it.
As the language designer himself has said: Scala is not a better Java, it is not Haskell on the JVM. I would add that it isn't just SML on the JVM either. It is much better, in my opinion, to embrace Scala for what it is, a powerful, expressive, pragmatic language for industrial use.
My biggest problem with Scala, to date, is all the optional syntax. On one hand, making things optional sounds nice, and it can be handy... but in Scala, you can have a line of code where there are 3 or 4 different ways to write it. Sorry, don't have a good example handy, I'd have to go through my "learning Scala" workspace to dig something up and I don't have that stuff nearby. Anyway, the point is, I sometimes feel like Scala can easily lead to a situation where one is writing "write only" code. I do not relish the idea of taking a large base of Scala code, written by somebody else, and trying to understand it well enough to work on it.
Probably not if you want to keep that Haskell background. I feel Lisp/Haskell have very different philosophies and you might not like Clojure's.
OTOH, stepping out of your comfort zone is always a great way to expand your views (even if you hate Clojure at the end).
- Poor tool support (refactoring regularly broken on both IDEA and Eclipse).
- Terrible backward compatibility story (want to use CoolLibrary v1.0, which was compiled with Scala 2.9 and you're using Scala 2.10? You're out of luck, you need the library to be compiled with the same version of the compiler).
- Very slow compilations, and getting worse at each version.
- The language is big (as big as C++) to the point where you must agree with your team on which subset to use.
- It's so big that nobody can agree on which idioms actually to stick to: pure immutability? Functional style? OO only? Use scalaz or not?
Shall I go on?
I like Scala, I use it every day on personal projects but putting it in production at work would be a terrible decision right now.
That being said, I would be willing to use it again. I didn't have an issue with compilation speed, and the size/flexibility of the language wasn't really a problem; we wrote in what I believe is the idiomatic Scala style (immutable objects, FP). Going back to Java now, I SORELY miss lightweight lambda expressions, pattern matching, native Option type (that people actually use), and the emphasis on immutability.
Upgrading my project to 2.10, several of the dependencies no longer compiled. I don't remember which ones specifically, but I believe one of them was a JSON library. We had to find libraries that fulfilled the same roles, then rewrite the code that used those libraries against the new APIs. It wasn't horrible in the sense of there being a nasty, hard-to-detect runtime bug, rather that it required basically redoing all of the "glue code" with respect to libraries.
This wasn't painful enough to scare me away from Scala in the future, though it does make me leery of using Scala libraries from anything but top-tier vendors. That is, I'd use a library from Twitter, FourSquare, TypeSafe, Akka, etc. but never again from anything not widely known.
So, what do you actually mean when you say, "The language is big (as big as C++) to the point where you must agree with your team on which subset to use"? Like you, I work in Scala daily and have never thought, shit, oh no, here we go again, the dreaded subset problem.
"It's so big that nobody can agree on which idioms actually to stick to: pure immutability? Functional style? OO only? Use scalaz or not?", use it exactly like Java...until you don't. Scala is not Python, there are many right ways to use the language.
The Scala-is-slow mantra is trance inducing, I agree, you just hear the phrase and voila, it's slow. Modular development (i.e. sub projects) largely mitigate the Scala-is-slow noise. Incremental builds are of course snappy, scalac and SBT have made great strides in this area, and SBT 0.13 furthers this trend (debunking the "getting worse at each version" nonsense).
According to Odersky Scala 2.11 will include [paraphrasing] aggressively stripping out unused/extraneous language features and improving compilation times.
Agreed on IDE support, it will come around, ScalaIDE has improved a ton during the past year (avoiding Juno helps).
I see the Scala glass as neither half full, nor half empty -- it's overflowing, future is bright ;-)
You could file bug reports with Jetbrains to have them fix any issues you can reproduce. They're generally pretty good at following up and working on bug reports when I have filed them myself.
Alternatively, tell me what the particular bugs are and I'll try to reproduce them myself and then file a bug report(s) if you don't wish to. I use their Scala plugin quite a bit and while I don't think it's quite as good as their Java support yet, it's the best I know of for a Scala IDE.
Poor tool support: I haven't had issues with IDEA refactoring
Backward compatibility: upgrading apps is usually not too hard, and from 2.10 onwards BC shouldn't be such an issue
Slow compilation: if you are working on very large programs anyway I feel sorry for you - we try and keep our services small and simple and compilation time isn't an issue
Language is big: depends what you compare it to. But choosing a subset doesn't seem necessary. Just make sure people have read one or more of the various good style guides around (the Twitter Effective Scala one for example, or Odersky's recent talk from Scala Days)
- Ibid. You should be using a functional style, but leveraging OO (case classes really). Although I do sympathise that Scala is more complex here.
Some of the points you raise have merit (mostly the ones related to complexity) but unless you are using a Lisp they are almost certainly true for your alternative language (such as Java, C++ etc.).
But lots of people successfully use Scala everyday at work. The organisation I work for has pretty much moved entirely to Scala now (from mostly a Java base) and we have about 60 devs. So it definitely can be done. And I haven't found a single person who wants to go back to Java.
There is one incredibly good reason - possibly the most important reason. How easy is it to find a Scala developer if you need to expand your team compared to a Java developer?
I'd put it the other way around: what excuse do you have for spending more per developer? (There are some excuses here, but they're far from clear cut.)
In addition, Scala tends to run slower than Java which can have a further cost if you're scaling to many servers. Porting Java code to Android is also far easier than porting Scala code.
Regarding speed, I don't mind about the runtime speed as much as compile speed, runtime speed is getting very close to Java, and is much faster than popular dynamic languages, I think it's a great alternative to JRuby, Jython or Clojure in that aspect.
How easy is it to find a GOOD developer? Much easier with Scala. It's not like wading through hundreds of Java resumes and interviewing them is free.
> In addition, Scala tends to run slower than Java which can have a further cost if you're scaling to many servers.
This depends on so much different factors in both Java and Scala that I'm happy to dismiss this claim as “not true”.
> Porting Java code to Android is also far easier than porting Scala code.
Really? Is there anything more to do than ProGuarding and dexing the existing code, both in Java and Scala?
If you are programming in a functional paradigm you will be throwing off garbage, often when you wouldn't expect to from a cursory glance at the code.
You can mitigate it, but often to do so you have to resort to writing scala as java (which is still better than java as java).
Scala performance is on par with Java if you keep your wits about you, but you do have to be mindful of the code you write. Scala collections (esp. maps, doubly so for immutable.Map, but also mutable.Map) are (currently) slower than the standard Java collections, but it's easy to use an implicit conversion wrapping a Java HashMap with little to no overhead in the very small number of situations where this type of thing is a bottleneck. For comprehensions can also cause some overhead, so if you're really pressed for performance a while loops is always an option.
If anyone from typesafe/Scala is reading this: please bring the performance of mutable.Map on par with java.util.HashMap
If you have a large read-only map being read by multiple threads (doing random lookups) ju.HashMap leaves both mutable.Map and immutable.Map very far behind. Scala is great, but the Map performance lags.
I'm not the only one who has noticed. Try googling "Scala map performance vs Java"
The great thing about Scala's immutable HashMap is that in terms of concurrency it is worry-free. You couple it with an AtomicReference and presto, you've got a non-blocking, concurrent HashMap.
I work on a really high-volume web service that's built on top of Scala. The performance of Scala's immutable collections has been the least of my worries.
In most cases in which I need a while loop, I use a tail recursion instead. You can keep your code free of side-effects that way and the compiler generates code equivalent to a while loop.
Hear, hear! I can corroborate this statement and have benchmarked it quite a bit in the past. If you can mark a method as @tailrec in scala and the compiler does not complain, it will go as fast as if it were written with a while loop. And in many cases it will feel cleaner as well.
Of course, not everything writes itself nicely in a recursive style, for this you should use while if you need the performance. Don't be afraid, scala is after all a mariage between OO, functional and bits and pieces of everything nice. It's still there for a reason.
* the @tailrec attribute is not necessary but forces the compiler to complain when your recursive method is not, in fact, tail recursive. It's also good documentation that a developer who makes changes should keep it tail recursive because it's sensitive.
Scala does not run slower than Java. Period. Additionally, the very nature of Scala and Akka allow you to be much, much more efficient on the hardware you're using; if you're writing Java code that requires, say, 100 application servers, often times you can get away with half of that if you're writing good Scala/Akka code (and because of the nature of Scala, it's much easier to write good, solid code than it is in Java).
which is good and all, but i think most businesses (especially large corps who is hiring for an internal line of business product that is serving their real business) do not want to invest in their human resources this way =(
It is fairly hard to find a good developer, but once you find one you can tell him or her to write Scala or Java or OCaml or whatever you like.
I spent most of my 15 years working almost exclusively with Java shops that were often this specific. In working with Ruby, Python and Scala/Clojure shops over the past couple years, I find they are much less concerned with which languages you know today. I'm not sure if this is a function of a programming culture in these shops, or if it has more to do with the huge amount of Java developers available and the perception of more limited number of available talent in some other languages (do Python shops hire non-Python programmers because they 'have to'?).
On the question "do Python shops hire non-Python programmers because they have to?", from my experience the answer is Yes, but the reasons are twofold.
On one hand, yes, it is harder to find Python developers and it makes no sense for a company to restrict itself to such a limited pool.
On the other hand it is also a matter of culture - companies that use less popular technologies often do so for good reasons. Such companies are often looking for good developers in general. In my interviews the least of my concerns is the programming language the candidate used, when most people fail to satisfy me on questions like "describe the perils associated with concurrency and parallelism".
The companies focusing on Java that you speak of, on the other hand, have no need for good developers as they focus on quantity, not quality. For them it is far more valuable to hire replaceable resources.
In your opinion, do you think that the perceived focus on quantity over quality is representative of the culture of some Java shops or a function of the Java language itself (a necessity for more programmers due to the nature of the language)?
I've run one of the larger Java Users' Groups in the US (Philadelphia) for over 13 years, but I keep a very open mind on things, and I have been critical of elements of the Java space in the past.
And really, it's logical - if you want to build an assembly line, you pick a popular language for which you've got not problem in finding cheaper developers.
This isn't representative of all Java shops btw. And if you've got a different perspective due to your involvement in a JUG, you do have to keep in mind that people (or companies) joining a JUG do so because they want to be a part of a community, or for the learning experience, which is why JUG members are not representative.
I wrote an article about this last year (http://jobtipsforgeeks.com/2012/07/11/advice-from-a-jug-lead...) that goes into the sudden spike in interest for topics that were not Java language specific, and our transition into a group focused more around the JVM than just the language. This transition was driven by what I generally considered the unofficial though leadership of the group, who were gravitating away from the language. This is just around the time of the Sun acquisition when this became most obvious, which may have precipitated some of the changes.
Paradigm changes are difficult to handle, for example Lisp will be a little to grasp if all you have ever worked on is some thing like Python.
On the problem domain I'm working on, the concern of the programming language used by candidates is the least of my worries when looking for people. And yes, the people we are looking for are more expensive than average. But that's not because they can work with Scala.
I really like the new site design, not all that bothered about the logo. Maybe Scala needs a mascot too :)
"Voy por la escalera" sounds fine to me if you're taking the stairs.
EDIT. Another example: when a building is divided in two stairs (left and right) we mark it as "Escalera Izquierda" and "Escalera Derecha".
There's a good reason, actually - library maturity, especially when trying to get data in and out. Try and do some inner joins with typesafe slick and you'll know what I mean when you see the SQL it generates.
Or try and use Play Framework's json de/serialization, and be prepared to punch your monitor in the face.
I think these critical libraries can get there, but the lack of resources on these projects has me thinking we'll be waiting awhile.
Think Scala Pickling by Sara Miller at TypeSafe looks excellent for serialization needs.
(It's Heather Miller from EPFL, though.)
There's a macro that will take an entire object, generate the converter and do the conversion in one line of code, but it won't let you choose which fields not to send. So your list of users get their password hashes sent too.
For deserialization I just do it manually by pulling the fields out of the objects sent.
The new Scala website perfectly embodies the philosophy of the language which says that if you squish together many concepts and elements, each of which is good on its own, then the result simply must be good as well. ;)
The dev could be a lisper.
Lots of garbage generation. I like Scala a lot, but the space where I can really use it is smaller than I'd like. I do really like it and Play for one-offs, though.
In practice, we have seen much much _less_ garbage created by our Scala code. The use of objects in Scala encourages static method creation, and there's so much boilerplate Java junk that your Scala code just doesn't need.
The ubiquitous "segmented drum" database icon has had me wondering before. Presumably it's a depiction of some big old vintage hardware.
Do you really believe that or just being flippant?