
Is It Time to Rewrite the Operating System in Rust? [video] - tambourine_man
https://youtube.com/watch?v=HgtRAbE1nBM
======
pornel
As someone who's rewritten several things in Rust, and even written C to Rust
"transpiler", I totally agree with the approach of keeping working C code as-
is, and switching to Rust for new code.

Rewrites from scratch are time consuming, and at risk of second system
syndrome (especially when you suddenly have all the shiny new language
features).

Direct 1:1 rewrites are underwhelming. After the initial C to Rust pass you
end up with the same program, with a C-like architecture, and all you've done
is replaced gcc with a slower rustc.

But wrapping a C implementation in a Rust API works _great_. You can translate
C's implied ownership semantics into explicit Rust types. You can wrap all
these C structs/handles with their init and free functions into RAII that
never leaks.

It's something you can do in days, not months to years. You keep a fully
working program at all times. You benefit from Rust for new development, and
you can gradually refactor C out of it when and where it's sensible to do so.

------
Chyzwar
I disagree with the suggested approach of gradual introductions of rust, this
would require kernel developers to master both languages and introduce
mismatch anyway.

I think before we jump into writing OS in rust we should first understand what
wrong with current dominant Linux. I think we could make a major revision on
how computers are built and how should be OS architected to last for another
few decades.

~~~
adamnemecek
> I think before we jump into writing OS in rust we should first understand
> what wrong with current dominant Linux.

Lack of an async API. Bad IPC primitives (how many are there? They are all
terrible). The whole "everything is a file" idea. Real time audio. Bash. File
systems. The process vs thread distinction. Package management. Permissions.
Security model. Scheduler. General cruft. X Server. Battery life. OOM killer.

I would much rather hack on a Rust kernel than C.

~~~
AnIdiotOnTheNet
There is really just so much that could be done better now that we have
decades of hindsight. Sadly, I doubt it'll happen because supporting even a
reasonable amount of existing hardware has become an exercise in futility.
Theoretically one could start with a well defined subset of hardware, but that
would make growth extremely difficult unless that hardware was both
inexpensive and common enough for anyone to acquire it easily while also being
good enough to cover a lot of use cases (and your OS amazing enough that
people would willingly sacrifice to use it). A Raspberry Pi fits this
requirement pretty well, but you still don't see useful new OSs on it do you?

~~~
adamnemecek
Raspberry Pi is a bad target because you are unlikely to make money with your
OS and fundamentally you need that to turn the OS into anything serious.

The advantage of Rust is that you can split things into modular code bases.
Redox is split very nicely.

I think that one could start a hosting company and write a hypervisor in Rust.

~~~
AnIdiotOnTheNet
I guess that's why it hasn't been done. Like too many things people are much
more concerned with making money than making things better, so we just keep
building on the same pile of garbage we've had since the 70s.

I'd hardly call Redox serious, it's a "research OS" with no explicit goals to
actually be useful.

~~~
adamnemecek
Correct however Redox paves a way. The project is very modular, I can imagine
someone coming along and using it as a starting platform and reusing parts of
it.

~~~
AnIdiotOnTheNet
I can imagine a lot of things that will never happen.

~~~
adamnemecek
Break down your reasoning to me. Don't look at what it doesn't have, look at
what it has.

~~~
AnIdiotOnTheNet
My reasoning has nothing to do with what it has, it is about what it is:
unambitious. It is unwilling to label itself as something that could ever
potentially be a useful replacement for anything, probably because that means
it can't be judged for failing to achieve it. Its developers are free to
engage in academic exercises which amuse them without regard for practical
applicability.

And that's fine really, but it is representative of the larger problem: no one
capable of pulling it off is willing to be so ambitious. No one is willing to
commit to the hard work of making a usable and practical platform, which will
undoubtedly involve distasteful compromises and uninteresting work sanding
down the rough edges.

I'd be glad to be proven wrong on this, but I just don't see it happening.

