Brand new Scala-lang.org | Hacker News Reader

Brand new Scala-lang.org

scala-lang.org

212 pointsbad_user126 comments

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

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.

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

Yes, Gilles Dubochet crafted the Scala logo from these stairs.

Except the logo goes the other way. That's a little infuriating.

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.

In Spanish it's "escalera", close enough :P

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

It also means "scale able language".

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

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/

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.

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

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?

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.

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.

(Disclaimer: I'm pretty much a n00b at Scala)

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.

Coming from a haskell background, I found scala + scalaz fits all my needs. Is there a reason I should still try clojure?

> Is there a reason I should still try clojure?

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

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?

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.

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.

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

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

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

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

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"

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

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.

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.

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 =(

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.

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.

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.

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

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.

Version compatibility is definitely a pain point, but as painful as that is I'd still pick that over using regular Java.

Can you give some details what caused the issues in your the 2.9 -> 2.10 migration?

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.

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

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

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.

Or Clojure.

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

Find out more about scala/pickling at: http://lampwww.epfl.ch/~hmiller/pickling/

(It's Heather Miller from EPFL, though.)

For libraries: if push comes to shove, you can just use Java libraries. The bridging is extremely easy (invisible in most cases"

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.

>> There's almost no excuse not to use Scala if you're deploying on the JVM.

The dev could be a lisper.

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?

I recently installed Scala. I'm a PHP Dev, who plays around with Clojure on the side, but wants to be converted into the static typing camp. I also wanted to keep things functional (hence my love of Clojure, and my PHP code keeps things as immutable as possible), but also have a language that is usable if I were to go and get another programming job.

Scala seemed a perfect fit. Until I looked at job boards for Brisbane :(

For those that use it regularly, what sort of things do you build in.it? I really want to replace PHP with something, but between Enterprise Language Java and just-as-dynamic-as-PHP Ruby and Python, Scala looks like the only language that might fit... but then Play as a framework looked very heavy for my usage.

On lightness, you'll have to evaluate. But Lift is an approach to web development that is relatively different from most out there, and which I've found tremendously refreshing, taking some really awesome approaches to separation of content and behavior and other stuff. It also embraces the benefits of static typing throughout and makes real-time stuff stupid easy. You can usually tune how many of Lift's more advanced features you use fairly easily—using it as a simple REST-based server is easy and still extremely pleasant, but going beyond that is also awesome.

Disclaimer: I found it so refreshing and awesome that I'm now a Lift committer.

We use Scala and Play to build (almost) any sort of web applications. The main reasons IMO are type safety in the code, the templates and the routes. The actors model allows doing side processing pretty easily too. Not mentioning the elegance of Scala itself.

> Play as a framework looked very heavy for my usage

What do you exactly mean by heavy? Actually I think it's quite simple since you only have to download an archive, unzip it, and start writing code as you would in any MVC Web framework.

Spray.io is great for building API. It usually has better performance than Play.

Scalatra is Scala's Sinatra, but the compiling times take out all the joy in using this kind of frameworks.

Another Scala Web framework is Lift, but I don't know much about it.

>but then Play as a framework looked very heavy for my usage.

The terms "lightweight" and "heavyweight" and variants get thrown around alot describing frameworks, but can mean different things to different people:

- size of framework codebase

- size of app codebase

- amount of code it takes to accomplish common tasks

- memory footprint

- deployment system

- learning curve

- feature list (barebones vs kitchen sink)

etc etc. If you could elaborate a little on what heavy and lightweight you're referring to, the Lift/Play/Scalatra/etc experts might be able to better address that.

In my testing, I evaluated Play 2 (right on release), and Grails 2 (Groovy is nice).

My thing is, Play seemed to do literally everything. I think it would be brilliant if I knew Scala well, but my problem is I dont even know Java! Ill use that as a segue: I had the same issue with Groovy/Grails -- great framework, nice language, but my lack of Java experience hasn't.made things as productive as I expected based on the hype I've seen.

Play simply seemed like I was learning Play, not Scala. I felt the same way when using Rails, which I never took too. The only larger more fully featured framework I've used and enjoyed is Symfony2, and that is solely due to my expertise in PHP.

I hope that helps explain what I meant. What should I do?

Was in same boat as you 3 years ago, new to the JVM.

Started with a few pleasant months of pure Groovy, followed by 6 painful months with Grails (during the pre 2.x days). At that point I had my feet wet and realized that Groovy, as language, was not going to cut it (tried building a CRUD layer on top of Grails and Groovy's lack of static typing became a real thorn).

At the time James Strachan had ditched Groovy (the very language he had created, mind you) and was raving about the wonders of Scala. Interested I picked up the stairway book, Programming in Scala.

That changed my life as a programmer. Checked out Scalatra, Spray, Lift, and Play. Play wound up being the best fit.

I still get JIRA notifications for bug requests I created with Grails -- each one the devs just kick the can down the road (fix) to the next version, glad I left ;-)

lol, now this is ironic, not having received a Grails JIRA notice in quite some time, after posting the above I checked my email and voila:

"Shared constraints not working in URL mappings Fix Version/s: 2.3-RC1 (struck through) Fix Version/s: 2.3-RC2 (the kicked can)" ;-)

As hackerboos suggested, try Scalatra [1], the Sinatra of Scala frameworks (eg, simple, lightweight).

As for not knowing Java, there's not a whole lot of carryover from Java at the language level. There is at the JVM level obviously, but you can ignore JVM tuning and bytecode and whatnot till later.

In fact, I actually found learning Haskell to be more valuable than Java in understanding Scala. Learn You A Haskell [2] is one of the best general programming books I've read, Lipovaca is excellent at explaining complicated functional programming concepts.

[1]: http://scalatra.org/

[2]: http://learnyouahaskell.com/

>Play as a framework looked very heavy for my usage.

Try Scalatra.

Play version 2.x is not heavy, being pretty modular and elegant. Give it a try.

On the job boards problem - the funny thing in this industry is that you're more likely to find jobs because you use a certain language that's not as popular as Java or PHP.

It's a supply and demand issue. Yes, there are many jobs for Java and PHP. But there are also many PHP and Java developers. And as a general rule of thumb, for finding good jobs smart developers focus on skill-sets that are much narrow and harder to practice than usage of a programming language.

Focus on scalability issues, on design, on social skills, on data analysis - people that are good at such things are worth their weight in gold.

I just had a look at Scala jobs around Australia. $200k plus is the average salary.

Time to start learning Scala properly, it seems. :|

I went from only doing PHP to working in Scala so it can be done. You'll need to do a fair bit of learning on the side if, like me, you were more of a 'PHP-developer' than 'developer' (by which I mean your CS knowledge and broader programming knowledge was lacking).

But if you are already familiar with functional programming, data structures, etc., then it will be straightforward as Scala has a nice syntax - at least, it does for a C-style language.

On the frameworks debate, I've found in the past that trying to use a large framework and learn a language at the same time is just too difficult because you are overloading the learning. Sticking to Scalatra here might help because you don't need to work hard to understand the framework, so you can focus on making your app and learning Scala. Play is probably nice once you understand it, but they'll be a lot more domain knowledge needed to use it effectively.

The sbt site ( http://www.scala-sbt.org/ )is still impenetrable to anyone trying to understand wtf it does in under 15 minutes. (Why do I need this? How is it different than the scala compiler? Is it a package management system? Is it a REPL?)

The first words of the website: "sbt is a build tool". I couldn't understand not grasping the benefits/differences of sbt in comparison to other build tools, especially if you're new to the JVM world, but I don't think the website leaves any doubt to what it is.

Build tool is a very broad category though. It could be improved by drawing a comparison, such as "sbt is a build tool, like make/bundler/whatever in scala"

Part of the problem is probably that sbt is basically every build tool combined into one.

You basically use it instead of Maven or Ant to build Scala/Java projects, but it's ridiculously comprehensive and extensive. I'm not sure calling it a mere "build tool" does it justice, more like "Recursive Extensible Project Management Tool" or something along those lines. And yes, it has both package management system and a REPL, among other things.

The new homepage gives Scala a very classy feel! Nice!!

This comes as a (personal) advise to all my fellow startups here.

Dear dudes and dudettes,

I've been a long and hard fan of the 'Get shit done' mentality and I still am. From my past experience running Rails and Scala, I'm going to tell you what exactly you should do for your startup:

1) If you KNOW FOR SURE your startup will face a lot of page views, requests etc. before hand (Example - Real estate portals like Airbnb, Trulia, etc), then you should not make the serious mistake of ignoring high performance frameworks beforehand. This could literally be anything, but the alternative I personally recommend is something Scala based [Read section 4 for WHY].

2) As usual, use Rails (or django/similar) ALWAYS to build your v1 prototype. I say always because you will be incredibly surprised to see how much rails gets stuff done for you. While this is a huge advantage initially, this can also become a nightmare, later. Hence, I suggest you use rails only initially and not forever.

When you build your app with rails initially, you're overcoming the most irritating pain point (or I'm just too lazy) - Building the database. Building the database with the required fields manually can be tiresome, if not slightly dangerous (assuming you are inexperienced). So, I suggest you install devise:

    gem install devise

And implement authentication through it. Why? Because Rails+Devise will create some useful columns for you auto-magically - created_at, updated_at, sign_in_count, etc. (to name a few).

3) Now, you NEED to understand what's happening underneath devise as this is one of the core portions of your app. For this I suggest this rails cast:

http://railscasts.com/episodes/250-authentication-from-scrat...

Now that you understand how the most important part of your app works, you should start to build a clone of your v1 on your desired high-performance framework of choice. I use Scala personally (and I would recommend you too).

4) So, Why Scala?

