7 ms·

Rust: “Move fast and break things” as a moral imperative

61 points by als0 6y ago

jonnypotty 6y ago
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.
- thesuperbigfrog 6y ago
  >> 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".
  - ddevault 6y ago
    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.
    - thesuperbigfrog 6y ago
      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.
      - ddevault 6y ago
        >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.
    - Thiez 6y ago
      Which features would you remove?
- pornel 6y ago
  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? Check out slides from this talk: https://www.usenix.org/conference/enigma2021/presentation/palmer 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.
  - jonnypotty 6y ago
    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.
    - pornel 6y ago
      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.
- nine_k 6y ago
  By working hard, testing, and moving very slowly. 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.
- Ar-Curunir 6y ago
  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?
thesuperbigfrog 6y ago
>> 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 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/ 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.
- ddevault 6y ago
  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.
CDSlice 6y ago
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++.
- ddevault 6y ago
  >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.
1MachineElf 6y ago
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_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 https://github.com/rust-lang/foundation-faq-2020/issues/35
- c-cube 6y ago
  This page was discussed on HN previously: https://news.ycombinator.com/item?id=21871479 https://news.ycombinator.com/item?id=21871479 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.
- erk__ 6y ago
  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.
lumpa 6y ago
Compare and contrast with https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.html https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.ht.... ISTM that Rust is way more deserving of an anti-FUD blog post than Wayland is. "Maybe Rust doesn’t work for your precious use-case."
- ddevault 6y ago
  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.
- kevincox 6y ago
  I agree. This is a much more reasonable post.
- PoignardAzur 6y ago
  Oh yeah. The lack of self-awareness is boggling.
theXspidy 6y ago
Get daily informative news from noisy news straight to your inbox with https://CutThroughTheNoise.co https://CutThroughTheNoise.co For free
emptyparadise 6y ago
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.
- ddevault 6y ago
  That would be cool.
- c-cube 6y ago
  There's checked C [1] as the most recent take on a safer C. [1] https://www.microsoft.com/en-us/research/project/checked-c/ https://www.microsoft.com/en-us/research/project/checked-c/
- thesuperbigfrog 6y ago
  MISRA C (https://en.wikipedia.org/wiki/MISRA_C https://en.wikipedia.org/wiki/MISRA_C) is a stripped-down version of C that is used in critical applications.
  - als0 6y ago
    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.
    - thesuperbigfrog 6y ago
      Yes. MISRA C might be a good candidate to add a borrow checker. 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.
- pornel 6y ago
  There are languages like that: https://www.microsoft.com/en-us/research/project/checked-c/ https://www.microsoft.com/en-us/research/project/checked-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.
Jkvngt 6y ago
Once there’s an ISO standard, Rust and Go and other nulangs might be worth looking at.
fctorial 6y ago
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.
- BearOso 6y ago
  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.
  - steveklabnik 6y ago
    Just so you know: 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 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
- edflsafoiewq 6y ago
  > Rustc is so big and slow because it does a lot. 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".
vlang1dot0 6y ago
> all the while yelling at us old fogies for being old and fogey. TIL that being 27 makes you an old fogie.
anthk 6y ago
I'm with you, this is getting ridiculous.
est31 6y ago
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).
weinzierl 6y ago
> 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 points by als0 6y ago

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.

thesuperbigfrog 6y ago
>> 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".
- ddevault 6y ago
  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.
  - thesuperbigfrog 6y ago
    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.
    - ddevault 6y ago
      >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.
  - Thiez 6y ago
    Which features would you remove?
pornel 6y ago
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? Check out slides from this talk: https://www.usenix.org/conference/enigma2021/presentation/palmer 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.
- jonnypotty 6y ago
  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.
  - pornel 6y ago
    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.
nine_k 6y ago
By working hard, testing, and moving very slowly. 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.
Ar-Curunir 6y ago
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?

thesuperbigfrog 6y ago

>> 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 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/ 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.

ddevault 6y ago
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.

CDSlice 6y ago

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++.

ddevault 6y ago
>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.

1MachineElf 6y ago

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_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 https://github.com/rust-lang/foundation-faq-2020/issues/35

c-cube 6y ago
This page was discussed on HN previously: https://news.ycombinator.com/item?id=21871479 https://news.ycombinator.com/item?id=21871479 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.
erk__ 6y ago
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.

lumpa 6y ago

Compare and contrast with https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.html https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.ht.... ISTM that Rust is way more deserving of an anti-FUD blog post than Wayland is. "Maybe Rust doesn’t work for your precious use-case."

ddevault 6y ago
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.
kevincox 6y ago
I agree. This is a much more reasonable post.
PoignardAzur 6y ago
Oh yeah. The lack of self-awareness is boggling.

theXspidy 6y ago

Get daily informative news from noisy news straight to your inbox with https://CutThroughTheNoise.co https://CutThroughTheNoise.co For free

emptyparadise 6y ago

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.

ddevault 6y ago
That would be cool.
c-cube 6y ago
There's checked C [1] as the most recent take on a safer C. [1] https://www.microsoft.com/en-us/research/project/checked-c/ https://www.microsoft.com/en-us/research/project/checked-c/
thesuperbigfrog 6y ago
MISRA C (https://en.wikipedia.org/wiki/MISRA_C https://en.wikipedia.org/wiki/MISRA_C) is a stripped-down version of C that is used in critical applications.
- als0 6y ago
  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.
  - thesuperbigfrog 6y ago
    Yes. MISRA C might be a good candidate to add a borrow checker. 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.
pornel 6y ago
There are languages like that: https://www.microsoft.com/en-us/research/project/checked-c/ https://www.microsoft.com/en-us/research/project/checked-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.

Jkvngt 6y ago

Once there’s an ISO standard, Rust and Go and other nulangs might be worth looking at.

fctorial 6y ago

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.

BearOso 6y ago
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.
- steveklabnik 6y ago
  Just so you know: 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 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
edflsafoiewq 6y ago
> Rustc is so big and slow because it does a lot. 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".

vlang1dot0 6y ago

> all the while yelling at us old fogies for being old and fogey. TIL that being 27 makes you an old fogie.

anthk 6y ago

I'm with you, this is getting ridiculous.

est31 6y ago

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).

weinzierl 6y ago

> 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.