6 ms·

Not a fan of where this is going. Just use Rust instead. All this is doing is making c++ even more unmanageable. When developers are pressed for time they will

Not a fan of where this is going. Just use Rust instead. All this is doing is making c++ even more unmanageable. When developers are pressed for time they will revert to what they are used to and know. What you get in the end is a mess of code with different ideas at different parts of the system because they are developed at different times by different people. Or you are going to put down very strict guidelines and redevelop everything according to these guidelines. Then you are back to rather use Rust instead. The guidelines is built in the Rust language.

klik99 2y ago
Clearly, this is not for you. I work in video games, most games use Unreal Engine, most existing toolsets and dependencies are built on C/C++, I have 17 years professional experience and nearly 30 years including hobbyist experience in C++. I often think I'd start new projects in Rust, but the last two large personal projects I started in C++, and one of them has been deployed in iOS, Android, Windows, Linux, Mac, WASM and RPi environments without much trouble. I haven't regretted that choice, even though I do really like Rust. In my contracting work, Rust just isn't an option. In my personal work, Rust is an option but since C++ has been getting better, I see less and less reason to use Rust. But, you, please keep using Rust. It's a great language and I hope it someday eclipses C++. C++ was never designed as a cohesive language (Bjarne said exactly this in a talk I attended), it was designed as a grab bag of ideas, and I believe much of what's bad about C++ stems from that philosophy. Rust is built from the ground up with good ideas. But there's nothing wrong with improving C++ for those of us who it's really the best or only option. EDIT: To be clear on this particular article, I agree it's not a great direction. But "just use Rust" is not helpful, and you may not have the problem this is trying to solve.
jampekka 2y ago
> When developers are pressed for time they will revert to what they are used to and know. Is not being able to do this a great selling point for Rust? It's better to have nothing instead of code that may have a bug?
singularity2001 2y ago
I agree, with the slightly altered advice: just use Swift instead
- jampekka 2y ago
  And ignore vast majority of computers? And suffer with Xcode?
  - cweagans 2y ago
    Swift runs on windows and linux too. It’s not limited to Apple devices by any means.
pjmlp 2y ago
This is for corporations with 40 years of code in production, that hardly do greenfield development. How will Rust look in 40 years, if it reaches thus far? When will rustc stop depending on a C++ compiler construction framework?
- holowoodman 2y ago
  This is pointless for corporations with 40 years of code in production. Changing all those 40 years worth of code to the safe subset is equivalent to a total rewrite. Especially since usually the really old parts of the code have never been touched or modernized, so are usually C-like and therefore very far away from the safe subset. One might as well rewrite it in something properly memory-safe.
  - pjmlp 2y ago
    Those same corporations have made the transition from C to C++ during the 40 years. They aren't going to do the same with a complete reboot. It is the same reason why from all JavaScript wannabe replacements, including WebAssembly ones, Typescript is the one that got the price.
    - holowoodman 2y ago
      That transition from C to C++ isn't really the same kind of transition. When moving over to C++ from C, you get to keep and use all your old code and gain new capabilities for the newly-written parts. Extending stuff like this is easy. Moving to a subset is very hard, because you loose capabilities. And since this is about memory-safety, you either loose them all at once, or you aren't really memory-safe until you migrated all your codebase to the subset. So while C->C++ takes 40 years, you get benefits in pieces during the 40 years of migration. With C++->SafeC++, you can only get those benefits at the end of those 40 years. Which usually means that it won't be done at all. What might be a possible approach is to divide a huge codebase into smaller parts, isolate them from each other (microservices if you want to call it that) and then migrate those smaller parts to SafeC++. But since that would change the whole architecture of the codebase, the viability is always a very big "maybe".

klik99 2y ago

Clearly, this is not for you. I work in video games, most games use Unreal Engine, most existing toolsets and dependencies are built on C/C++, I have 17 years professional experience and nearly 30 years including hobbyist experience in C++. I often think I'd start new projects in Rust, but the last two large personal projects I started in C++, and one of them has been deployed in iOS, Android, Windows, Linux, Mac, WASM and RPi environments without much trouble. I haven't regretted that choice, even though I do really like Rust. In my contracting work, Rust just isn't an option. In my personal work, Rust is an option but since C++ has been getting better, I see less and less reason to use Rust. But, you, please keep using Rust. It's a great language and I hope it someday eclipses C++. C++ was never designed as a cohesive language (Bjarne said exactly this in a talk I attended), it was designed as a grab bag of ideas, and I believe much of what's bad about C++ stems from that philosophy. Rust is built from the ground up with good ideas. But there's nothing wrong with improving C++ for those of us who it's really the best or only option. EDIT: To be clear on this particular article, I agree it's not a great direction. But "just use Rust" is not helpful, and you may not have the problem this is trying to solve.

jampekka 2y ago

> When developers are pressed for time they will revert to what they are used to and know. Is not being able to do this a great selling point for Rust? It's better to have nothing instead of code that may have a bug?

singularity2001 2y ago

I agree, with the slightly altered advice: just use Swift instead

jampekka 2y ago
And ignore vast majority of computers? And suffer with Xcode?
- cweagans 2y ago
  Swift runs on windows and linux too. It’s not limited to Apple devices by any means.

pjmlp 2y ago

This is for corporations with 40 years of code in production, that hardly do greenfield development. How will Rust look in 40 years, if it reaches thus far? When will rustc stop depending on a C++ compiler construction framework?

holowoodman 2y ago
This is pointless for corporations with 40 years of code in production. Changing all those 40 years worth of code to the safe subset is equivalent to a total rewrite. Especially since usually the really old parts of the code have never been touched or modernized, so are usually C-like and therefore very far away from the safe subset. One might as well rewrite it in something properly memory-safe.
- pjmlp 2y ago
  Those same corporations have made the transition from C to C++ during the 40 years. They aren't going to do the same with a complete reboot. It is the same reason why from all JavaScript wannabe replacements, including WebAssembly ones, Typescript is the one that got the price.
  - holowoodman 2y ago
    That transition from C to C++ isn't really the same kind of transition. When moving over to C++ from C, you get to keep and use all your old code and gain new capabilities for the newly-written parts. Extending stuff like this is easy. Moving to a subset is very hard, because you loose capabilities. And since this is about memory-safety, you either loose them all at once, or you aren't really memory-safe until you migrated all your codebase to the subset. So while C->C++ takes 40 years, you get benefits in pieces during the 40 years of migration. With C++->SafeC++, you can only get those benefits at the end of those 40 years. Which usually means that it won't be done at all. What might be a possible approach is to divide a huge codebase into smaller parts, isolate them from each other (microservices if you want to call it that) and then migrate those smaller parts to SafeC++. But since that would change the whole architecture of the codebase, the viability is always a very big "maybe".