#Scala has a decent minimal syntax compared to Java, PHP and the rest.

    Scala:
    def test = {"hello world"}
    
    PHP:
    <?php echo "hello world; ?>

    Java:
    class HelloWorldApp {
    public static void main(String[] args) {
    System.out.println("Hello World!");
    }
    }

# Generally, on an average, 1 line of Scala = 10 lines of Java. That's less maintainable LOC (it can be argued otherwise, but just assume it's a good thing)

# Performance. Now this is where Scala really shines. Scala's base performance is almost near Java's in most real world scenarios. You get the benefit of Java without actually using it. How fast is Scala in contrast to Ruby? Well:

1 JVM = 10 thins ("Rails is meant for a toy blog engine" - Soundcloud)

Source: http://www.slideshare.net/pcalcado/from-a-monolithic-ruby-on...

Approximately 20-40x faster: http://www.techempower.com/benchmarks/#section=data-r5

#Inter-operability with JAVA. This is a HUGE plus. While everyone loves to bash Java, you should not forget that it's a tried and battle-tested enterprise backed language. It's horrible (arguable), but reliable. So, this means, you can use that high performance image-processing function written in Java you always wanted by calling it from within your scala code NORMALLY. Now that's why I prefer Scala over newer languages like Go (It's really good, but the library support is still growing). Don't under-estimate this use case. Some secure functions used for authentication are available on various implementations on the Java land, compared to Go, etc.

