3 ms·
What the JVM has going for it is the incredible amount of resources thrown at it in order to make it fast. Technically, the CLR seems more interesting (it has
by pwpwp 16y ago
What the JVM has going for it is the incredible amount of resources thrown at it in order to make it fast. Technically, the CLR seems more interesting (it has runtime type information for generics, it allows structs, it allows unboxed data, ...).
Personally, I'm not a fan of runtimes. They don't give me the same warm, fuzzy feeling as compiling to native code and running directly on the OS.
- Someone 16y agoAre you sure all of these makes the CLR more interesting? One can argue some of it just makes it more complicated. Real generics, I agree about, but structs and unboxed data? I am not sure that implementing these instead of investing time in making the compiler & runtime smarter is the thing to do.
- pwpwp 16y agoUnboxed data (incl. structs) can be a performance win, because it removes indirections = memory loads.
- derefr 16y ago> They don't give me the same warm, fuzzy feeling as compiling to native code and running directly on the OS. What if the the OS's native code is bytecode? http://en.wikipedia.org/wiki/Singularity_(operating_system) http://en.wikipedia.org/wiki/Singularity_(operating_system)