7 ms·

Yes. Rust needs radically more use not to end up fizzling like myriad languages before it. But its stalwarts are hostile to measures to make it easier for peopl

by ncmncm 4y ago

Yes. Rust needs radically more use not to end up fizzling like myriad languages before it. But its stalwarts are hostile to measures to make it easier for people to pick up, even easy ones that do not alter the language at all. (E.g., allowing a debug build to complete despite borrow complaints.) It takes a special dedication to overcome barriers that most of the people it must attract lack. It was meant to supplant C, but C users, as a rule, are defined by seeing a thousand other languages go by and not jumping. So Rust mostly picks up discontents from other languages, including Java, Go, and, yes, C++. The danger in appealing to discontents is that they are likely to jump ship for the next shiny thing.

oncewas 4y ago
I mean I get what you are saying about how old stuff doesn't have adoption issues. But, rust is a pretty unique paradigm. The safety guarantees it offers aren't found in other languages without garbage collectors. Rust is boring and technical. Boring in the "it just works and when it doesn't it's not hard to figure out why" way. You didn't say this, but for others passing by, it would be a mistake to view rust as a "shiny thing". People use it for a reason, barring syntax entirely.
neutronicus 4y ago
The Rust community is, uh, a little in denial about how similar Rust and C++ are (and how much more similar Rust is to C++ than to C)
- oncewas 4y ago
  I've talked with people in the rust community about modern c++ being similar to rust. They all agreed and honestly thought it was cool. Maybe 1 out of 50 rust programmers language bash and are ignorant, those people tend to be junior and are trying to learn. Everyone else is cool. That said rust is pretty different from c++. Most people don't compare rust to c because c is so heinously unsafe and rust being the polar opposite. Ironically, rust was indoctrinated as the second supported language to the Linux kernel, alongside C. So they have that in common... I wouldn't make too many assumptions about the rust community, they are pretty nice smart reasonable people who tend to write c/c++ for work...
- staticassertion 4y ago
  They are? That's weird. Rust and C++ have tons in common and Rust takes tons of inspiration from C++, lots of Rust developers (on the compiler/ early Mozilla adopters) were C++ developers before. C++ still comes up often, like in discussions on constexpr vs const fn. I've also never seen anyone say that Rust is closer to C than C++, that also seems weird.
  - throwaway17_17 4y ago
    The argument that Rust is closer to C than C++ is usually not how it is raised in most discussion around complexity and similarity. Also, to be clear, the discussion is usually centered around ‘a replacement for C’ or ‘why Rust is not a C replacement when compared to <insert-other-language>’. From my massive forum lurking habit, at multiple places, the argument seems to be closer to the following: Person 1 says, “Zig is a viable C replacement, Rust is a C++ replacement.” Person 2 responds, “Rust is absolutely a C replacement, Rust is so much more simple than C++, that they should not be compared. That simplicity, which is much closer to C than C++, is why Rust should be viewed as the ultimate C replacement.” So, it’s not a clear cut statement that Rust is closer to C than C++. However, I certainly have taken that as the argument in most discussions I have seen.
    - ncmncm 4y ago
      Rust is not, in fact, much simpler than C++, and gets less so every release. In five years Rust will be obviously, fully as complex as C++ -- provided it is still used.
      - oncewas 4y ago
        Extremely doubtful on of this claim... Again, really recommend learning the language...
        pjmlp 4y ago
        Try to debug an error related to macro expansions in Serde, or how Pin semantics work in asynchronous code,....