---------

5) So if you use Scala, there's a lot of alternatives for frameworks out there. The most popular ones are Play, Lift and Scalatra.

Play - Claims to be Rails like, but not even close to it. You need to work out everything on your own. Some stuff is still buggy and some are still scary (implementation of security functions). Stateless.

Scalatra - Sinatra for scala. Minimal, super-fast, awesome. (I personally recommend this). Stateless.

Lift - Tried and battle tested, used in production by so many popular guys (Foursquare for example). HUGE learning curve and too heavy for a framework. A hell lot of stuff is done automatically for my taste (like generating it's own login boxes with forgot password links, for example).

Performance comparison of all three frameworks here:

http://www.techempower.com/benchmarks/#section=data-r5

Note: Scalatra is the fastest (for most use cases) of them all.

6) Now, write a clone of your app in your framework of choice. Use the v1 Rails prototype initially to get your investors, clients, etc. But, by v2, ship out the code on Scala. This means,

#Reduced costs (1 app server vs 10 app servers)

#More time to focus on business activities and a LOT more time before you need to start worry about scaling (the framework)

Pls note: The above point isn't true if your app is db constrained.

Database suggestions:

Please ignore the noSQL hype. noSQL is DAMN GOOD for prototypes (use it for your v1) and for specific production use-cases. 99% of the use cases are covered by SQL. And the noSQL hipsters have created a terrible image for SQL databases that they don't scale, etc. But it simply isn't really true. Even something as basic as MYSQL scales pretty well. As documented by Quora's founder here:

