9 ms·

Nice to see the language page be as easy on the eyes as the language itself. There's almost no excuse not to use Scala if you're deploying on the JVM. On a rel

by rtpg 13y ago

Nice to see the language page be as easy on the eyes as the language itself. There's almost no excuse not to use Scala if you're deploying on the JVM. 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

frou_dh 13y ago
Curiously, the Scala logo is reminiscent of the stairs in the photo at the bottom of the linked page. The ubiquitous "segmented drum" database icon has had me wondering before. Presumably it's a depiction of some big old vintage hardware.
moondowner 13y ago
The logo actually resembles the stairs @ EPFL :) https://secure.flickr.com/photos/gilles_dubochet/7327041044/ https://secure.flickr.com/photos/gilles_dubochet/7327041044/
- modersky 13y ago
  Yes, Gilles Dubochet crafted the Scala logo from these stairs.
- zabcik 13y ago
  Except the logo goes the other way. That's a little infuriating.
noelwelsh 13y ago
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.
- kaoD 13y ago
  In Spanish it's "escalera", close enough :P
  - omaranto 13y ago
    Maybe this varies from country to country, but in Mexico "escalera" means ladder, and "escaleras" means stairs (or the plural, ladders, with context disambiguating).
    - kaoD 13y ago
      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".
- deleted 13y ago
  [deleted]
- Dewie 13y ago
  It also means "scale able language".
kaoD 13y ago
> 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!"
- dinduks 13y ago
  Scala is statically typed while Clojure is dynamically typed. Comparing them is irrelevant. > There's almost no excuse not to use Scala if you're deploying on the JVM. s/deploying on the JVM/a Java developer/
  - fiatmoney 13y ago
    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.
    - chc 13y ago
      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.
- shadowfiend 13y ago
  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 ;)
pron 13y ago
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. ;)
eropple 13y ago
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.
- mark242 13y ago
  Wha? 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.
trailfox 13y ago
After learning and using Scala there is no way I would ever voluntarily choose to use Java over Scala. Simply put it's a better Java than Java. I really like the new site design, not all that bothered about the logo. Maybe Scala needs a mascot too :)
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?
laureny 13y ago
> 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.
- rybosome 13y ago
  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.
  - trailfox 13y ago
    Version compatibility is definitely a pain point, but as painful as that is I'd still pick that over using regular Java.
  - happy_dino 13y ago
    Can you give some details what caused the issues in your the 2.9 -> 2.10 migration?
coolsunglasses 13y ago
Or Clojure.
sam-mueller 13y ago
"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.
- virtualwhys 13y ago
  I built ScalaQuery 0.10 against Scala 2.10.2, not touching Slick until the library matures. Think Scala Pickling by Sara Miller at TypeSafe looks excellent for serialization needs.
  - phaller 13y ago
    Find out more about scala/pickling at: http://lampwww.epfl.ch/~hmiller/pickling/ http://lampwww.epfl.ch/~hmiller/pickling/ (It's Heather Miller from EPFL, though.)
- rtpg 13y ago
  For libraries: if push comes to shove, you can just use Java libraries. The bridging is extremely easy (invisible in most cases"
- coopdog 13y ago
  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.
shriphani 13y ago
>> There's almost no excuse not to use Scala if you're deploying on the JVM. The dev could be a lisper.
sultezdukes 13y ago
There's almost no excuse not to use Scala if you're deploying on the JVM Do you really believe that or just being flippant?

by rtpg 13y ago

frou_dh 13y ago

Curiously, the Scala logo is reminiscent of the stairs in the photo at the bottom of the linked page. The ubiquitous "segmented drum" database icon has had me wondering before. Presumably it's a depiction of some big old vintage hardware.

moondowner 13y ago

The logo actually resembles the stairs @ EPFL :) https://secure.flickr.com/photos/gilles_dubochet/7327041044/ https://secure.flickr.com/photos/gilles_dubochet/7327041044/

modersky 13y ago
Yes, Gilles Dubochet crafted the Scala logo from these stairs.
zabcik 13y ago
Except the logo goes the other way. That's a little infuriating.

noelwelsh 13y ago

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.

kaoD 13y ago
In Spanish it's "escalera", close enough :P
- omaranto 13y ago
  Maybe this varies from country to country, but in Mexico "escalera" means ladder, and "escaleras" means stairs (or the plural, ladders, with context disambiguating).
  - kaoD 13y ago
    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".
deleted 13y ago
[deleted]
Dewie 13y ago
It also means "scale able language".

kaoD 13y ago

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

dinduks 13y ago
Scala is statically typed while Clojure is dynamically typed. Comparing them is irrelevant. > There's almost no excuse not to use Scala if you're deploying on the JVM. s/deploying on the JVM/a Java developer/
- fiatmoney 13y ago
  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.
  - chc 13y ago
    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.
shadowfiend 13y ago
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 ;)

pron 13y ago

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

eropple 13y ago

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.

mark242 13y ago
Wha? 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.

trailfox 13y ago

After learning and using Scala there is no way I would ever voluntarily choose to use Java over Scala. Simply put it's a better Java than Java. I really like the new site design, not all that bothered about the logo. Maybe Scala needs a mascot too :)

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?

laureny 13y ago

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

rybosome 13y ago
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.
- trailfox 13y ago
  Version compatibility is definitely a pain point, but as painful as that is I'd still pick that over using regular Java.
- happy_dino 13y ago
  Can you give some details what caused the issues in your the 2.9 -> 2.10 migration?

coolsunglasses 13y ago

Or Clojure.

sam-mueller 13y ago

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

virtualwhys 13y ago
I built ScalaQuery 0.10 against Scala 2.10.2, not touching Slick until the library matures. Think Scala Pickling by Sara Miller at TypeSafe looks excellent for serialization needs.
- phaller 13y ago
  Find out more about scala/pickling at: http://lampwww.epfl.ch/~hmiller/pickling/ http://lampwww.epfl.ch/~hmiller/pickling/ (It's Heather Miller from EPFL, though.)
rtpg 13y ago
For libraries: if push comes to shove, you can just use Java libraries. The bridging is extremely easy (invisible in most cases"
coopdog 13y ago
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.

shriphani 13y ago

>> There's almost no excuse not to use Scala if you're deploying on the JVM. The dev could be a lisper.

sultezdukes 13y ago

There's almost no excuse not to use Scala if you're deploying on the JVM Do you really believe that or just being flippant?