
System programming in Rust: beyond safety - mpweiher
https://blog.acolyer.org/2017/06/14/system-programming-in-rust-beyond-safety/
======
verytrivial
I look forward to more "Rust proved to be great to implement this real
feature/system/OS, here it is!" posts and fewer "Why you/someone else should
use Rust for feature/system/OS instead of your awful and dangerous language,
sneer!" (The people at redox-os.org are doing great work here I think)

~~~
dbaupp
Genuine question: when was the last article to "sneer" on HN? There was the
Linux kernel one a few weeks ago, but the meat of that that was more actual
code proving that Rust worked in practice to replace a section of a large
existing code base, rather than abstract sneering.

It seems like the thing that happens most often is people complaining about
"RiiR" and "RESF" etc, rather than the actual annoying things those refer to,
so much so that it has become a self-perpetuating meme seizing upon the
smallest hint of the bad behaviour.

------
doody12
I think one of the big issues with Rust is that it isn't as portable as C.

Bootstrapping Rust is hard, doing the same for C is simple. I could create a
simple C compiler just to bootstrap the real C compiler, something I have
actually done once or twice before. That's not something you do with Rust, at
least from the limited experience I have with Rust.

~~~
lloydjatkinson
Rust is also 32bit/64bit. That's totally fine (obviously) for PC-like
situations and servers and more powerful embedded systems, etc.

But there are literally billions of 8bit and 16bit embedded systems out there,
many of which have a C compiler.

~~~
nine_k
Are 8-bit systems still being used for new development?

~~~
shortsightedsid
Oh, absolutely. The most familiar to software engineers is the AVR used in
Arduino but there are so many 8 Bit micros out there (literally 10's of
thousands different device) and new ones are coming out every month. So plenty
of new development going on.

~~~
kjs3
There are a couple of orders of magnitudes more Intel 8051 derivatives out
there than there will ever be AVRs, and they still have yearly sales in the
100s of millions.

~~~
jononor
And how many percent of this is for new development?

------
empath75
This is more interesting than the standard Rust article about borrowing and
lifetimes, and is more about how linear types can be used to enable new safety
features easily.

------
rnestler
There was a small discussion about it on the Rust reddit:
[https://www.reddit.com/r/rust/comments/6h5mht/system_program...](https://www.reddit.com/r/rust/comments/6h5mht/system_programming_in_rust_beyond_safety_the/)

~~~
tom_mellior
... a large part of which was just responses to one person who said "OMG, you
can't write a kernel in Haskell, it uses malloc", as if (a) Linux didn't have
its own kmalloc, and (b) a hypothetical Rust kernel wouldn't use malloc.

~~~
hashhar
That is a very good question for someone new to the field and the answer is
really well detailed. Honestly, as of right now the discussion there is more
enlightening than here.

~~~
tom_mellior
I agree that in a thread about Rust systems programming, asking how Rust (and,
come to think of it, Haskell) can do dynamic allocation on the bare metal is a
good question. I think the good underlying question was devalued by what I
think was the poster's lack of reflection. Obviously Rust can do it because
Rust is magical, but Haskell? How would that ever work?

Your interpretation may vary.

~~~
hashhar
With the added context your original comment makes more sense to me.

Also, now this thread is better than the one over on Reddit.

------
gens
C is not only better for performance, but also because you simply can not do
some things in most other languages. Rust lacks bitfields, for one. But the
bigger thing are pointers. AFAIK you can not do type punning in rust, and i
don't know if you can do other pointer plays. (note that pointers are barely
even mentioned in this blog post)

IMO rust is a replacement for C++, not for C. C is much closer to assembly
then most all other languages, especially those that deal with memory
allocation natively.

~~~
steveklabnik
[https://crates.io/crates/bitflags](https://crates.io/crates/bitflags)

Rust's raw pointers have equivalent power to C's pointers.

~~~
gens
>[https://crates.io/crates/bitflags](https://crates.io/crates/bitflags)

Not native, see C.

>Rust's raw pointers have equivalent power to C's pointers.

Again, AFAIK you can't do type punning.

That wasn't even my point, that was that C gives you almost everything a cpu
does and not much more.

~~~
tetromino_
> Not native.

Bitflags crate _is_ native; 100% Rust, 0% C. Here is the source:
[https://github.com/rust-lang-
nursery/bitflags/blob/master/sr...](https://github.com/rust-lang-
nursery/bitflags/blob/master/src/lib.rs)

~~~
gens
[https://docs.rs/bitflags/0.9.1/bitflags/](https://docs.rs/bitflags/0.9.1/bitflags/)
vs
[https://www.tutorialspoint.com/cprogramming/c_bit_fields.htm](https://www.tutorialspoint.com/cprogramming/c_bit_fields.htm)

But i give up, as this isn't a technical discussion.

~~~
tetromino_
I am sorry, but really I don't understand specifically which difference
between C bitfields and Rust bitflags you regard as crucial. Is it about the
feature being baked into the compiler vs. available as an external macro
package? But the only reason it needs to be baked into the compiler in C is
because there's no other choice - the C preprocessor syntax is too limited and
awful.

~~~
mcguire
I believe the point is that C bitfields allow sub-word addressing; the
variable refers to specific bits within a word. The Rust flags is the same as
using bitwise operations on word-sized values.

To be honest, I don't know if a functional difference, but I have not done any
embedded programming where there might be a difference.

~~~
AnimalMuppet
I've seen plenty of hardware registers that use one bit for some X, two bits
for some Y, and 5 bits for some Z. (Yes, in embedded programming.) One way of
dealing with that is with C bitfields.

Now, I never did it that way myself. I just and-ed it with a bitmask to get
the part that I wanted. But it's a bit messier to do it that way, because if
you want one of the fields as a number, and it's not from the least-
significant bits, then you have to shift it as well as mask it, whereas with
bitfields you can just read it as a number and get the right value.

~~~
pjmlp
Spend a few minutes writing wrapper functions and its done.

Never bothered me on Turbo Pascal days, plus if I remember correctly bitfield
ordering is not portable across compilers anyway.

