9 ms·

> I think this is an excellent example of why people get so excited about Rust. It can't do anything you can't do in C or C++, but it makes a whole bunch of thi

by sobkas 5y ago

> I think this is an excellent example of why people get so excited about Rust. It can't do anything you can't do in C or C++, but it makes a whole bunch of things significantly easier and less stressful. Which makes maintenance easier, and in practice often leads to performance improvements because more ambitious designs can be attempted. For most people Rust is just overkill, what I really want is secure subset of c++, enforced by compiler with hardened standard library(that is sanctioned by standard body, might be not 100% compatible with generic one, because it contains only a subset of functionality and some functions might work differently).

nicoburns 5y ago
I'm not sure about this. Remember that most people (even most software developers) don't know C++ (or even C). And IMO (as someone who has tried to learn both) Rust is a lot easier to learn than C++
pornel 5y ago
To me "C/C++, but secure" is equivalent to dreaming about sex on a beach. Sounds lovely as a concept, because you imagine the positives, not where the sand will get in. It would be nice to keep the same language, same libraries, and codebases, and just somehow make them safe. But these were written for C++, not for a restrictive subset. You'll end up removing features that dependencies use (e.g. can you even ban non-smart pointers?). You'll add runtime checks to constructs that existing code assumed were free, and never needed to avoid (zero cost is a reason to use C++, otherwise a GC+JIT language can have runtime checks, but better). You will have to rewrite your code to clarify lifetimes, ownership, and remove constructs compiler can't analyze for safety. You get many of the same pains that switching to Rust has, but none of Rust's features, and not even a fully-functional C++.
- deleted 5y ago
  [deleted]
dureuill 5y ago
A subset of C++ cannot simultaneously be secure and useful, because to be secure a subset would need to ban pointers, references, iterators, moves and the ability to include code that is not part of this subset (for the last point modules might help, but they aren't here and they introduce their own ODR violations cases, so "safe" is a stretch even for them). To retain usefulness, we need a superset of C++ that would include either a GC (at which point, why use C++), or lifetime-like annotations, and the need to actively migrate the ecosystem to it. At which point what you have is a rust-shaped language with an outdated compilation model, tons of pitfalls, an inexpressive type system, and a slightly better interop with C++. Considering that such a language doesn't exist, that which features to remove and which to add will be source for endless discussions, I'd say that the move that isn't overkill is to use the language that actually exists today and delivers on these promises. Rust isn't overkill, despite 10-years of C++ experience I'm way more productive in Rust, be it while writing code, fetching dependencies, reviewing code, and of course all of this compounds during maintenance. You do need to invest 3 months to learn the language, and some more to write the occasional bindings, but they will be very quickly recovered by avoiding writing CMake (not even counting asan/valgrind debugging sessions).
unionpivo 5y ago
> what I really want is secure subset of c++, enforced by compiler with hardened standard library(that is sanctioned by standard body, might be not 100% compatible with generic one, because it contains only a subset of functionality and some functions might work differently). Problem with this is, that your code would use such subset, but what about libraries you use ? Then you would have confusion as to which libraries are safe to use in such new C++, would they work with the standard C++ ? You would effectively have 2 languages inside of one. Remember all the C/C++ confusion and how compatibility to C has kept it back? That would lead to similar problems.

by sobkas 5y ago

nicoburns 5y ago

I'm not sure about this. Remember that most people (even most software developers) don't know C++ (or even C). And IMO (as someone who has tried to learn both) Rust is a lot easier to learn than C++

pornel 5y ago

To me "C/C++, but secure" is equivalent to dreaming about sex on a beach. Sounds lovely as a concept, because you imagine the positives, not where the sand will get in. It would be nice to keep the same language, same libraries, and codebases, and just somehow make them safe. But these were written for C++, not for a restrictive subset. You'll end up removing features that dependencies use (e.g. can you even ban non-smart pointers?). You'll add runtime checks to constructs that existing code assumed were free, and never needed to avoid (zero cost is a reason to use C++, otherwise a GC+JIT language can have runtime checks, but better). You will have to rewrite your code to clarify lifetimes, ownership, and remove constructs compiler can't analyze for safety. You get many of the same pains that switching to Rust has, but none of Rust's features, and not even a fully-functional C++.

deleted 5y ago
[deleted]

dureuill 5y ago

A subset of C++ cannot simultaneously be secure and useful, because to be secure a subset would need to ban pointers, references, iterators, moves and the ability to include code that is not part of this subset (for the last point modules might help, but they aren't here and they introduce their own ODR violations cases, so "safe" is a stretch even for them). To retain usefulness, we need a superset of C++ that would include either a GC (at which point, why use C++), or lifetime-like annotations, and the need to actively migrate the ecosystem to it. At which point what you have is a rust-shaped language with an outdated compilation model, tons of pitfalls, an inexpressive type system, and a slightly better interop with C++. Considering that such a language doesn't exist, that which features to remove and which to add will be source for endless discussions, I'd say that the move that isn't overkill is to use the language that actually exists today and delivers on these promises. Rust isn't overkill, despite 10-years of C++ experience I'm way more productive in Rust, be it while writing code, fetching dependencies, reviewing code, and of course all of this compounds during maintenance. You do need to invest 3 months to learn the language, and some more to write the occasional bindings, but they will be very quickly recovered by avoiding writing CMake (not even counting asan/valgrind debugging sessions).

unionpivo 5y ago

> what I really want is secure subset of c++, enforced by compiler with hardened standard library(that is sanctioned by standard body, might be not 100% compatible with generic one, because it contains only a subset of functionality and some functions might work differently). Problem with this is, that your code would use such subset, but what about libraries you use ? Then you would have confusion as to which libraries are safe to use in such new C++, would they work with the standard C++ ? You would effectively have 2 languages inside of one. Remember all the C/C++ confusion and how compatibility to C has kept it back? That would lead to similar problems.