I fundamentally disagree with the sentiment in this article. Rust does not have a culture of "move fast and break things", if anything it suffers from the opposite problem where language additions for things like const generics or async can take a long time to be stabilized because once they are they can't be changed. This is also why the standard library is so small, since it is subject to the same stability requirments as the language once something gets added to the standard library it can't be removed unless it is unsound.
Rust does have one current implementation, but there are efforts to get another one written in C added to GCC. There is also mrustc which is written in C++ and does not have a dependency on LLVM and can be very useful in bootstrapping rustc anywhere that has a C++ compiler.
I also personally don't think that Rust only having T1 support for Windows, Mac, and Linux on x86 and Arm is a problem, everything else is practically non-existant when compared to these platforms. The only potential execption I can think of is the BSDs but FreeBSD and NetBSD have T2 support which means that Rust will have a build for these platforms, they just might be buggy. If anyone wants to put in the work to make sure these builds are not buggy and make features work for them the Rust team will gladly bump them up to T1. However, I don't think it is worth putting in the effort for the other platforms mentioned in the blog post. How many people are using POWER9? Can you even buy a useable RISCV machine at the moment? If and when these architectures start being widely used I'm sure there will be somebody willing to port Rust to them, however until then it would be wasted effort.
I'm not going to argue that a formally verified C program is going to be worse than a Rust program, let alone that writing a program in Rust will instantly solve every security problem you have, but considuring how many memory safety bugs regularly cause security issues I think that writing new programs in Rust and putting the effort in to carefully rewrite C/C++ programs into Rust is a net benifit to security and certainly better than starting a new project in C or C++.
> I also personally don't think that Rust only having T1 support for Windows, Mac, and Linux on x86 and Arm is a problem, everything else is practically non-existant when compared to these platforms.
This sentiment of "Just use what is most popular!" is pretty common, and it always makes me sad especially on a site like this. Not supporting operating systems outside of the absolute mainstream also sends the signal of a lack of interest in developing new things.
I'd argue that valuing portability and making it as easy as possible in general comes with more benefits than just "supporting those unpopular platforms I don't care about", typically the users of those platform will come forward and do work if only you welcome them. Not focusing on niche systems in particular I can understand, but what speaks against making the porting easier for the willing?
There's nothing wrong with saying, "Look, I'll do everything I can to help you, but you're using a PowerPC on a $5000 FPGA board that I don't have, so the things I'll be able to do for you may be somewhat limited." It's super common to see kernel developers responding to bug reports stating that they need more traces from people with the affected hardware configuration. How is this any different?
There has to be a cutoff somewhere. The crux of this debate is the subjectivity around what counts as "niche".
When it comes to workstations or web servers, what the GP said is true: everything outside of Windows/Mac/Linux x86/arch64 (and maybe BSD) is extremely niche. When it comes to the space of all systems where C runs, that probably isn't the case. When it comes to the space of all systems that Rust (and packages that depend on Rust) should support (for some definition of "should")? Who knows.
There are two questions:
a) What kinds of systems should be targeted (by Rust itself and also downstream packages/distros)? Hardware from the past ten years? Twenty years? Forty years? Embedded devices? Industrial control systems? Mainframes? Obsolete workstations from companies that have been dead for decades and are only used because one other piece of crucial software requires them?
b) What percentage of the devices in those spheres are actually unsupported right now? If you told me that purely in terms of number of devices, Windows/Mac/Linux x86/arch64 covers 90% of the devices in the world, I would believe you. I would also believe you if you told me those only covered 40% of the devices in the world. I genuinely don't know. And this question has to be asked in the context of the answers to (a). Our subjective impressions of "how wide of an impact this has" are at the heart of the argument; we don't have a common truth. I think a lot of the emotions being seen are by people for whom it feels like their entire world is excluded. That alone isn't a basis for project scoping, though it's worth listening to.
Traditionally C's mantra has been that it runs on anything with an instruction-set (maybe inconsistently, but there will be something available!). That's cool! But if that's the bar for a new systems language, we will never ever get a new systems language because C has half a century's head-start. We can debate whether a specific package or distro was premature to require Rust, which is highly dependent on their target market of users (and not really the responsibility of the Rust community itself!), but no matter what, Rust itself is going to have a cutoff, and that alone isn't a valid reason to dismiss it.
>I also personally don't think that Rust only having T1 support for Windows, Mac, and Linux on x86 and Arm is a problem, everything else is practically non-existant when compared to these platforms. The only potential execption I can think of is the BSDs but FreeBSD and NetBSD have T2 support which means that Rust will have a build for these platforms, they just might be buggy. If anyone wants to put in the work to make sure these builds are not buggy and make features work for them the Rust team will gladly bump them up to T1. However, I don't think it is worth putting in the effort for the other platforms mentioned in the blog post. How many people are using POWER9? Can you even buy a useable RISCV machine at the moment? If and when these architectures start being widely used I'm sure there will be somebody willing to port Rust to them, however until then it would be wasted effort.
This is towing the party line, and the party line basically amounts to "fuck you" to anyone else. I addressed this directly in the article. T2 platforms are a nightmare to bootstrap and maintain. "Putting the work in" is a huge amount of work, because Rust is an extremely complicated and huge machine. These arguments are mainly made by people who have never actually tried to bootstrap rust on a T2 or T3 platform. Take it from someone who has: it SUCKS. I lack the vocabulary to adequately describe the suckage, and I have a pretty colorful vocabulary.
Yes, you can get working POWER9 and RISC-V hardware, and even find it in use in the field. And they've had working C toolchains for several years.
Why would you need to bootstrap Rust on a T2 platform? You already have a rustc build for that platform, can't you just use it? It may be buggy yes, but if you have a built compiler you should already be a good deal of the way to having a working compiler since you can "just" run the tests and see which ones break. Descriptions of what actual problems you ran into would be greatly appreciated, especially since riscv64-musl isn't a target mentioned at all in https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and I do want to know what makes it so hard to get a platform from T2 to T1.
I also resent the insults that I am blindly "towing the party line", I truly don't believe that with the market share POWER9 and RISCV have it is worth putting in the effort of supporting them unless you are a "true beliver" in them, in which case you can put the work in yourself if you want to. If this is unreasonably hard (which it does appear to be since you weren't able to make any progress in a week) it would be much better to hear what actually made it so hard instead of whining that the Rust devs won't support your esoteric platform for you.
> T2 platforms are a nightmare to bootstrap and maintain.
Yep. And devoting more resources to this, IMO, does not have the payoff of devoting more resources to making the language better or improving Rust on T1 platforms.
I think C, for example, was held back by support for esoteric platforms, such that the language doesn’t even say that a byte is 8 bits, or what the encoding for a string is. It gives great flexibility, but it has huge costs.
>> C is not memory safe. It suffers from undefined behavior. These are valid complaints. However, C code can be secure!
C and C++ code CAN be secure, but most of it is not. It is too easy to write or update C / C++ code so that it is not secure or has unexpected results.
The lack of memory safety and undefined behavior that is difficult to reason about is why C and C++ are being displaced by Rust.
https://blog.regehr.org/archives/213 gives great insights into how undefined behavior in C and C++ can be difficult to reason about and cause problems.
I agree with Drew that Rust is not perfect and it still needs to target more architecture and platforms, needs a formal specification, and needs more implementations, but it is the most promising alternative to C and C++ so far and it has a bright future with the recent Rust Foundation: https://foundation.rust-lang.org/
With support from AWS, Google, Huawei, Microsoft, and Mozilla, Rust will continue to get better and will undoubtedly begin to replace C and C++ more and more.
To me, the most promising alternative to C are actually alternatives to GCC and Clang, which don't use "undefined behavior" as a wanton license to rewrite your program to do whatever they feel like at the time. See for example the cproc compiler that I linked to in the article. And, as someone who still writes heaps of C code, I feel like undefined behavior is an over-stated problem. I run into weird C issues pretty infrequently. Memory safety does cause issues more often than undefined behavior, though. Unintialized values, use-after-free, buffer overflows, I run into these more often than I'd like. Usually they're pretty loud, though, so it's apparent that there's a bug somewhere, and tools like Valgrind make dealing with them pretty straightforward.
It helps to remember that you're not clever enough to do clever things, in any language. The other most promising alternative to C is just doing it more conservatively.
Also, the Rust Foundation just looks to me like a corporate mouthpiece, not unlike the Linux Foundation, which will do little to nothing to make Rust better for anyone. 10 directors and 1 developer, what a recipe for success!
Aside: I'm working on a new programming language which I hope will be interesting with respect to these ideas. It's being kept private while it's under development, but anyone who is interested in this problem space should shoot me an email if they want to hear more.
> Also, the Rust Foundation just looks to me like a corporate mouthpiece, not unlike the Linux Foundation, which will do little to nothing to make Rust better for anyone. 10 directors and 1 developer, what a recipe for success!
The Rust foundation isn't supposed to have any control over the project, rather it is meant to serve as a liason between companies that want to fund Rust development and operational costs and the developers that work on it full time. It also serves as a holding ground for various trademarks that used to be owned by Mozilla. You are also wrong on your numbers, only 5 of the directors are from companies, the rest are members of already existing Rust leadership.
>> To me, the most promising alternative to C are actually alternatives to GCC and Clang, which don't use "undefined behavior" as a wanton license to rewrite your program to do whatever they feel like at the time.
That's one of the biggest issues with C and C++: Undefined behavior is in the standards, so compilers can do whatever they want which can be problematic.
>> The other most promising alternative to C is just doing it more conservatively.
There are other programming languages besides C, C++, and Rust which target low-level and embedded targets. Ada or SPARK might be options depending on your needs and targets.
>> Aside: I'm working on a new programming language which I hope will be interesting with respect to these ideas. It's being kept private while it's under development, but anyone who is interested in this problem space should shoot me an email if they want to hear more.
That sounds very interesting. I look forward to seeing your ideas in the future.
> Switching to Rust breaks things for anyone who steps even a toe out of the norm of Linux/macOS/Windows on x86_64 or aarch64.
That's one way to see it. I much prefer to think "it doesn't work yet".
I mean, if it doesn't work in C too, Rust certainly didn't break it . If it works in C but there is no native Rust solution - just use the C code. Again, nothing broken.
Are non-native libraries a problem? Yes, but they are a perfectly good temporary solution too. The C world wasn't made in one day either and we will come to that - as long as we develop and change and unfortunately that means that we sometimes break things. At least that's how I see it.
I wonder if Rust can be stripped down (or C can be enhanced) to basically be C with a borrow checker and other safety features? I can live without Cargo or evangelism, but I'd also like to live without CVEs.
They are doomed to fail. You get all the downsides of not-C with all the downsides of C.
You still pay the cost of losing compatibility with standard compilers, and people with IBM/360 are still mad at you. You still pay the cost of learning borrow-checker-like semantics, and have to convince others to learn your unpopular language.
But you get very little in return. It's still C with its old warts. Whenever safety is the only thing you gain, there's a ton of people like Drew who will tell you it's stupid, because "C can be safe", we've been trying for only 40 years, so it's too soon to give up.
Rust attracts people who need safety, but they stay for the sum types, error handling, hygienic macros, and rich ecosystem.
CHERI (http://cheri-cpu.org) provides a spatially-safe C and C++, and also heap temporal safety (specifically it prevents use-after-reallocation, which is the actual vulnerability, since use-after-free doesn't matter if freed memory is never reallocated). Most code requires few, if any, changes (0.17% LoC in our fork of FreeBSD, which includes the kernel itself and all the low-level runtime libraries), with the changes tending to be due to people conflating pointers and integers (i.e. use uintptr_t not unsigned long/uint64_t for storing a union of a pointer and an integer, or a real union, and use size_t not uintptr_t when you mean a plain integer, though the latter can sometimes still work, just a little less efficiently and likely with some compiler warnings). It doesn't solve the concurrency issues, but unlike CHERI C/C++ those require invasive changes to the language and thus code.
MISRA C doesn't include a borrow checker, so it won't stop many memory safety issues. It's just a set of guidelines to discourage you from writing nasty or ambiguous C.
Rustc is so big and slow because it does a lot. The problem with rust is that it's trying to compete with both c and node, and it has started to tilt more towards node in recent years.
From the outside, it's hard to tell if this is true, or if Rust and rustc just consistently makes choices without valuing smallness or speed. The crate ecosystem definitely skews away from these and towards "grand abstraction".
I like rust, but I detest cargo. I don’t like that it forces a particular structure that makes every project feel like a visual studio template. I also don’t like that it has an single authoritative registry that it pulls packages from on build. This means that someone somewhere has too much control over the build process, and that I can’t work where there’s no internet access.
I agree about some of the points made here, but others are wrong. Sure you can write safe C, but maintaining and extending such a code base requires far more attention than working on a Rust code base. I think the criticism about additional RAM and CPU requirements is spot on. I'd love if the new Rust foundation would sponsor further engineering to reduce both requirements (although in many instances, it's an either or tradeoff).
As for the future, Rust has pioneered many features that clang lacks. E.g. incremental compilation, or multithreading (still not enabled by default).
Readit News
Rust does have one current implementation, but there are efforts to get another one written in C added to GCC. There is also mrustc which is written in C++ and does not have a dependency on LLVM and can be very useful in bootstrapping rustc anywhere that has a C++ compiler.
I also personally don't think that Rust only having T1 support for Windows, Mac, and Linux on x86 and Arm is a problem, everything else is practically non-existant when compared to these platforms. The only potential execption I can think of is the BSDs but FreeBSD and NetBSD have T2 support which means that Rust will have a build for these platforms, they just might be buggy. If anyone wants to put in the work to make sure these builds are not buggy and make features work for them the Rust team will gladly bump them up to T1. However, I don't think it is worth putting in the effort for the other platforms mentioned in the blog post. How many people are using POWER9? Can you even buy a useable RISCV machine at the moment? If and when these architectures start being widely used I'm sure there will be somebody willing to port Rust to them, however until then it would be wasted effort.
I'm not going to argue that a formally verified C program is going to be worse than a Rust program, let alone that writing a program in Rust will instantly solve every security problem you have, but considuring how many memory safety bugs regularly cause security issues I think that writing new programs in Rust and putting the effort in to carefully rewrite C/C++ programs into Rust is a net benifit to security and certainly better than starting a new project in C or C++.
This sentiment of "Just use what is most popular!" is pretty common, and it always makes me sad especially on a site like this. Not supporting operating systems outside of the absolute mainstream also sends the signal of a lack of interest in developing new things.
I'd argue that valuing portability and making it as easy as possible in general comes with more benefits than just "supporting those unpopular platforms I don't care about", typically the users of those platform will come forward and do work if only you welcome them. Not focusing on niche systems in particular I can understand, but what speaks against making the porting easier for the willing?
Tier 2 support is still support, and there are a lot of tier 2 targets. Seriously, look at the list:
https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
There's nothing wrong with saying, "Look, I'll do everything I can to help you, but you're using a PowerPC on a $5000 FPGA board that I don't have, so the things I'll be able to do for you may be somewhat limited." It's super common to see kernel developers responding to bug reports stating that they need more traces from people with the affected hardware configuration. How is this any different?
When it comes to workstations or web servers, what the GP said is true: everything outside of Windows/Mac/Linux x86/arch64 (and maybe BSD) is extremely niche. When it comes to the space of all systems where C runs, that probably isn't the case. When it comes to the space of all systems that Rust (and packages that depend on Rust) should support (for some definition of "should")? Who knows.
There are two questions:
a) What kinds of systems should be targeted (by Rust itself and also downstream packages/distros)? Hardware from the past ten years? Twenty years? Forty years? Embedded devices? Industrial control systems? Mainframes? Obsolete workstations from companies that have been dead for decades and are only used because one other piece of crucial software requires them?
b) What percentage of the devices in those spheres are actually unsupported right now? If you told me that purely in terms of number of devices, Windows/Mac/Linux x86/arch64 covers 90% of the devices in the world, I would believe you. I would also believe you if you told me those only covered 40% of the devices in the world. I genuinely don't know. And this question has to be asked in the context of the answers to (a). Our subjective impressions of "how wide of an impact this has" are at the heart of the argument; we don't have a common truth. I think a lot of the emotions being seen are by people for whom it feels like their entire world is excluded. That alone isn't a basis for project scoping, though it's worth listening to.
Traditionally C's mantra has been that it runs on anything with an instruction-set (maybe inconsistently, but there will be something available!). That's cool! But if that's the bar for a new systems language, we will never ever get a new systems language because C has half a century's head-start. We can debate whether a specific package or distro was premature to require Rust, which is highly dependent on their target market of users (and not really the responsibility of the Rust community itself!), but no matter what, Rust itself is going to have a cutoff, and that alone isn't a valid reason to dismiss it.
This is towing the party line, and the party line basically amounts to "fuck you" to anyone else. I addressed this directly in the article. T2 platforms are a nightmare to bootstrap and maintain. "Putting the work in" is a huge amount of work, because Rust is an extremely complicated and huge machine. These arguments are mainly made by people who have never actually tried to bootstrap rust on a T2 or T3 platform. Take it from someone who has: it SUCKS. I lack the vocabulary to adequately describe the suckage, and I have a pretty colorful vocabulary.
Yes, you can get working POWER9 and RISC-V hardware, and even find it in use in the field. And they've had working C toolchains for several years.
I also resent the insults that I am blindly "towing the party line", I truly don't believe that with the market share POWER9 and RISCV have it is worth putting in the effort of supporting them unless you are a "true beliver" in them, in which case you can put the work in yourself if you want to. If this is unreasonably hard (which it does appear to be since you weren't able to make any progress in a week) it would be much better to hear what actually made it so hard instead of whining that the Rust devs won't support your esoteric platform for you.
Yep. And devoting more resources to this, IMO, does not have the payoff of devoting more resources to making the language better or improving Rust on T1 platforms.
I think C, for example, was held back by support for esoteric platforms, such that the language doesn’t even say that a byte is 8 bits, or what the encoding for a string is. It gives great flexibility, but it has huge costs.
Deleted Comment
C and C++ code CAN be secure, but most of it is not. It is too easy to write or update C / C++ code so that it is not secure or has unexpected results.
The lack of memory safety and undefined behavior that is difficult to reason about is why C and C++ are being displaced by Rust.
https://blog.regehr.org/archives/213 gives great insights into how undefined behavior in C and C++ can be difficult to reason about and cause problems.
I agree with Drew that Rust is not perfect and it still needs to target more architecture and platforms, needs a formal specification, and needs more implementations, but it is the most promising alternative to C and C++ so far and it has a bright future with the recent Rust Foundation: https://foundation.rust-lang.org/
With support from AWS, Google, Huawei, Microsoft, and Mozilla, Rust will continue to get better and will undoubtedly begin to replace C and C++ more and more.
It helps to remember that you're not clever enough to do clever things, in any language. The other most promising alternative to C is just doing it more conservatively.
Also, the Rust Foundation just looks to me like a corporate mouthpiece, not unlike the Linux Foundation, which will do little to nothing to make Rust better for anyone. 10 directors and 1 developer, what a recipe for success!
Aside: I'm working on a new programming language which I hope will be interesting with respect to these ideas. It's being kept private while it's under development, but anyone who is interested in this problem space should shoot me an email if they want to hear more.
The Rust foundation isn't supposed to have any control over the project, rather it is meant to serve as a liason between companies that want to fund Rust development and operational costs and the developers that work on it full time. It also serves as a holding ground for various trademarks that used to be owned by Mozilla. You are also wrong on your numbers, only 5 of the directors are from companies, the rest are members of already existing Rust leadership.
That's one of the biggest issues with C and C++: Undefined behavior is in the standards, so compilers can do whatever they want which can be problematic.
>> The other most promising alternative to C is just doing it more conservatively.
There are other programming languages besides C, C++, and Rust which target low-level and embedded targets. Ada or SPARK might be options depending on your needs and targets.
>> Aside: I'm working on a new programming language which I hope will be interesting with respect to these ideas. It's being kept private while it's under development, but anyone who is interested in this problem space should shoot me an email if they want to hear more.
That sounds very interesting. I look forward to seeing your ideas in the future.
"Maybe Rust doesn’t work for your precious use-case."
Dead Comment
That's one way to see it. I much prefer to think "it doesn't work yet".
I mean, if it doesn't work in C too, Rust certainly didn't break it . If it works in C but there is no native Rust solution - just use the C code. Again, nothing broken.
Are non-native libraries a problem? Yes, but they are a perfectly good temporary solution too. The C world wasn't made in one day either and we will come to that - as long as we develop and change and unfortunately that means that we sometimes break things. At least that's how I see it.
They are doomed to fail. You get all the downsides of not-C with all the downsides of C.
You still pay the cost of losing compatibility with standard compilers, and people with IBM/360 are still mad at you. You still pay the cost of learning borrow-checker-like semantics, and have to convince others to learn your unpopular language.
But you get very little in return. It's still C with its old warts. Whenever safety is the only thing you gain, there's a ton of people like Drew who will tell you it's stupid, because "C can be safe", we've been trying for only 40 years, so it's too soon to give up.
Rust attracts people who need safety, but they stay for the sum types, error handling, hygienic macros, and rich ecosystem.
We have a technical report that gives an overview of CHERI and describes how to write good C/C++ that doesn't use dodgy idioms that break in CHERI C/C++ if you're interested at https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.html. Arm are also working on a prototype of Armv8-A with CHERI, dubbed Morello: https://www.morello-project.org.
[1] https://www.microsoft.com/en-us/research/project/checked-c/
From the outside, it's hard to tell if this is true, or if Rust and rustc just consistently makes choices without valuing smallness or speed. The crate ecosystem definitely skews away from these and towards "grand abstraction".
1. You can configure cargo to change the directory layout if you'd like
2. You can use alternative registries
3. There is an offline mode that will specifically not even attempt internet access.
Deleted Comment
Deleted Comment
TIL that being 27 makes you an old fogie.
As for the future, Rust has pioneered many features that clang lacks. E.g. incremental compilation, or multithreading (still not enabled by default).