3 ms·

One thing I like about Rust is that it prevents you from doing stupid things on the compiler level. I write a little bit of C/C++ and Rust. If you don't do C++

by f311a 1y ago

One thing I like about Rust is that it prevents you from doing stupid things on the compiler level. I write a little bit of C/C++ and Rust. If you don't do C++ on a daily basis, you will silently introduce problems in the code that are very hard to spot. You just need to have a very good mental model of how to write good C++. It requires constant exercising. For Rust, you just have to fight the compiler. This is especially useful when you have people on your team with some experience who also want to contribute, but you don't want to constantly point them in the right direction. I actually have no idea how big teams work on large C++ codebases. Usually, you need to have a good idea of how the whole thing works. You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled. Isolated changes are hard. And historically, a lot of C++ codebases lack good test coverage.

cmrdporcupine 1y ago
Honestly after 6 months to a year of constant Rust development you don't even fight with the compiler anymore. Instead it's mostly just your friend. There are still logical holes in the borrow checker, but they're mostly irrelevant.
dataflow 1y ago
> If you don't do C++ on a daily basis, you will silently introduce problems Even if you do, you still will. Just less often. > I actually have no idea how big teams work on large C++ codebases... You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled Part of it is lots of tests, sanitizers, assertions, etc. Part of it is keeping things modular and avoiding spooky action at a distance to the extent possible. Part of it is unavoidable, and that's why people are moving to safer languages.
- unshavedyak 1y ago
  Your post reminds me of the old runtime vs compile time language debates of old (for me). Some would argue duck typing is all that we need, and that lots of tests can cover the missing types/etc. Eventually i realized that i'm just manually implementing compile time typing by way of robust tests to cover interface requirements.
  - sdeframond 1y ago
    > Eventually i realized that i'm just manually implementing compile time typing by way of robust tests to cover interface requirements This, so much this!
  - dataflow 1y ago
    Note that duck-typing can still be a compile-time thing: it's basically what you'd get in C++ if you use auto and templates for everything. The trade-off between compile-time and run-time checking depends in large part on the time needed to address the issue. It's not really black and white. People just don't want to wait forever for static verification - I think that's kind of why clang-static-analyzer isn't used as much as clang-tidy.
jmull 1y ago
> I actually have no idea how big teams work on large C++ codebases. They choose a memory management strategy and stick to it. Of course, the problem, relative to something like rust, is the compiler doesn't enforce it. You can use linting tools and/or reviews. > Usually, you need to have a good idea of how the whole thing works. You can change one part of the code, and it will introduce bugs in the whole project That's not a problem with C++ specifically. That's a problem with organization. It's probably best know as the "Big Ball of Mud" architecture[1]. Rust has no particular defense against it, nor other languages that I am familiar with. If you don't see it as much with rust it's only because it takes time to develop. (counter-intuitively, it's an impressively successful architecture -- so many long-lived projects use it). [1] http://www.laputan.org/mud/ http://www.laputan.org/mud/
on_the_train 1y ago
> You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled Why would it do that?
- keanb 1y ago
  I suppose because it will start writing in memory that is handled by other parts of the code and corrupting it.
  - on_the_train 1y ago
    That is an incredibly general statement at best. And reeks a bit of ancient c++ style. This bug would be pretty exotic and nothing I have ever seen in my life.
wavemode 1y ago
> I actually have no idea how big teams work on large C++ codebases Well yeah, you don't. Most people who comment on these sorts of threads don't, which obviously colors their bias in favor of the solution they do understand.

by f311a 1y ago

cmrdporcupine 1y ago

Honestly after 6 months to a year of constant Rust development you don't even fight with the compiler anymore. Instead it's mostly just your friend. There are still logical holes in the borrow checker, but they're mostly irrelevant.

dataflow 1y ago

> If you don't do C++ on a daily basis, you will silently introduce problems Even if you do, you still will. Just less often. > I actually have no idea how big teams work on large C++ codebases... You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled Part of it is lots of tests, sanitizers, assertions, etc. Part of it is keeping things modular and avoiding spooky action at a distance to the extent possible. Part of it is unavoidable, and that's why people are moving to safer languages.

unshavedyak 1y ago
Your post reminds me of the old runtime vs compile time language debates of old (for me). Some would argue duck typing is all that we need, and that lots of tests can cover the missing types/etc. Eventually i realized that i'm just manually implementing compile time typing by way of robust tests to cover interface requirements.
- sdeframond 1y ago
  > Eventually i realized that i'm just manually implementing compile time typing by way of robust tests to cover interface requirements This, so much this!
- dataflow 1y ago
  Note that duck-typing can still be a compile-time thing: it's basically what you'd get in C++ if you use auto and templates for everything. The trade-off between compile-time and run-time checking depends in large part on the time needed to address the issue. It's not really black and white. People just don't want to wait forever for static verification - I think that's kind of why clang-static-analyzer isn't used as much as clang-tidy.

jmull 1y ago

> I actually have no idea how big teams work on large C++ codebases. They choose a memory management strategy and stick to it. Of course, the problem, relative to something like rust, is the compiler doesn't enforce it. You can use linting tools and/or reviews. > Usually, you need to have a good idea of how the whole thing works. You can change one part of the code, and it will introduce bugs in the whole project That's not a problem with C++ specifically. That's a problem with organization. It's probably best know as the "Big Ball of Mud" architecture[1]. Rust has no particular defense against it, nor other languages that I am familiar with. If you don't see it as much with rust it's only because it takes time to develop. (counter-intuitively, it's an impressively successful architecture -- so many long-lived projects use it). [1] http://www.laputan.org/mud/ http://www.laputan.org/mud/

on_the_train 1y ago

> You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled Why would it do that?

keanb 1y ago
I suppose because it will start writing in memory that is handled by other parts of the code and corrupting it.
- on_the_train 1y ago
  That is an incredibly general statement at best. And reeks a bit of ancient c++ style. This bug would be pretty exotic and nothing I have ever seen in my life.

wavemode 1y ago

> I actually have no idea how big teams work on large C++ codebases Well yeah, you don't. Most people who comment on these sorts of threads don't, which obviously colors their bias in favor of the solution they do understand.