6 ms·

"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

by RyanZAG 13y ago

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

eranation 13y ago
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.
- fecak 13y ago
  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.
- Qerub 13y ago
  I've heard that argument here: http://2013.flatmap.no/simen.html http://2013.flatmap.no/simen.html
happy_dino 13y ago
> 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?
- wheaties 13y ago
  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.
  - brodo 13y ago
    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?
    - kasey_junk 13y ago
      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).
trailfox 13y ago
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
- mark242 13y ago
  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.
  - trailfox 13y ago
    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"
    - psuter 13y ago
      For some use cases (not necessarily yours), it's worth looking at Scala's concurrent.TrieMap.
    - orp 13y ago
      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.collection.mutable.OpenHashMap http://www.scala-lang.org/api/current/index.html#scala.colle...
mark242 13y ago
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).
- chii 13y ago
  > 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 =(
anonymoushn 13y ago
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.
- fecak 13y ago
  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'?).
  - bad_user 13y ago
    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.
deleted 13y ago
[deleted]
bad_user 13y ago
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.
rtpg 13y ago
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.

by RyanZAG 13y ago

eranation 13y ago

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.

fecak 13y ago
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.
Qerub 13y ago
I've heard that argument here: http://2013.flatmap.no/simen.html http://2013.flatmap.no/simen.html

happy_dino 13y ago

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

wheaties 13y ago
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.
- brodo 13y ago
  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?
  - kasey_junk 13y ago
    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).

trailfox 13y ago

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

mark242 13y ago
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.
- trailfox 13y ago
  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"
  - psuter 13y ago
    For some use cases (not necessarily yours), it's worth looking at Scala's concurrent.TrieMap.
  - orp 13y ago
    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.collection.mutable.OpenHashMap http://www.scala-lang.org/api/current/index.html#scala.colle...

mark242 13y ago

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

chii 13y ago
> 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 =(

anonymoushn 13y ago

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.

fecak 13y ago
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'?).
- bad_user 13y ago
  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.

deleted 13y ago

[deleted]

bad_user 13y ago

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.

rtpg 13y ago

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.