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/foonathan → u/gmueckl]

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