Hacker News Reader

Comment by cwzwarich | Hacker News Reader

As far as I can tell, Rust OS projects generally use gratuitous amounts of unsafe code and are not substantially different than if they were written in C. I could just be looking in the wrong places. Are there any that take advantage of Rust's type system to provide real guarantees?

View on HN

The OP talks about this in the most recent post:

"In the previous post we switched from assembly to Rust, a systems programming language that provides great safety. But so far we are using unsafe features like raw pointers whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer."

That may just be the impression given by tutorials, which spend most of their time dealing with the hardware. In a real OS, you'd wrap that up in safe interfaces and then the core of things like scheduling, file systems, etc. could be in a safe layer on top of the unsafe drivers.

But has anyone actually done that? Can you even express those as safe interfaces in Rust?

IMO, the answers to those questions are "no" and "yes" respectively. Redox in particular seems like it has way more unsafe code than it actually has to (though it seems to have gotten a bit better very recently).

It's the same thing with Haskell, or any other "real" system that, at some level, has to interface with low-level primitives. The platform gives you a pile of unsafe, low-level primitives ( https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GH... ) on top of which you (or a library writer) can provide safe interfaces, e.g. https://hackage.haskell.org/package/buffer-builder

The unsafe low-level stuff gives rise to some great function names like `reallyUnsafePtrEquality` and `accursedUnutterablePerformIO` https://github.com/haskell/bytestring/blob/dd3c07d115840d134...

I expect a lot of this to be like this at first: https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51...

There's a period of writing only all the usual stuff that you've done before, then slowly discovering what kinds of abstractions you can put over it, and what kinds of stuff needs to remain super-low.

There are times that you have to do "unsafe" things when interacting directly with hardware. That's not to say one shouldn't attempt to limit the use of "unsafe" to use cases that absolutely require it.

Reply on news.ycombinator.com