4 ms·

This is not true. Nor is the post you're replying to, for what it's worth. Rust and C++ are roughly equally expressive for high-performance, high-scale softwar

This is not true. Nor is the post you're replying to, for what it's worth. Rust and C++ are roughly equally expressive for high-performance, high-scale software. The reasons to use one or the other for new code have little to do with whether each language can do the job; clearly, both languages can. Rather, what dominates are factors like whether your build/deployment system is set up to handle one language or another, what your engineers are experienced in, whether you care about memory safety, etc. Source: I'm one of the maintainers of Rust at a large organization you have heard of that very much cares about high-performance, high-scale systems software.

zozbot234 4y ago
> clearly, both languages can. C++ is not memory safe, which is table stakes these days for any truly "high scale" software. Which is why most large-scale software projects have been written in Java, a memory-safe language, since the late 1990s (taking over from the previously common use of C++). And no, even the C++ Core Guidelines and "modern" coding style do not fully address this issue; they're way too clunky, whether or not legacy code is involved. Rust, even more so than Java in the mid-1990s, is uniquely positioned in offering better performance and safety than C++ and a lower complexity in development.
- pjmlp 4y ago
  All big GPU and HPC related companies have ISO C++ people on their payroll, so I doubt they will care to add something else. And NVidia rather uses Ada/SPARK instead of Rust for high integrity computing. In regards to Java, while I do agree, there is still enough JNI being used there, hence why Project Panama, to improve such workflows where C++ is part of the story.
worik 4y ago
True. But. The learning curve of Rust should not be underestimated, IMHO. I do not know except by my own experience and "gossip", and would be interested in hearing from a bigger shop that has to deal with it. Rust can make an experienced developer feel utterly clueless. The borrow checker is a very harsh mistress. Moving from C++ to Rust for a computer programmer with many years of experience in C++ must be a frustrating and humbling experience. The simplest things become so hard. I love Rust, but I do not use it professionally (I would love to). I can clearly see that it is a step closer to what we have been waiting for, it may even be the destination. But I can imagine the pain of moving a programmer from 20 years of C++ into Rust. Becoming a novice again
- zozbot234 4y ago
  > The learning curve of Rust should not be underestimated, IMHO. Not sure how this is relevant in a conversation about C++, for which the notion of a learning curve is even hard to apply given that practically no one manages to write code that can be trusted to be free of basic defects in the language. > Rust can make an experienced developer feel utterly clueless. The borrow checker is a very harsh mistress. And rightly so. Rust is only unique in that you get the hangover before deploying the code in production. It's puzzling that some might see this as a drawback of the language.
  - worik 4y ago
    I am commenting on the difficulties faced moving a computer programmer from C++ to Rust. Any conversation about C++ has to consider the costs of abandoning the ship
  - pjmlp 4y ago
    Sky vs Snowboard, basically. Sky day one is very easy, yet it takes years to master. Snowboard day one is going to be mostly about falling, unless you want into xgames, it is much easier to master afterwards. It depends on which experience one wants to have.
