4 ms·

The benefit of using Rust is that management of 3d party libraries compared to C++ is a lot easier with cargo, so you can do things quicker. The downside to us

The benefit of using Rust is that management of 3d party libraries compared to C++ is a lot easier with cargo, so you can do things quicker. The downside to using Rust is that its still an evolving language so you may have to refactor your code down the line. Generally Rust use case is targeted towards enterprise software, where you have lots of people working on it, and it needs to be fast, and you want to minimize chances of introducing memory bugs. For personal use, I don't think its honestly worth it tbh, it just slows you down. Personally, I use Python and C exclusively. Its pretty easy to write C extensions to Python to handle the things you need to go fast, and then let Python handle the launching of the code. For example, I was playing around with MCTS, and I would have the tree set up in Python, and then use multiprocessing to split the tree into x processes, and each process would launch C code that did the search a lot faster. Overall the implementation was super easy since I didn't have to write the low level C code for the initial setup, with memory management and so on. There was a recent video about using torch to compile custom CUDA kernels (https://www.youtube.com/watch?v=nOxKexn3iBo https://www.youtube.com/watch?v=nOxKexn3iBo). I have implemented this for some custom data processing that I do that I previously had C code to do on the CPU, and its WAY faster using CUDA.

AlotOfReading 3y ago
I've had to refactor a heck of a lot more C++ than Rust. C++11, std::optional, concepts and ranges, std::format, etc. It's not even that I dislike these changes necessarily, but you're always rewriting C++ to keep up with the language. In rust it's mainly been nightly stuff getting merged to stable, pre-1.0, and async. Much more stable overall.
- staunton 3y ago
  > you're always rewriting C++ to keep up with the language If that's what you want to do, which is a big if. I guess strictly speaking the same is true for Rust but in Rust, with it being new, it "feels" more like I should keep up (at least for me). In c++, I would mostly just not mess with old code that works...
  - AlotOfReading 3y ago
    I'm approaching this from an enterprise perspective of "how confident am I that this code is safe and correct?" If you hand me a pile of c++03 code that happens to compile, my confidence in it meeting both of those criteria is fairly low. If you ask the standards committee or bjarnes, what they're going to tell you is to rewrite it in modern C++, which constantly evolves. Contrast that with rust where it's probably fine if it compiles.
    - staunton 3y ago
      > standards committee or bjarnes, what they're going to tell you is to rewrite it The same will be true for Rust in 50 years (assuming Rust doesn't die any time soon). If they didn't think it was worth modernizing, they'd just leave C++ alone (which I think they should, but that's another matter). For old C++, you run valgrind and a linter on it and if nothing comes up it's also "probably fine". At least it's hard for me to think of a situation where the most productive/profitable-for-buisness thing a developer can be doing is modernizing their old C++.
      - AlotOfReading 3y ago
        Would you bet your life/money/application security on valgrind and a linter being sufficient to catch all of those issues, knowing that a single mistake invalidates every guarantee the standard gives you? That's the situation we're in with C++. When you're building old code, the compiler can't check that it upholds the standard to the degree that it can for modern C++. That's why the advice is to update the code, because the tooling can't save you otherwise. Rust by contrast guarantees that you either have a compiler/runtime bug or the issue is more narrowly localized than "potentially every single line of code". Sure, I'd like better, but it's an improvement.
        staunton 3y ago
        > Would you bet your life Definitely not. But it's rare that so much is at stake. I would not bet my life on the borrow checker either, there's a lot of things that can go wrong in a program. Money is of course a question of how much. Application security is just "the above". The "undefined behavior can explode your PC, travel back in time and become your father" problem is not to be underestimated. However, in cases where old code works well for years but really has some lurking bad UB, one can disable some optimizations and be conservative with compiler choice. A lot of people dislike the trend towards compilers being ever more punishing of UB and I can see their point, while it's of course hard to argue for (let alone find) a balance between performance and some robustness to ubiquitous and almost inevitable code issues. Rust's giarantees are nice and I sure would prefer working on a modern Rust project than any C++ project, as well as a modern C++ project compared to C99-with-classes. Modernizing existing code is a different matter. I've seen very few attempts at modernizing a big and old C++ codebase, no attempts where it clearly paid off and one attempt where it went wrong...

AlotOfReading 3y ago

I've had to refactor a heck of a lot more C++ than Rust. C++11, std::optional, concepts and ranges, std::format, etc. It's not even that I dislike these changes necessarily, but you're always rewriting C++ to keep up with the language. In rust it's mainly been nightly stuff getting merged to stable, pre-1.0, and async. Much more stable overall.

staunton 3y ago
> you're always rewriting C++ to keep up with the language If that's what you want to do, which is a big if. I guess strictly speaking the same is true for Rust but in Rust, with it being new, it "feels" more like I should keep up (at least for me). In c++, I would mostly just not mess with old code that works...
- AlotOfReading 3y ago
  I'm approaching this from an enterprise perspective of "how confident am I that this code is safe and correct?" If you hand me a pile of c++03 code that happens to compile, my confidence in it meeting both of those criteria is fairly low. If you ask the standards committee or bjarnes, what they're going to tell you is to rewrite it in modern C++, which constantly evolves. Contrast that with rust where it's probably fine if it compiles.
  - staunton 3y ago
    > standards committee or bjarnes, what they're going to tell you is to rewrite it The same will be true for Rust in 50 years (assuming Rust doesn't die any time soon). If they didn't think it was worth modernizing, they'd just leave C++ alone (which I think they should, but that's another matter). For old C++, you run valgrind and a linter on it and if nothing comes up it's also "probably fine". At least it's hard for me to think of a situation where the most productive/profitable-for-buisness thing a developer can be doing is modernizing their old C++.
    - AlotOfReading 3y ago
      Would you bet your life/money/application security on valgrind and a linter being sufficient to catch all of those issues, knowing that a single mistake invalidates every guarantee the standard gives you? That's the situation we're in with C++. When you're building old code, the compiler can't check that it upholds the standard to the degree that it can for modern C++. That's why the advice is to update the code, because the tooling can't save you otherwise. Rust by contrast guarantees that you either have a compiler/runtime bug or the issue is more narrowly localized than "potentially every single line of code". Sure, I'd like better, but it's an improvement.
      - staunton 3y ago
        > Would you bet your life Definitely not. But it's rare that so much is at stake. I would not bet my life on the borrow checker either, there's a lot of things that can go wrong in a program. Money is of course a question of how much. Application security is just "the above". The "undefined behavior can explode your PC, travel back in time and become your father" problem is not to be underestimated. However, in cases where old code works well for years but really has some lurking bad UB, one can disable some optimizations and be conservative with compiler choice. A lot of people dislike the trend towards compilers being ever more punishing of UB and I can see their point, while it's of course hard to argue for (let alone find) a balance between performance and some robustness to ubiquitous and almost inevitable code issues. Rust's giarantees are nice and I sure would prefer working on a modern Rust project than any C++ project, as well as a modern C++ project compared to C99-with-classes. Modernizing existing code is a different matter. I've seen very few attempts at modernizing a big and old C++ codebase, no attempts where it clearly paid off and one attempt where it went wrong...