http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use...

Also, noSQL isn't a golden solution: http://blog.engineering.kiip.me/post/20988881092/a-year-with...

Some popular questions:

1) Scala engineers are difficult to find and hire

This is partially (in)correct. If you face issues with your Scala code OR if your scala code is the bottleneck (highly unlikely), then you can always hire a good Java developer and have that particular function/code module re-written in JAVA. Java developers aren't difficult to find. Also, If you made the transition from Ruby to Scala, so can anybody else.

2) The productivity gain vs Performance gain

If you write your app in rails, you get a lot of productivity benefits, at the cost of performance. If you write your code in Scala, you lose your productivity at the gain of extra performance. So which one should you choose?

There is no doubt that Rails scales really well. But, out of the box, it is slow. Imagine it this way:

There are two ways to make a sculpture - Using plastic (Rails) and using metal (Scala/Go/etc). Sculpting a metallic structure is hard (ignore molding techniques). Sculpting plastic is easy.

But if you stress the plastic sculpture, it simply breaks out. There are lots of commercially available metallic coatings for your plastic sculpture that will promise you of no breakage etc. (SOA, Scalable PaaS like Heroku, etc.)

But they are expensive, and they don't eliminate your pain points as promised. At some point you or an engineer is going to worry about the code. Better be it you and now than someone else, later.

It is important you understand what goes under a framework's Magic (like authentication, database calls, etc) than just blindly believe it to be magic. This will not only make you a better developer, it will also help you from being taken advantage of by your outsourced companies or your engineers.

--------

I just poured out everything from a personal stand point. Frameworks are a matter of personal choice - You choose whatever that resonates with your philosophy. So, at the end of the day, be sure to go with whatever makes you happy (and confident).

All the best.

This is very helpful. Thank you for taking the time to write this.

You're most welcome.

Great write up!

One small picky thing:

> Scala: def test = {"hello world"}

Can be actually

   def test = "hello world"

p.s. you can play with Scala code live in the browser here:

http://scalatutorials.com/tour/ (work in progress)

To get parity with his PHP & Java snippets, you probably want one of several variants below -

    scala> def test1 = println ("hello world")
    scala> def test2(f: =>Unit) = println ("hello world")
    scala> def test3(f:Unit) = println ("hello world")
    scala> test1
    hello world
    scala> test2()
    hello world
    scala> test3()
    hello world
    scala> val t = test2 _
    scala> t apply Unit
    hello world
    scala> t()
    hello world
    scala> t(())
    hello world

I will leave it as an exercise to the reader to distinguish between these thunks :)

It can go quite crazy on function definition styles:

    val add:(Int,Int)=>Int = _ + _

(from http://scalatutorials.com/tour/12_tour_of_scala_anonymous_fu...)

Oh noes, I purposely avoided this variation because I didn't want readers to think functions don't have braces AT ALL. :)Thanks for your input!

This looks like the Perl philosophy applied to Java world. I'm all the more motivated to go ahead try this now.

Nice comment. Question: can you recommend any libraries/frameworks for interacting with the database. E.g., something like the ActiveRecord in rails, or perhaps hibernate?

The closest I can think of is something called 'Slick'. It has a bit of a steep learning curve, though. Also the docs are a bit scattered.

http://slick.typesafe.com

