4 ms·
The problem, is that at the end of the day, some code somewhere is going to have to deal with resource allocation. Generally speaking with all the other fluff a
by Arelius 14y ago
The problem, is that at the end of the day, some code somewhere is going to have to deal with resource allocation. Generally speaking with all the other fluff aside, an operating system, fundamentally manages and multiplexes resources. It's naive to think that resource management would be best done in a language with automatic GC. Somebody
I don't doubt that C is not the systems programming language of the future. But it's not going to be done in a system that's based around automatic GC either.
- pjmlp 14y agoRead the papers of proven work, instead of stating your beliefs.
- Arelius 14y agoYou use the word proven as if it means something. The work you list is no more proven in terms of building production systems than any other research work. Additionally, I find it interesting to note, that if you had in fact been very familiar with all the work you mention. You should actually have noted that many of these systems go through significant effort to sidestep the GC.
- pjmlp 14y agoIt is proven, because groups of people went through the effort of spending time and effort implementing those systems and used them for daily work as well. It not just talk about some guys showing up papers at OS geek conferences. The Oberon Native for example, was for long time the main operating system at the operating system research department at ETHZ. Most researchers used it as their daily OS for all tasks you can think of. http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf The GC was done at kernel level. Besides Oberon code, there is just a little bit of assembly for the device drivers and boot loader.