5 ms·

> Rust is as complex as C++: ...no, it's not. Maybe not yet, but it is heading in that direction; and I only say this because of the absolutely giant pile of f

> Rust is as complex as C++: ...no, it's not. Maybe not yet, but it is heading in that direction; and I only say this because of the absolutely giant pile of features in unstable that seem to be stuck there, but I hope will eventually make its way to stable at some point. > Async Rust really is fine I dunno. Always thought it was too complicated, but as another person pointed out avoiding Tokyo::spawn solves many issues (you said this too, I think). So maybe, not Rust's fault :D

CryZe 2y ago
> Maybe not yet, but it is heading in that direction About 95% of the unstable features lift limitations that most people expect not to be there in the first place. I'm not aware of all too many that aren't like that.
Diggsey 2y ago
> Maybe not yet, but it is heading in that direction; It's definitely getting more complex, but C++ has a huge lead haha. C++ is like a fractal in that you can look at almost any feature closer and closer to reveal more and more complexity, and there are a lot of features... Here's a page on just one dark corner of the language: https://isocpp.org/wiki/faq/pointers-to-members https://isocpp.org/wiki/faq/pointers-to-members and it interacts in interesting ways with all the other corners (like virtual vs non-virtual inheritance) in fun and exciting ways... Also, there are far more ways to cause UB in C++. Rust has a big lead on formalizing what constitutes UB, and even those rules you only need to learn if you are using "unsafe", whilst in C++ you don't have that luxury.
- tialaramex 2y ago
  > Also, there are far more ways to cause UB in C++. As well as lots of Undefined Behaviour, C++ also has what its own experts call "False positives for the question is this a C++ program" the Ill-Formed No Diagnostic Required features, nothing like these exist in Rust, they're cases where you can write what appears to be C++ but actually although there are is no error or warning from the compiler your entire program has no meaning and might do absolutely anything from the outset. I've seen guesses that most or even all non-trivial C++ invokes IFNDR. So that's categorically worse than Undefined Behaviour. Finally, C++ has cases where the standard just chooses not to explain how something works because doing so would mean actually deciding and that's controversial so in fact all C++ where this matters also has no defined meaning and no way for you to discover what happens except to read the machine code emitted by your compiler, which entirely misses the point of a high level programming language. One of the things happening in Rust's stabilization process is solving those tough issues, for example Aria's "Strict Provenance experiment" is likely being stabilized, formally granting Rust a pointer provenance model, something C++ does not have and C23 had to fork into a separate technical document to study.
  - googh 2y ago
    Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I wonder what you are trying to achieve by this, but I assure you that this does not do Rust any favor other than giving the impression that the Rust community is obnoxious.
    - tialaramex 2y ago
      > Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I haven't measured but it's easy to say categorically that it's not "all" unless somehow my posts about network protocols, aeroplanes, security and psychology among others fall into this vague category. And yes, like Ignaz Semmelweis I can see an obvious improvement to how my profession does what it does and it's infuriating that the response from many other practitioners is "No, I don't like change, therefore you're crazy for explaining why I should change" Ignaz Semmelweis died in an asylum. But on the other hand while Ignaz was correct and his proposals would have worked he couldn't explain why because germ theory was only confirmed after he died. Rust isn't in that situation, we know already exactly what the problems are with C++. So that means I can tell you not just that using C++ is a bad idea, but why it's a bad idea.
      - googh 2y ago
        Most HN users already use languages with GC which are more memory safe than Rust. People still use C++ either because they are maintaining existing code, or they work in domains where memory safety is not really necessary (games, HFT, ML). Apart from these, C++ is rarely used in the real world. > practitioners is "No, I don't like change, therefore you're crazy for explaining why I should change" Who exactly are you referring to here? Your co-workers? LLVM maintainers? or the Linux kernel developers? Please be more precise.
        hyperbrainer 2y ago
        What is "more memory-safe than rust" supposed to mean? Rust is completely memory-safe.
