I started using Scala ~2.5 years ago for my undergrad thesis. At the time I didn't really know what I was doing and essentially wrote Java with map/reduce on collections.
I've been working steadily in Scala since and currently do so professionally. I'm a fan, especially with the Akka actor framework.
Lately I've been playing with Play, Akka and ReactiveMongo. For-comprehensions offer a terrific abstraction for dealing with asynchronous code. My current side project is "Street View for Flights" implemented in the above stack. Lots of calls to third-party REST APIs after checking if data has already been retrieved and inserted into Mongo. Code like the following allows for controllers to be asynchronous while staying readable:
The advantage for me is that those futures could be redeemed either by finding the requested object in Mongo and on failure retrieving it from a third-party API while not blocking and keeping the code readable. Either way, the controller just gets a Future without blocking.
Other parts of this project make heavy use of Akka actors to feed server-sent events (sort of a compromise between Comet and WebSockets). Development has been great fun because Scala really allows me to write code at a higher level. Asynchronous, typesafe, nullsafe code with the compiler as my safety net.
The maintainer and contributors have full-time jobs. On the one hand, part of that job is keeping up Scalaz for their own professional usage. On the other hand, no part of that job is documenting it for everyone else.
Really now? As if these guys get paid to do create and fix scalaz all day right? Like Oracle yeah? This is the story about every single open source project. You can choose something else, wait it out for documentation, or contribute it. Lucky you even have the source!
It's possible to make them typed with the stdlib[1]. Link also gives some reasons as to why they're untyped. Short answer is it started as a way to replicate Erlang in Scala[2].
At the risk of being trite, it's down to the order of evaluation.
You know that a for comprehension expands into calls to flatMap and map? So
for {
a <- forA
b <- forB
} yield a + b
expands to
forA flatMap { a => forB map { b => a + b } }
Remember that forB creates and returns a future. Only when this future has been created will it start running.
It should be apparent that forB is not evaluated till forA's future delivers a value, and thus the future returned by forB will run in serial with the future returned by forA.
In the other example the futures are created outside of the for comprehension, and thus start running in parallel.
Actors and the way Scala handles async is one of the reasons I wanted to get into using Scala on Android actually. The awkward way Android handles it is chock full of Java boilerplate and Scala's way is just much more elegant.
Another feature that got my attention was the ability to have a SQL framework that handled things similar to LINQ. I haven't tried it much yet, but Squeryl[1] has looked promising for being a Scala equivalent. I may have to look into Akka more though as that will easily take care of async SQLite calls as well[2].
I used Squeryl in my thesis (admittedly a while ago) and Slick[1] on a more recent project. Like you, I had ample experience in LINQ and it's definitely the feature I missed most from C#. I'm a fan of Slick.
I'm also looking forward to async SQL calls.
I've been building some Akka-based projects for a client and both they and I have been thrilled with the results. They're a startup that's gaining traction and they brought me in to help with scalability. I won't go so far as to say that Akka is a magic bullet but it makes reasoning about scalability far easier, though in our case we're mostly dancing around the IO bottleneck.
My GSOC project for this year is an extension to for comprehensions to enable LINQ-like conciseness without LINQ's inflexibility. If it ends up being merged into the compiler proper (a pretty big if), it should really help to make writing complex queries a lot less painful.
That's a shame, on both accounts. It looks nice and the right way to abstract out SQL, but admittedly, I would not use it if it won't let you drop down to SQL for something that needs it.
I've been working steadily in Scala since and currently do so professionally. I'm a fan, especially with the Akka actor framework.
Lately I've been playing with Play, Akka and ReactiveMongo. For-comprehensions offer a terrific abstraction for dealing with asynchronous code. My current side project is "Street View for Flights" implemented in the above stack. Lots of calls to third-party REST APIs after checking if data has already been retrieved and inserted into Mongo. Code like the following allows for controllers to be asynchronous while staying readable:
The advantage for me is that those futures could be redeemed either by finding the requested object in Mongo and on failure retrieving it from a third-party API while not blocking and keeping the code readable. Either way, the controller just gets a Future without blocking.Other parts of this project make heavy use of Akka actors to feed server-sent events (sort of a compromise between Comet and WebSockets). Development has been great fun because Scala really allows me to write code at a higher level. Asynchronous, typesafe, nullsafe code with the compiler as my safety net.