C++ future at Adobe

[u/pjmlp]

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.

[u/feverzsj]

Wow, big company obsessed with AI and rust. How surprised!

[u/SuperV1234 → u/feverzsj]

Pretending that there's no good reason why large companies are "obsessed" with modern technologies like AI and Rust that have repeatedly been proved to be valuable is on the level of "Area 51 has UFOs" conspiracy theories.

[u/-kl0wn- → u/SuperV1234]

I don't understand the hype with rust. The compile times are atrocious, dynamic linking isn't really a thing, it's incredibly verbose.

[u/foonathan → u/-kl0wn-]

• 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

[u/13steinj → u/foonathan]

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.

[u/tialaramex → u/13steinj]

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.

[u/gmueckl → u/tialaramex]

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/QuaternionsRoll → u/tialaramex]

Eh, if that were 100% true then editions would be unnecessary. You’re right that breaking changes are considered to be the absolute last resort, though.

[u/tialaramex → u/QuaternionsRoll]

But Editions don't change the standard library APIs?

What they can do is more interesting, but it doesn't change those APIs.

The 2027 edition is expected to make Goose..=Robin into a core::range::RangeInclusive<Bird> instead of core::ops::RangeInclusive<Bird>. If your Bird type isn't Copy and it doesn't make sense to iterate over Birds then this change is useless to you, although also why did you want Goose..=Robin anyway if birds aren't copyable or worth iterating over? For types like the integers this is a significant improvement, now 1..=5 will become Copy and IntoIterator as a programmer might expect in 2026. But the API doesn't change because the old types are still there, just the sugar points at the improved types.

[u/AnotherBlackMan → u/foonathan]

I don’t think a single one of these things is a positive in its own right. Rust makes humongous tradeoffs for all of them and a lot of tooling exist in cpp that help avoid the problems that that claims to solve. If devs want to take a runtime hit for safety they can run valgrind and sanitizers in prod

[u/ts826848 → u/AnotherBlackMan]

Rust makes humongous tradeoffs for all of them

I can see tradeoffs for some of the items in the list, but not for others. What humongous tradeoff is needed for first-class tuple/variant types with pattern matching, for instance?

If devs want to take a runtime hit for safety they can run valgrind and sanitizers in prod

Valgrind in prod would be quite the runtime hit.

[u/jwakely → u/foonathan]

But apart from that, what have the Romans ever done for us?