5 ms·

Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now. A

Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now. And no, I don't trust the Rust propaganda machine. When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser. And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.

sgift 6y ago
> Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now. How exactly is having one compiler defining what is okay and what is not worse than "what we have now"? The multiple implementations of C++ are all incompatible with each other in various subtle ways, produce code which works differently and at the end of the day everyone just takes one and says "we write C++ which works with <compiler>" and that's it. > When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser. Why exactly is it a problem that the core team of a language is interested in the language? Or do you want to imply that the rust devs working on Firefox weren't interested in it? All the progress Firefox made in the last few years tells a very different story (yes, not all of it is due to rust, but a relevant part is). > And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust. If you haven't read any critical postmortem about Rusts difficulties in these spaces you haven't looked around very much. This is an impression I generally get from your post. You don't like Rust (for some reason, it's not very clear what it is) and seem to have an axe to grind with it. Which is .. okay? No one forces you to like a language, but doesn't make for a very interesting conversation.
- blub 6y ago
  Rust is a pragmatic project. They chose a compiler which is performant and widely available and bet everything on it to keep things straightforward. It looks like it's served them well. This compiler is on the other hand naturally not available on all platforms and is not appropriate for all contexts. Alternate implementations could have filled these gaps, but they're not there. The fact that the compiler defines the language and vice-versa enables additional flexibility in changing the language/compiler and development speed at the cost of instability. Different projects may tolerate different amounts of instability and for those that are more conservative Rust may not be an appropriate investment. With C++ one can code for a specific compiler or in a standard way. One can pick C++98 or 17 or anything in between. All of these are supported options and they give C++ its massive breadth and offer the most flexibility to teams. There's obviously disadvantages associated with all that, but claiming that diversity is a weakness is not generally true.
  - hobofan 6y ago
    I'm assuming you mean LLVM by "compiler". If platform support of Rust is your concern here due to limited platform support of LLVM, then that might be going away. Based on the fact that Cranelift recently landed as a non-LLVM codegen backend in nightly, I assume that work is already pretty far on supporting alternative backends that could support alternative platforms.
    - blub 6y ago
      Correct, I was not precise. Actually LLVM is not a problem for me personally, as the platforms I'm using right now are mainstream. I was merely trying to explain why some wouldn't be content just with LLVM.
  - karavelov 6y ago
    Similarly you can compile Rust in "edition = 2015" or "edition = 2018" and soon "edition = 2021" to guard against changes in the language, e.g. adding keywords. There are already alternative compilers, though most of them are WIP, e.g. mrustc[1], rust front-end for gcc[2][3], or using cranelift[4] for the back-end. [1] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc [2] https://github.com/sapir/gcc-rust/tree/rust https://github.com/sapir/gcc-rust/tree/rust [3] https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs [4] https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift
sischoel 6y ago
Why would you say Rust is bad for kernels and drivers? Asking this because I am curious, not as an argument.
- rcxdude 6y ago
  I would also be interested if there's any specific reasoning there, especially because there's an effort to get rust supported as way of writing kernel modules in linux, a pretty dogmatically C (though not standard C) codebase. I am personally very exciting for rust's potential in low-level embedded applications.
  - steveklabnik 6y ago
    My day job is doing embedded rust, with kernels and drivers. It works great.
