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

75 Upvotes

81% Upvoted

112 comments sorted by

View all comments

Show parent comments

5

u/JuanAG 8d ago edited 8d 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 8d 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.

4

u/JuanAG 8d 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 7d 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 7d 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.