> There's almost no excuse not to use Scala if you're deploying on the JVM.
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!"
I would take some issue with that. I think if you see the dual goal of creating a very strong, pervasive type system and trying to maintain OO compatibility, the features that are “thrown in” make a great deal of sense as a cohesive whole. It's certainly a complex language, but there is a coherent vision behind the features it has, IMO.
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 ;)
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.
I just think that dual goal is messy and not really a good goal. Can anyone comment on how possible it is to just ignore any OO stuff in Scala and just treat it like a normal statically typed functional language that happens to be on the JVM?
It's quite possible, up to a point. In fact, there is a new book "Functional Programming in Scala" that shows precisely how to do that. However, Scala is a fusion of OO and FP. Even its functional features are written in terms of objects. What you don't particularly need is mutable objects. But Scala's OO features -- notably traits -- are arguably useful for structuring code.
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.
Why wouldn't you be able to? That's sort of what they're getting at when they say (if you follow the link) right under the headline: "Or anything in-between."
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.
I'm not sure, I haven't looked very deeply at the language, I'm not sure if most of the libraries and culture and such make use of OO, or if it's just baggage for Java interop.
Quite easy with a couple of caveats:
1. You don't care about working with java libraries.
2. You don't care about generating tons of memory overhead.
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.
I haven't had any trouble doing mostly pure FP with Clojure, as the general pattern is to wrap Java libraries to present a functional interface, I guess I'm curious if this is the attitude in Scala, or if you're sort of forced to embrace OO.
As a Clojure guy currently learning Haskell since I'm curious about working with a good static type system, I'm interested in why you're using Scala instead of sticking with Haskell?
It's a bit of a simplification to say that Clojure is dynamically typed - for instance, all of the builtin data structures conform to particular interfaces (for instance Seq) and operations over those abstractions are resolved statically. You can even make it into a parens-y Java with raw method calls, and tell it to warn you if it can't resolve a call statically (albeit you usually have to hint the initial input).
There's also things like protocols, and Typed Clojure.
Protocol method references being resolved statically is just an optimization — it is not at all the same thing as a static type system like Scala has. There is no easy way in Clojure to say "This function takes an Address and a PhoneNumber" and have the compiler throw an error on compilation if Insufficiently Caffeinated You accidentally passes an integer in place of the PhoneNumber.
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.
> There's almost no excuse not to use Scala if you're deploying on the JVM
- 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.
OK, so you work with Scala on personal projects, daily. The issues you bring up then are based on your own experience, and presumably not various postings on the net about Scala, fair enough.
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 ;-)
We used Scala in production at my previous job. It was great for the most part, but upgrading from 2.9 to 2.10 was a massive, massive pain. I think I spent nearly a week on the refactor. We didn't even have that much code (relatively speaking); the majority of the time was spent on finding substitutes for the libraries which were irreparably broken, and rewriting client code against the new API. That's pretty damning, but we could have avoided the upgrade if the team had better communication, so I see this also partly as a human issue.
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.
To be honest, I don't remember the technical specifics...too much time has passed. It wasn't so much that a breaking feature change required rewriting code as it was that a single failure propagated. One component written in Scala on which my project depended was upgraded to 2.10, and a backwards-incompatible change in case classes broke the ability to serialize/deserialize objects between my project and the other component.
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.
Speaking as someone who uses Scala everyday for a largish organisation lots of this just seems wrong or irrelevant.
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.
> - Poor tool support (refactoring regularly broken on both IDEA and Eclipse).
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.
"There's almost no excuse not to use Scala if you're deploying on the JVM."
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.
It's incredibly difficult to find good Scala developers today, no doubt. However, it is incredibly easy to find Java developers who are curious about expanding their skillset. Those are the guys and gals who I hire, simply because it's faster for a Java dev to go through the ramp-up time on Scala than it is to wait for a pure-Scala dev to come onto the market.
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).
> However, it is incredibly easy to find Java developers who are curious about expanding their skillset.
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 =(
I guess it depends on your team. We didn't have much trouble with Java guys picking up Scala very quickly.
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 map performance is really an issue for you, you should look into using the parallel collections. For maps with less than 10k entries, I'm unable to see any difference between the immutable/mutable and ju.HashMap collections. For maps with >100k entries, it makes sense to farm out your iterating to multiple threads.
Put and lookup are much slower vs ju.HashMap. For most use cases where the system is already multithreaded the parallel collections don't gain us anything.
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"
java.util.HashMap is not thread-safe, so using it in the context of multiple threads reading from it is less than ideal.
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.
> For comprehensions can also cause some overhead, so if you're really pressed for performance a while loops is always an option.
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.
> 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.
Do companies actually restrict themselves to people who already have experience in a certain language when hiring? I've never encountered this practice.
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.
Recruiter here, and unfortunately many companies still won't look at people without having specific language experience (and often a specific amount of language experience). I find this has traditionally been more true in the Java world, where I've had clients ask for x years of Java and > n years of a specific framework.
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'?).
I'm not a recruiter per se, but I have been recruiting.
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.
Interesting points. A follow-up question for you regarding your belief in the focus on quantity over quality.
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.
I think it's about the culture. Many Java shops are simply assembly lines.
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.
This is definitely not representative of all Java shops, but I'd agree that some (many) are as you describe. I think the perspective that I get from JUG, where I have interacted regularly with hundreds of Java pros over a 10+ year period, gives me a sense of the morale of the Java community and their feelings about Java.
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.
While I agree that the "how hard is it to find an X developer" complaint is overblown, I think you are going too far. I can't just find a "good developer" and have them start working on a haskell project. They need to learn a lot if they don't have haskell experience.
Outside edge cases yes, but other wise in nearly all C based languages any one who claims to be an expert in one language, in a very quick time should be able to scale up and code in any other language.
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.
Someone had this argument (can't find the link) - for every ace Java developer out there you have hundreds of companies with a relevant position to compete over her / him. For a Scala developer position, you are competing with less companies, so you might as well be able to fill the Scala developer position faster than the Java one.
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.
As a recruiter, I think I'd have an easier time filling a Scala position because the demand for Scala jobs (primarily among those with little professional experience) has outstripped supply in the past couple years. If I post a Scala or Clojure job, I will get applicants from across the country. My Java job postings don't get nearly that much attention on a national level, because they are more common. People generally don't have to move for a Java position, but many are willing to move for a Scala/Clojure job.
You can basically write Java in Scala, you just have to change some small bits of syntax. There are no major semantic differences in the Java-esque subset of Scala's functionality.
It really depends on what kinds of developers you need.
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.
Yes, Android's Garbage Collector is a one legged mule. Slow, crippled and needy. Scala, on the other hand, generates a ton of little objects. I'm a full time Scala dev but if I were doing Android I'd probably for the foreseeable future work in... dare I say it? Java.
Sure but every anonymous function call creates new objects, as do each call to the collections library methods (often many objects), for comprehensions, tuple creation, lazy vals, pattern matching, futures, options etc. all create objects.
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 means "stairs" in Italian (and perhaps Spanish; I forget.) As another person noted, the logo is based on the stairs at the birthplace of Scala, EPFL.
Maybe this varies from country to country, but in Mexico "escalera" means ladder, and "escaleras" means stairs (or the plural, ladders, with context disambiguating).
In Spain (or at least where I live) "escaleras" means stairs, and "escalera" means both depending on context. "Escalera de mano" is the ladder-specific word.
"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 almost no excuse not to use Scala if you're deploying on the JVM."
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.
I've definitely felt the pain of Play JSON serialization, it's infuriating.
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.
I agree that the website reflects the language, but my take is the opposite to yours (and allow me to be a little mean):
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. ;)
There's almost no excuse not to use Scala if you're deploying on the JVM.
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.
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