4 ms·

Is there a reason why some developers prefer Rust over C++? I often hear that it’s because of Cargo, but in my experience, universal build systems and package m

Is there a reason why some developers prefer Rust over C++? I often hear that it’s because of Cargo, but in my experience, universal build systems and package managers end up not really solving the problem they are designed to solve, and are a huge attack vector. Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. C++, on the other hand, has a variety of choices for build systems. CMake is prevalent, you can use simple makefiles just like C, or you could use countless other custom solutions. I’ve found that languages which support a singular build system are really easy to build simple demo apps, but once you need to build something that the default build system doesn’t support, you’re in big trouble.

rational_indian 6y ago
>Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. Maven != Cargo > C++, on the other hand, has a variety of choices for build systems. None of which even remotely approach the ease of use and maintainability of the Cargo build system. > once you need to build something that the default build system doesn’t support, you’re in big trouble. Cargo can build arbitrary dependencies using the build.rs build mechanism.
- pjmlp 6y ago
  > Maven != Cargo Indeeed, Maven supports binary libraries.
pornel 6y ago
Variety of choices for C++ end up causing fragmentation, and all choices are flawed in some way. If you choose Cmake, someone will tell you how much it sucks, and you should have used Meson. You choose Meson, people will complain that it needs Python, or Bazel needs Java, or why bother with any of them if Makefile is good enough, and so on in circles forever. OTOH Cargo is the only option for Rust projects. There's nothing to bikeshed about. Everyone has it and knows how to use it. Apart from that the project is about memory safety. Companies like Google, Microsoft, and Mozilla already have huge C++ codebases, top engineers with lots of C++ experience, spent tons of effort on making it safe, and still weren't happy with the results.
lovasoa 6y ago
I like cargo because I don't like having to even think about build systems. I often renounce to contribute to C/C++ projects because I know I will spend more time figuring out how to install all of their dependencies than making my two-line fix. On the contrary, in the rust ecosystem, I know I can just make my two-line fix, run cargo test, and if there is no red line in the output, I'm done. > I often hear that it’s because of Cargo I don't think the main reason is cargo. The main reason is that you don't have to worry that the very simple pointer dereference you just wrote may allow anyone on the internet to take full control of the machine of anyone that runs your software.
ragnese 6y ago
Cargo is the least of reasons I prefer Rust. Rust APIs are much more ergonomic than C++'s, its type system is better (built-in ADTs and type classes, no null), it's obviously safer by default, it's expression-based which is just sooo ergonomic, its move semantics are enforced by the compiler, and it just doesn't have all the sharp edges of C++ (returning dangling references, implicit constructors, 57 different kinds of lvalue, rvalue, xvalue, lrxhvalue, whatever), etc.
Arch-TK 6y ago
At this point if you stick to a limited subset of C++ and don't go too deep you can get a perfectly safe language which is powerful and performant. If you want a safer language with in my opinion a far better type system than anything Rust could possibly achieve at this point you can use Ada. But why not those two options? Old, smelly and most importantly, difficult to deal with dependencies. You have to actually think about how your API will work in your library because if your library ever ends up used anywhere people are going to be running different versions and you don't want to ruin their day by having them change their code every time they update their machine. In comes cargo (and friends, lots of other languages have picked up the same idea) where everything is managed by the programming language's choice of build system and API stability and dealing with dependency hell no longer exists when you statically link everything. I think people don't care or want to care about why we got to where we are (distributions with dependencies and API stability and an aversion to micro-modules). A lot of people just want things to work when you run one command no matter how much complexity gets hidden under the carpet, how obscure the issues end up being and how windows-esque the debugging process ends up being when things do go wrong. All this pushed by lots of big companies who don't care about the origins of the open source model and how distributions do things and instead only care about lining their own pockets. Mark my words, distributions will disappear in a few year's time, people will cheer this on as some great technological advancement, things like snap will become the de-facto standard and debugging a complex problem will just never happen again. The internet will become filled with forum posts of how people "fixed" a problem by rebooting their machine or deleting a random file or re-installing. Anyway, maybe I'm just a crazy person thinking up crazy scenarios and being irrationally scared of "progress".
- c-cube 6y ago
  Is Ada memory safe in the presence of malloc/free?
  - Arch-TK 6y ago
    Here is a good summary of how Ada deals with safety in the context of memory management: https://news.ycombinator.com/item?id=14216128 https://news.ycombinator.com/item?id=14216128 It's not rust but at the same time I think rust has sacrificed general safety in favor of memory safety which has produced a tendency towards a false sense of security. After all, it seems rust still has memory safety issues despite the borrow checker: https://arxiv.org/pdf/2003.03296.pdf https://arxiv.org/pdf/2003.03296.pdf