oblio 6y ago
> Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now. This is a double standard. C was created in 1972 and standardized in 1989. A major C compiler (MSVC) doesn't even fully implement C99 from 21 years ago. C++ itself was created in 1985 and standardised in 1998. Yet it was adopted. Yes, things have changed and the bar has been raised. But people don't seem to have followed your reasoning even for C and C++. > Apart from kernels and drivers (where Rust seems an outright no-go) Why? From what I've read Rust can actually help with managing hardware resources through its semantics. What blocks it from being used?
- blub 6y ago
  Having an international standard behind a language gives it a certain weight that can't even be compared to the ad-hoc structures that are seen in other projects. It enables experts in different areas from different countries to come and work together under a set of specific rules that are much stronger that words written in wikis or repos. It also makes it clear that the language is designed for the long term and is not under the control of a single party (as was the concern about e.g. Mozilla which the Rust community tried so hard to dispel). It avoids embarrassing transitions like Python's 2->3 or one corporation taking control of a language like Oracle did with Java by simply buying it. It avoids having to watch a language go extinct because its corporate sponsor wishes it so (Objective-C, VB 6) and many other such unpleasantness. This is partly why this AWS focus is strange to say the least. I would have thought that it's obvious for the Rust community that having one large sponsor is not healthy. This tells me that Rust was never really as independent from Mozilla as claimed and Mozilla refocusing away from it seriously hurt the language.
  - oblio 6y ago
    Yet Python and Java have been around for 30+/25+ years and are some of the most popular languages around. Not many people care about standardization, it seems.
    - tannhaeuser 6y ago
flohofwoe 6y ago
C only became standardized after 20 years or so, and only out of necessity because there were different compiler toolchains moving into different directions and this ensuing chaos had to be brought under control somehow. And arguagbly the standard is just as much a problem as an advantage (look at all the very useful extensions in clang and gcc which will never make it into the standard, and the C standard libary is still essentially a snapshot of what was already the least common denominator in 1989, and far from the "state of the art" even back then). As long as a language only has a single implementation or "reference compiler" (like Rust), standardization only adds needless bureaucratic overhead.
- rualca 6y ago
  > C only became standardized after 20 years or so, and only out of necessity because there were different compiler toolchains moving into different directions and this ensuing chaos had to be brought under control somehow. The "after 20 years" remark is totally irrelevant because just because the C community was extremely slow it doesn't mean everyone is supposed to repeat the same mistakes. The only relevant point in your remark is that a standard is required when there are at least two implementations that need to interoperate. That's the only relevant point. A standard is the only way to ensure that interop is possible, and that implementations are reliable.
  - flohofwoe 6y ago
    It takes a couple of decades before a language has stabilized enough and gets popular enough to spawn multiple competing compiler toolchains. And before all that hasn't happened a standard makes no sense.
steveklabnik 6y ago
> My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser. It is true that the folks working on Rust are focused on "advancing the language," yes. I don't see why it would be any other way? > Apart from kernels and drivers (where Rust seems an outright no-go), Rust works great in these scenarios. We'll see about some higher profile examples, like Linux. Work there is ongoing. Only one way to find out. > C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. There are a ton of projects in this space. After all, the Rust compiler, for example, is one of the two OG massive Rust codebases. But there's also tons and tons of projects here. > Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust. Sort of, but also not really. Implementing a DOM would be easier if Rust had inheritance, is usually what is claimed. Yet, Servo was still built, and nobody would suggest that the DOM was a hard blocker here.
- tannhaeuser 6y ago
  > It is true that the folks working on Rust are focused on "advancing the language," yes. I don't see why it would be any other way? That wasn't the argument. What's problematic is that Rust developers are focused on their language above anything else, to the detriment of the primary product they're developing. When the product - a web browser to stand against Chrome - is much more important than yet another programming language. It's about obsessing on your tools and being in love with a programming language; I call it "thinking with your fingers".
  - steveklabnik 6y ago
    > to the detriment of the primary product they're developing I guess this is the core of it. It is hard for me to understand why you'd think people working on a language would have "the primary product" be something other than the language. There isn't even a single coherent other project to be associated with. Why would "a browser" be special here? It’s even in the name: the Rust developers. We develop Rust. Do you fault the C standards body for working on C? Or the Ruby core team for working on Ruby? What language do the developers of the language consider something other than the language as their primary product? Now, of course, as a tool maker, you have to make sure the tool is fit for purpose. You want to enable the people who are working on projects like a browser to be able to do their job. But that's their job, not our job. It seems like you're suggesting that the primary job of Rust developers is to improve Firefox, and it's very confusing to me why you'd say that, when nobody would say that about any other language. Or at least, I've never come across that sentiment before.

