What kind of things I can do with Scala that I cannot do (or they are very difficult) if I use Java?

[Rogerio Kioshi]

I'd like to know: what kind of things I can do with Scala that I cannot do (or they are very difficult) if I use Java.

[Bear Bibeault]

Concurrency is the major thing I've heard bandied about.

[saad khawaja]

The list is would be long. Here is a a link(http://www.artima.com/pins1ed/) to the Programming in Scala First Edition. It should give you a fair idea.

[Rogerio Kioshi]

Bear Bibeault wrote:Concurrency is the major thing I've heard bandied about.

Concurrency, like threads programming?

[chris webster]

Rogerio Kioshi wrote:Concurrency, like threads programming?

I think the idea is that it's not like threads programming in Java. There's some info on Scala Actors here, and Scala's Akka library provides a lot of functionality based on Actors (Akka is also available for Java).

And remember that "Akka In Action" is one of the books in this week's promotion!

[Josh Suereth]

Rogerio Kioshi wrote:

Bear Bibeault wrote:Concurrency is the major thing I've heard bandied about.

Concurrency, like threads programming?

Actually no. A fundamental idea in Scala is that threads programming is rather more difficult than worth it for most shops.

As an example, Scala has added "Futures and Promises" to the language. I recently gave a talk on multi-thread asynchronous programming that I think highlights the kinds of *different* things you can do with concurrency in scala: Functional Programming Patterns for the Asynchronous Web

Most of the code i their is pseudo-code, but it highlights the features of Scala that enable asycnhronous & concurrent programming to be far more elegant than Java.
Language features that make this style programming easier:
* For-expressions (monadic style)
* Closures

As already stated, "Akka" provides a different model of concurrency known as Actors. Actors are a simple way to express *concurrent processes* in such a way that very little actual machine locking occurs. It helps you design a concurrent application in many different ways, but is by no means a silver bullet. Essentially, akka views the world as a set of objects that can only communicate through asynchronus messages and each one has its own conceptual thread.
Language features that make this style programming easier:
* Closures
* Pattern matching

If you take a look at Scala's Future class vs. Java's, you'll notice that Scala's is far more powerful (and IMHO more useful) for actually gaining asynchronous concurrency and chaining together a set of tasks. Java's Future is more about "fork-join" style concurrency, where you *have* to join back on a future to get its result.

[Qunfeng Wang]

I took the coursera course of Functional Programming Principles in Scala by professor Martin Odersky, who is also the author of the Scala language. It's a quite exciting experience. Below are some points might make sense to your question.

1. Programming with recursion and high order functions. It usually means more elegant solution and less code.
2. Use immutable objects. Multi-thread programming will be easy with immutable objects.

The course will be restared in March. I strongly suggest you to take the course. It will provide you another view of programming. Below is the link of the course.
https://www.coursera.org/course/progfun

[Brian Hanafee]

Rogerio Kioshi wrote:I'd like to know: what kind of things I can do with Scala that I cannot do (or they are very difficult) if I use Java.

Pattern matching. A simple match in Scala can achieve the same functionality as reams of incomprehensible syntax in Java.

To me, a lot of the other differences aren't about something being more difficult to do in Java so much as it's about being more concise in Scala. Because it's concise, you can spend a lot more time reading code and a lot less time scrolling around trying to find code. The differences tie back to making a lot of the syntactic sugar optional. There are also stylistic choices that emphasize not including the sugar (for example, many Java shops consider it a huge violation to omit curly braces around a one-line block, but in Scala that's the norm).

On top of that, there's a vastly better collections library. It uses an inheritance system using traits that allows simple interfaces to bring along rich functionality.

To understand the power of the inheritance system and how it's used by the collections library, compare the Iterator and Iterable interfaces in Java to their Scala counterparts. Implementing the Java Iterator gets you exactly what you implemented: next(), hasNext() and maybe remove(). Implementing the Java Iterable gets you a single function that returns an Iterator. On the other hand, implementing the next() and hasNext() functions on a Scala Iterator gets you a few dozen methods with no further work, and Iterable gets you a few dozen more.

[Raymond Roestenburg]

There are of course language features in Scala that are not available in Java.

You cannot do the things that some of these features provide directly in Java.
If the effort of emulating this in java is too big compared to the effort in Scala I would for the sake of this question like to say that you 'cannot do it' in Java.
Otherwise you can do anything in any language which I don't think is what you are asking.

The main thing you cannot do in Java is write as little code in Java as in Scala to accomplish the same thing. That's a big thing for me.
On the other hand you can always write the same amount of code in Scala as in Java to accomplish the same thing, i.e. it never gets worse.

It's a huge thing that Java does not have first class functions.
For instance the Strategy pattern in Java (interface, implementation, delegate to interface) is not necessary when you have functions. You just pass a function to another function. (the function is the strategy)
You can sort of do the same thing with anonymous classes in Java as functions but it's so cumbersome that you really don't want to and its only on the surface that that is the same thing, you cannot just do partial application, currying, composition and so many other things you would like to do with functions once you get used to them.

type inference, expressions, vals, case classes, first class functions, pattern matching, traits, tuples, typeclasses, type constructors, implicits, objects and so many other features are all boilerplate cutters.

For instance in java you can't mixin functionality like you can with Scala traits. You will have to use composition/delegation. I wrote a post for a simple little pattern in Akka here http://letitcrash.com/post/30585282971/discovering-message-flows-in-actor-systems-with-the
and someone asked recently how to write this in Java. It's a lot more work. I wouldn't even want to try it. Sure it's possible but I just would not have the strength for it ;-)

And then there are features like macros that are not possible in Java. The new Typed Channels feature in Akka shows some of the possibilities of macros: http://doc.akka.io/docs/akka/snapshot/scala/typed-channels.html
You can't simply write something in Java that will be checked compile time like that.

I say try it out ;-)