Why was Scala not implemented with C or C++

Question

Does anybody know why was Scala implemented in Java and .NET instead of C or C++? Most languages are implemented with Cor C++ [i.e Erlang, Python, PHP, Ruby, Perl]. What are the advantages for Scala implemented in Java and .NET other than giving access to Java and .NET libraries?

UPDATE

Woudln't Scala gain more benefit if it is implemented in C because it can be tuned better rather than relying on JVM?

Answer 1

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 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 or easy of maintenance and debugging is 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?

Answer 2

One of the big hurdles languages face when being introduced to the world at large is library availability. The traditional response to this has been to provide a C-based FFI (foreign function interface) to permit you access to C-based libraries. This is not ideal for a variety of reasons, chief among them:

• There's a lot of different ways that libraries want to interact that aren't compatible with many higher-level languages. For example if the library wants a pointer to a struct, how do the languages with no pointers AND no structs cope?
• There are harsh interactions between memory models of different libraries and languages which are often not resolvable or, if resolvable, are highly error- and bug-prone.
• The glue code for many FFIs is non-trivial and assumes knowledge that may not, in fact, be universal. (Believe it or not, not all programmers are C gurus, and neither do they want to be nor should they be required to be!)

This gets even worse with C++. C++ isn't even compatible with C++ (at a binary level, I mean) from compiler to compiler on the same platform (!), not to mention with other languages.

Targeting the JVM solves many of these problems while giving you access to the absolutely enormous suite of Java-based libraries. (How enormous? Just scope out The Apache Software Foundation's huge selection for starters.)

• Java's calling and ownership conventions are more regular than C's.
• The JVM also provides a single memory model (including garbage collection) for languages and libraries both to interface with. There's no need to keep track of who owns what and which has to clean up where. The runtime does it for you.
• The glue code for FFI, for most languages built on the JVM, is non-existent (as in it's provided as a framework behind the scenes in the language). There's no need to program in Java, for example, to access Java libraries in Scala, Clojure, JRuby, etc. You access the Java objects the same way you access native "objects" (scare quotes because, for example, Clojure doesn't have actual objects in the OOP sense) and in your native language.

On top of these advantages you also have the added advantages of running anywhere Java runs without recompilation (but with testing!: write once, test everywhere) and having access to Java's rather impressive JIT technology.

The CLR provides similar strengths, but adds what is IMO a weakness: it's pretty much a vendor lock-in environment. (Yes I know about Mono. I still think it's a vendor lock-in environment.)

Answer 3

All the other languages you mention, Erlang, Python, PHP, Ruby, Perl -- these were all created before Java & .NET. If the creators of those languages had the Java or .NET runtime environment available to them at the time, then it's possible they might have leveraged those when building their language.

Of course, I can't speak for the developers of those languages, so I can't say for sure that they would've used .NET and/or Java when building them had they been available, but it seems to me like a good idea. After all, by designing your language to compile to Java/.NET bytecode, you get all of the advantages of the JIT compilers/optimiziers, your language automatically runs on all platforms that Java/.NET runs on, you have access to all of the Java/.NET libraries and so on.

Answer 4

According to this interview, access to existing Java infrastructure and libraries was the primary reason.

Answer 5

JVM / CLR

The JVM (and the CLR) provide unique advantages in terms of optimization and code portability.

As far as I know, only the JVM version of Scala is being kept current, the .NET version is not.

Answer 6

It looks like you are mixing two unrelated things.

The first one is, which programming language is used by Scala author(s) to implement Scala?

To which the answer is, Scala itself. And it's the only acceptable answer, really, because if you have invented this new language, but don't use it yourself for implementing it - what good is it for?

The second thing is, what is the target platform for running programs written in Scala?

Here the choice becomes more interesting, but for now, the only target that works 100% is JVM. Support for .NET is still work in progress. Also, some people are working to get Scala to compile to javacsript. In theory, nothing prevents someone from adding more 'backends' for compiling to C, C++, LLVM, native code or whatever.

Why JVM was chosen as primary platform? My guess is because

• everyone wants garbage collection
• large number of good libraries ready to use
• large number of programmers bored with Java ready to jump to something new, but stay withing the limits of JVM (no one wants to migrate their existing code to another platform)

Answer 7

JVM written in C, but javac is in Java.

Answer 8

It's not clear that having ability for better tuning would be a good tradeoff. JVMs can do optimization at runtime, and that's commonly at least good enough, if not superior to what typically happens with static compilation. (Obviously in principle for a specific application and workload it ought to be possible to beat JIT with static optimizations, but practically you don't often have the precise workload or even the whole application.)