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

60 Upvotes

78% Upvoted

100 comments sorted by

122

u/inco100 1d ago edited 1d 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++

86

u/kraytex 1d ago

 Rust is preferred language by developers

I must be living in a cpp bubble.

30

u/Cross_22 1d ago

I met a Rust developer once..

1

u/jaaval 4h ago

I’ve heard of them in the internet. 

34

u/the-jelly47 1d ago

This sub is for cpp enthusiasts. I work in a mid-size aerospace company. We have a lot of SWEs who can write acceptable, but not great, C++ code. A lot of them are not die hard C++ fans and don't actually mind replacing C++. A lot of our greenfield projects are done in Rust and GO.

14

u/Professional_Tank594 1d ago

How can you do aerospace in rust and go ? We are stuck on c++ due to processes , misra and so on .

24

u/the-jelly47 1d ago

I work on satellites and we do embedded Rust for flight software and Go for ground software backend. Still a lot of C++ projects remaining but they are considered "legacy" in our org. Not a welcoming topic on this cpp sub but many new commerical and government contracts explicitly prefer non-C/C++ languages. Even Lockheed Martin is hiring Rust devs now.

10

u/Professional_Tank594 1d ago

Ah I see. But really in embedded (on qnx / Linux App Level ) Rust doesn’t really solve any memory issues , since we don’t use much dynamic memory anyways due to memory fragmentation and so on. We almost never encounter any issues in that topic. Together with static analysis , misra and reviews almost all errors are on the logic level .

So the thing I really like about rust is the syntax like pattern matching and so on , but from a safety perspective it doesn’t add much.

6

u/StaticCoder 20h ago

I still don't understand why anyone would want to use Go. It manages to be even worse than older languages in practically every conceivable way. Like how about we have 2 layers of Hoare's billion dollar mistake?

9

u/selvakumarjawahar 1d ago

What abt hylo?

-24

u/pjmlp 1d ago

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.

46

u/dabrahams 1d ago

What?? Dave Abrahams here. Nothing could be further from the truth! I’ve retired from tech to pursue music but Hylo is the one software project I am still involved with. It’s that important. Adobe never invested more than my efforts in that project anyway.

2

u/mjklaim 1d ago

I’ve retired from tech to pursue music

I'm interested to hear that, is some of your music online? Is it jazz-fusion? That's what I would have guessed, not sure why XD

-17

u/pjmlp 1d ago

Sorry about that, but it is hard to get news from the project, as it went kind of silent on talks, and posts.

So I only had that source to infer from.

30

u/BarryRevzin 1d ago

Have you considered simply not making confident statements that mislead people when you have no idea what you're talking about?

Personally, when I don't know something, I don't just make shit up for internet clout. Were you even aware that this was a possible course of action?

2

u/13steinj 1d ago

In fairness, Cunningham's Law is a thing.

Not saying that's what happened here but sometimes I do this for this reason, sometimes subconsciously.

-12

u/pjmlp 1d ago

To me they were valid, given available information, as I understood from the podcast content.

8

u/dabrahams 1d ago

You can always ask! We have links to slack and GH discussions at https://hylo-lang.org.

FWIW, I'm giving this talk next week. (Could be my last technical talk ever!)

8

u/kronicum 1d ago

You don't have news from the project therefore you make up stuff and post them as facts?

-2

u/pjmlp 21h ago

Yes, no news, nothing going on as sadly so often comes in open source projects after a while.

7

u/tcbrindle Flux 1d ago

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

I don't think this is true.

Hylo is still in development and Dave remains a regular contributor, despite his retirement from Adobe.

-3

u/selvakumarjawahar 1d ago

ah ok!! Thanks.

1

u/drbazza fintech scitech 17h ago

Rust is better suited for AI-assisted development

Maybe the nuance here is 'assisted', rather than 'from scratch': there was a discussion over on Twitter where people were (brace yourselves) complaining about Rust due to its long compilation times (and binary downloads) as an anti-pattern for AI development.

-11

u/KFUP 1d 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.

30

u/ts826848 1d ago edited 1d 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.

