4 ms·

Besides what I've already said about Rust in the past¹, the only thing that I understand Rust has over C++ is additional cross-checks, performed at every compil

Besides what I've already said about Rust in the past¹, the only thing that I understand Rust has over C++ is additional cross-checks, performed at every compilation. In C++ these kind of additional expensive operations are covered by optional 3rd party tools, in this particular case by static code analyzers. There is a good (i.e. useful) reason to engineer the compilation in such separate steps. Of course, the option of having the entire batch of operations tightly integrated has benefits (as well as drawbacks), but that's just about it. ¹ https://news.ycombinator.com/item?id=31565024 https://news.ycombinator.com/item?id=31565024

AlotOfReading 4y ago
Are you kidding? Just one very obvious example: Rust has had good interfaces for std:: optional and std::expected since v1. C++ is finally getting them in c++23 and c++26 (maybe) respectively. Moreover, you only have to learn Rust once because the language doesn't have nearly the same number of weird limitations and radical overhauls every 3 years. I attend the conferences and write C++ regularly. I still run into issues when reviewing teams where I have to consult the standard because I'm not sure if some weird construct is valid because everyone has their own subset of C++ they're comfortable with. God forbid you have to onboard someone new to the language and explain all the different kinds of initialization, a topic that's utterly trivial in literally any other language. As an aside, static code analyzers are not able to provide the same kind of guarantees rustc does to arbitrary C++.
- restalis 4y ago
  "As an aside, static code analyzers are not able to provide the same kind of guarantees rustc does to arbitrary C++." Yes, and now the question becomes - is this due to hard limitations of the C++ as a language (in the sense that provision of such guarantees is simply impossible for static code analyzers, no matter what), or is it that static code analyzers just didn't provide so far (but can and most likely will)? I personally recognize and am thankful for Rust's effort to raise general awareness on the safeness aspect. This (awareness rising) would have been indeed hard to do without forcing this safety to the language core design, although I don't see it working well for Rust in the long run (after people will start having quality alternatives and won't have to pay the "safe by default" price that Rust asks of them).
  - AlotOfReading 4y ago
    C and C++ are both very mature languages at this point and there have been 30-40 years of fairly intense efforts to try and retrofit memory safety onto them with analyzers, language extensions, and runtimes. I wouldn't bet money that it's provably impossible, but I think it's safe to say that we're unlikely to see a general solution in the near future.
hot_gril 4y ago
Rust has a more automatic type system, not just inferring LHS with `auto` like in C++. And overall newer language features, a more modern module system, and a nicer standard lib IMO.

AlotOfReading 4y ago

Are you kidding? Just one very obvious example: Rust has had good interfaces for std:: optional and std::expected since v1. C++ is finally getting them in c++23 and c++26 (maybe) respectively. Moreover, you only have to learn Rust once because the language doesn't have nearly the same number of weird limitations and radical overhauls every 3 years. I attend the conferences and write C++ regularly. I still run into issues when reviewing teams where I have to consult the standard because I'm not sure if some weird construct is valid because everyone has their own subset of C++ they're comfortable with. God forbid you have to onboard someone new to the language and explain all the different kinds of initialization, a topic that's utterly trivial in literally any other language. As an aside, static code analyzers are not able to provide the same kind of guarantees rustc does to arbitrary C++.

restalis 4y ago
"As an aside, static code analyzers are not able to provide the same kind of guarantees rustc does to arbitrary C++." Yes, and now the question becomes - is this due to hard limitations of the C++ as a language (in the sense that provision of such guarantees is simply impossible for static code analyzers, no matter what), or is it that static code analyzers just didn't provide so far (but can and most likely will)? I personally recognize and am thankful for Rust's effort to raise general awareness on the safeness aspect. This (awareness rising) would have been indeed hard to do without forcing this safety to the language core design, although I don't see it working well for Rust in the long run (after people will start having quality alternatives and won't have to pay the "safe by default" price that Rust asks of them).
- AlotOfReading 4y ago
  C and C++ are both very mature languages at this point and there have been 30-40 years of fairly intense efforts to try and retrofit memory safety onto them with analyzers, language extensions, and runtimes. I wouldn't bet money that it's provably impossible, but I think it's safe to say that we're unlikely to see a general solution in the near future.

hot_gril 4y ago

Rust has a more automatic type system, not just inferring LHS with `auto` like in C++. And overall newer language features, a more modern module system, and a nicer standard lib IMO.