># Generally, on an average, 1 line of Scala = 10 lines of Java. That's less maintainable LOC (it can be argued otherwise, but just assume it's a good thing)

># Performance. Now this is where Scala really shines. Scala's base performance is almost near Java's in most real world scenarios.

Scala's great, but don't overhype it. I just finished re-writing a mid-sized (~30k LOC) API app from Java (Play 1) to Scala (Scalatra). In this case the code size was reduced to about 40% of the original, but we needed about 50% more CPU and 100% more RAM to get comparable performance.

It was still well worth it - aside from the reduction in the size of the code there are additional maintainability benefits from immutability and other nice aspects of idiomatic Scala.

Wow! But, I am not sure, I think it varies with individual use-cases. The last time I checked for a simple CRUD app, I got a good 85% performance of the Java equivalent.

In this app we're doing a lot of serializing and deserializing of large JSON objects (using Jackson in Java and Json4S-Jackson in Scala), which is the main performance bottleneck.

Thank you for the useful insight! :)

Good points. However, regarding performance, you can get a lot of mileage by moving over to JRuby + Torquebox (cluster) and further improve response times by adding a caching layer and maybe throwing in Angular.js / Backbone.js (templating moves to the client side). So the goodness of Rails dev speed and the performance of JRuby is a decent combo IMHO. But like you mentioned, if you need to scale beyond that Scala is a good option.

Saying that "1 JVM = 10 thins" to discard Rails is either ignorant or misguided. JRuby brings all the power of the JVM to Ruby. Use Puma + JRuby for a simple and performant solution. Want Netty, HornetQ and Infinispan? Use Torquebox.

The page loads quite slowly on my macbook air. I wonder how many 'reactive' Scala web technologies went into the creation of it!

Scala is wonderful and all the hard work put into it is greatly appreciated. However, every Typesafe product targeting the web that I've tried has given my browser indigestion.

It must be something with safari as it is very slow on my iPhone running iOS 6

> The page loads quite slowly on my macbook air

The 3771 DOM elements composing the front page may be the cause.

Chrome in OS X here and it all seems fine.

A billion useless nested divs will do that.

It's quite a pretty site, but the home page loads very slowly on my quad core I5. Something about this page is hanging up the dom onload event pretty significantly - Network tab showing about 7 seconds. Got a screenshot of the network tab here: http://farm4.staticflickr.com/3769/9399721127_a63086e535_o.j...

Luckily the api docs and tutorials are unaffected and load quite quickly.

Beautiful. Glad to see another open source project with a solid site.

The staircase in the picture down the page is mirrored compared to the Scala logo. I've added some css to 'correct' this ;-) Pull request here: https://github.com/scala/scala-lang/pull/75

Play Framework is as good for v1 prototype as RoR/Django/Grails/PHP frameworks. But it's better in the whole project development process as you can easy go from v1 to v2 with it )

Very nice, but this still sucks ass => http://www.scala-lang.org/api/current/#package

Anyone else find this hard to read? The light blue/cyan is about 3 shades lighter than ideal. Especially for links.

I've always been intrigued by Scala as everyone says it's super fast but I was put off by the fact it had 'Java' in the description. But, looking through the new site (looks brilliant!) I think I'll take a look as it's got a nice syntax :-)

The ribbon as a brand logo is still not working for me. In its red colored form, it has an ugly faux 3D shine applied to it. In it's flat form, it is just a bunch of white waves, hardly recognizable or interesting.

The page is nice! But it doesn't have snippets. They are very useful to get the feeling of the language at a glance.

Scala took the hipster way. I hope it will catch some new peoples attention because it is a lovely language.

Summary:

Object Oriented Programming: Everything is an object

Function Programming: Everything is a function

Scala: Everything is a function and an object both

Very nice, except for the typesafe blue that crept in at the bottom. That site needs an overhaul.

It's beautiful! The original one is good enough, this is even better.

Good job!

great design but some text are hard to read. dark color or dark background and no scrollbar on chrome.

Reply on news.ycombinator.com