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?


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

  • 19
    Also, being able to use existing Java libraries and tightly inter-operate with java code is a HUGE benefit, not some minor thing. Apr 20 '11 at 7:09
  • 6
    @OP: you speak as though its bad to have a language implemented on top of the JVM (or CLR for that matter). The tuning you mention that is possible in C is nowhere near the amount of tuning put into CLR or the JVM. And if the platform improves, your language automatically gets it for free. Given the choice, no one should be implementing their language on top of good'ol C anymore imho.
    – Chii
    Apr 20 '11 at 12:44
  • 8
    @Chii, just admit it, Java is still slower than C. Apr 20 '11 at 13:05
  • 19
    @jpartogi, Java cannot be slower or faster than C. They're both languages, not stallions. In some specific conditions, some specific code compiled by Java compiler and executed with a certain JVM is slower than a roughly comparable code, generated by a C compiler. In some other conditions the latter will be slower.
    – SK-logic
    Apr 20 '11 at 13:13
  • 4
    Scala's runtime environment is a C++ program; the JVM.
    – mike30
    Jun 27 '13 at 13:27

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?

  • 3
    @mike30 Scala would run on any JVM, even if it were not written in C++, so that argument does not hold. And, at run time, there's no C++ code, just machine code. I'm not sure what this comment is about, though. Jun 29 '13 at 1:08
  • 3
    the real point is: generating machine code is quite more complex than generate byte-code and it require a specific implementation for every OSes around as well as tuning on CPUs and differents architectures (ARM, x86, x86_64) and advanced instructions (MMX, SSE...). So in this way is delegate to the JVM this aspect.
    – Raffaello
    Apr 18 '15 at 12:33
  • 2
    If you speak so much about the execution performance, why don't you speak about the memory performance? Are you afraid that things may come out not as well as you imagine?
    – luke1985
    Jan 2 '16 at 13:08
  • 3
    @lukasz1985 It does drive performance, but the performance discussion covers that, so it is irrelevant in that respect. All that remains is whether you care how much memory an application takes, and then you have to choose between GC and that, and I'll pick GC every time except for very specific development spaces, none of which is occupied by Scala. And "isn't anybodys right to tell" is bullshit -- everybody HAS that right. And while C/C++ is very relevant due to legacy, they would never become popular if they had been released in the past five years. Jan 11 '16 at 22:04
  • 3
    @lukasz1985 Your only evidence that I do not understand that is that I disagree with you. An alternate explanation to that is that you are wrong. And, as someone alive and programming "then", I have a first hand perspective on the decision making involved in picking C and C++ over contemporary alternatives, which I mention not to prove my point, but to offer as a counter to yours: similarity to spoken language was in no way relevant, whereas similarity to machine code was. Jan 21 '16 at 0:29

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

  • 3
    You do realize that C# and the CLR are actually an open standard any one can use.
    – Erin
    Apr 20 '11 at 14:02
  • 7
    I think the bit about where I "know about Mono" and then "still think it's a vendor lock-in environment" should give you a bit of a clue there, Erin. Apr 20 '11 at 14:07
  • 3
    @Erin not all of the .NET Framework is though Apr 21 '11 at 0:12
  • 1
    @alternative: If that's too much lockin, consider that the Java conformance tests are still not free, and it's at best 6 of one, half a dozen of the other for Java. Jan 22 '15 at 19:38

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

... Java is an existing language with very hard constraints. As a result, I couldn't do a lot of things the way I would have wanted to do them—the way I was convinced would be the right way to do them. So after that time, when essentially the focus of my work was to make Java better, I decided that it was time to take a step back. I wanted to start with a clean sheet, and see whether I could design something that's better than Java. But at the same time I knew that I couldn't start from scratch. I had to connect to an existing infrastructure, because otherwise it's just impractical to bootstrap yourself out of nothing without any libraries, tools, and things like that.

