3 ms·
As I read around, the JVM seems to be the state of the art for language runtimes. Can you elaborate why you hope it will not be the unified one in the future? J
by DeusExMachina 16y ago
As I read around, the JVM seems to be the state of the art for language runtimes. Can you elaborate why you hope it will not be the unified one in the future? Just curious.
- pwpwp 16y agoWhat 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)
- shadowfox 16y agoLoss of (generic) types at byte code level. Coordinating between dynamic languages and standard java code is a little cumbersome ..
- deleted 16y ago[deleted]