faitswulff 2y ago
> Maybe not yet, but it is heading in that direction When people say that Rust is complex, they often neglect to differentiate between implementation complexity and developer facing complexity. The implementation complexity is growing in part to support the end user simplicity. I also don't understand why anyone feels the need to know every feature of the language. You can just learn about and use the features that you need.
- jiggawatts 2y ago
  That only works if you sit in isolation on a mountain and start with no_std and write everything else from scratch, yourself. The majority exist in a community and have to collaborate with others. They have to deal with the code written by others, code which may use any language feature. Every developer doing serious work will trip over every available language feature eventually.
  - faitswulff 2y ago
    > Every developer doing serious work will trip over every available language feature eventually. Steve Klabnik: “Just to provide another perspective: if you can write the programs you want to write, then all is good. You don't have to use every single tool in the standard library. I co-authored the Rust book. I have twelve years experience writing Rust code, and just over thirty years of experience writing software. I have written a macro_rules macro exactly one time, and that was 95% taking someone else's macro and modifying it. I have written one proc macro. I have used Box::leak once. I have never used Arc::downgrade. I've used Cow a handful of times. Don't stress yourself out. You're doing fine.“ https://www.reddit.com/r/rust/comments/1fofg43/i_am_struggling_with_rust_because_i_cant_see_when/lopwnyd/ https://www.reddit.com/r/rust/comments/1fofg43/i_am_struggli...
dartos 2y ago
> Maybe not yet, but it is heading in that direction I have little doubt that Rust will end up being as complicated as C++ eventually, but a big difference is how explicit and well documented the discusson of new features are. The Rust RFCs provide a ton of context to almost every feature of the lagnuage. I find that historical context extremely helpful when trying to figure out why something is the way that it is. There may be something like that for C++, but I feel like a lot of it is "you had to be there" kind of reasons.
- pjmlp 2y ago
  ISO Rationales and papers.
  - dartos 2y ago
    Yeah I’m sure they exist, but googling “C++ ISO Rationales” doesn’t give me them. Searching for “Rust RFCs” reveals a git repo with thousands of markdown files describing features and their motivations with links to discussions.
    - pjmlp 2y ago
      Because ISO processes are only open to those in the know. Same applies to Ada, C, Modula-2, Pascal, Fortran, Algol, Cobol,.....
      - dartos 2y ago
        That's... what I originally said... "in the know" and "you had to be there" are effectively the same statment It's is exactly why I feel more comfortable with complexity creep in Rust as opposed to C++, since I can easily find and read the rationale for just about every feature.
        pjmlp 2y ago
        No they aren't, those "in the know" have access to ISO servers, mailing lists, meeting minutes, paper votes, and related content. Some of the public C++ stuff: https://www.open-std.org/jtc1/sc22/wg21 https://www.open-std.org/jtc1/sc22/wg21 Some of the public C stuff: https://www.open-std.org/jtc1/sc22/wg14/ https://www.open-std.org/jtc1/sc22/wg14/ Some of the public Ada stuff: https://www.open-std.org/JTC1/SC22/WG9/ https://www.open-std.org/JTC1/SC22/WG9/ And so on. Those "in the know" have access to the stuff that is beyond that. However that is already plenty of stuff publicly available at those https://www.open-std.org https://www.open-std.org subsites as well.

CryZe 2y ago

> Maybe not yet, but it is heading in that direction About 95% of the unstable features lift limitations that most people expect not to be there in the first place. I'm not aware of all too many that aren't like that.

Diggsey 2y ago

> Maybe not yet, but it is heading in that direction; It's definitely getting more complex, but C++ has a huge lead haha. C++ is like a fractal in that you can look at almost any feature closer and closer to reveal more and more complexity, and there are a lot of features... Here's a page on just one dark corner of the language: https://isocpp.org/wiki/faq/pointers-to-members https://isocpp.org/wiki/faq/pointers-to-members and it interacts in interesting ways with all the other corners (like virtual vs non-virtual inheritance) in fun and exciting ways... Also, there are far more ways to cause UB in C++. Rust has a big lead on formalizing what constitutes UB, and even those rules you only need to learn if you are using "unsafe", whilst in C++ you don't have that luxury.

