So now I am really wondering. What is the sub java parts of the JVM that need to be implemented to completely free Scala from the JVM ( i.e. what C interfaces are needed to allow scalc to compile to LLVM or comparable VM)
Why would you want to? The JVM is pretty awesome. There's already a scala implementation for .net, so it's got at least some level of VM independence, but the JVM is the primary target and I'd expect it to remain so.
As well as the VM there's the runtime library to consider. There was a project recently here that compiled scala to javascript to use on web pages, but unfortunately it needed a 16mb standard library.
I've heard this before in the context of why .NET tends to have less alternate language implementations on it than the JVM. I don't understand why though. Why do reified generics make it near impossible?
My understanding is that it gives you less flexibility in how your type system works. To a certain extant you are stuck with the C# type system no matter what the language is because it is baked in to the VM. I assume this doesn't apply as much to dynamic languages but still makes interoperability a pain.
The start up time of the JVM and the size of the generated executables ( jar files ) make scala not terribly useful for those small programming tasks ( scripting and such )
You misunderstand me...it has to read and decompress (jars are basically zip files) those 50MB are so (just for the system jars) on every startup before it can even think about validating the cache
And which implementation that you seem to imply exists DOESN'T suffer from this seemingly fundamental issue? You built this strawman, now defend it or stop waving your hands.
Of course not, all the code and data that go into the processor needs to go through the processor cache first.
My OP comment has an example of a JVM that doesn't read jar files as you mentioned, while executing native code stored in a JIT cache present in the hard disk, between invocations.
Google is your friend if you look for the respective documentation. Or, who knows, you could even download it and play around with it.
I'm out, please turn the lights off on the way out.
Huge amounts. Practical scala apps leverage huge parts of the Java infrastructure. The Scala types are often thin wrappers over the Java types, JDBC, NIO, etc. It'd be a bit like trying to write a C++ app without access to, say, the STL, or Boost.
The point is that currently the Scala compiler provides one target - the JVM. Support for .NET was officially dropped last year, and nobody seems to care.
Scala and the JVM are very tightly coupled - targeting LLVM or something should be possible, but getting that to run with high performance would be very difficult.