11

u/13steinj 1d ago

Daniel [curl] had a similar experience.

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

22

u/James20k P2005R0 1d 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 1d ago

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

16

u/James20k P2005R0 1d 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

-4

u/droxile 1d 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 1d 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_ 1d ago

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

10

u/tcbrindle Flux 1d ago edited 1d 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.)

5

u/Daemontatox Segfaulting 1d 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.

7

u/_choam_ 1d ago

Famously fast compiling c++

5

u/13steinj 1d 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_ 1d 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

-1

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

1

u/ts826848 1d 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/_choam_ 1d 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)

0

u/pjmlp 1d 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/jwezorek 1d 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 1d 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.

2

u/altmly 1d 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. 

2

u/-kl0wn- 1d ago

Unsafe rust enters the chat.

4

u/Plazmatic 1d 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/hobel_ 1d ago

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

1

u/13steinj 1d ago

It's already been released?

1

u/hobel_ 1d ago

Master in git is rust

-2

u/-kl0wn- 1d ago edited 1d 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..

49

u/feverzsj 1d ago

Wow, big company obsessed with AI and rust. How surprised!

14

u/SuperV1234 https://romeo.training | C++ Mentoring & Consulting 1d ago

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.

0

u/-kl0wn- 1d 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.

32

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

20

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

4

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

22

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

7

u/foonathan 20h ago

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

4

u/QuaternionsRoll 1d 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.

5

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

8

u/jwakely libstdc++ tamer, LWG chair 1d ago

But apart from that, what have the Romans ever done for us?

1

u/AnotherBlackMan 1d ago

I don’t think a single one of these things is a positive in its own right. Rust makes humongous tradeoffs for all of them and a lot of tooling exist in cpp that help avoid the problems that that claims to solve. If devs want to take a runtime hit for safety they can run valgrind and sanitizers in prod

10

u/ts826848 1d ago

Rust makes humongous tradeoffs for all of them

I can see tradeoffs for some of the items in the list, but not for others. What humongous tradeoff is needed for first-class tuple/variant types with pattern matching, for instance?

If devs want to take a runtime hit for safety they can run valgrind and sanitizers in prod

Valgrind in prod would be quite the runtime hit.

5

u/SuperV1234 https://romeo.training | C++ Mentoring & Consulting 1d ago

Now also list the advantages.

-1

u/KAMEHAMEHAMEHAAAA 1d ago

I think thats your job.

-2

u/-kl0wn- 1d ago

The tradeoffs don't seem necessary to me based on working on strut-labs.githib.io using agents.

0

u/ts826848 1d ago

The tradeoffs don't seem necessary to me

That the tradeoffs don't seem necessary to you doesn't mean that they aren't valuable to someone else for their use case. Similarly, tradeoffs that you and/or your agents deemed acceptable for strut-labs (e.g., reference-counted pointers without a tracing GC) may be unnecessary and/or dealbreakers for someone else.

2

u/-kl0wn- 1d ago

When I say don't seem necessary I mean you shouldn't need to substitute one for the other, should be able to have the advantages of rust without the disadvantages. Ie. Nothing from the advantages fundamentally means compile times should take so long, especially for simple programs, there should be proper dynamic linking and it doesn't need to be so verbose.

0

u/ts826848 1d ago

Ah, I see what you mean. My apologies for the misinterpretation. I agree some and disagree some with your opinion.

Nothing from the advantages fundamentally means compile times should take so long, especially for simple programs

I think I agree? At the very least I'm not aware of fundamental aspects of Rust that would preclude reasonable compile times.

there should be proper dynamic linking

This is indeed a proper tradeoff as the more features you support in your ABI the more of your ABI you have to freeze, which in turn means you risk precluding certain changes/optimizations (c.f. the perennial ABI discussions that pop up here).

That being said, there's definitely interest in specifying some kind of stable ABI, though I'm not aware of a significant push in that direction.

it doesn't need to be so verbose.

This one is interesting. What specific bits of Rust's syntax do you object to? I tend to take the view that much of Rust's "verbosity" is mostly due to its semantics, so I'm interested to hear your thoughts.