So I decided that even though I wanted to design a language that was different from Java, it would always connect to the Java infrastructure — to the JVM and its libraries. That was the idea...


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.

  • 2
    The advantages described are some of the reasons that e.g. Python has been reimplemented both for JVM (Jython) and .NET (IronPython). Apr 20 '11 at 8:29
  • 2
    -1: Assuming that new languages could have been dependant on a specific platform (.Net or JVM) because they would be available don't look like a good argument to me. For example, I dont' see any good reason for Python or Erlang to run on such platform. Hystory don't say it all.
    – Klaim
    Apr 20 '11 at 9:58
  • 1
    And even PHP would never be able to do what it does over the JVM or .Net. @Dean Harding> I don't think IronPython or Jython did prove anything of value.
    – Klaim
    Apr 20 '11 at 11:18
  • 1
    Sorry I was not clear, what I meant is that it wouldn't have it's had it's "success" (PHP or Python) because worknig over a JVM or .Net imply a lot of things that would have annoyed a lot of developpers, making them more niche language than they are currently. On the technical side, the platform (.Net or JVM) would have been a problem because it does drive the way you build a language over it. Stating with the machine is a way to make exactly the language you want. So with or without JVM available, I see 0 good reason to build over .Net and JVM. Other than rapid implementation.
    – Klaim
    Apr 20 '11 at 12:02
  • 2
    Small correction: Java is older than PHP. But PHP started as CGI program, later became an Apache httpd module and as such it became big. Both things (cgi and httpd module) don't work well for Java. So things aren't that easy, a JVM is not the platform for everything. ;-)
    – johannes
    Jul 14 '13 at 23:45

C code is statically compiled to native code (machine code).

Scala is statically compiled to java bytecode and then, as required, dynamically compiled to optimised native code. The process:

Scala code ---statically-compiled-to---> JVM byte code ---dynamically-compiled-by-JVM-Hotspot-to---> native code

General options for building / running any language:

  • a) interpret source code directly via a runtime interpreter engine
  • b) statically compile code to native code (possibly via intermediate stages e.g. source -> C -> native)
  • c) statically compile source code to lower-level intermediate code, and interpret it at runtime
  • d) statically compile source code to lower-level intermediate code, then use initial interpretation, followed by dynamic compilation and optimisation techniques to convert to native code. Code is interpreted until typical execution paths and bottlenecks are found, then code is compiled for fastest execution under typical conditions. It's recompiled/retuned when execution conditions change enough to warrant this

Your Question: "Why does Java use (d) with a JVM, rather than (b) with C intermediate code?"