sgift 6y ago

> Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now. How exactly is having one compiler defining what is okay and what is not worse than "what we have now"? The multiple implementations of C++ are all incompatible with each other in various subtle ways, produce code which works differently and at the end of the day everyone just takes one and says "we write C++ which works with <compiler>" and that's it. > When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser. Why exactly is it a problem that the core team of a language is interested in the language? Or do you want to imply that the rust devs working on Firefox weren't interested in it? All the progress Firefox made in the last few years tells a very different story (yes, not all of it is due to rust, but a relevant part is). > And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust. If you haven't read any critical postmortem about Rusts difficulties in these spaces you haven't looked around very much. This is an impression I generally get from your post. You don't like Rust (for some reason, it's not very clear what it is) and seem to have an axe to grind with it. Which is .. okay? No one forces you to like a language, but doesn't make for a very interesting conversation.

blub 6y ago
Rust is a pragmatic project. They chose a compiler which is performant and widely available and bet everything on it to keep things straightforward. It looks like it's served them well. This compiler is on the other hand naturally not available on all platforms and is not appropriate for all contexts. Alternate implementations could have filled these gaps, but they're not there. The fact that the compiler defines the language and vice-versa enables additional flexibility in changing the language/compiler and development speed at the cost of instability. Different projects may tolerate different amounts of instability and for those that are more conservative Rust may not be an appropriate investment. With C++ one can code for a specific compiler or in a standard way. One can pick C++98 or 17 or anything in between. All of these are supported options and they give C++ its massive breadth and offer the most flexibility to teams. There's obviously disadvantages associated with all that, but claiming that diversity is a weakness is not generally true.
- hobofan 6y ago
  I'm assuming you mean LLVM by "compiler". If platform support of Rust is your concern here due to limited platform support of LLVM, then that might be going away. Based on the fact that Cranelift recently landed as a non-LLVM codegen backend in nightly, I assume that work is already pretty far on supporting alternative backends that could support alternative platforms.
  - blub 6y ago
    Correct, I was not precise. Actually LLVM is not a problem for me personally, as the platforms I'm using right now are mainstream. I was merely trying to explain why some wouldn't be content just with LLVM.
- karavelov 6y ago
  Similarly you can compile Rust in "edition = 2015" or "edition = 2018" and soon "edition = 2021" to guard against changes in the language, e.g. adding keywords. There are already alternative compilers, though most of them are WIP, e.g. mrustc[1], rust front-end for gcc[2][3], or using cranelift[4] for the back-end. [1] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc [2] https://github.com/sapir/gcc-rust/tree/rust https://github.com/sapir/gcc-rust/tree/rust [3] https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs [4] https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift

sischoel 6y ago

Why would you say Rust is bad for kernels and drivers? Asking this because I am curious, not as an argument.

rcxdude 6y ago
I would also be interested if there's any specific reasoning there, especially because there's an effort to get rust supported as way of writing kernel modules in linux, a pretty dogmatically C (though not standard C) codebase. I am personally very exciting for rust's potential in low-level embedded applications.
- steveklabnik 6y ago
  My day job is doing embedded rust, with kernels and drivers. It works great.

oblio 6y ago

> Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now. This is a double standard. C was created in 1972 and standardized in 1989. A major C compiler (MSVC) doesn't even fully implement C99 from 21 years ago. C++ itself was created in 1985 and standardised in 1998. Yet it was adopted. Yes, things have changed and the bar has been raised. But people don't seem to have followed your reasoning even for C and C++. > Apart from kernels and drivers (where Rust seems an outright no-go) Why? From what I've read Rust can actually help with managing hardware resources through its semantics. What blocks it from being used?

