7 ms·

> They're trying to compete with Rust I honestly think it's the other way around.

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.
tialaramex 4y ago
Hmm. From Rust 1.0 in 2015 Rust provides natural for syntax which let you write: for clown in clowns This is pretty different from how C++ iterators work: for (auto clown = clowns.begin(); clown != clowns.end(); ++clown) So, to "try to compete" we'd expect Rust to adopt the C++ features here right? But instead, in C++ 20 now you can write: for (auto clown : clowns) Notice that, as so often, to get here C++ has to add layers of hacks. In Rust clowns is simply any type that implements IntoIterator. That's all, this feature is just syntax sugar and you can implement it yourself calling std::iter::IntoIterator::into_iter(clowns) and then looping over the resulting iterator -- but C++ has not only explicit handling for the range feature here, it also needs two extra special cases to handle the broken C++ built-in array type and the C++ initialiser structures so that these both do what you expect. So, five years later, and with extra hacks, C++ gives you the same feature as Rust, and we are to believe that C++ isn't the one trying to compete?
- atq2119 4y ago
  Range for loops are in C++11, 4 years earlier than Rust 1.0.
  - Rexxar 4y ago
    And c++11 was very late, so it was already a very old idea at this point.
  - tialaramex 4y ago
    Thanks, I had this wrong because I was thinking of the concrete ranges (from C++ 20) instead.
- Kranar 4y ago
  None of what you're saying is true though. Range based for loops were introduced in C++11 (technically C++11 was published in 2011, but almost all compilers supported this way back in 2008-2009) and it's also nothing more than syntactic sugar. In order to provide support for a type T you need the following functions, which can be free functions or member functions: begin(T&) end(T&) ++(decltype(begin(T&))) The only hack I can think of related to your post is that if T is an array, it uses the free functions std::begin and std::end which are overloaded to work with C arrays.
IshKebab 4y ago
Rust is trying to compete from a popularity point of view, but C++ is now trying to compete with Rust from a language point of view. Look at the first comment here: https://news.ycombinator.com/item?id=18037566 https://news.ycombinator.com/item?id=18037566 And there's a pattern matching proposal: https://news.ycombinator.com/item?id=21933590 https://news.ycombinator.com/item?id=21933590 And CJJ23 only just added `string::contains`, `string::starts_with` and so on after Rust had them. Coincidence? I think not! (j/k obvs.)

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.

tialaramex 4y ago

Hmm. From Rust 1.0 in 2015 Rust provides natural for syntax which let you write: for clown in clowns This is pretty different from how C++ iterators work: for (auto clown = clowns.begin(); clown != clowns.end(); ++clown) So, to "try to compete" we'd expect Rust to adopt the C++ features here right? But instead, in C++ 20 now you can write: for (auto clown : clowns) Notice that, as so often, to get here C++ has to add layers of hacks. In Rust clowns is simply any type that implements IntoIterator. That's all, this feature is just syntax sugar and you can implement it yourself calling std::iter::IntoIterator::into_iter(clowns) and then looping over the resulting iterator -- but C++ has not only explicit handling for the range feature here, it also needs two extra special cases to handle the broken C++ built-in array type and the C++ initialiser structures so that these both do what you expect. So, five years later, and with extra hacks, C++ gives you the same feature as Rust, and we are to believe that C++ isn't the one trying to compete?

atq2119 4y ago
Range for loops are in C++11, 4 years earlier than Rust 1.0.
- Rexxar 4y ago
  And c++11 was very late, so it was already a very old idea at this point.
- tialaramex 4y ago
  Thanks, I had this wrong because I was thinking of the concrete ranges (from C++ 20) instead.
Kranar 4y ago
None of what you're saying is true though. Range based for loops were introduced in C++11 (technically C++11 was published in 2011, but almost all compilers supported this way back in 2008-2009) and it's also nothing more than syntactic sugar. In order to provide support for a type T you need the following functions, which can be free functions or member functions: begin(T&) end(T&) ++(decltype(begin(T&))) The only hack I can think of related to your post is that if T is an array, it uses the free functions std::begin and std::end which are overloaded to work with C arrays.

IshKebab 4y ago

Rust is trying to compete from a popularity point of view, but C++ is now trying to compete with Rust from a language point of view. Look at the first comment here: https://news.ycombinator.com/item?id=18037566 https://news.ycombinator.com/item?id=18037566 And there's a pattern matching proposal: https://news.ycombinator.com/item?id=21933590 https://news.ycombinator.com/item?id=21933590 And CJJ23 only just added `string::contains`, `string::starts_with` and so on after Rust had them. Coincidence? I think not! (j/k obvs.)