~~~
adamnemecek
I'm not talking about redox in particular but like, you have for example a
bootloader that someone can reuse.

I'm saying in the next 10 years, there will be a serious OS written in Rust.

------
karmakaze
Start at 29:31 to skip past 'what is an os?' history lesson.

> Go, JavaScript and others are _garbage collected_ , making interacting with
> C either impossible or excruciatingly slow.

I don't see why interacting with C is a requirement. Android (SDK) could be
considered an OS that doesn't have this either.

~~~
ldng
Humm, I don't think you can equal an SDK to an OS. Before getting this high
level, you really have to start with a kernel to handle/manage device. And
this as a lot of constraint that yous simply can not fulfill with a garbage
collected language.

edit: I wasn't at the point you mentioned yet. Well, IMHO, it is not just the
GC, it is not having access to native pointer prevent you to implement
algorithm that are keys in term of performance for a kernel. IIUC more savvy
dev than me it might not even be possible to implement a kernel in Rust
without "unsafe" (which give you access to those raw pointers)

Happy to be proven wrong though.

~~~
karmakaze
OK that was a bad example. I just meant to say that C compatibility is an
over-specification. We just need machine level interfacing like maybe locking
to hardware threads, fixed address referencing, etc.

Edit: I don't know much about this but it might be a better example "GRiSP 2 –
Erlang and Elixir on bare metal." I'm assuming this is possible and includes
the BEAM VM with GC.

