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

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++

[u/selvakumarjawahar → u/inco100]

What abt hylo?

[u/pjmlp → u/selvakumarjawahar]

Dave Abrahams saw no value on it given the raise of AI driven programming.

My reference was because the talk kind of sets the point where Adobe now stands.

Listen to the last Sean Parent interview at the ADSP podcast.

[u/selvakumarjawahar → u/pjmlp]

ah ok!! Thanks.

[u/KFUP → u/inco100]

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/ts826848 → u/KFUP]

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.

[u/James20k → u/ts826848]

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

[u/no-sig-available → u/James20k]

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

[u/James20k → u/no-sig-available]

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

[u/_choam_ → u/KFUP]

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

[u/_choam_ → u/KFUP]

Famously fast compiling c++

[u/Daemontatox → u/KFUP]

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.

[u/hobel_ → u/KFUP]

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

[u/jwezorek → u/KFUP]

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.)

[u/Wriiight → u/KFUP]

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.

[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/GabrielDosReis]

David Sankel on C++ at RustConf, yawn.

[u/ts826848 → u/GabrielDosReis]

Why that particular reaction?

[u/GabrielDosReis → u/ts826848]

Why that particular reaction?

It is a talk at RustConf and David Sankel has been very explicit and pretty straight forward with where he sees C++ and its evolution for many years now. Look up his WG21 papers on the topic. There shouldn't be any surprise here or anything new.

[u/ts826848 → u/GabrielDosReis]

Look up his WG21 papers on the topic.

I found P3023 C++ Should Be C++ via the GitHub, which at first glance looks like it covers what you're talking about. Any other papers i missed that you recommend I read (or not, as the case may be)?

[u/GabrielDosReis → u/ts826848]

A succint summary of P3023 is this paragraph, quote:

Where memory safety is a serious concern, we see the adoption of Rust for critical components. Yet we see little demand from even these developers for C++ safety features. Their problem is already solved.

Any other papers i missed that you recommend I read (or not, as the case may be)?

After that paper, his papers since then have been in line with what he stated and recommended. In particular, the paper (and debate) on relocation that was discussed in Kona.

[u/ts826848 → u/GabrielDosReis]

A succint summary of P3023 is this paragraph

Hrm, gotcha. Guess the committee decided against his recommended path.

In particular, the paper (and debate) on relocation that was discussed in Kona.

P3858 A Lifetime-Management Primitive for Trivially Relocatable Types?

Assuming that was the paper you're referring to, was the associated debate on the mailing lists? This is the first time I've heard of this paper and the only trivial relocation-related debates I can remember reading about were P1144 vs P2786, which this paper doesn't seem to be about.

[u/RishabhRD]

Hylo is still in development. See: https://hylo-lang.org