Hacker News Reader

Comment by ggm | Hacker News Reader

I can see both sides of this. The excitement of "new" and the concern of what is lost.

C++ wasn't put into critical dependency in the kernel in FreeBSD either. If you think it's just a dialect of C (I don't) then that speaks to the strength of opposition.

Lua was put in the kernel. Perhaps because "it's just forth" and has less risk of drift from a critical dependency.

When the pace of change of Rust moves to less-than-annual, I think it might be valid but frankly I think RustBSD is a better model: fork the code, write a rust kernel, maintain an ABI which C can live with, move forward.

View on HN

If we're going to write RustBSD, why not RustMinix -- and get the benefits of microkernel design? Isn't it about time we give up a few percent performance for robustness?

> why not RustMinix -- and get the benefits of microkernel design?

A person could reasonably argue that this is redox. It's different in that it's a new OS rather than a rust-ified version of an existing thing, but still, it's a microkernel unix-ish OS in rust.

If it has an ABI which means POSIX tools just work, I'm fine if its a microkernel. MACH was at the heart of lots of things too. We could do capabilities based OS design you name it. 9P, I don't care.

What I care about is getting an interactive shell prompt and a filesystem with . and .. and / and BOURNE shell compatible semantics, and an ability to run vi and emacs. (I am less sure plan9 people care about shell btw they went rc and then into some place I don't understand up in the 5th dimension)

Did anybody mention plan9? At any rate it is not a microkernel. There is at least one effort implementing v6 unix in rust. That would probably meet your minimum requirements!

Minix is sadly dead. Minix on RISC-V seems like it would have been a pedagogical gold mine and yet it hasn’t happened last I checked.

xv6 is now targeting RISC-V and has displaced MINIX as a better pedagogical tool in my opinion.

MINIX is dead for multiple reasons, including technical ones [1]. Simply put, its design and implementation are no longer fit for purpose on modern systems. At this point, starting over from scratch would probably be more effective than trying to address all of its issues.

[1] https://news.ycombinator.com/item?id=34916261

> When the pace of change of Rust moves to less-than-annual

Doubt: https://blog.rust-lang.org/2014/10/30/Stability.html#will-ru...

> Will Rust and its ecosystem continue their rapid development?

> Yes! [...] and we expect this will only accelerate.

Emphasis mine.

You're quoting a post from 2014, before Rust released 1.0. Of course the pace of changes was going to accelerate. I don't think it's fair to present that as if it were a current forward-looking statement from the Rust project. And of course it will slow down over time. Rust and it's ecosystem are much more stable now, ten years later and 80 releases after 1.0.

I got that from https://doc.rust-lang.org/edition-guide/editions/index.html, the second link in the first paragraph.

Alright. I can see how that might be confusing. To my eye, they are linking to that page because it documents how they intend to approach releases and editions. Not to indicate that they expect the pace of change to monotonically increase into the perpetual future.

Reply on news.ycombinator.com