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)
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.
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.
Rust is based on LLVM so it can only support the architectures that are supported there (save maybe a reimplementation like sibling comment mentioned).
What I don't understand is this whole thing about bootstrapping a new arch by building a whole new compiler on it, then compiling the source of an existing compiler on it (twice). Bytes of machine code don't have color, it's just a regular pile of bytes like everything else. Why does the compiler even have to run on the new arch? Just build a new backend for an existing compiler, then cross compile. It makes no sense to me why the machine code of a system must be assembled on that system.
I don't mean to sound adversarial, I'm just very confused.
> It makes no sense to me why the machine code of a system must be assembled on that system.
Assembling the machine code of a system on itself means it's independent of its "parent" system. If I can't run the compiler on my new architecture (including compiling itself), I'll forever depend on having another machine with a different architecture to compile things. Yes, usually it's done by writing a new backend for an existing compiler, then using the new backend to cross-compile the compiler itself, and finally running the resulting compiler on the new architecture; you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks.
In the same way, when compiling a new version of a compiler, having the recently-built compiler build itself again makes sure it's independent of its "parent" compiler.
"Assembling the machine code of a system on itself means it's independent of its "parent" system."
Far as a compiler, that doesn't really matter for most systems (esp embedded). You can cross-compile to any architecture you want with portable code and a new backend. The only tools you need for each architecture's CPU's/MCU's are something to load and test the code. Those already exist in embedded sector. Instrumentation for Rust code would be necessary but this doesn't involve doing the whole compiler on, say, an 8-bitter.
"you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks."
That's an SCM security problem. You'd need to trust every compiler developer, the repo it's stored in, the transmission process, and whatever you used to build it. Most supposed solutions focus on the last one almost exclusively when the first three were the source of most attacks historically. In any case, that's barely relevant to the discussion of using Rust on a new architecture as almost nobody will every be hit by that & most people wanting Rust backends aren't doing high-assurance security for stopping nation-states or something. Those people hand-verify the assembly anyway.
> You'd need to trust every compiler developer, the repo it's stored in, the transmission process, and whatever you used to build it. Most supposed solutions focus on the last one almost exclusively when the first three were the source of most attacks historically.
The first three aren't a "trusting trust" attack. With the first three, any attack is visible in the code that you eventually compile. The whole point of "trusting trust" is no amount of source code inspection will ever uncover the problem.
As infogulch noted, the reason I counter mentions of Paul Karger's attack (MULTICS early 70's) that Thompson wrote about is that is has to be a social fad/meme to mention it when it's happened only twice on record. Millions of attacks, countless vulnerabilities by compiler errors, many repos compromised, and 2 instances of a compiler-induced subversion. Yet, you brought up Trusting Trust instead of the other stuff we really need to worry about. That's typical do I always point it out.
Plus, Karger pointed out solution shortly after the problem: verified compiler, safe languages, repo security (esp paper in safes), crypto/courier distribution, and designed to build locally from source using onsite tools rerunning all tests, proofs, etc. Mitigates the need for worrying about Trusting Trust most of the time plus knocks out majority of attacks. Better to mention that if worried about subversion. Or Myer's landmark work that defined in detail problems and solutions.
Trusting Trust meme just misdirects focus from important issues.
> you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks.
The point of that comment (at least, as I read it) isn't that you have to be worried about "trusting trust", but rather that there's no point in writing a new compiler from scratch unless you already are worried about "trusting trust" (with the implication being that most people aren't and so writing a new compiler from scratch isn't necessary).
SCM security issues (as you mentioned) are irrelevant at this point, because they really have no bearing on whether you have to write a new compiler from scratch.
I think nickpsecurity's point is that there are many more lucrative targets to attack than compiler binaries. More lucrative in both effort/reward payoff and also difficulty of detection. For example: Analog Malicious Hardware [1], that would allow a single component added to the chip mask to compromise the entire chip only by the attacker and be undetectable and maintain plausible deniability. Other targets like BIOS, Intel AMT, etc would also be better.
The "trusting trust" argument is wholly unconvincing for the reasons nickpsecurity mentioned. There are too many moving pieces in this equation already, and piling on "moving to a new architecture" on top of everything else just doesn't make sense.
So that leaves just independence, which you solved right in your comment: use an existing compiler with a new backend to cross-compile itself. If your compiler is portable this still means the only thing you need to write is the new backend.
You'd think this is the case but in practice it's actually pretty solid. Right now I've got a nontrivial(opengl + vm language + ssl + http) project with a mix of C/Rust I'm bringing up that runs on:
There's 8-bit MCU's all over the place. I tried to find some numbers for you with a quick Google. This 2014 Amtel report puts 8-bitters at $6+ billion a year. Even the 4-bitters are still making hundreds of millions a year. I include a bonus link on that if it perplexes you.
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.
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.
Yes but those are unlikely to be networked. The nasty stuff is something that is powerful enough to be connected to the internet and too weak to run modern languages. Fertile fields for Rust.
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.
... 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.
In the event that anyone isn't clear on the relative quality of discussions across various websites, please click the reddit link and observe someone asking a sincere question and getting specific and helpful responses, with no attempt to score points by misrepresenting the position of the others.
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.
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?
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.
"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)"
I'll note that Ada developers have been writing high-performance or real-time code in C's domain for some time without relying too much on unsafe pointers. They mostly use references or restricted pointers. It has additional benefit of separating types from how many bits represent them where miles and kilometers might be 32 bit but compiler error if you mix them. Also, bounds-checks on arrays or pointers. Then, SPARK subset that verifies absence of common vulnerabilities has no pointers at all. People still manage to build useful things like the IRONSIDES DNS server.
These show the advantages of C's pointers are overstated in the general case. Actually a drawback if building high-integrity software. Worst case, we write just those few algorithms in C, unsafe Ada, unsafe Rust, assembly or whatever then wrap them in strongly-typed, safer functions with input validation when called. That's standard in safe languages. Probably how Rust people do it, too.
Not having to do pointer play and other dangerous things is one of the points. This way you cannot reuse your machine code as a source of constants, or write self-modifying code the way you can do it in assembly.
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.
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.
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.
What does "native" mean, built into the language? Why does it matter?
I suspect it's the same with type punning (though also, to some degree because we're still working out the details of what exactly the semantics of unsafe are.) In the end, you can always cast stuff to bytes and then cast those bytes to something else.
I don't take (too much) objection to that, and little with "not much more", but that doesn't mean that C has some secret stuff that only C can do, which it feels like you're implying.
>What does "native" mean, built into the language? Why does it matter?
I don't know how that macro works, but in kernel C bitfields are used in structs that map to device registers (that are mapped to memory).
>I suspect it's the same with type punning (though also, to some degree because we're still working out the details of what exactly the semantics of unsafe are.) In the end, you can always cast stuff to bytes and then cast those bytes to something else.
So if i want to store a series of things with random (length) types in a single array, i can ? Sounds like i can, even though you explained the simpler case.
>I don't take (too much) objection to that, and little with "not much more", but that doesn't mean that C has some secret stuff that only C can do, which it feels like you're implying.
And for the third (edit:second) time, that is not my point. Thing is that C does not have "secret stuff" and rust does. In C you get what you wrote, and not much more. There is no need for telling the compiler to not do some checking or to not make a copy of something. (edit2: granted, bitfields are not native to cpus as type punning is)
Rust, IMO, is more for the C++ crowd then C. And those two are very different.
This is really not the case, not with modern C compilers. You may find calls to functions from the standard library to be converted in surprising ways, while touching undefined behaviour can eliminate evaluations, branches, function calls and more. Your mental model might have a close resemblance to assembly; but compilers don't see it like that any more.
>You may find calls to functions from the standard library to be converted in surprising ways, while touching undefined behavior can eliminate evaluations, branches, function calls and more.
Yes, things like memcpy and printf are (in most cases) built-in in compilers. Not surprising really.
Undefined behavioral is bad programming, if your ask me. Almost all examples of it, that i ran across, are in really ugly code that only a "smart" programmer would write.
Clangs static analyzer points out undefined behavior, and gcc is close to getting a "-Wundefined" flag that points that out at compile time.
A optimizing C compiler can change the resulting code even more then just doing dead code elimination. But the point still stands, that C maps well to assembly and that languages that do things like their own memory allocation are not even comparable to what the cpu provides (only automatic memory allocation that a cpu somewhat provides is the stack, and C exposes even that).
"Deterministically locating all undefined behavior is undecidable. Static analyzers can only locate a subset of it."
It might be true but barely matters when we have tools like KCC. It's built on an executable semantics of C that runs in a framework on top of Maude rewrite engine.
That's fascinating; thank you for that. I often find academic papers are too densely written to me to read, but the authors of that paper have gone out of their way to describe everything in a straightforward manner.
> I don't know how that macro works, but in kernel C bitfields are used in structs that map to device registers (that are mapped to memory).
Same thing. There's no requirement to use it in a kernel context, though you can if you'd like.
> So if i want to store a series of things with random (length) types in a single array, i can ? Sounds like i can, even though you explained the simpler case.
Yes, though it'd use a lot of unsafe code.
> And for the third (edit:second) time, that is not my point. Thing is that C does not have "secret stuff" and rust does.
Ah, sorry! The contrapositive (or whatever) is tough. My bad for misunderstanding.
