History proves that the only system programming languages that succeed in the industry, have been at a given moment adopted by OS vendors as their main language.
It hasn't happened so far to D, but it might still happen.
History proves that the only system programming languages that succeed in the industry, have been at a given moment adopted by OS vendors as their main language.
It hasn't happened so far to D, but it might still happen.
Then there's the history thing about Java being designed from the start to run devices: http://www.oracle.com/technetwork/java/javase/overview/javah...
I am fully aware of JNode.
It uses language extensions for the dirty tricks system programming languages need to do.
> Then there's the history thing about Java being designed from the start to run devices:
The devices are expected to have a ROM installed VM able to process the bytecodes. Which is the case of many devices that have Java VM available.
Until sun.misc.Unsafe or similar is not officially part of Java's public API, the language does not offer standard mechanisms for systems programming.
There are language extensions that allow such uses, but the language itself, according to the JLS does not support systems programming.
You need:
- value types
- control when a GC might happen, to avoid it ocurring during interrup handling
- means to tell the GC not to touch memory currenly involved in DMA operations
- all the nice operations sun.misc.Unsafe provides