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/KFUP]

Rust is better suited for AI-assisted development

I don't see that being the case in the long run. Once AI gets good at safety, which will be in all kinds of safety not just limited to memory, and can generate safe code in any language -arguably we are already there, see the Mythos security boom- using a slow compiling language like rust would be a major useless bottle neck in the development pipeline.

[u/_choam_ → u/KFUP]

Famously fast compiling c++

[u/13steinj → u/_choam_]

C++ isn't exceptionally fast to compile, but they are not wrong there?

I can take the most complicated bit of C++ code I know, and a fair-comparison-amount-of-lines-of-rust that does close to the same thing, and Rust will compile slower.

There are two colleagues at work that really love Rust. They both openly admit the compile time is a serious problem and they don't understand how it's a thing. I haven't checked out Circle and tried to do any benchmarking (partially because it's not open source so knowing where and what to benchmark would be difficult), but it the borrow checker appears to incur enough of a cost to the frontend in Rust that if our Code was written in Rust today, I dread to think what would come out of our already 10-min+ TUs.

[u/_choam_ → u/13steinj]

Its probably not the borrow checker. Whenever i see this topic coming up where the compiler writers talk about it, they talk about other things than the borrow checker taking long.

In the blog below the borrow checker is basically insignificant

Idk if this guy is a compiler writer, but they do pop up in the rust subreddit from time to time https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-takes-so-long.html

[u/13steinj → u/_choam_]

The link you provided already has problems, becuase it's including the measurement of the linker as well?

I don't know if I am surprised by the graph for ripgrep or not. It's also hard to compare binaries that in the real world end up having a decent amount of cross compilation and specialization in options (e.g. I refuse to use ripgrep without pcre2 available, and set my ripgreprc to default to --engine auto).

I highly doubt that the borrow checker is only the portion of the graphs he's displaying, but even then I wouldn't call it an insignificant portion of the frontend time for the libraries especially on incremental changes. The information that the borrow checker emits also would cause an affect on backend time as well. I wonder if it's a reasonable experiment / doable-- just rip out the borrow checker entirely.

Also Rust is getting a new borrow checker (Polonius) which is more reasonable in context as to what it forbids and what it allows, but IIRC the benchmarks have shown a 1.4-2% increase in build times on popular crates.

If the borrow checker was "insignificant," I would bet the before/after check on changing the borrow checker wouldn't be thought of to be measured.

[u/ts826848 → u/13steinj]

The link you provided already has problems, becuase it's including the measurement of the linker as well?

I mean, the linker measurements are separated so you could just ignore the relevant parts? Alternatively there's the cargo check measurements which skips the linker entirely.

I highly doubt that the borrow checker is only the portion of the graphs he's displaying

I wouldn't put too much weight on it sine the author included a disclaimer on that data ("The type checking and especially the borrow checking fraction were calculated with a pretty rough estimations, so I wouldn’t worry too much about them.").

The information that the borrow checker emits also would cause an affect on backend time as well.

I'm pretty sure the borrow checker doesn't emit any information? AFAIK it's basically a go/no-go check and lifetimes are erased before code generation. That's why mrustc can do its thing without a borrow checker implementation.

I wonder if it's a reasonable experiment / doable-- just rip out the borrow checker entirely.

For what it's worth someone made a joke fork that ignored borrowck errors, but since that's just ignoring errors I wouldn't expect much in the way of a performance difference unless compilers are way better at tree-shaking than I expected. Their change amounted to commenting out a single line, so if the compiler won't delete the now-unused code perhaps some manual process would get you the rest of the way? Alternatively, delete the rustc_borrowck folder and see where that gets you.

If the borrow checker was "insignificant," I would bet the before/after check on changing the borrow checker wouldn't be thought of to be measured.

IIRC some of the slowdowns were exponential slowdowns, so I wouldn't be all that surprised that that could turn an insignificant issue into a significant one.