You get rid of bugs by working hard and testing, not language features.
I feel like the safety that Rust offers is balanced out by the complexity it introduces. I don't understand why anyone would rewrite in Rust to try and get rid of bugs. You never get a more reliable product after this process.
>> You get rid of bugs by working hard and testing, not language features.
Hard work and testing do not solve all problems. There is a certain amount of inherent complexity in system-level and high performance application development that is not guaranteed to disappear through hard work and testing alone.
>> I feel like the safety that Rust offers is balanced out by the complexity it introduces.
Rust is merely exposing the complexity that is inherent to system-level and high performance application development. The same problem exists whether you use C, C++, Rust, or other programming languages that target system-level and high performance applications.
The difference is that Rust points out the problems instead of the C / C++ approach of "the developer knows what they are doing".
To some extent, Rust exposes the complexity inherent in systems programming, through features like the borrow checker. However, it's disingenous to say that all of Rust's complexity is a reflection of complexity inherent in systems. Rust is a very complicated language, much more so than is strictly necessary to achieve its goals. It has a lot of language features which have nothing to do with addressing the complexity of systems.
I agree that Rust is opinionated and complex. But most of the other widely-supported programming languages (that I use) for low-level and embedded development are also opinionated and complex: C++ and Ada.
C is obviously not as complex, but it that is because it offers so much less. Depending on what is needed, C may be a great choice, but it generally means bringing or creating a bunch of library code for string-handling, data structures, etc.
>C is obviously not as complex, but it that is because it offers so much less. Depending on what is needed, C may be a great choice, but it generally means bringing or creating a bunch of library code for string-handling, data structures, etc.
Yes, water is wet. I think that Rust is a great alternative to C++, but I wasn't using C++, either. Part of what makes C good and desirable for those of us that use it is that very simplicity which Rust eschews.
There are projects like Chromium that work extra hard, and yet they keep having memory safety bugs. Do they need to work harder? Get better programmers? Take security more seriously?
At some point you have to admit that the language is the problem. Eliminating entire classes of bugs by construction is much more effective than testing for them.
For example, sum types prevent most cases of unexpected nulls and uses of returned values without error checking.
Languages can't eliminate all bugs, but the more they can prevent, the more you can focus on testing the rest.
I agree that trying to eliminate a class of bugs through language design is a good thing to try, absolutely.
I just mean to say that the idea that you inherently make your software more reliable by "rewriting in Rust" is false. I don't contend that it could have benifits but I think to some extent you swap one set of problems for another and maybe in a language you don't understand as well as the one you're coming from.
I have first-hand experience that yes, Rust does make software more reliable. It noticeably changes the class of bugs you deal with. The low-level bugs like memory corruption or dangling pointers disappear. You're left dealing with mainly high-level issues, like features not implemented up to the spec, and deficiencies in the program architecture or algorithms (which you still have in any language).
It's not some Ying/Yang balance of force or a contract with the devil where getting rid of sneaky Undefined Behaviors must be paid for with another evil.
In C I've struggled with multi-threaded software, and even relatively tame solutions like OpenMP ended biting me. OTOH I haven't had to debug a data race in Rust yet (I've caused a bunch of deadlocks, but these are relatively easy). In C, despite my best efforts, I've occasionally had buffer overflows, leaks, and UAFs. In Rust I've had these only when interacting with C libraries via FFI.
You could probably say that my C bugs were my fault, and I'm just not a good C programmer. Well, I haven't got any smarter, but I'm a good Rust programmer.
The rate of new big features in Rust is slowing down quickly. The only big upcoming one is Generic associated Types.
That’s pretty good for 6-yr old language
Er every major tech company regularly reports that 70% of vulns in their C/C++ code bases are memory-safety related. How would rewriting in Rust, a language where those bugs are impossible, not prevent those bugs?
>> 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.
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. 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.
> 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.
Maintaining T2 platforms doesn't need to be a lot of work unless you make it so. Rust made that choice by being extraordinarily complicated, which I don't feel compelled to forgive it for.
There are a lot of platforms which aren't as stupid as "bytes aren't 8 bits" and are still useful to support. Rust supports TWO architectures with anything other than broken promises.
That is likely due to the fact the historically that wasnt the meaning of the word. There is a reason the RFC for IP uses octet to refer to 8 bit bytes. Another example of an old document that doesnt use byte to refer to 8 bit bytes is the Common Lisp standard.
So even though the current definition of byte is 8-bits the fact that the C standard uses the old definitiom is most likely because it is a document that can be traced back to an era were there was more diversity in the hardware architectures in common use.
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.
I like to build things from source, but I'd also like to hear more details about the problems encountered.
The whole tiers thing is first of all a chicken and egg problem. Which probably could be solved faster by keeping Drew invested. I also constantly have to fiddle with rust's lack of support for T2 (armv7-linux-musleabihf in the past and aarch64-linux-musl now, having given up on the former) and I agree that this aspect sucks and hinders adoption. And furthermore it defies one of rust's main goals, security: With something like ME/PSP having unrestricted access to whatever they want, why bother that much about memory safety?
Drew is an Alpine maintainer. Alpine, which you might know as probably the most-used server-side Linux distribution in the world right now, bootstraps everything in its repositories, just like every major Linux distribution on the planet.
> I do want to know what makes it so hard to get a platform from T2 to T1
Basically tier-1 targets must have tests run on CI for every merged commit. If anybody have a way to do that for their interest platforms, that's a huge step in making it to tier-1 platform support.
> 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 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.
>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
Say the same again about embedded devices and the Netflix network backend if you dare. Also, some compiling toolchains for consoles based on BSD os'es.
Embedded devices are MUCH more than the 90% of the world. Not eveything is a cumputer.
Add routers, switches, and mobile devices and now your "90%" goes out of the window.
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?
While Rust seems like a great programming language, I have come across some criticisms of it which appear to have some validity. Comparatively more impactful than what Drew describes here is the trademark problem that's listed on Hyperbola GNU/Linux site's webpage titled Rust's Freedom Flaws: https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...
*Please be aware that the rust project is now independent of Mozilla, so while the following has not been resolved, it is also not based on the latest information available.
Rust and also Cargo (the Rust package manager) violate the freedom to redistribute without “explicit” approval. Their trademark license imposes requirements for the distribution of modified versions that make it inconvenient to exercise freedom 3. The Rust's Media Guide says it merely supplements the official Mozilla trademark policy; it doesn't replace it. Since their trademark policy applies, then everything in that list (including Rust and Cargo) pulls in the same issue as Firefox and Thunderbird.
In short, Mozilla won't be happy with us applying patches and modifications to their trademarked language without “explicit approval”, except for non-commercial usage, so it is a freedom issue. For further references, there is a report in Rust about those trademark restrictions and Niko's response (one of the members of the Rust Legal Team).
I'm not an expert in this stuff, but this sounds like it could bear some weight. Currently the problem has not been resolved and it is still a matter to be considered by the rust board. Here is the latest thread on the problem I could find on the rust-lang GitHub: https://github.com/rust-lang/foundation-faq-2020/issues/35
Simply put, it's hyperbolic. Having several implementations would be good for multiple reasons, but one of them would be to put a final nail in that coffin.
The board had its first meeting yesterday so it will probably be looked at soon, i don't think that the minutes from the first meeting have been released yet, but they or a future set of minutes will likely contain a answer.
That article is specifically about people who harass the maintainers and bemoan Wayland over problems which it does not actually have, but feel free to cherry pick quotes to support whatever narrative you want.
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.
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.
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.
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.
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.
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 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).
> 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.
61 comments
[ 3.8 ms ] story [ 145 ms ] threadI feel like the safety that Rust offers is balanced out by the complexity it introduces. I don't understand why anyone would rewrite in Rust to try and get rid of bugs. You never get a more reliable product after this process.
Hard work and testing do not solve all problems. There is a certain amount of inherent complexity in system-level and high performance application development that is not guaranteed to disappear through hard work and testing alone.
>> I feel like the safety that Rust offers is balanced out by the complexity it introduces.
Rust is merely exposing the complexity that is inherent to system-level and high performance application development. The same problem exists whether you use C, C++, Rust, or other programming languages that target system-level and high performance applications.
The difference is that Rust points out the problems instead of the C / C++ approach of "the developer knows what they are doing".
C is obviously not as complex, but it that is because it offers so much less. Depending on what is needed, C may be a great choice, but it generally means bringing or creating a bunch of library code for string-handling, data structures, etc.
Yes, water is wet. I think that Rust is a great alternative to C++, but I wasn't using C++, either. Part of what makes C good and desirable for those of us that use it is that very simplicity which Rust eschews.
Check out slides from this talk: https://www.usenix.org/conference/enigma2021/presentation/pa...
At some point you have to admit that the language is the problem. Eliminating entire classes of bugs by construction is much more effective than testing for them.
For example, sum types prevent most cases of unexpected nulls and uses of returned values without error checking.
Languages can't eliminate all bugs, but the more they can prevent, the more you can focus on testing the rest.
I just mean to say that the idea that you inherently make your software more reliable by "rewriting in Rust" is false. I don't contend that it could have benifits but I think to some extent you swap one set of problems for another and maybe in a language you don't understand as well as the one you're coming from.
It's not some Ying/Yang balance of force or a contract with the devil where getting rid of sneaky Undefined Behaviors must be paid for with another evil.
In C I've struggled with multi-threaded software, and even relatively tame solutions like OpenMP ended biting me. OTOH I haven't had to debug a data race in Rust yet (I've caused a bunch of deadlocks, but these are relatively easy). In C, despite my best efforts, I've occasionally had buffer overflows, leaks, and UAFs. In Rust I've had these only when interacting with C libraries via FFI.
You could probably say that my C bugs were my fault, and I'm just not a good C programmer. Well, I haven't got any smarter, but I'm a good Rust programmer.
This is how you build pyramids.
If you want to build something taller and in 1% of the time, you relegate most of the work to machines.
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.
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 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.
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.
There are a lot of platforms which aren't as stupid as "bytes aren't 8 bits" and are still useful to support. Rust supports TWO architectures with anything other than broken promises.
That is likely due to the fact the historically that wasnt the meaning of the word. There is a reason the RFC for IP uses octet to refer to 8 bit bytes. Another example of an old document that doesnt use byte to refer to 8 bit bytes is the Common Lisp standard.
So even though the current definition of byte is 8-bits the fact that the C standard uses the old definitiom is most likely because it is a document that can be traced back to an era were there was more diversity in the hardware architectures in common use.
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.
The whole tiers thing is first of all a chicken and egg problem. Which probably could be solved faster by keeping Drew invested. I also constantly have to fiddle with rust's lack of support for T2 (armv7-linux-musleabihf in the past and aarch64-linux-musl now, having given up on the former) and I agree that this aspect sucks and hinders adoption. And furthermore it defies one of rust's main goals, security: With something like ME/PSP having unrestricted access to whatever they want, why bother that much about memory safety?
[citation needed]
Basically tier-1 targets must have tests run on CI for every merged commit. If anybody have a way to do that for their interest platforms, that's a huge step in making it to tier-1 platform support.
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?
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.
Once you get down from the obvious large players people tend to consider what they do mainstream enough and what they don't do too niche.
Say the same again about embedded devices and the Netflix network backend if you dare. Also, some compiling toolchains for consoles based on BSD os'es.
Embedded devices are MUCH more than the 90% of the world. Not eveything is a cumputer.
Add routers, switches, and mobile devices and now your "90%" goes out of the window.
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?
*Please be aware that the rust project is now independent of Mozilla, so while the following has not been resolved, it is also not based on the latest information available.
Rust and also Cargo (the Rust package manager) violate the freedom to redistribute without “explicit” approval. Their trademark license imposes requirements for the distribution of modified versions that make it inconvenient to exercise freedom 3. The Rust's Media Guide says it merely supplements the official Mozilla trademark policy; it doesn't replace it. Since their trademark policy applies, then everything in that list (including Rust and Cargo) pulls in the same issue as Firefox and Thunderbird.
In short, Mozilla won't be happy with us applying patches and modifications to their trademarked language without “explicit approval”, except for non-commercial usage, so it is a freedom issue. For further references, there is a report in Rust about those trademark restrictions and Niko's response (one of the members of the Rust Legal Team).
I'm not an expert in this stuff, but this sounds like it could bear some weight. Currently the problem has not been resolved and it is still a matter to be considered by the rust board. Here is the latest thread on the problem I could find on the rust-lang GitHub: https://github.com/rust-lang/foundation-faq-2020/issues/35
Simply put, it's hyperbolic. Having several implementations would be good for multiple reasons, but one of them would be to put a final nail in that coffin.
"Maybe Rust doesn’t work for your precious use-case."
[1] https://www.microsoft.com/en-us/research/project/checked-c/
I am not terribly familiar with the MISRA C rules, so I am not sure how much borrowing / move semantics is permitted under MISRA C.
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. 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.
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".
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).
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.