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.
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:
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.
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.
[+] [-] verytrivial|8 years ago|reply
[+] [-] dbaupp|8 years ago|reply
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.
[+] [-] jeffdavis|8 years ago|reply
Just experimenting myself, but I've had a positive experience so far.
[+] [-] bluejekyll|8 years ago|reply
Lots of great discussion on new tools, libraries, etc.
[+] [-] Ar-Curunir|8 years ago|reply
[+] [-] maxxxxx|8 years ago|reply
[+] [-] doody12|8 years ago|reply
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.
[+] [-] infogulch|8 years ago|reply
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.
[+] [-] vvanders|8 years ago|reply
[+] [-] lloydjatkinson|8 years ago|reply
But there are literally billions of 8bit and 16bit embedded systems out there, many of which have a C compiler.
[+] [-] sadiq|8 years ago|reply
https://juliacomputing.com/blog/2016/03/10/j2c-announcement....
[+] [-] jjnoakes|8 years ago|reply
I have high hopes for something like https://github.com/thepowersgang/mrustc
[+] [-] pjmlp|8 years ago|reply
C wasn't that portable in the 80's and 90's, with all its flavous across CP/M, MS-DOS, 8-bit home micros, mainframes, ...
[+] [-] empath75|8 years ago|reply
[+] [-] rnestler|8 years ago|reply
[+] [-] tom_mellior|8 years ago|reply
[+] [-] gens|8 years ago|reply
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.
[+] [-] nickpsecurity|8 years ago|reply
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.
http://www.adacore.com/knowledge/technical-papers/safe-and-s...
https://en.wikipedia.org/wiki/SPARK_(programming_language)
http://ironsides.martincarlisle.com/
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.
[+] [-] nine_k|8 years ago|reply
It's just a different set of tradeoffs.
[+] [-] steveklabnik|8 years ago|reply
Rust's raw pointers have equivalent power to C's pointers.
[+] [-] Ar-Curunir|8 years ago|reply
And no-no should program in assembly unless they know exactly what they're doing.