[https://news.ycombinator.com/item?id=19358133](https://news.ycombinator.com/item?id=19358133)

~~~
brightball
The BEAM GC is a little bit special because there’s not a shared memory model.
Millions of little Erlang processes will be GC’d independently which
simplifies things a ton.

That isolation model probably wouldn’t translate to the greater code ecosystem
even though it’s very effective for BEAM applications.

------
Redoubts
By Bryan Cantrill, which makes it totally worth it.

~~~
bullen
He's the programmer equivalent of a stand-up comedian!

------
scoutt
Write from scratch, maybe. Rewrite, I don't think it will happen anytime soon.
In fact, the more time it passes, the more code needs to be rewritten.

Regarding firmware, if the talk was about bare-metal embedded development,
then I think Rust is the solution to a problem that no one has.

Since the food on my table comes from firmware development, I passed several
days trying to understand the reasons to move to the approach described here:
[http://blog.japaric.io/brave-new-io/](http://blog.japaric.io/brave-new-io/)
(Embedded in Rust blog, great reading BTW).

But found little. It's a nice _toy_ but it may be too much. If that is the
trend, then I think Rust for Embedded is the answer to a question no one
asked, because in my work, if I need to set a bit into a register, I have to
be sure it's _fking_ set; not playing around "just because it may be
_problematic_ ".

~~~
blub
I hope this idea of taking the complexity of memory management and encoding it
in the language syntax is an evolutionary dead end, because that Rust code
looks genuinely _painful_.

Otherwise I agree that a rewrite is nonsense. In these kinds of huge projects,
only a gradual solution that can co-exist with the existing code base could
work, if anything. An example would be tightening the safety of the existing
code through static analysis of the kind offered by Frama-C.

~~~
pjmlp
The problem with static analysis of the kind offered by Frama-C, is that many
developers not even at gunpoint bother to use them.

------
xemoka
Prior comments:
[https://news.ycombinator.com/item?id=18405804](https://news.ycombinator.com/item?id=18405804)

------
OJFord
Redox (an OS written in rust) has a related page: [https://doc.redox-
os.org/book/introduction/will_redox_replac...](https://doc.redox-
os.org/book/introduction/will_redox_replace_linux.html)

------
Animats
Is there a summary of this hour-long video?

~~~
chubot
Here's my summary from 2 months ago:

[https://lobste.rs/s/qz9d82/is_it_time_rewrite_operating_syst...](https://lobste.rs/s/qz9d82/is_it_time_rewrite_operating_system_rust#c_gnp1gb)

Overall I was sort of disappointed in this video. I would rather hear about
someone writing their OWN code in Rust. I watched one of Cantrill's previous
talks about this which I liked, so I watched this one too.

It's not that interesting to hear "well Rust has problems for MY domain
(kernels), but OTHER people should write their code in Rust (user services and
firmware).

There's an obvious asymmetry there, because you know all about the problems in
your own domain, but you're less familiar with the problems of other domains
(e.g. ones that require a lot of async code, a lot of text parsing, etc.)

\-----

I just watched this video. I liked the part about failed C++ operating systems
from the early 90’s (Apple’s Copland, an effort from Sun, and Taligent).

Overall he’s excited by Rust, but points out some problems with using it for
kernel development:

\- Multiply-owned data structures are all over Unix kernels, and Rust’s
ownership system doesn’t like those. (i.e. the doubly linked list problem)

\- Rust doesn’t allow you to handle memory allocation failure. This is being
worked on? I didn’t know this about Rust and it seems odd for a low level
language.

He says that instead of kernel development, Rust could be used for:

\- user-level services like systemd, or

\- firmware.

This doesn’t seem like anything more than a wish though. I don’t see that Rust
really shines in those areas.

\- I think you could probably write systemd in Go. I don’t see that Rust has
any advantage there. Whereas a kernel in Go has some obvious downsides (I know
it’s been tried).

\- Rewriting firmware in Rust sounds nice, but I don’t think vendors will do
it. They have enough problems writing decent C, and they don’t write open
source code. He is wishing for them to write Rust and release it as open
source, but I’m not optimistic about either of those things.

I think the kernel and the browser are where Rust is interesting – when you
need both performance and memory safety. I’m not really excited about Rust for
other applications like web services, i.e. doing the job that Go, Python, or
Ruby can do. So it does seem unfortunate that there are still some open
problems with using Rust for the kernel.

He also points out the many nascent Rust OSes kernels, and the fact that they
are “from scratch” systems, i.e. not compatible. I agree that you need a
compatible kernel to have any hope of adoption.

~~~
steveklabnik
> Rust doesn’t allow you to handle memory allocation failure. This is being
> worked on? I didn’t know this about Rust and it seems odd for a low level
> language.

The standard library panics upon allocation failure, but allocation is a
library thing, not a language thing. You can handle failure if you do it
yourself. Eventually we have a path forward to handling it for those data
structures too, but we’re not quite there yet.

This wasn’t a big concern because when you’re doing OS level stuff you’re
generally not using the standard library anyway.

~~~
chubot
OK, thanks for the clarification. C++ also has this issue, because vector<>
and so forth can raise std::bad_alloc. So AFAIK basically nobody who writes
kernels in C++ uses STL.

Although on second thought, I guess you _can_ handle it because it's an
exception rather than a panic. But exceptions have other downsides so people
don't use them in that domain.

~~~
steveklabnik
No problem. And yeah, it’s effectively the same. You can catch panics if you
really need to, but it’s certainly not idiomatic generally. (And most OS-level
code makes them aborts which cannot be caught.) This is a situation where it
would be... fine. Not as nice as making the api fallible from the start.

------
xuesj
Freedom is not free, what people make what ruler.

------
ncmncm
Since they started putting Rust in Firefox, it crashes literally hundreds of
times a day. (Usually the crashes are in subprocesses. Not always.) Is Rust to
blame? I don't know. But I would rather see some attention to the crashes than
any new features, or new OSes, right at the moment.

~~~
lytedev
If you're truly seeing crashes "literally hundreds of times per day", I'm sure
the Firefox team would appreciate the information you have! I suspect that the
problem is not Firefox itself, which I put through the ringer daily and am
extremely happy with it.

~~~
beatgammit
Usually this is graphics driver related, but there could definitely be some
bugs that OP's unique usage triggers.

