7 ms·

I think there is a big ideological element to this. As a Rust outsider, I feel like it's the computer science embodiment of the current political discourse. Th

I think there is a big ideological element to this. As a Rust outsider, I feel like it's the computer science embodiment of the current political discourse. There is something about the "one true cause" mentality, and the need to co-opt projects with other goals and steer them towards the cause. Honestly, it is a really weird experience to have around a programming language, and to me is offputting for something that otherwise could have some very interesting merits. I expect people wont agree with me, and I'm not arguing against the technical merits of the language, I'm just saying that it stands out because of the ideological following it has, and that is cause for concern if ideology is a big reason people try and push to integrate it in something as important as linux.

roca 6y ago
Some of us are mentally scarred from decades of dealing with weak type systems, undefined behavior, and general inability to be sure of what's going on in gargantuan C++ codebases. Rust was more or less specifically designed to appeal to people like us. Throw a rope to a drowning person and they'll grab onto it hard.
- otabdeveloper4 6y ago
  Rust won't make legacy code and legacy coders go away. In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow. So Rust is not a solution.
  - nicoburns 6y ago
    > In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow But it will make those codebases a lot easier to deal with because the Rust compiler enforces correctness in a myriad of ways that other languages don't. I would much, much rather deal with a legacy Rust codebase than a legacy C++ one.
    - otabdeveloper4 6y ago
      This isn't true. Or, rather, there are also a myriad of ways that C++ enforces correctness that Rust doesn't. Legacy codebases are smelly not because of a lack of tools for enforcing correctness. They're smelly because a) programming is hard, and b) a boatload of things are more important than correctness, in the real world. > I would much, much rather deal with a legacy Rust codebase than a legacy C++ Obviously, because right now legacy Rust codebases are only 5 years old, while legacy C++ codebases are 30+ years old. But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today.
      - nicoburns 6y ago
        > there are also a myriad of ways that C++ enforces correctness that Rust doesn't. There are? Like what? > But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today. I don't really believe this. There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones. And Rust is stricter than Java.
        otabdeveloper4 6y ago
        > There are? Like what? Exceptions, for example. > There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones. That's because Java doesn't attempt to solve difficult problems.
        roca 5y ago
        Exceptions are terrible for correctness. They introduce hidden control flow paths that developers forget about and fail to handle correctly. (Also they break the "pay for what you use" principle, so C++ is split into two ecosystems, one which uses exceptions and one which doesn't.) Exceptions are better than magical return values to indicate errors, that's true, but Rust Results achieve the same thing without the downsides of exceptions. > That's because Java doesn't attempt to solve difficult problems. Java isn't my favourite language, but that's just silly. GraalVM will do as a counterexample.
  - roca 6y ago
    Fortunately I am mostly able to avoid working on legacy C++ code these days (rr being the exception, and it's only 70K lines). Rust code accumulates some cruft over time, but Rust's type system and safety guarantees put a floor on how crappy the code can be. The first Rust code I ever wrote is still part of my project five years later; it's less than perfect, but it's free of undefined behavior now just as it was then. The data structure parsers I wrote four years ago look a bit ugly to me now, but are free of exploitable security bugs, and always were. Etc.
    - otabdeveloper4 6y ago
      > undefined behavior What does that even mean in the absence of a formal standard and competing compiler implementations? (Hint: nothing.) If you refuse to define anything then you automatically make the "undefinedness" problem go away. (But not the pain it causes.) > Rust's type system and safety guarantees put a floor on how crappy the code can be No. The floor on crappiness is defined by the problem domain. Powerful features allow for powerful takes on crappiness. Unless you want Rust to stay a teaching language forever, you must necessarily introduce abusable features. (See Python for a real-time slow-motion elaboration of this train wreck if you don't believe me.)
      - roca 5y ago
        > What does that even mean in the absence of a formal standard and competing compiler implementations? It means that when the language designers are asked "what is the behavior of this code (that compiles and doesn't use 'unsafe')?" they never throw up their hands and say "it's undefined behaviour, you must not write that code" (as the C++ definition often says). They may say "oops, we're not sure what it should do, we need to clarify the language definition and write some tests to ensure the compiler does that". (This happens in C++ too.) > Powerful features allow for powerful takes on crappiness. I don't know what this means. > Unless you want Rust to stay a teaching language forever A lot of companies big and small are using Rust in production so this is not a compelling premise.
        otabdeveloper4 5y ago
  - mlindner 5y ago
    It doesn't no, but if I advocate for the language enough and get it used enough, I can guarantee for the entire rest of my career I can maybe avoid ever having to write any more new projects in said languages. I can just avoid jobs where such languages are still used commonly.
    - otabdeveloper4 5y ago
      Wait ten more years and Rust will become one of these 'said languages'. (Maybe even faster; the Rust people make it their principle to never learn from others' mistakes. There is no way they won't repeat them.)
      - roca 5y ago
        You're just making stuff up. Most aspects of Rust's design are based on lessons learned from mistakes and good ideas in C++ and other languages. There was a conscious effort to avoid inventing more new things than necessary.
techdragon 6y ago
Is it an ideology or is it just a growing consensus that Rust is really as good as everyone says it is? While I can see how it might look ideological, it doesn’t “feel” ideological to me at least. It feels like a few years ago we hit critical mass and crossed the point where enough people feel like Rust is never going away, that people began to really rely on it, and once they showed this work to other people those people liked what they saw and decided to give it a try and Rust is growing organically on the back of “doing the right things” and just generally being “a good language” for so many more things than people are used to.
- ansible 6y ago
  Yep. I think Bryan Cantrill's talk from 2018 encapsulates things pretty well: https://www.youtube.com/watch?v=LjFM8vw3pbU https://www.youtube.com/watch?v=LjFM8vw3pbU Bryan is a hardcore C guy, and can write safe and reliable C code. But he has reached the limits of what C can offer in terms of composability and abstraction. Like Linus, he wants and needs the kind of high performance and dependable behavior for systems programming that isn't possible with a garbage-collected language.
  - ssokolow 5y ago
    He also wrote a couple of blog posts called "Falling in love with Rust" and "Rust after the honeymoon": http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/ http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-... http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeymoon/ http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeym...
- selfhoster11 6y ago
  This is exactly my perception too.
saemei 6y ago
Sometimes ideologies actually point in the right direction. The hard part is to recognize the gems amid the firehose of truly bad ones. FWIW, I think the memory safety-first ideology of Rust is worth spreading.
- bjourne 6y ago
  Agreed. Which is why I prefer garbage collected languages. Rustaceans, however, harbor an irrational fear of garbage collection pauses, hence "memory safety-first ideology" built on garbage collection is heresy. The one true path to memory safety nirvana is through the holy borrows checker. :)
  - mlindner 5y ago
    Well the set of all programs where garbage collectors can be used is smaller than the set of all programs where manual memory management can be used (either done by the compiler or manually by the programmer). This doesn't counter your point completely, but it bears thinking about.
  - saemei 5y ago
    Rust' memory safety feature includes "fearless concurrency". Popular GC languages like Java or Go are not able to prevent a class of data race bugs that Rust prevents at compile time. Languages like Haskell of course handle it much better, but are for a multitude of reasons not popularly used in production. And as the sibling comment points out, GC languages are not applicable everywhere. This discussion is in the context of the first not-C language being added to the Linux kernel. Can you imagine a GC language being similarly considered? So yes, the borrow checker is amazing. That feeling of satisfaction and confidence when the program finally compiles after a round of serious coding or refactoring is unparalleled among the mainstream languages I've tried so far.
    - bjourne 5y ago
      > Rust' memory safety feature includes "fearless concurrency". Can you give me an example?