- jltsiren 4y ago
  When I started learning Rust after ~25 years of C++, I was quite productive after a couple of months. If C++ teaches you something, it's that you can be productive with a language without being fully familiar with it. After all, 25 years doesn't seem to be enough for learning C++. The borrow checker is not such a big deal. You should have learned the basics in undergraduate CS in the context of concurrency and/or databases. If you have done shared data parallelism in modern C++ (let's say with OpenMP), you are probably used to similar reasoning. Borrow checking and lifetimes do make some design patterns difficult to use, which is a reason you should not use such patterns in Rust. But there are almost always ways of achieving the same goals with idiomatic Rust. It's a bit like having to unlearn gotos when transitioning from BASIC to more serious languages and their fancy "structured programming".
nyanpasu64 4y ago
Increasingly feeling that Rust is like Elm: a language with novel ideas, teaching valuable lessons (a vocabulary for teaching and checking thread safety, documenting exclusive vs. shared mutability in the type system, arguably a vocabulary for teaching and checking memory safety, though that comes at a steep cost), yet so stubborn the community treats its values (avoiding shared mutability) as moral judgments of code, and the language and deliberately obstructs writing code outside of approved patterns (single ownership tree, exclusive mutability). struct{Cell...}& doesn't need to be harder to use than C++ struct{T...}*, but Rust keeps it difficult because the community views it as bad code design and wants to keep it hard. And *mut T lacks RAII unlike C++'s unique_ptr, and requires unsafe blocks in every dereference. As a result, people turn to unsound patterns like https://github.com/kimundi/owning-ref-rs https://github.com/kimundi/owning-ref-rs, https://github.com/mcoblenz/Bronze/ https://github.com/mcoblenz/Bronze/, and https://github.com/emu-rs/snes-apu/blob/master/src/smp.rs#L53 https://github.com/emu-rs/snes-apu/blob/master/src/smp.rs#L5... (and https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a42462 https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a... raises questions about what exactly is sound or will be redefined as sound). It's a good language to learn. I hesitate to consider it a replacement for asm/C/C++. Writing rust is hoping that the code you're porting to rust can adapt well to the restrictions, and if not, searching for esoteric and needlessly unsafe/verbose workarounds.

zozbot234 4y ago

> clearly, both languages can. C++ is not memory safe, which is table stakes these days for any truly "high scale" software. Which is why most large-scale software projects have been written in Java, a memory-safe language, since the late 1990s (taking over from the previously common use of C++). And no, even the C++ Core Guidelines and "modern" coding style do not fully address this issue; they're way too clunky, whether or not legacy code is involved. Rust, even more so than Java in the mid-1990s, is uniquely positioned in offering better performance and safety than C++ and a lower complexity in development.

pjmlp 4y ago
All big GPU and HPC related companies have ISO C++ people on their payroll, so I doubt they will care to add something else. And NVidia rather uses Ada/SPARK instead of Rust for high integrity computing. In regards to Java, while I do agree, there is still enough JNI being used there, hence why Project Panama, to improve such workflows where C++ is part of the story.

worik 4y ago

True. But. The learning curve of Rust should not be underestimated, IMHO. I do not know except by my own experience and "gossip", and would be interested in hearing from a bigger shop that has to deal with it. Rust can make an experienced developer feel utterly clueless. The borrow checker is a very harsh mistress. Moving from C++ to Rust for a computer programmer with many years of experience in C++ must be a frustrating and humbling experience. The simplest things become so hard. I love Rust, but I do not use it professionally (I would love to). I can clearly see that it is a step closer to what we have been waiting for, it may even be the destination. But I can imagine the pain of moving a programmer from 20 years of C++ into Rust. Becoming a novice again

zozbot234 4y ago
> The learning curve of Rust should not be underestimated, IMHO. Not sure how this is relevant in a conversation about C++, for which the notion of a learning curve is even hard to apply given that practically no one manages to write code that can be trusted to be free of basic defects in the language. > Rust can make an experienced developer feel utterly clueless. The borrow checker is a very harsh mistress. And rightly so. Rust is only unique in that you get the hangover before deploying the code in production. It's puzzling that some might see this as a drawback of the language.
- worik 4y ago
  I am commenting on the difficulties faced moving a computer programmer from C++ to Rust. Any conversation about C++ has to consider the costs of abandoning the ship
- pjmlp 4y ago
  Sky vs Snowboard, basically. Sky day one is very easy, yet it takes years to master. Snowboard day one is going to be mostly about falling, unless you want into xgames, it is much easier to master afterwards. It depends on which experience one wants to have.
jltsiren 4y ago
When I started learning Rust after ~25 years of C++, I was quite productive after a couple of months. If C++ teaches you something, it's that you can be productive with a language without being fully familiar with it. After all, 25 years doesn't seem to be enough for learning C++. The borrow checker is not such a big deal. You should have learned the basics in undergraduate CS in the context of concurrency and/or databases. If you have done shared data parallelism in modern C++ (let's say with OpenMP), you are probably used to similar reasoning. Borrow checking and lifetimes do make some design patterns difficult to use, which is a reason you should not use such patterns in Rust. But there are almost always ways of achieving the same goals with idiomatic Rust. It's a bit like having to unlearn gotos when transitioning from BASIC to more serious languages and their fancy "structured programming".

nyanpasu64 4y ago

Increasingly feeling that Rust is like Elm: a language with novel ideas, teaching valuable lessons (a vocabulary for teaching and checking thread safety, documenting exclusive vs. shared mutability in the type system, arguably a vocabulary for teaching and checking memory safety, though that comes at a steep cost), yet so stubborn the community treats its values (avoiding shared mutability) as moral judgments of code, and the language and deliberately obstructs writing code outside of approved patterns (single ownership tree, exclusive mutability). struct{Cell...}& doesn't need to be harder to use than C++ struct{T...}*, but Rust keeps it difficult because the community views it as bad code design and wants to keep it hard. And *mut T lacks RAII unlike C++'s unique_ptr, and requires unsafe blocks in every dereference. As a result, people turn to unsound patterns like https://github.com/kimundi/owning-ref-rs https://github.com/kimundi/owning-ref-rs, https://github.com/mcoblenz/Bronze/ https://github.com/mcoblenz/Bronze/, and https://github.com/emu-rs/snes-apu/blob/master/src/smp.rs#L53 https://github.com/emu-rs/snes-apu/blob/master/src/smp.rs#L5... (and https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a42462 https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a... raises questions about what exactly is sound or will be redefined as sound). It's a good language to learn. I hesitate to consider it a replacement for asm/C/C++. Writing rust is hoping that the code you're porting to rust can adapt well to the restrictions, and if not, searching for esoteric and needlessly unsafe/verbose workarounds.