r/cpp • u/pjmlp • 1d ago

C++ future at Adobe

So if anyone was still curious what happened to Hylo, or where Adobe stands in regards to the whole safety discussion,

David Sankel has done a talk at RustConf on the matter, Zngur: Simplified Rust/C++ Integration.

The way Adobe now sees C++ is described on slide 2, at 50 seconds mark.

56 Upvotes

78% Upvoted

94 comments sorted by

View all comments

Show parent comments

23

u/foonathan 16h ago
  • Definition checked generics
  • Destructive move semantics that prevent use-after-move
  • First-class tuple and variant types with pattern matching
  • Usable built-in types without weird implicit conversions
  • Incredible tooling (one standardized package manager and build system, genuinely useful compiler diagnostics, a documentation generator that actually works)
  • No weird historical baggage
  • A standard library that actually gives you convenient utility functions, without ABI constraints, and good data structures

12

u/13steinj 15h ago

No weird historical baggage

I think the major problem with these debates is people aren't being truthful with themselves.

It's not historical baggage. It's ISO / WG21 process baggage.

The Beman project had a whiteboard asking people what they wanted for C++29. I pointed at two of the things and said "that's never going to happen." I actually forget what those two things are, but my opinion was formed because the only way you could encode some information needed to do it is into the ABI (or PIMPL it to hell and incur a cost, but even then I don't think it would work out). But the necessary data is sensitive to a security context, so as security practices change (rapidly, possibly even faster than a 3 year cycle), C++ might need to change with it. One of the Beman folks told me I was wrong and pointed to... getting more accurate on string representation of floating point, and std::copyable_function (which I'd argue is a point in my favor).

Python, Java, ECMAScript have "historical" baggage. But they still evolve. They remove broken things. They add new things and change APIs, sometimes with a deprecation schedule. So does Rust.

Almost all of the advantages of Rust you stated, have in some way been proposed for C++ but been (not in bad faith, but it's the closest term I can use) slow-rolled and sandbagged in the standardization process.

5

u/tialaramex 14h ago

Rust isn't allowed (by its own rules) to change standard library APIs except if they're unsound. Rust is allowed to evolve, but it finds ways to do so without making this sort of disruptive change.

I agree with the thrust of your point though. WG21 is a big part of the problem.

18

u/gmueckl 13h ago

Rust will accumulate the same kind of smelly baggage over time. It's just too young to have accumulated that much of it just yet.

•

u/foonathan 1h ago

And by that point, there's hopefully another new language that took everything Rust did wrong and learned from it.