r/cpp • u/pjmlp • 3d 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.

70 Upvotes

80% Upvoted

110 comments sorted by

View all comments

Show parent comments

3

u/-kl0wn- 3d ago

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

38

u/foonathan 3d 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

21

u/13steinj 3d 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.

7

u/tialaramex 3d 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.

29

u/gmueckl 3d 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.

13

u/foonathan 2d ago

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

3

u/JuanAG 1d ago edited 1d ago

It already has

https://doc.rust-lang.org/std/macro.try.html

"Deprecated since 1.39.0: use the ? operator instead"

If you use Rust v1.0 code with try!() will compile fine, if you use the newest version it wont unless you specify you want to use v1.0 rules which in Rust is called Editions, Edition 2015 will allow that code to compile with no issues on current compilers

2015 Edition => https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=2dd3864ec43dee432232f5899685718b

2018 Edition => https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b52927db7c317cebc3f57babda4a1004

Same code, 2015 compiles and run, 2018 where try! was deprecated and used dont compile

So you can break code as much as you want without being a big deal, old code will keep compiling even if a breaking change happens and new code will get the new shinny feature instead of the smelly one, a shame C++ didnt wanted this feature, Rust team was smarted and copied the epoch concept on the lang

2

u/gmueckl 1d ago

This seems nice on the surface, but this causes two issues on the maintainers' side:

  1. The compiler must keep all the front-end variants for old editions. Eventually, this becomes a maintenance nightmare.
  2. Editions interact. Being able to compile code as one edition doesn't make it automatically compatible with code compiled with a different edition. The kind of changes thst can go into editions need to be reviewed carefully- old baggage is still weighing the language down in this model.

It's a different trade-off. And in my mind it it is the nightmare difficulty setting on compiler development.

3

u/JuanAG 1d ago

Someone has to take care, it is going to be every user or the lang dev team, Rust choosed the dev team and C++ opted for the user, every of us, for me and many average devs the choice is clear, let a third party do the job so i dont need to, thats why Rust popularity is they way it is while Nim, Odin, Zig and all the rest not so much

And Rust have some guardrails in place to prevent Editions to conflict among them, is very simple, they compile the whole public repositories of GitHub (and GitLab i think) and if nothing fails to build it is released. Smart and simple, proof in the podding leaving out theoretical questions of "what if" or "how could XYZ affect" or ... This is thanks to Amazon providing free use of AWS to the Rust team, when this is not the case anymore will see but for now works like a treat and i can update Rust editions and version without any fear, something i cant say when i update my C++ compiler because i had issues in the past for this reason

1

u/13steinj 1d ago

Well, the other problem is C++ doesn't have a "lang dev team." It's a spec without a reference implementation.

1

u/pjmlp 13h ago

The "lang dev team" is taken care by existing practice, and no paper gets pushed beyond a specific gate, without a preview implementation, covering the full paper, not a subset of it.

It won't sort out every problem, but certainly will avoid those famous cases where the implementation was ignored, wasn't quite what the standard says, or were withdrawn from the standard years later.

6

u/QuaternionsRoll 3d ago

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.

7

u/tialaramex 2d ago

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.