roca 6y ago

Some of us are mentally scarred from decades of dealing with weak type systems, undefined behavior, and general inability to be sure of what's going on in gargantuan C++ codebases. Rust was more or less specifically designed to appeal to people like us. Throw a rope to a drowning person and they'll grab onto it hard.

otabdeveloper4 6y ago
Rust won't make legacy code and legacy coders go away. In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow. So Rust is not a solution.
- nicoburns 6y ago
  > In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow But it will make those codebases a lot easier to deal with because the Rust compiler enforces correctness in a myriad of ways that other languages don't. I would much, much rather deal with a legacy Rust codebase than a legacy C++ one.
  - otabdeveloper4 6y ago
    This isn't true. Or, rather, there are also a myriad of ways that C++ enforces correctness that Rust doesn't. Legacy codebases are smelly not because of a lack of tools for enforcing correctness. They're smelly because a) programming is hard, and b) a boatload of things are more important than correctness, in the real world. > I would much, much rather deal with a legacy Rust codebase than a legacy C++ Obviously, because right now legacy Rust codebases are only 5 years old, while legacy C++ codebases are 30+ years old. But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today.
    - nicoburns 6y ago
      > there are also a myriad of ways that C++ enforces correctness that Rust doesn't. There are? Like what? > But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today. I don't really believe this. There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones. And Rust is stricter than Java.
      - otabdeveloper4 6y ago
        > There are? Like what? Exceptions, for example. > There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones. That's because Java doesn't attempt to solve difficult problems.
        roca 5y ago
        Exceptions are terrible for correctness. They introduce hidden control flow paths that developers forget about and fail to handle correctly. (Also they break the "pay for what you use" principle, so C++ is split into two ecosystems, one which uses exceptions and one which doesn't.) Exceptions are better than magical return values to indicate errors, that's true, but Rust Results achieve the same thing without the downsides of exceptions. > That's because Java doesn't attempt to solve difficult problems. Java isn't my favourite language, but that's just silly. GraalVM will do as a counterexample.
- roca 6y ago
  Fortunately I am mostly able to avoid working on legacy C++ code these days (rr being the exception, and it's only 70K lines). Rust code accumulates some cruft over time, but Rust's type system and safety guarantees put a floor on how crappy the code can be. The first Rust code I ever wrote is still part of my project five years later; it's less than perfect, but it's free of undefined behavior now just as it was then. The data structure parsers I wrote four years ago look a bit ugly to me now, but are free of exploitable security bugs, and always were. Etc.
  - otabdeveloper4 6y ago
    > undefined behavior What does that even mean in the absence of a formal standard and competing compiler implementations? (Hint: nothing.) If you refuse to define anything then you automatically make the "undefinedness" problem go away. (But not the pain it causes.) > Rust's type system and safety guarantees put a floor on how crappy the code can be No. The floor on crappiness is defined by the problem domain. Powerful features allow for powerful takes on crappiness. Unless you want Rust to stay a teaching language forever, you must necessarily introduce abusable features. (See Python for a real-time slow-motion elaboration of this train wreck if you don't believe me.)
    - roca 5y ago
      > What does that even mean in the absence of a formal standard and competing compiler implementations? It means that when the language designers are asked "what is the behavior of this code (that compiles and doesn't use 'unsafe')?" they never throw up their hands and say "it's undefined behaviour, you must not write that code" (as the C++ definition often says). They may say "oops, we're not sure what it should do, we need to clarify the language definition and write some tests to ensure the compiler does that". (This happens in C++ too.) > Powerful features allow for powerful takes on crappiness. I don't know what this means. > Unless you want Rust to stay a teaching language forever A lot of companies big and small are using Rust in production so this is not a compelling premise.
      - otabdeveloper4 5y ago
- mlindner 5y ago
  It doesn't no, but if I advocate for the language enough and get it used enough, I can guarantee for the entire rest of my career I can maybe avoid ever having to write any more new projects in said languages. I can just avoid jobs where such languages are still used commonly.
  - otabdeveloper4 5y ago
    Wait ten more years and Rust will become one of these 'said languages'. (Maybe even faster; the Rust people make it their principle to never learn from others' mistakes. There is no way they won't repeat them.)
    - roca 5y ago
      You're just making stuff up. Most aspects of Rust's design are based on lessons learned from mistakes and good ideas in C++ and other languages. There was a conscious effort to avoid inventing more new things than necessary.

techdragon 6y ago

Is it an ideology or is it just a growing consensus that Rust is really as good as everyone says it is? While I can see how it might look ideological, it doesn’t “feel” ideological to me at least. It feels like a few years ago we hit critical mass and crossed the point where enough people feel like Rust is never going away, that people began to really rely on it, and once they showed this work to other people those people liked what they saw and decided to give it a try and Rust is growing organically on the back of “doing the right things” and just generally being “a good language” for so many more things than people are used to.

ansible 6y ago
Yep. I think Bryan Cantrill's talk from 2018 encapsulates things pretty well: https://www.youtube.com/watch?v=LjFM8vw3pbU https://www.youtube.com/watch?v=LjFM8vw3pbU Bryan is a hardcore C guy, and can write safe and reliable C code. But he has reached the limits of what C can offer in terms of composability and abstraction. Like Linus, he wants and needs the kind of high performance and dependable behavior for systems programming that isn't possible with a garbage-collected language.
- ssokolow 5y ago
  He also wrote a couple of blog posts called "Falling in love with Rust" and "Rust after the honeymoon": http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/ http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-... http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeymoon/ http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeym...
selfhoster11 6y ago
This is exactly my perception too.

saemei 6y ago

Sometimes ideologies actually point in the right direction. The hard part is to recognize the gems amid the firehose of truly bad ones. FWIW, I think the memory safety-first ideology of Rust is worth spreading.

bjourne 6y ago
Agreed. Which is why I prefer garbage collected languages. Rustaceans, however, harbor an irrational fear of garbage collection pauses, hence "memory safety-first ideology" built on garbage collection is heresy. The one true path to memory safety nirvana is through the holy borrows checker. :)
- mlindner 5y ago
  Well the set of all programs where garbage collectors can be used is smaller than the set of all programs where manual memory management can be used (either done by the compiler or manually by the programmer). This doesn't counter your point completely, but it bears thinking about.
- saemei 5y ago
  Rust' memory safety feature includes "fearless concurrency". Popular GC languages like Java or Go are not able to prevent a class of data race bugs that Rust prevents at compile time. Languages like Haskell of course handle it much better, but are for a multitude of reasons not popularly used in production. And as the sibling comment points out, GC languages are not applicable everywhere. This discussion is in the context of the first not-C language being added to the Linux kernel. Can you imagine a GC language being similarly considered? So yes, the borrow checker is amazing. That feeling of satisfaction and confidence when the program finally compiles after a round of serious coding or refactoring is unparalleled among the mainstream languages I've tried so far.
  - bjourne 5y ago
    > Rust' memory safety feature includes "fearless concurrency". Can you give me an example?