Disclaimer: I'm not a Scala guru.
Scala does two things extremely well which Java (currently) does not.
Solve functional problems
At the most basic level, Scala has fully fledged closures with collections support. This means you no longer have to write boiler plate code such as (shamelessly ripped off a DZone post)
public List<Item> bought(User user)
{
List<Item> result = new ArrayList();
for (Item item : currentItems)
{
if (user.bought(item))
{
result.add(item);
}
}
return result;
}
But instead write something like:
def bought(user: User) = items.filter(user bought _)
- There's more functional love, but I'm not qualified to talk about it since I currently still suck at functional programming :)
Solve concurrency in a safer way
- Scala has an actors model (+ some other goodness) which is inheritly safer than Java's mutable data + locks on Thread model (no matter how good the libs are getting, Java is still hindered by the language).
I can't honestly think of too much else that makes Scala stand head and shoulders above Java. Lots of small gains and improvements yes, but also far more rope to hang yourself with. YMMV
HTH a little
Break and Continue:
In a talk about Scala, Martin Odersky gave 3 reasons not to include break or continue on slide 22:
- They are a bit imperative; better use many smaller functions.
- Issues how to interact with closures.
- They are not needed!
And he then says, "We can support them purely in the libraries." On slide 23, he gives code that implements break. Although I don't quite know Scala well enough to be certain, it looks like the short snippet on that slide is all that's needed to implement break, and that continue could be implemented in code that is similarly short.
Being able to implement stuff like this in libraries simplifies the core language.
In 'Programming in Scala, Second Edition', by Martin Odersky, Lex Spoon, and Bill Venners, the following explanation is given:
You may have noticed that there has been no mention of break or continue. Scala leaves out these commands because they do not mesh well with function literals... It is clear what continue means inside a while loop, but what would it mean inside a function literal? ... There are many ways to program without break and continue, and if you take advantage of function literals, those alternatives can often be shorter than the original code.
Return:
Returns could be considered a bit imperative in style, since return is a verb, a command to do something. But they can also be seen in a purely functional/declarative way: they define what the return value of the function is (even if, in a function with multiple returns, they only each give a partial definition).
In the same book, they say the following about return:
In the absence of any explicit return statement, a Scala method returns the last value computed by the method. The recommended style for methods is in fact to avoid having explicit, and especially multiple, return statements. Instead, think of each method as an expression that yields one value, which is returned.
Methods end and return a value, even if a return statement isn't used, so there can be no issues with closures, since otherwise closures wouldn't work period.
There can also be no problem meshing well with function literals, since the function has to return a value anyway.
Best Answer
The question is confusing, as C and C++ are languages, while JVM is a virtual machine and .Net is a platform. Scala could be implemented in C or C++, and it could generate machine code instead of bytecode for a virtual machine.
Answering the question that was asked:
Scala was not implemented in C or C++ because Scala, the language in which it is actually implemented, is a much better language.
Why is it better? Well, go read about Odersky's goals for the Scala language.
Answering the question that may have been intended:
Scala generates primarily JVM bytecode because that provides great portability as well as features such as a reliable and efficient garbage collector, run-time optimizations and just-in-time compilation by the JVM.
Let me repeat that last thing: JVM will compile to machine code hot spots in the code it is running. That's compile just like C and C++ compilers do.
There are other virtual machines available, but Odersky, Scala's creator, was already very familiar with JVM. He intended to have CLR as an alternative, but the effort to get that going hasn't achieved success yet.
Answering the question that could/should have been asked:
Compiling to machine code doesn't provide enough benefits over compiling to JVM bytecode.
It is certainly possible to generate microbenchmarks in C or C++ that beat JVM-equivalents. It is also true that extremely optimized code in C or C++ will beat extremely optimized code in Java or Scala. The difference isn't all that great, however, for long-running program.
Note that Scala isn't a particularly good scripting language precisely because the overhead for short-running programs is too big.
However, in most cases the speed of development and ease of maintenance are more important than the speed of execution. In those cases, where people are more concerned in writing very high level code that is easily understand and change, the run-time optimizations provided by the JVM may easily beat compile-time optimizations made by C or C++ compilers, making JVM (and CLR) the target that will actually execute faster.
So, no matter whether the question was about Scala compiler being a machine code executable, or Scala programs being machine code, the potential speed gains do not, necessarily, translate into real speed gains.
And, by the way,
I'll give you a counter-example: Haskell. Haskell generates machine code, and, yet, Haskell programs fare worse on Debian's shootout than Scala's. Given that, can anyone be sure Scala programs would be faster if compiled directly to machine code?