Firstly, observe that Scala's a much higher level language than C, giving programming power, ease of programming and conciseness. It's about '1 level higher' than Java due to first class & higher order functions, implicit functions, functions as objects, closures and currying, support for tail-recursion compiling to fast stack-conserving loops, everything as objects, all operators as methods which can be (re-)defined in libraries, case classes and reduction (pattern matching), implicit type derivation, stronger polymorphism through expanded multi-inheritable traits and expanded generics, built-in syntax for pairs & tuples & cons (lists & trees) & maps, support for immutabile data structures, support for powerful 'reactive' parallel and concurrent computing with message copying and passing between actors, advanced support for arbitrary domain-specific DSLs, scriptability, and the REPL. Java's about '1 level higher' than C due to object-orientation, pointer management and garbage collection, string support, multi-threading support and concurrency control, plus standard API libraries.

  1. Performance: For a high level language, (d) gives faster performance than (a)-(c).
    Directly written and hand-optimised C code is fast. However, higher-level languages statically compiled to C are relatively slow. The java designers knew this well. Their current "Hotspot" design boosts performance by up to order of magnitude. On a single core, Java HotSpot code is on average '50% as fast' as human-optimised C (in the best it's case '120% as fast', in the worst case '30% as fast'). But of course that's comparing apples with oranges - low-level code v high-level code. And that would be much worse if Hotspot optimisation wasn't used. To confirm, just disable hotspot compilation via JVM args! Or consider java 1 & 2 performance, when hotspot didn't exist or was immature. Or try compiling another language via C - e.g. perlcc. So the above are great results for a powerful and productive language. With further development, it's possible (or even likely) that JVM may soon outpace hand-coded C on average. Scala is merely 70-80% as slow as java on average. But scala strongly scales across multiple cores (with further improvements to be ongoing), whereas java does partially and C doesn't. Single Core performance for such high-level languages is rated:

    interpreteted < statically compiled < dynamically compiled

    Multi-Core performance/scalability is rated:

    interpreted dynamic code < statically compiled imperative code < statically compiled functional / declarative code < dynamically compiled functional / declarative code

    This puts scala in the winning seat because processor speed has hit it's limit and now the number of cores are increasing by Moore's law. Scala's very fast on multi-cores and in future, could become several times faster than C or java. Compiling statically to C is clearly not the fastest option.

  2. Interoperability: languages on a widely supported VM have better language interoperability than 'isolated' languages. Scala "automatically plays with" java classes, interfaces and objects by simply importing them and using them as if they were scala classes, traits and objects. Similar is possible with other JVM languages such as Groovy, Clojure, JRuby and JPython - with ease of interoperability dependent upon how cleanly each language was made to compile to understandable & usable java runtime classes/interfaces/objects. That much comes for 'free' (as in 'close to'). Scala interoperates with C via JNA, the successor to JNI - which comes with some effort, but the tools have been quite well streamlined over time. JNA can actually interoperate with compiled native code from any arbitrary language - but you must know the exact structure of compiled datatypes and functions. If not, you can use a C wrapper object (or in the worst case, chain an additional 'C to other language' mechanism), to interoperate with Objective C, C#, Perl, Ruby, Cobol, etc.

  3. Portability: JVM runs on dozens of operating system platforms / versions 'out of the box'. Scala is automatically ported to these. Noted exception is iOS (iPad/iPhone/iPod) - blocked 'commercially', rather than 'technically' by Apple. This couldn't have been anticipated 12 years previously, during initial design of JVM. JVM runs fine on dozens of other servers, desktops, mobiles and embedded devices, including ones that don't support C - including Android with Google adapted Dalvik VM (50%+ of new phones sold). Sure, C code works on a multitude of platforms, so may be rated 'up there with or probably beyond' Java (notably, C is a subset of Objective-C). But C would come at the cost of (1), (2) & (3). Of course, HTML5/javascript/webkit (or objective-C) presentation layer on iOS can interoperate with a remote scala app - so developer's should very much do that. Of course, they'll be less productive.

  4. Tools and Libraries: Obviously there are thousands of commercial and open-source Java libraries and tools that can leverage / be leveraged by Scala - more than for C.

  5. Security: - running on a controlled app server or JVM environment gives stronger support for security policies and restrictions, which can be highly valuable in a corporate environment.



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.


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)
  • I don't see why a garbage collector cannot be implemented with C or C++? I don't see that as a good reason. Python have done it. Ruby have done it. Heck even erlang have done it. Who knows that Scala might end up with a better garbage collector if it is written with C or C++? Apr 21 '11 at 5:03
  • 1
    I meant 'real' garbage collection. I don't think that garbage collection that provokes questions like this one is good enough. Heck even JVM is not good enough - otherwise people like AzulSystems would not be able to make a living by helping other people to overcome JVM deficiencies.
    – artem
    Apr 21 '11 at 5:21
  • Also, libraries. It's really difficult to use libraries written for explicit memory management in a language with garbage collection. One indication is peculiar insistence of java people to have everything in 'pure java'.
    – artem
    Apr 21 '11 at 5:35

First of all - what I guess you really wanted to ask is why Scala is not compiled language in it's strict manner. I will tell you I don't know. But I will tell you also that there is no reason to favor JVM over native code.

Why? The reason is simple: any virtualization technology is memory hungry, produces unnecessary overhead and another layer of indirection. This is not a matter of their implementation - this is a matter of fact, of the logic that lies behind the core concept of virtualization. No matter what you do you will ALWAYS end up with inferior characteristics. Especially JVM is memory hungry. It's not anymore so slow, because it has it's own runtime compiler running behind the back, but still - it has to run the compiler process to be able to spot the most congested parts of code and turn them into binary code.

Said that - the only reason I think was there for making Scala JVM-based was probably the popularity of the language. I also guess that some laziness was behind this decission because it's easier to implement a language over the JVM than figure out how things should look like assembled to work cross platform - and even using existing C backends requires a lot more of work due to the fact that things are not as well standarized as with JVM.

That are the reason I can think of, but keep in mind that there may be other reasons - like licensing issuess and politics involved there (which are dirty things I won't ever like to get into).


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


Not the answer you're looking for? Browse other questions tagged or ask your own question.