blub 6y ago
Having an international standard behind a language gives it a certain weight that can't even be compared to the ad-hoc structures that are seen in other projects. It enables experts in different areas from different countries to come and work together under a set of specific rules that are much stronger that words written in wikis or repos. It also makes it clear that the language is designed for the long term and is not under the control of a single party (as was the concern about e.g. Mozilla which the Rust community tried so hard to dispel). It avoids embarrassing transitions like Python's 2->3 or one corporation taking control of a language like Oracle did with Java by simply buying it. It avoids having to watch a language go extinct because its corporate sponsor wishes it so (Objective-C, VB 6) and many other such unpleasantness. This is partly why this AWS focus is strange to say the least. I would have thought that it's obvious for the Rust community that having one large sponsor is not healthy. This tells me that Rust was never really as independent from Mozilla as claimed and Mozilla refocusing away from it seriously hurt the language.
- oblio 6y ago
  Yet Python and Java have been around for 30+/25+ years and are some of the most popular languages around. Not many people care about standardization, it seems.
  - tannhaeuser 6y ago

flohofwoe 6y ago

C only became standardized after 20 years or so, and only out of necessity because there were different compiler toolchains moving into different directions and this ensuing chaos had to be brought under control somehow. And arguagbly the standard is just as much a problem as an advantage (look at all the very useful extensions in clang and gcc which will never make it into the standard, and the C standard libary is still essentially a snapshot of what was already the least common denominator in 1989, and far from the "state of the art" even back then). As long as a language only has a single implementation or "reference compiler" (like Rust), standardization only adds needless bureaucratic overhead.

rualca 6y ago
> C only became standardized after 20 years or so, and only out of necessity because there were different compiler toolchains moving into different directions and this ensuing chaos had to be brought under control somehow. The "after 20 years" remark is totally irrelevant because just because the C community was extremely slow it doesn't mean everyone is supposed to repeat the same mistakes. The only relevant point in your remark is that a standard is required when there are at least two implementations that need to interoperate. That's the only relevant point. A standard is the only way to ensure that interop is possible, and that implementations are reliable.
- flohofwoe 6y ago
  It takes a couple of decades before a language has stabilized enough and gets popular enough to spawn multiple competing compiler toolchains. And before all that hasn't happened a standard makes no sense.

steveklabnik 6y ago

> My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser. It is true that the folks working on Rust are focused on "advancing the language," yes. I don't see why it would be any other way? > Apart from kernels and drivers (where Rust seems an outright no-go), Rust works great in these scenarios. We'll see about some higher profile examples, like Linux. Work there is ongoing. Only one way to find out. > C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. There are a ton of projects in this space. After all, the Rust compiler, for example, is one of the two OG massive Rust codebases. But there's also tons and tons of projects here. > Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust. Sort of, but also not really. Implementing a DOM would be easier if Rust had inheritance, is usually what is claimed. Yet, Servo was still built, and nobody would suggest that the DOM was a hard blocker here.

tannhaeuser 6y ago
> It is true that the folks working on Rust are focused on "advancing the language," yes. I don't see why it would be any other way? That wasn't the argument. What's problematic is that Rust developers are focused on their language above anything else, to the detriment of the primary product they're developing. When the product - a web browser to stand against Chrome - is much more important than yet another programming language. It's about obsessing on your tools and being in love with a programming language; I call it "thinking with your fingers".
- steveklabnik 6y ago
  > to the detriment of the primary product they're developing I guess this is the core of it. It is hard for me to understand why you'd think people working on a language would have "the primary product" be something other than the language. There isn't even a single coherent other project to be associated with. Why would "a browser" be special here? It’s even in the name: the Rust developers. We develop Rust. Do you fault the C standards body for working on C? Or the Ruby core team for working on Ruby? What language do the developers of the language consider something other than the language as their primary product? Now, of course, as a tool maker, you have to make sure the tool is fit for purpose. You want to enable the people who are working on projects like a browser to be able to do their job. But that's their job, not our job. It seems like you're suggesting that the primary job of Rust developers is to improve Firefox, and it's very confusing to me why you'd say that, when nobody would say that about any other language. Or at least, I've never come across that sentiment before.