tialaramex 2y ago
> Also, there are far more ways to cause UB in C++. As well as lots of Undefined Behaviour, C++ also has what its own experts call "False positives for the question is this a C++ program" the Ill-Formed No Diagnostic Required features, nothing like these exist in Rust, they're cases where you can write what appears to be C++ but actually although there are is no error or warning from the compiler your entire program has no meaning and might do absolutely anything from the outset. I've seen guesses that most or even all non-trivial C++ invokes IFNDR. So that's categorically worse than Undefined Behaviour. Finally, C++ has cases where the standard just chooses not to explain how something works because doing so would mean actually deciding and that's controversial so in fact all C++ where this matters also has no defined meaning and no way for you to discover what happens except to read the machine code emitted by your compiler, which entirely misses the point of a high level programming language. One of the things happening in Rust's stabilization process is solving those tough issues, for example Aria's "Strict Provenance experiment" is likely being stabilized, formally granting Rust a pointer provenance model, something C++ does not have and C23 had to fork into a separate technical document to study.
- googh 2y ago
  Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I wonder what you are trying to achieve by this, but I assure you that this does not do Rust any favor other than giving the impression that the Rust community is obnoxious.
  - tialaramex 2y ago
    > Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I haven't measured but it's easy to say categorically that it's not "all" unless somehow my posts about network protocols, aeroplanes, security and psychology among others fall into this vague category. And yes, like Ignaz Semmelweis I can see an obvious improvement to how my profession does what it does and it's infuriating that the response from many other practitioners is "No, I don't like change, therefore you're crazy for explaining why I should change" Ignaz Semmelweis died in an asylum. But on the other hand while Ignaz was correct and his proposals would have worked he couldn't explain why because germ theory was only confirmed after he died. Rust isn't in that situation, we know already exactly what the problems are with C++. So that means I can tell you not just that using C++ is a bad idea, but why it's a bad idea.
    - googh 2y ago
      Most HN users already use languages with GC which are more memory safe than Rust. People still use C++ either because they are maintaining existing code, or they work in domains where memory safety is not really necessary (games, HFT, ML). Apart from these, C++ is rarely used in the real world. > practitioners is "No, I don't like change, therefore you're crazy for explaining why I should change" Who exactly are you referring to here? Your co-workers? LLVM maintainers? or the Linux kernel developers? Please be more precise.
      - hyperbrainer 2y ago
        What is "more memory-safe than rust" supposed to mean? Rust is completely memory-safe.

faitswulff 2y ago

> Maybe not yet, but it is heading in that direction When people say that Rust is complex, they often neglect to differentiate between implementation complexity and developer facing complexity. The implementation complexity is growing in part to support the end user simplicity. I also don't understand why anyone feels the need to know every feature of the language. You can just learn about and use the features that you need.

jiggawatts 2y ago
That only works if you sit in isolation on a mountain and start with no_std and write everything else from scratch, yourself. The majority exist in a community and have to collaborate with others. They have to deal with the code written by others, code which may use any language feature. Every developer doing serious work will trip over every available language feature eventually.
- faitswulff 2y ago
  > Every developer doing serious work will trip over every available language feature eventually. Steve Klabnik: “Just to provide another perspective: if you can write the programs you want to write, then all is good. You don't have to use every single tool in the standard library. I co-authored the Rust book. I have twelve years experience writing Rust code, and just over thirty years of experience writing software. I have written a macro_rules macro exactly one time, and that was 95% taking someone else's macro and modifying it. I have written one proc macro. I have used Box::leak once. I have never used Arc::downgrade. I've used Cow a handful of times. Don't stress yourself out. You're doing fine.“ https://www.reddit.com/r/rust/comments/1fofg43/i_am_struggling_with_rust_because_i_cant_see_when/lopwnyd/ https://www.reddit.com/r/rust/comments/1fofg43/i_am_struggli...

dartos 2y ago

> Maybe not yet, but it is heading in that direction I have little doubt that Rust will end up being as complicated as C++ eventually, but a big difference is how explicit and well documented the discusson of new features are. The Rust RFCs provide a ton of context to almost every feature of the lagnuage. I find that historical context extremely helpful when trying to figure out why something is the way that it is. There may be something like that for C++, but I feel like a lot of it is "you had to be there" kind of reasons.

pjmlp 2y ago
ISO Rationales and papers.
- dartos 2y ago
  Yeah I’m sure they exist, but googling “C++ ISO Rationales” doesn’t give me them. Searching for “Rust RFCs” reveals a git repo with thousands of markdown files describing features and their motivations with links to discussions.
  - pjmlp 2y ago
    Because ISO processes are only open to those in the know. Same applies to Ada, C, Modula-2, Pascal, Fortran, Algol, Cobol,.....
    - dartos 2y ago
      That's... what I originally said... "in the know" and "you had to be there" are effectively the same statment It's is exactly why I feel more comfortable with complexity creep in Rust as opposed to C++, since I can easily find and read the rationale for just about every feature.
      - pjmlp 2y ago
        No they aren't, those "in the know" have access to ISO servers, mailing lists, meeting minutes, paper votes, and related content. Some of the public C++ stuff: https://www.open-std.org/jtc1/sc22/wg21 https://www.open-std.org/jtc1/sc22/wg21 Some of the public C stuff: https://www.open-std.org/jtc1/sc22/wg14/ https://www.open-std.org/jtc1/sc22/wg14/ Some of the public Ada stuff: https://www.open-std.org/JTC1/SC22/WG9/ https://www.open-std.org/JTC1/SC22/WG9/ And so on. Those "in the know" have access to the stuff that is beyond that. However that is already plenty of stuff publicly available at those https://www.open-std.org https://www.open-std.org subsites as well.