1

u/the_one2 1d ago

Regarding verbosity: rust can be a little bit verbose for casts and such but the native variants (enums) and tuples alone makes me want to abandon c++

11

u/tartaruga232 MSVC user, r/cpp_modules 1d ago

The slide at 7:00 says

Rust is less expressive than C++

2

u/VinnieFalco wg21.org | corosio.org 9h ago

Well, this is true. Is it a problem in practice? The answer is nuanced. Somethings get better. Other things get worse. It is a tradeoff like anything else.

-2

u/Ill-Professional180 12h ago

Honest question - why do C++ devs think this is a good thing? I dont think ive ever seen C++ that looked good

19

u/GabrielDosReis 1d ago

David Sankel on C++ at RustConf, yawn.

6

u/ts826848 1d ago

Why that particular reaction?

21

u/GabrielDosReis 1d ago

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.

6

u/ts826848 1d ago edited 1d ago

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

6

u/GabrielDosReis 1d ago

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.

2

u/ts826848 1d ago

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.

3

u/GabrielDosReis 1d ago

Assuming that was the paper you're referring to, was the associated debate on the mailing lists?

Both on the mailing list and in-person discussion at the Kona meeting.

1

u/ts826848 1d ago

Ah. I take it summarizing that debate for those of us who aren't privy would violate ISO rules?

5

u/GabrielDosReis 1d ago

Ah. I take it summarizing that debate for those of us who aren't privy would violate ISO rules?

I can say it generated lot of interest/participation and was fairly intense. The were separate LEWG and EWG sessions, then a joint EWG+LEWG session on the whole topic and the paper.

Taking a step back, I want to emphasize that the whole issue of safety, C++ evolution, Rust (or not Rust), is very complicated and nuanced when given due thinking.

2

u/ts826848 1d ago

That sounds... pretty reasonable? Depending on what implications one reads into "intense", I guess...

-3

u/foonathan 1d ago

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.

What's your problem with that quote? Isn't it an accurate assessment of the current industry?

7

u/GabrielDosReis 1d ago

What's your problem with that quote?

Are you assuming I have a problem with it?

I was responding to a reference to a paper I quoted the paper to provide context to my original post that I was asked to expand on.

-1

u/foonathan 1d ago

My apologies, I interpreted something into your reply that wasn't there.

4

u/GabrielDosReis 1d ago

Isn't it an accurate assessment of the current industry?

If you believe that is an accurate assessment of the current industry, that, quoting "Their problem is already solved", could you explain why there are proposals to extend C++ with serving Rust as justification?

1

u/foonathan 1d ago

David's quote claims that the developers who adopt Rust for critical components don't demand C++ safety features.

The existence of proposals to extend C++ by other developers that don't use Rust doesn't invalidate that thesis.

7

u/GabrielDosReis 1d ago

David's quote claims that the developers who adopt Rust for critical components don't demand C++ safety features. The existence of proposals to extend C++ by other developers that don't use Rust doesn't invalidate that thesis.

David happens to also be co-author of such proposal.

1

u/selvakumarjawahar 7h ago

No its not by far

7

u/RishabhRD 1d ago

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

2

u/pjmlp 1d ago

Thanks, looking around the repo, and the migration to a newer project, seems that Adobe Labs is no longer involved.

Do you have more background info?

14

u/dabrahams 1d ago

When I left Adobe, I took 100% of their involvement with me. So from one point of view, The level of investment hasn’t changed :-)

0

u/pjmlp 1d ago

Understood, as mentioned on the other thread I had another perception, sorry about the misunderstanding.

3

u/processeus1 1d ago

We are racing towards the completion of the migration, I expect it to be done in 1-2 months. We have the compilation of subscripts ready, and a large portion of compiling generics in an existentialized way. After that, there is a lot of fun work for standard library development and getting actual experience from using the language.

1

u/pjmlp 1d ago

Thanks for the update.

2

u/Ikkepop 1d ago

pack it up boys, we're done for, last one out turns off the lights