Hacker News Reader

Comment by RyanZAG | Hacker News Reader

"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.

View on HN

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"

You should take a look at scala's OpenHashMap - a mutable hashmap in the scala standard library that is often as fast as ju.HashMap. Link to scala doc: http://www.scala-lang.org/api/current/index.html#scala.colle...

I have used OpenHashMap, but the results are mixed sometimes is much faster, other times it's much slower. It really depends on the use case.

For some use cases (not necessarily yours), it's worth looking at Scala's concurrent.TrieMap.

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.

Scala's immutable hashmap is about 4-5x slower than ju.HashMap for reads and 6-7x slower for inserts.

> 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.

I've heard that argument here: http://2013.flatmap.no/simen.html

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.

> How easy is it to find a Scala developer if you need to expand your team compared to a Java developer?

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?

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.

Scala creates a ton of little objects? Are you aware that primitive types are only converted to objects in Scala, if they are used as objects?

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).

Reply on news.ycombinator.com