Linked by Thom Holwerda on Sun 26th May 2013 18:48 UTC
OSNews, Generic OSes "A tiny 32 bit kernel written in Rust. I was inspired to download Rust and try to do this after seeing zero.rs - a stub that lets Rust programs run almost freestanding. It paints the screen bright red and then hangs. That's it."
Thread beginning with comment 563005
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: I clicked it, I liked it
by moondevil on Tue 28th May 2013 07:48 UTC in reply to "RE[6]: I clicked it, I liked it"
moondevil
Member since:
2005-07-08

I disagree with that conclusion. What OSs mainly written in C or C++ show is that it is possible to write most of an OS' logic in another programming language, and only keep Assembly for the few operations that actually access hardware directly. Sure, these Assembly parts are vital, but so is the logic code: it is where all the interesting stuff is decided, and what differentiates one OS project from another one.


And Object Pascal, Modula-2, Ada, ...

Of course, we can argue that some languages are better-suited for OS development than others. As an example, any language with heavy runtime requirements, or nondeterministic performance due to garbage collection, is probably a very poor fit unless such mechanisms are optional as in C++.


10 years ago no one would believe you could do something like Unreal in JavaScript.

I think it is also a question how much the industry is willing to invest in such topics.

Also, the fact that he has to define abort, memcmp, memcpy, malloc and free for the code to compile worries me. It means that some part of the OS binary somewhere requires these primitives, and will cause a random crash if it ever attempts to run them. But perhaps that's a result of someone not properly reading his compiler's manual...


I think he just had them as stubs, because it was just a proof of concept. Of course in a real kernel similar functions need to be defined.

Reply Parent Score: 2

Neolander Member since:
2010-03-08

"I disagree with that conclusion. What OSs mainly written in C or C++ show is that it is possible to write most of an OS' logic in another programming language, and only keep Assembly for the few operations that actually access hardware directly. Sure, these Assembly parts are vital, but so is the logic code: it is where all the interesting stuff is decided, and what differentiates one OS project from another one."

And Object Pascal, Modula-2, Ada, ...

Indeed, many languages are potentially suitable for OS development although some are more suitable than others.

From my short look at it, Ada in particular could be a very interesting choice for OSdeving. Too bad so little Ada OS projects have survived to this day...

"Of course, we can argue that some languages are better-suited for OS development than others. As an example, any language with heavy runtime requirements, or nondeterministic performance due to garbage collection, is probably a very poor fit unless such mechanisms are optional as in C++."

10 years ago no one would believe you could do something like Unreal in JavaScript.

Then again, gamers have also come to expect quite a bit more than Unreal from games these days.

I think it is also a question how much the industry is willing to invest in such topics.

The industry seems to be satisfied with kernels from the 80s and the 90s and to focus on higher layers of the OS stack these days.

So if innovation is to come in the realm of low-level OS design in the next decades, it will probably be either from academia, hobbyists, or companies' fundamental research departments. Not from a team of people which actually have the goal of producing a product that can be sold.

"Also, the fact that he has to define abort, memcmp, memcpy, malloc and free for the code to compile worries me. It means that some part of the OS binary somewhere requires these primitives, and will cause a random crash if it ever attempts to run them. But perhaps that's a result of someone not properly reading his compiler's manual..."

I think he just had them as stubs, because it was just a proof of concept. Of course in a real kernel similar functions need to be defined.

Sure, but is there a subset of Rust which is formally guaranteed in writing to work forever without calling these functions ? Otherwise, these functions cannot safely be implemented in Rust, which noticeably means that the whole memory manager has to be written in another language like Assembly or C.

That would be a serious blow to Rust's suitability as an OS development language.

Reply Parent Score: 2

moondevil Member since:
2005-07-08

Then again, gamers have also come to expect quite a bit more than Unreal from games these days.


I fully agree. My point is that technology improves when there are people willing to invest research on them.

The industry seems to be satisfied with kernels from the 80s and the 90s and to focus on higher layers of the OS stack these days.

So if innovation is to come in the realm of low-level OS design in the next decades, it will probably be either from academia, hobbyists, or companies' fundamental research departments. Not from a team of people which actually have the goal of producing a product that can be sold.


Actually the industry is happy using OS that they can get for free, instead of investing in OS research.

This is the main reason why outside academia, Microsoft Research seems to be the only visible OS vendor R&D department doing OS research.

Sure, but is there a subset of Rust which is formally guaranteed in writing to work forever without calling these functions ? Otherwise, these functions cannot safely be implemented in Rust, which noticeably means that the whole memory manager has to be written in another language like Assembly or C.


It is no different than C in that regard.

You cannot do an OS in ANSI/ISO C without Assembly.

So I don't see any issue if you really need to implement a few tiny functions in Assembly, just like you need in C anyway.

Reply Parent Score: 2