aw1621107 4y ago
> But its stalwarts are hostile to measures to make it easier for people to pick up, even easy ones that do not alter the language at all. (E.g., allowing a debug build to complete despite borrow complaints.) That seems like a rather unusual suggestion to me. Are there commonly used languages/situations where optimization level changes semantics/allowed constructs? The only thing I can think of off the top of my head is stuff that relies on tail calls be optimized in languages that don't guarantee tail call optimizations, but I think that's a relatively niche case compared to debug vs. release builds. I also feel that that suggestion could arguably make the language harder to pick up, since something that worked in debug mode might require extensive refactoring for release mode. Given how much Rust relies on the optimizer to see through its abstractions, that seems problematic. In addition, I suspect (but don't know for sure) that writing code that works correctly in both modes can be tricky - think of something that uses multiple threads, where "release-mode code" can rely on the lack of mutable aliasing but "debug-mode code" cannot. Either you maintain two versions of the code or you write code that doesn't rely on the borrow checker guarantees, which seems like it would defeat the purpose of having the borrow checker in the first place. This is a gut feeling, though, so I wouldn't be surprised if there were a way around this. Finally, I'm not sure I agree with the notion that this change "[does] not alter the language at all." It's like the concept of "allowing a debug build to complete despite [type] complaints" in C++. You're going to have to change the language somehow to define the semantics of ignoring type errors, and I'm not sure how this will help newcomers or how easy such a change would be to implement. Out of curiosity, what other measures did you have in mind? Or can you point me somewhere which discusses similar measures?
- ncmncm 4y ago
  All compilers allow builds that trigger warnings to complete. Obviously code that only runs when built "debug" differs from released code, which ... doesn't run. That is the whole point. Before you ship, you will resolve all the borrow nags, and then there will be a release build, and it will run the same. In the meantime, you probably have more urgent worries to act on first. The only difference is who decides when, you or the compiler. As is, the compiler decides, period. (I confess it utterly mystifies me how this is such a difficult concept for so many. Inability to comprehend something so simple bodes ill for judgment on more weighty matters.)
chris_wot 4y ago
The question is, how do you modularise yourself codebase enough to write chunks of it in Rust and not C++? Take a massive codebase like Libreoffice. How would you even start to migrate this to Rust?
- Kelteseth 4y ago
  Isn't that exactly what Mozilla did with Stylo? https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
- oncewas 4y ago
  In a lot of cases I would consider a staged rewrite. Ie, I would turn what I could into dylibs going either from rust to c++ or c++ to rust. Assuming the code has structure and isn't infinite singletons and free standing functions this can make more or less sense. I'd translate the parts with the most likelihood for memory safety or thread safety issues first, so the transition could be part of the release cycle. It would still be a lot of work, but you might see benefits at intermediate releases this way.

by ncmncm 4y ago

oncewas 4y ago

I mean I get what you are saying about how old stuff doesn't have adoption issues. But, rust is a pretty unique paradigm. The safety guarantees it offers aren't found in other languages without garbage collectors. Rust is boring and technical. Boring in the "it just works and when it doesn't it's not hard to figure out why" way. You didn't say this, but for others passing by, it would be a mistake to view rust as a "shiny thing". People use it for a reason, barring syntax entirely.

neutronicus 4y ago

The Rust community is, uh, a little in denial about how similar Rust and C++ are (and how much more similar Rust is to C++ than to C)

oncewas 4y ago
I've talked with people in the rust community about modern c++ being similar to rust. They all agreed and honestly thought it was cool. Maybe 1 out of 50 rust programmers language bash and are ignorant, those people tend to be junior and are trying to learn. Everyone else is cool. That said rust is pretty different from c++. Most people don't compare rust to c because c is so heinously unsafe and rust being the polar opposite. Ironically, rust was indoctrinated as the second supported language to the Linux kernel, alongside C. So they have that in common... I wouldn't make too many assumptions about the rust community, they are pretty nice smart reasonable people who tend to write c/c++ for work...
staticassertion 4y ago
They are? That's weird. Rust and C++ have tons in common and Rust takes tons of inspiration from C++, lots of Rust developers (on the compiler/ early Mozilla adopters) were C++ developers before. C++ still comes up often, like in discussions on constexpr vs const fn. I've also never seen anyone say that Rust is closer to C than C++, that also seems weird.
- throwaway17_17 4y ago
  The argument that Rust is closer to C than C++ is usually not how it is raised in most discussion around complexity and similarity. Also, to be clear, the discussion is usually centered around ‘a replacement for C’ or ‘why Rust is not a C replacement when compared to <insert-other-language>’. From my massive forum lurking habit, at multiple places, the argument seems to be closer to the following: Person 1 says, “Zig is a viable C replacement, Rust is a C++ replacement.” Person 2 responds, “Rust is absolutely a C replacement, Rust is so much more simple than C++, that they should not be compared. That simplicity, which is much closer to C than C++, is why Rust should be viewed as the ultimate C replacement.” So, it’s not a clear cut statement that Rust is closer to C than C++. However, I certainly have taken that as the argument in most discussions I have seen.
  - ncmncm 4y ago
    Rust is not, in fact, much simpler than C++, and gets less so every release. In five years Rust will be obviously, fully as complex as C++ -- provided it is still used.
    - oncewas 4y ago
      Extremely doubtful on of this claim... Again, really recommend learning the language...
      - pjmlp 4y ago
        Try to debug an error related to macro expansions in Serde, or how Pin semantics work in asynchronous code,....

aw1621107 4y ago

> But its stalwarts are hostile to measures to make it easier for people to pick up, even easy ones that do not alter the language at all. (E.g., allowing a debug build to complete despite borrow complaints.) That seems like a rather unusual suggestion to me. Are there commonly used languages/situations where optimization level changes semantics/allowed constructs? The only thing I can think of off the top of my head is stuff that relies on tail calls be optimized in languages that don't guarantee tail call optimizations, but I think that's a relatively niche case compared to debug vs. release builds. I also feel that that suggestion could arguably make the language harder to pick up, since something that worked in debug mode might require extensive refactoring for release mode. Given how much Rust relies on the optimizer to see through its abstractions, that seems problematic. In addition, I suspect (but don't know for sure) that writing code that works correctly in both modes can be tricky - think of something that uses multiple threads, where "release-mode code" can rely on the lack of mutable aliasing but "debug-mode code" cannot. Either you maintain two versions of the code or you write code that doesn't rely on the borrow checker guarantees, which seems like it would defeat the purpose of having the borrow checker in the first place. This is a gut feeling, though, so I wouldn't be surprised if there were a way around this. Finally, I'm not sure I agree with the notion that this change "[does] not alter the language at all." It's like the concept of "allowing a debug build to complete despite [type] complaints" in C++. You're going to have to change the language somehow to define the semantics of ignoring type errors, and I'm not sure how this will help newcomers or how easy such a change would be to implement. Out of curiosity, what other measures did you have in mind? Or can you point me somewhere which discusses similar measures?

ncmncm 4y ago
All compilers allow builds that trigger warnings to complete. Obviously code that only runs when built "debug" differs from released code, which ... doesn't run. That is the whole point. Before you ship, you will resolve all the borrow nags, and then there will be a release build, and it will run the same. In the meantime, you probably have more urgent worries to act on first. The only difference is who decides when, you or the compiler. As is, the compiler decides, period. (I confess it utterly mystifies me how this is such a difficult concept for so many. Inability to comprehend something so simple bodes ill for judgment on more weighty matters.)

chris_wot 4y ago

The question is, how do you modularise yourself codebase enough to write chunks of it in Rust and not C++? Take a massive codebase like Libreoffice. How would you even start to migrate this to Rust?

Kelteseth 4y ago
Isn't that exactly what Mozilla did with Stylo? https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
oncewas 4y ago
In a lot of cases I would consider a staged rewrite. Ie, I would turn what I could into dylibs going either from rust to c++ or c++ to rust. Assuming the code has structure and isn't infinite singletons and free standing functions this can make more or less sense. I'd translate the parts with the most likelihood for memory safety or thread safety issues first, so the transition could be part of the release cycle. It would still be a lot of work, but you might see benefits at intermediate releases this way.