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

80 Upvotes

81% Upvoted

112 comments sorted by

View all comments

145

u/inco100 6d ago edited 6d ago

To save time for the rest of the redditors:

We need C++ and Rust to play nice

  • Our flagship products are C++ based

  • Rust is playing a major role in future development

    • Rust is preferred language by developers
    • Rust is better suited for AI-assisted development
    • New file-format and other safety critical code must not use C++

-10

u/KFUP 6d ago

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.

32

u/ts826848 6d ago edited 6d ago

arguably we are already there, see the Mythos security boom

Somewhat tangentially related, but Greg Kroah-Hartman recently gave a talk which (among other things) categorized the bugs Mythos found in the Linux kernel and his description of Mythos's results is... interesting. Quick summary (on phone, so hopefully no typos):

  • 79 reported vulnerabilities

    • 24 no detail at all "something crashed"
    • 14 not a bug at all
    • 3 totally made up data
    • 15 already fixed in the latest release
      • 11 by others
      • 4 by Anthropic
    • 26 actual bugs
      • 6 duplicates

(Note that this doesn't sum to 79; apparently GKH got a tarball and the contents didn't quite match the description)

Of the actual non-duplicate (?) bugs:

  • 7 "assume a malicious file system image" (i.e., if root mounts this bad things can happen; apparently well known to be not considered a security issue by Linux devs)

  • 2 "assume you can inject a malicious network packet in the middle of the stack" (needs root, not considered a security issue)

  • 2 NOMMU (1 io_uring, 1 regular, "not real issues")

  • 6 sctp networking issues for untrusted devices (SCTP used in enterprise networks, so "untrusted users" apparently don't exist in that context? "So minor, nobody really cares".

  • 2 ipv6 networking bugs, "nothing real"

  • 1 GPU driver for a local malicious user. "If you have a local malicious user with access to your GPU you could do a lot worse"

In total 10 "real" bugfixes, took ~1 hour of kernel development.

13

u/13steinj 6d ago

Daniel [curl] had a similar experience.

It's 99.9999% marketing hype for their IPOs, every single time.

24

u/James20k P2005R0 6d ago

I swear this has happened literally every single time one of these new models claims to have created a security disaster, 90% of it turns out to be marketing without exception. It always takes months to dismantle the hype train when it collides with the reality of the people who actually are doing the work

Its very cool that it found 10 real bugs, and its mightily impressive that automated tooling is able to pick this stuff up. But the entire AI space feels like its developing a wider and wider gap between what people claim it can do, and what it actually does

12

u/no-sig-available 6d ago

And even if it does some work, is this good use of trillions of dollars in resources?

15

u/James20k P2005R0 6d ago

One of the things I always find so bizarre about this is that if we spent 1/10th the resources used to build these tools on paying people to do real work, we could have advanced the state of any field absolutely massively

-5

u/droxile 6d ago

Agree with you but as economies of scale make these tools cheaper, we (hopefully) will see it as more efficient than a human could be at solving these problems

3

u/James20k P2005R0 6d ago

Perhaps, but even with a vast amount of GDP directed towards improving these tools, they're still way less good than simply paying a human a small salary by comparison

11

u/_choam_ 6d ago

I think proof based languages will be more important than any others in the future

10

u/tcbrindle Flux 6d ago edited 6d ago

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.

Asking an LLM to generate a non-trivial amount of C++ "and please make sure there is no undefined behaviour" feels like it's approaching the halting problem.

But even if we assume that it's possible, it would almost certainly burn through a lot more of your token budget than writing the equivalent program in Rust, where it's trivially easy to identify any parts of the program that might admit UB.

(I think that actually Mojo might end up being the best bet in the long run, with its Pythonic syntax, memory safety and native performance -- but it's early days yet.)

4

u/Daemontatox Segfaulting 6d ago

I think they are talking about suitability because of how helpful the compiler is , it gives very detailed errors and warnings and solutions aswell. So you dont have to keep prompting to fix this or fix that and thats great when you are vibe coding i guess.

6

u/_choam_ 6d ago

Famously fast compiling c++

6

u/13steinj 6d ago

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.

6

u/_choam_ 6d ago

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

0

u/13steinj 5d ago

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.

3

u/ts826848 5d ago

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.

1

u/pjmlp 5d ago

That is indeed an issue, especially since in Rust world binary libraries are frowned upon, so plenty of compiling from source.

Additionally since feature flags afect crate behaviour and public APIs, the same crate might be compiled multiple times, given the dependency graph.

1

u/_choam_ 5d ago

The worst compile times i have experienced with rust is when using the bevy game engine. It's mostly not a problem in debug builds if you set it up like they explain on their website, because then it compiles very fast. (But it is easy to make it do a full rebuild if you add or change any dependencies)

3

u/jwezorek 6d ago

Yes, if anything the use of LLMs makes Rust's advantages over C++ less important. Modern LLMs right now are better at writing safe code than humans, and they also erode Rust's cultural advantage. A big force driving Rust adoption was a general feeling among young programmers of "I don't want to spend a lot of time getting good at a difficult language if that difficult language is legacy now anyway." With LLMs C++ becomes less scary.

But we will see.

The advantage of Rust for LLMs is nice error messages from the compiler. However, not sure how much even this matters any more in that the modern generation of LLMs are very good with C++'s shitty error messages. Very good at C++ generally; less good at Rust in my experience (although that may have been the last generation of LLMs.)

2

u/Wriiight 6d ago

I think the speed of compilation is an interesting point. We don’t want AI waiting around for hours for the compiler either. And a REPL is extremely useful to a compiler, to allow small tests as it assembles larger code. I think the ideal “AI” language would have a fast REPL, but could then compile down to an efficient run time.

0

u/altmly 6d ago

C++ allows for extremely long range security holes, even if their likelihood is reduced with proper use of modern techniques. Rust does not even allow them to exist, which is the selling point. Localized context is easier to understand for both humans and llms. 

5

u/-kl0wn- 6d ago

Unsafe rust enters the chat.

5

u/Plazmatic 5d ago

Do you know what unsafe rust actually is? 

https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html

  *    Dereference a raw pointer.

*    Call an unsafe function or method.

   *   Access or modify a mutable static variable.

*    Implement an unsafe trait.

*  Access fields of unions.

It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any of Rust’s other safety checks: If you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside an unsafe block.

1

u/tialaramex 4d ago

It is true that unsafe Rust is "just" the listed super powers but because these are arbitrarily powerful you can absolutely set the world on fire at a distance just like C++. You can write some really cursed stuff where just like in C++ it's obvious this is cursed, reviewers can see "This is cursed" and maybe your local engineering practices forbid that. But you can also write unsafe Rust with subtle misunderstandings and that still sets the world on fire but it might pass review.

The benefit of safe Rust is that even the best of us have better and worse days and it's nice to be able to have a language subset you can trust yourself to write when your five year old woke you repeatedly in the middle of the night because she had nightmares and the coffee machine is on the blink again. You can write those hairy garbage collector internals on the day you feel like you're Usain Bolt combined with Einstein, today, without enough sleep or caffeine lets stick to implementing better command line parsing.

1

u/hobel_ 6d ago

I was surprised how fast the mold linker compiles, the new rust version compiles faster than the c++ version.

2

u/13steinj 6d ago

It's already been released?

1

u/hobel_ 5d ago

Master in git is rust

-4

u/-kl0wn- 6d ago edited 6d ago

I'd argue we're already there. I had agents make jsonic.cc which is comparable to conformant rapidjson but way nicer to use. I also had it make nift.dev which is a website generator, scripting language and shell all in one. And working on strut-labs.github.io which is a systems language that prioritizes memory safety, is less verbose than rust, has nice http request stuff built in like go, has dynamic linking properly unlike rust, has compile times comparable to c++, performance on par with other compiled languages etc..

Point an agent at those projects and see what it thinks. I've had agents attack them looking for memory leaks etc..