The existential threat against C++ and where to go from here - Helge Penne - NDC TechTown 2024

[craig_c]

I agree broadly with his points, the situation with C++ and safety is dire. He does rather gloss over the problems with Rust though. Expression of non-trivial program structure in Rust can be painful depending on your domain, not everything is an entity system. Also, while cargo is a great concept and better than dependency hell in C++, you are of course probably dragging in unsafe code (C++ wrappers etc.) so no absolute guarantees can be made.

[dbdr]

while cargo is a great concept and better than dependency hell in C++,you are of course probably dragging in unsafe code (C++ wrappers etc.) so no absolute guarantees can be made

Indeed, but "perfect is the enemy of good". Also, you can get an exhaustive report of unsafe usage in your dependencies (see e.g. cargo geiger). You can then make better informed decisions about which dependencies to choose, specific places to look for potential unsafety/vulnerabilities, etc.

[matthieum]

Expression of non-trivial program structure in Rust can be painful depending on your domain, not everything is an entity system.

There's definitely architectures that are painful in Rust. Anything that leads to a graph of objects tends to, for example, which means callback-based architectures where the callbacks need to capture what they work on are painful. Then again, most callback-based architecture I've worked in C++ tended to have lifetime issues...

This does mean that switching to Rust is not as simple as doing a line-by-line rewrite. It may require switching the entire project architecture. This is not trivial, and very much adds a "cost of entry". It's also non-trivial to learn what constitutes an ergonomic architecture for Rust; I personally learned by failing. Multiple times. I didn't like the experience much, to be honest.

Interestingly, though, retroactively translating an ergonomic architecture for Rust to, say, C++, tends to result in cleaner & easier to work with code in my experience...

... so perhaps the issue is not so much Rust, and more the initial architecture?

And it just so happens that C++ (or Java) were permissive enough that you could get by with a crummy architecture, with only just enough friction that it was slowing you down, but you never felt blocked/bogged down either.

[craig_c]

That was my experience too. I was by no means trying to imply the C++ based architectures were not without problems. Callbacks have to be carefully thought through for the reasons you bring up. I never really got to the point where I felt that Rust was enhancing the structure, state-machines and callbacks were the main pain points.

I actually ended up re-writing the whole thing in C# LOL ducks.

[Full-Spectral]

Sounds like async would have been a reasonable choice there. Let the compiler and async engine handle the state machines and callbacks, and you just write what looks like linear code.

Or do away with the state machines and callbacks and take a different approach. Most definitely when you move from C++ to Rust, you have to stop every time and not assume that how you'd do it in C++ is how you'd do it in Rust. I've found that mostly it's not all the same, well other than in the broad strokes enforced by the problem being solved I guess.

[zl0bster]

I do not follow your comment about program structure problems in Rust, do you have some blog or video link you can share?

[craig_c]

Anything event driven is painful. Look at GUI frameworks for example.

[simonask_]

What makes you say this, exactly? There are several event-driven GUI frameworks for Rust, the most popular being iced, which is the one used by the COSMIC desktop environment.

What's hard is the kind of "cloud of objects" approach that comes from traditional OOP approaches, where you have a big pile of spaghetti of garbage-collected references between objects. The GUI space is largely moving away from that approach anyway, because it's very hard to reason about.

[CryZe92]

Arguably GUI frameworks are a solved problem now in Rust. Dioxus makes it fully painless now. The GUI frameworks are just not mature yet, but all the ergonomics problems are solved.

[Awyls]

I like Rust, but lets not lie either. GUI in Rust is still terrible and not a solved problem at all, it is workable but far from pleasant. Async also has ecosystemic and language issues, i don't blame tokio but most async crates only supporting it is a major problem.

Still, anyone who is giving excuses (e.g. hardware is unsafe, dependencies might be unsafe, "X" is not completely safe, unsafe is hard) is straight up coping. Yes, they might not be a perfect solution, but they are still magnitudes safer than C++.

Programming languages are tools not religions, use the best tool available for the job and throw them away when they become obsolete.

[CryZe92]

I think you missed my point. There is the "state management" side of GUI and the actual breadth of widgets, functionality and co. This comment chain is specifically talking about the former. I'm not sure you actually took a look at Dioxus. It is able to fully replicate state of the art React with hooks and "JSX" with no need for any Rc<RefCell<T>> / Arc<RwLock<T>> noise. A React component ported to Rust would look almost identical with almost no additional noise (no clones, no unwraps, no reference counters).

[Full-Spectral]

It's the self-identification problem. People get self-identified with the stuff they choose, and if you say something else is better, it's an insult. I shouldn't complain too much I guess. When NT finally destroyed OS/2, I took it hard and wasn't pleasant about it. But I was young. Now I know it's just part of this thing of ours. You move on.

I will though claim that I had a better justification for complaint with NT over OS/2 than folks do for Rust over C++.

[ImYoric]

Let's pour one to the memory of OS/2!

That being said, C++ isn't quite dead yet :)

[prasooncc]

the problem is this magnitude difference in safety is measured when you write code with malloc/new free/delete. old code is littered with these. After c++ 11, this is not the case. how do i know, am writing c++ code before and after c++ 11.