Comment by jacquesm
7 hours ago
There should be no such difference. The bigger problem is that OS's enforce this duality when in fact there should only be application level software and an absolutely tiny core to handle IPC and scheduling. This then allows you to enforce the boundaries between various bits far more strictly.
The kernel, the memory manager and device drivers, the language runtimes for managed languages; would these not be written in "systems" languages? Essential complexity can only be rearranged, not removed. Nothing changes the fact that every interface between hardware and software needs to be bridged.
On a different note: why should the kernel even handle IPC or scheduling? Those take the basic capabilities of context switching, timer management, and memory management. Even "core functionality" can be a context switch (or a few) away; is a syscall not just a message to a system server? Only the most basic form of communication is necessary to delegate arbitrary functionality, so a true microkernel should only introduce that as an abstraction. Everything else either follows from the hardware or is left to the whims of software.
> The kernel, the memory manager and device drivers, the language runtimes for managed languages; would these not be written in "systems" languages?
The kernel and memory manager: probably yes, the device drivers: not necessarily, the language runtimes for managed languages: not necessarily.
> On a different note: why should the kernel even handle IPC or scheduling?
Because any other solution will quickly run into chicken-and-the-egg style problems.
> Those take the basic capabilities of context switching, timer management, and memory management.
Yes. But only one timer, the rest should be free to use by other applications.
> Even "core functionality" can be a context switch (or a few) away; is a syscall not just a message to a system server?
No. A syscall is usually defined as a call to a ring one level in from the one where you currently are. But lots of things that are syscalls right now do not necessarily have to be.
> Only the most basic form of communication is necessary to delegate arbitrary functionality, so a true microkernel should only introduce that as an abstraction.
Indeed. And they do.
> Everything else either follows from the hardware or is left to the whims of software.
A lot of the stuff that 'follows from the hardware' can be dealt with at the application level.
It seems like you think that some shadowy cabal somewhere decided to differentiate systems languages from managed languages and keep them divided. That is not the case. The distinction describes how the language has been implemented, which is based on the choices of the language authors alone, and is usually down to practical considerations about how to implement the thing at all.
Saying "There should be no such difference." is a bit like saying bicycles should be allowed on the highway and semi trucks should be accepted on walking paths. The difference is inherent in the thing. A result of how they were built. And what they can and can't accomplish as a result.
> It seems like you think that some shadowy cabal somewhere decided to differentiate systems languages from managed languages and keep them divided. That is not the case.
You could have made that point without the strawman, and what a ridiculous thing to say anyway.
> The distinction describes how the language has been implemented, which is based on the choices of the language authors alone, and is usually down to practical considerations about how to implement the thing at all.
That is so obvious I do not understand what point you are trying to make here.
> Saying "There should be no such difference." is a bit like saying bicycles should be allowed on the highway and semi trucks should be accepted on walking paths. The difference is inherent in the thing. A result of how they were built. And what they can and can't accomplish as a result.
No, the error is yours: you are interpreting my sentence in a way that is blatantly wrong and then argue with the outcome. I'm not saying that there shouldn't be 'trucks or bicycles' in terms of programming languages. What I'm saying is that the boundary between where you use a 'systems programming language' and where you use an 'application programming language' is artificial and that we are using too much of the former in a place where we probably should be using the latter.