rcxdude 6y ago
C++'s build systems are miserable. Almost any other language is preferable (yes, even a complex maven project). CMake and co are just as susceptable to issues when you want to do something off the beaten path, and have a few landmines on the beaten path just to spice it up. Cargo is a breath of fresh air in comparison (and as package managers go it's very good: they took some care to learn from the mistakes of others from the get-go). And rust isn't wedded to cargo: you can build your code using make if you wish. In fact rustc doesn't use cargo.

rational_indian 6y ago

>Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. Maven != Cargo > C++, on the other hand, has a variety of choices for build systems. None of which even remotely approach the ease of use and maintainability of the Cargo build system. > once you need to build something that the default build system doesn’t support, you’re in big trouble. Cargo can build arbitrary dependencies using the build.rs build mechanism.

pjmlp 6y ago
> Maven != Cargo Indeeed, Maven supports binary libraries.

pornel 6y ago

Variety of choices for C++ end up causing fragmentation, and all choices are flawed in some way. If you choose Cmake, someone will tell you how much it sucks, and you should have used Meson. You choose Meson, people will complain that it needs Python, or Bazel needs Java, or why bother with any of them if Makefile is good enough, and so on in circles forever. OTOH Cargo is the only option for Rust projects. There's nothing to bikeshed about. Everyone has it and knows how to use it. Apart from that the project is about memory safety. Companies like Google, Microsoft, and Mozilla already have huge C++ codebases, top engineers with lots of C++ experience, spent tons of effort on making it safe, and still weren't happy with the results.

lovasoa 6y ago

I like cargo because I don't like having to even think about build systems. I often renounce to contribute to C/C++ projects because I know I will spend more time figuring out how to install all of their dependencies than making my two-line fix. On the contrary, in the rust ecosystem, I know I can just make my two-line fix, run cargo test, and if there is no red line in the output, I'm done. > I often hear that it’s because of Cargo I don't think the main reason is cargo. The main reason is that you don't have to worry that the very simple pointer dereference you just wrote may allow anyone on the internet to take full control of the machine of anyone that runs your software.

ragnese 6y ago

Cargo is the least of reasons I prefer Rust. Rust APIs are much more ergonomic than C++'s, its type system is better (built-in ADTs and type classes, no null), it's obviously safer by default, it's expression-based which is just sooo ergonomic, its move semantics are enforced by the compiler, and it just doesn't have all the sharp edges of C++ (returning dangling references, implicit constructors, 57 different kinds of lvalue, rvalue, xvalue, lrxhvalue, whatever), etc.

Arch-TK 6y ago

At this point if you stick to a limited subset of C++ and don't go too deep you can get a perfectly safe language which is powerful and performant. If you want a safer language with in my opinion a far better type system than anything Rust could possibly achieve at this point you can use Ada. But why not those two options? Old, smelly and most importantly, difficult to deal with dependencies. You have to actually think about how your API will work in your library because if your library ever ends up used anywhere people are going to be running different versions and you don't want to ruin their day by having them change their code every time they update their machine. In comes cargo (and friends, lots of other languages have picked up the same idea) where everything is managed by the programming language's choice of build system and API stability and dealing with dependency hell no longer exists when you statically link everything. I think people don't care or want to care about why we got to where we are (distributions with dependencies and API stability and an aversion to micro-modules). A lot of people just want things to work when you run one command no matter how much complexity gets hidden under the carpet, how obscure the issues end up being and how windows-esque the debugging process ends up being when things do go wrong. All this pushed by lots of big companies who don't care about the origins of the open source model and how distributions do things and instead only care about lining their own pockets. Mark my words, distributions will disappear in a few year's time, people will cheer this on as some great technological advancement, things like snap will become the de-facto standard and debugging a complex problem will just never happen again. The internet will become filled with forum posts of how people "fixed" a problem by rebooting their machine or deleting a random file or re-installing. Anyway, maybe I'm just a crazy person thinking up crazy scenarios and being irrationally scared of "progress".

c-cube 6y ago
Is Ada memory safe in the presence of malloc/free?
- Arch-TK 6y ago
  Here is a good summary of how Ada deals with safety in the context of memory management: https://news.ycombinator.com/item?id=14216128 https://news.ycombinator.com/item?id=14216128 It's not rust but at the same time I think rust has sacrificed general safety in favor of memory safety which has produced a tendency towards a false sense of security. After all, it seems rust still has memory safety issues despite the borrow checker: https://arxiv.org/pdf/2003.03296.pdf https://arxiv.org/pdf/2003.03296.pdf

rcxdude 6y ago

C++'s build systems are miserable. Almost any other language is preferable (yes, even a complex maven project). CMake and co are just as susceptable to issues when you want to do something off the beaten path, and have a few landmines on the beaten path just to spice it up. Cargo is a breath of fresh air in comparison (and as package managers go it's very good: they took some care to learn from the mistakes of others from the get-go). And rust isn't wedded to cargo: you can build your code using make if you wish. In fact rustc doesn't use cargo.