It's quite frightening to see how an enormous 120KLOC pull request gets merged at once with very little public discussion or coverage by the devs after just 3 months (which IMO is very little time in relation to the amount of code). There used to be extensive RFCs and series of conference talks long preceding changes this big, e.g. React Fiber.
I support wholeheartedly the move to AOT-compiled languages but it looks like paying off the cognitive debt is going to be brutal on whichever team gets to maintain it in the long run.
Nevertheless, it's also React team that came up with prefixes like __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED in their codebase because people couldn't stop messing with the internals. So any documentation about the new compiler would be anything but rejected by the community.
i feel like ppl have magical beliefs about type systems. just because it's _probably_ (did it use unsafe?) memory-safe doesn't mean it does what you want it to do
Seems like all the "best practices" that were preached from these engineers for years are just disregarded and thrown out of the window with this reckless use of LLMs on high profile project.
Just creating permanent cognitive debt for everyone else with no-one else understanding what the code is doing.
The cognitive debt is by design. Now everyone must use an LLM to maintain the codebase, because it's beyond any single human's capacity for understanding.
After bun [1] this is another high-profile project that was ported to Rust by extensively using LLMs.
Very curious to see how these rewrites play out. Is the LLM foundation solid enough to build upon and iterate on? Or does this cause projects to become unmaintainable because no person understands the implementation anymore?
I think there's a few Rust ones knocking around, some LLM-assisted. I've recently had Claude re-implement the inline parser (https://github.com/oxidecomputer/react-asciidoc) using our large corpus (600+) of AsciiDoc documents
Had it convert it in this and the stock version, compare the output, fix and repeat.
This is a great point, previously the tradeoff was build in python in 2 weeks versus 2 months and even if your app performance is worse you built it faster and maintain it more easily. Now I am wondering, for all the devs who do not have experience in Rust, can they still maintain the code when the usage limits get hit? Since there is an automated test suite and easily verifiable results, this is a good area where you can be assured the compiler is working properly; however, if new features need to be added, I'm not sure how easy it will be for them.
Honestly it is a moot point. The benefit of languages like Python compare to Rust still hold. Algorithmic complexity rules the roost. For the hot path, write a C extension that is rigorously tested. Python you can iterate much faster same as any scripting language.
The AI can iterate faster in Python too, guaranteed, because you don’t have any compile time.
Also, this is how AIs already get stuff done: they write SCRIPTS to perform tasks in a sandbox with tool calls. This is the future, dynamic languages, not using static languages.
If this works and passes all of the tests, then it seems like a done deal to me. LLMs are just too good at doing ports where they have a rigorous automated test suite or oracle to compare against. They're oddly bad at following instructions like "port this mechanically, exactly" - worse than a human for sure - but they seem to do a great job of sitting there and comparing results to find bugs for hours and hours. It's hard for me to imagine a world where they aren't used to assist ports, not just writing them but especially refining them.
I suspect this won't have as big of a shit storm as the Bun port in part just due to the input/output nature of the React compiler.
That said, while I use React still, I still have never tried the React compiler... So I have no idea how important this is. But you know, very few people are ever upset over faster iteration cycles or CI builds.
> This is an experimental, work-in-progress port of React Compiler to Rust. ...
And then gets merged.
So after the craziness to use node on the backend, we are back to using compiled languages to compile Javascript assets and Web resources, just like Java and .NET were doing in the 2000's, however since it is Go and Rust it is cool, not the boring languages grandpas were using on their heyday.
The initial commit attached to that message was the start of the experiment. Are you reading the first message as if it was the last?
It was merged after 3 months and a huge number of incremental commits. The code that was merged was completely different than the code used to open the experimental WIP PR
Why is it a criticism that they started as a work in progress experiment? That’s how experiments work. It’s normal to push code as a work in progress PR and then add to it over time.
TBF there is an advantage to having a tool like this being a native binary in Rust or Go, which are rather smaller, faster to start up and don't need a runtime like the JVM or .NET. It's also a lot more "web native" than Java applets were.
I'm not sad to see the pendulum swing away from "javascript everywhere" though.
Java has had native code compilers at very least since Excelsior JET exists, and there is a whole story of commercial offerings, before GraalVM and OpenJ9 come to be, so a moot point in 2026.
Likewise, .NET has had NGEN since day one even if with limitations, and after several detours in AOT approaches, NativeAOT is in the package and cross platform, thus also a moot point in 2026.
I think you miss my point a bit. It's not about what can be done with those ecosystems in 2026 - you mentioned what was done in the 2000's, and I'm suggesting one reason that wasn't perceived as "cool" is because of the whole VM / overhead requirement. Maybe technologies for that existed then, but they certainly weren't being used much - every experience I remember with Java back then was "download this jar, now go and get yourself a JVM to run it".
And I do still think there is an advantage for this kind of tooling to choose languages that are designed to compile to a native binary. At best Java and C# are equivalent to Go and Rust here, maybe they are less "cool" but I don't see any reason why this rewrite would be better if it were to Java than Rust.
Shameless plug. I'm writing a TypeScript checker in Rust. It's not a port. I made this with a different architecture that hopefully once is done will be proven to be a better set of trade-off
Speaks volumes to the strengths of the language, also speaks volumes that LLMs lift the barrier of entry for Rust programming, the borrow checker woes can be offloaded to the model, you focus on all the other programming logic.
Whats funny is I had been using Rust more with Claude because of this, and before Anthropic did their rewrite of Bun I tried a Rust rewrite of a C# project I had laying around (.NET 3.5 from back in 2008) it wasnt perfect but its nearly there now, mostly for fun, and I did it because for a little while I realized LLMs can be useful for more serious refactors, and figured it might be good for a language rewrite. Sure enough.
I think rewriting tooling that takes text and transforms it in a language like Rust is fine for JS projects, so is Go, which is why TypeScript is migrating to Go. The “free” optimized speed increases are worth it, at the temporary cost of dealing with the migration for a year or two, which with LLMs trims down the initial work into a week effort it seems? Wild.
Memory safety is just a tiny part of over all security. If a LLM can transcode correctly, then it should also output 100% correct C code.
On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.
> On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.
Isn't it the other way around? Rust guarantees lack of undefined behavior in safe code. If you have undefined behavior in your code your bug might become a heisenbug, or make the rest of your program behave weird, or the bug might simply be dormant until a very specific situation occurs (i.e. be "soundless" as you say).
If you're going to automatically translate your code from one language to another then a memory-safe target language (whether it's Rust, Java, C# or something else) is the only sane, reasonable choice. And if you want C or C++-like performance (i.e. you want to maximize performance) then you're pretty much left with Rust on the table.
> Memory safety is just a tiny part of over all security.
No, it's a pretty massive part with disproportionate severity.
> If a LLM can transcode correctly, then it should also output 100% correct C code.
Translating code seems to largely rely on having a strong suite of existing tests, not on ability to code correctly.
It's unclear if LLMs are great at writing safe C code, it's much clearer that they can meet targets with external feedback properties like "test passes/fails".
> On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.
But current LLMs have a context window limitation, so you can't fit your whole source code into the context, that's why compilers guide the LLMs when they are producing code and that's where Rust compiler shines, it has very good diagnostics that help fix the issues with a few iterations.
So while LLMs are good at writing walls of code, they do not produce good code, just good enough and sometimes it is wrong (here is where Rust can help a bit by checking that the program is sound, but for the most part you should also validate the logic).
The dream language for LLMs would be one that has some kind of proving that function inputs/outputs are what you expect (I think it's called proof theory, but it's not my area of expertise, so I could be wrong), you kind of can emulate this with new types[0].
> If a LLM can transcode correctly, then it should also output 100% correct C code
An LLM can't (currently) transcode correctly in a vacuum. It needs tight guardrails to keep it on the straight-and-narrow (such as an existing conformance test suite that is extremely comprehensive).
The value of transcoding to Rust specifically is that the compiler gives you a pretty substantial set of guardrails "for free" - in a C port, your conformance test suite would also need to test every aspect of memory safety and fearless concurrency...
> If a LLM can transcode correctly, then it should also output 100% correct C code.
Well LLM's cannot transcode perfectly correctly, so the fact that Rust has lots of static checking is really important. Not just for memory safety - Rust helps with many other classes of bugs too.
> then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.
I think what you're saying here is that LLM's often cheat to solve the immediate error, e.g. by using `unsafe` where you really shouldn't, or just making a test not test anything. That's definitely possible.
> Speaks volumes to the strengths of the language, also speaks volumes that LLMs lift the barrier of entry for Rust programming, the borrow checker woes can be offloaded to the model, you focus on all the other programming logic.
I get the opposite impression. If they aren't confident enough to write it by hand, I think it means the language is either hard to write, hard to read, or both. And by delegating to a LLM, there's no "barrier of entry" being lifted, it's just saving you typing time (like it would if it was being translated to C or Kotlin). If they actually decide to "focus on all the other programming logic" and they aren't just vibe coding this, they'll still need to be able to understand and reason about the code.
For a model, yeah absolutely. You'll spend virtually 0 tokens on memory safety, which means your token budget gets allocated elsewhere. If you wrote a C codebase you'd need to allocate some portion of your budget towards memory safety.
This depends whether you have one of those barriers made of bollards that raise out of the ground (expensive, hard to retrofit on an existing parking structure), or the kind where an arm lowers across the road (cheap, trivial to retrofit)
I think such barriers are usually considered permanent and must always be overcome. You get over a barrier. So it is more like a wall or hurdle. In the metaphors of difficulty it is assumed there will always be some residual difficulty so there will still be a barrier, but one that is easier to get over, so it is replaced with a lower one.
Not really, any Standard ML derived language would do.
Also I think this is all temporary, just like devs still did not believe on optimising compilers and checked each line of generated Assembly code, during the 1960's.
Eventually it will be natural language, and all languages will be kind of irrelevant.
Soon: Microsoft announces entire TypeScript language ported to Rust using LLM, with a 1M LoC merged after a week of intense vibe coding. And nobody would be surprised.
It's brilliant: all useMemo and useCallback can be removed and you get the same runtime performance and then some, at the cost of only a slight increase in code size.
A small downside at the moment is the build time. This change will hopefully help address that because it will no longer depend on babel.
I haven't tried the compiler yet, but I been very skeptical of the automatic memoization features. Both in that sometimes the default strategy to decide when to memoize is not good enough but also the hidden flow to trigger the memoization causing hard to spot performance regressions.
I would be interest to hear how it worked out for you.
It really does work very well in practice. A few things really help:
- Lints [1] that flag code that cannot be (correctly) optimised. Usually this is obscure code that is too smart for its own good. But the compiler leaves it alone and flags it for review, so most things just keep working.
- Lints that flag code that violate the rules of hooks. These rules became more critical to follow: failure to do so may break rendering. But non-compliant code can be easily be excluded from compilation [2], so you do not have to fix everything at once.
- Popular libraries that are not compatible (yet) are flagged and excluded automatically [3].
The compiler is better than manual memoization, because 1) it is hard not to forget memoizations, and 2) the compiler's output memoizes more granularly than manual memoization realistically could.
I have not found performance regressions. Not saying they're not possible; but we haven't encountered them.
We have a very performance-sensitive project that used preact (chosen for performance) via its compatibility layer, that we switched to React + React compiler. Performance is noticeably better than with preact. Whereas previously the React-only version was incredibly slow even with carefully placed memoizations, because they were very hard to get right.
I think the reason you haven't heard about it is that it just works. It's fast - with Vite 8 my moderately large app compiles in ~800ms, which includes typescript, react compiler etc.
I also took a step to clean out all memo, useMemo, useCallback across the app and so far have not run into any issues from doing this.
My company tried it but reverted the changes. The biggest reasons - it's not compatible with mobx and we didn't notice any perf gains on an existing codebase.
We have used React Compiler in production for a large ecom / media website for about a year. Performance has been fine overall, and we haven't ran into any major bugs attributable to it in that time.
If I had to guess, some humans skim things quickly for structural red flags, a bunch of LLMs do reviews based on various humans prompting to look for mistakes/ bugs, and then "tests pass == the code is good to merge".
I'm sure its technically possible, you might need to provide a bit more context if you expect anyone to change course here and port it to a programming language approximately no one has heard of rather than Rust though. What makes you think that would be a good idea?
Just cause it isn't used for webshit doesn't mean "approximately no one" has heard of it.
Lean is pretty much the most popular language mathematicians use today for computer-assisted proofs. More mature audiences may know about Rocq, Isabelle, etc., but Lean was already popular enough for a few people I know to have written their PhD theses on it about a decade ago.
I think GP is joking about a port to Lean because that would at least produce a formally verifiable output.
Oh, PhDs, you're right, that's not approximately no one... It's probably approximately one.
I like Lean (and more generally dependent types) but ffs Lean has a very, very small userbase for a project like this. GGP would have to really justifyv the benefits for such a switch.
Never heard of it, and I nerd out on programming languages. Reminds me of a convo yesterday with my coworkers where I noted I never heard of Sheerpower a language someone who worked there had done, and I have heard of languages so old and niche most people are shocked.
My first programming interview my interviewer was like what the heck are you doing with D? And he noted he has a room full of devs where nobody knows what D is.
I thought arenas were one of the simplest and most easy to deal with and conceptualize memory management strategies around. Arguably easy, even easier to understand and just as easy to manage as GC. Did they do something special?
I think they use something called “flow” last time I’ve checked, it’s like typescript but when I went to visit the website with more information it was so slow it crashed my browser.
Are you sure? The React compiler is a fairly new addition to React, Flow is Facebook's old alternative to Typescript, but Typescript won the ecosystem in terms of broad adoption in the end. I think Flow is barely used today, I would be really surprised if they choose it for a new tool, even for a Facebook project.
You may be thinking about React itself, not the new compiler? I'm sure there must be some flow in there still from back in the day.
You may be right. I think Flow was a predecessor to TypeScript.
I just checked out Flow and woah. First-class syntax sugar for React. Maybe cool. (If it doesn't break catastrophically in a sane build system like Vite)
The benefit of Rust over TypeScript is that Rust is faster.
TypeScript is memory-safe, but you can't really control where the memory comes from. In Rust you have structs, traits, references and all sorts of things to control both your memory usage and your memory efficiency, and you just don't really get that in TypeScript. Plus, in Rust it's a lot easier to utilize multithreading -- JS is notoriously tedious to parallelize (message-passing between JS workers is a bit annoying compared to structured concurrency in Rust)
Why are they porting the Babel-isms? They should be using Oxc tooling directly, not hanging onto JavaScript parsers, IMHO -- isn't the benefit of porting to Rust that you can use fast native code?
It seems backwards that they are freezing the Babel AST into the interoperability contract and only using the more efficient native representations in an isolated fashion -- shouldn't it be the other way around?
OXC is not the only consumer, so using the OXC AST wouldn't particularly make sense? I thought it was pretty well explained in the PR:
> Note that the conversion from any AST into our HIR is complex, and we can only maintain one version. Hence we've aligned on using a Babel-like AST as our public API. Another key point is that we don't yet implement our own scope analysis (since the TS version of the compiler relied on Babel's scope analysis), so for now we require that the scope data be serialized. It's a denormalized graph, and some metadata has to be stored to associate nodes with scopes. We're open to feedback about the AST and scope representation - we iterated a bit just to get things to work, but it can be more optimal.
I saw, I just don't understand the rationale for picking Babel over OXC or something else as the interchange format -- other than "we were already doing it this way". After all, you know what they say about temporary solutions.
What I mean is, if you're going to rewrite it in Rust, why rewrite Babel rather than leaning on the existing ecosystem? I know they're not actually rewriting Babel, just reusing the semantic layout of its AST, but it's feeling a bit like the MediaWiki parser situation to me (roughly "if we started from scratch today, we wouldn't choose to have it this way, but we started a different way before, and it's been a difficult path to get to where we want to be"). Maybe that's a fairly remote analogy but it feels similar.
> if we started from scratch today, we wouldn't choose to have it this way, but we started a different way before, and it's been a difficult path to get to where we want to be"
This is just how software development for a large public project goes. If you want to land big changes in a finite amount of time, you take the path that breaks the least number of things along the way.
Once the whole ecosystem is rust-based, they can always trim out some of the redundant intermediate representations for performance gains.
It's quite frightening to see how an enormous 120KLOC pull request gets merged at once with very little public discussion or coverage by the devs after just 3 months (which IMO is very little time in relation to the amount of code). There used to be extensive RFCs and series of conference talks long preceding changes this big, e.g. React Fiber.
I support wholeheartedly the move to AOT-compiled languages but it looks like paying off the cognitive debt is going to be brutal on whichever team gets to maintain it in the long run.
The public contract previously discussed in RFCs and conference talks hasn't changed. Coding language is just an implementation detail.
Nevertheless, it's also React team that came up with prefixes like __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED in their codebase because people couldn't stop messing with the internals. So any documentation about the new compiler would be anything but rejected by the community.
Implementation details matter! Especially when reviewing the implementation.
While this is true, the fact that it is Rust provides a much greater level of confidence than if it was Python or something.
Confidence about what? That it works properly? Hopefully? Why don’t you read the 120k lines of code and tell us all how it works.
i feel like ppl have magical beliefs about type systems. just because it's _probably_ (did it use unsafe?) memory-safe doesn't mean it does what you want it to do
Seems like all the "best practices" that were preached from these engineers for years are just disregarded and thrown out of the window with this reckless use of LLMs on high profile project.
Just creating permanent cognitive debt for everyone else with no-one else understanding what the code is doing.
The cognitive debt is by design. Now everyone must use an LLM to maintain the codebase, because it's beyond any single human's capacity for understanding.
After bun [1] this is another high-profile project that was ported to Rust by extensively using LLMs.
Very curious to see how these rewrites play out. Is the LLM foundation solid enough to build upon and iterate on? Or does this cause projects to become unmaintainable because no person understands the implementation anymore?
[1]: https://news.ycombinator.com/item?id=48132488
I'd love to see Asciidoctor vibe-ported to Rust! Have either of these people detailed their methodology & costs?
I think there's a few Rust ones knocking around, some LLM-assisted. I've recently had Claude re-implement the inline parser (https://github.com/oxidecomputer/react-asciidoc) using our large corpus (600+) of AsciiDoc documents
Had it convert it in this and the stock version, compare the output, fix and repeat.
Interesting how LLMs are possibly putting an end to the era where we were increasingly trading off machine performance for developer productivity.
This is a great point, previously the tradeoff was build in python in 2 weeks versus 2 months and even if your app performance is worse you built it faster and maintain it more easily. Now I am wondering, for all the devs who do not have experience in Rust, can they still maintain the code when the usage limits get hit? Since there is an automated test suite and easily verifiable results, this is a good area where you can be assured the compiler is working properly; however, if new features need to be added, I'm not sure how easy it will be for them.
Honestly it is a moot point. The benefit of languages like Python compare to Rust still hold. Algorithmic complexity rules the roost. For the hot path, write a C extension that is rigorously tested. Python you can iterate much faster same as any scripting language.
The AI can iterate faster in Python too, guaranteed, because you don’t have any compile time.
Also, this is how AIs already get stuff done: they write SCRIPTS to perform tasks in a sandbox with tool calls. This is the future, dynamic languages, not using static languages.
If this works and passes all of the tests, then it seems like a done deal to me. LLMs are just too good at doing ports where they have a rigorous automated test suite or oracle to compare against. They're oddly bad at following instructions like "port this mechanically, exactly" - worse than a human for sure - but they seem to do a great job of sitting there and comparing results to find bugs for hours and hours. It's hard for me to imagine a world where they aren't used to assist ports, not just writing them but especially refining them.
I suspect this won't have as big of a shit storm as the Bun port in part just due to the input/output nature of the React compiler.
That said, while I use React still, I still have never tried the React compiler... So I have no idea how important this is. But you know, very few people are ever upset over faster iteration cycles or CI builds.
>If this works and passes all of the tests
Only if the existing tests were actually useful in what they tested and covered.
I love it starts with the usual hand waving,
> This is an experimental, work-in-progress port of React Compiler to Rust. ...
And then gets merged.
So after the craziness to use node on the backend, we are back to using compiled languages to compile Javascript assets and Web resources, just like Java and .NET were doing in the 2000's, however since it is Go and Rust it is cool, not the boring languages grandpas were using on their heyday.
> I love it starts with the usual hand waving,
> And then gets merged.
The initial commit attached to that message was the start of the experiment. Are you reading the first message as if it was the last?
It was merged after 3 months and a huge number of incremental commits. The code that was merged was completely different than the code used to open the experimental WIP PR
Why is it a criticism that they started as a work in progress experiment? That’s how experiments work. It’s normal to push code as a work in progress PR and then add to it over time.
TBF there is an advantage to having a tool like this being a native binary in Rust or Go, which are rather smaller, faster to start up and don't need a runtime like the JVM or .NET. It's also a lot more "web native" than Java applets were.
I'm not sad to see the pendulum swing away from "javascript everywhere" though.
Java has had native code compilers at very least since Excelsior JET exists, and there is a whole story of commercial offerings, before GraalVM and OpenJ9 come to be, so a moot point in 2026.
Likewise, .NET has had NGEN since day one even if with limitations, and after several detours in AOT approaches, NativeAOT is in the package and cross platform, thus also a moot point in 2026.
But again, they aren't cool for the kids today.
The point isn't "AOT", the point is an efficient, compiled binary. Acting like Java's AOT story is comparable to a native Rust binary is delusional.
And yes, both languages are considered "not cool" since they lean heavily into code structuring that the industry has largely moved past.
If you mean OOP, it is pretty much present in the industry, including the very cool AI darling, the Python language, to its very bones.
I think you miss my point a bit. It's not about what can be done with those ecosystems in 2026 - you mentioned what was done in the 2000's, and I'm suggesting one reason that wasn't perceived as "cool" is because of the whole VM / overhead requirement. Maybe technologies for that existed then, but they certainly weren't being used much - every experience I remember with Java back then was "download this jar, now go and get yourself a JVM to run it".
And I do still think there is an advantage for this kind of tooling to choose languages that are designed to compile to a native binary. At best Java and C# are equivalent to Go and Rust here, maybe they are less "cool" but I don't see any reason why this rewrite would be better if it were to Java than Rust.
Shameless plug. I'm writing a TypeScript checker in Rust. It's not a port. I made this with a different architecture that hopefully once is done will be proven to be a better set of trade-off
https://github.com/tsz-org/tsz
<something> rewrite to rust using AI sound like meme now.
Speaks volumes to the strengths of the language, also speaks volumes that LLMs lift the barrier of entry for Rust programming, the borrow checker woes can be offloaded to the model, you focus on all the other programming logic.
Whats funny is I had been using Rust more with Claude because of this, and before Anthropic did their rewrite of Bun I tried a Rust rewrite of a C# project I had laying around (.NET 3.5 from back in 2008) it wasnt perfect but its nearly there now, mostly for fun, and I did it because for a little while I realized LLMs can be useful for more serious refactors, and figured it might be good for a language rewrite. Sure enough.
I think rewriting tooling that takes text and transforms it in a language like Rust is fine for JS projects, so is Go, which is why TypeScript is migrating to Go. The “free” optimized speed increases are worth it, at the temporary cost of dealing with the migration for a year or two, which with LLMs trims down the initial work into a week effort it seems? Wild.
> Speaks volumes to the strengths of the language
Memory safety is just a tiny part of over all security. If a LLM can transcode correctly, then it should also output 100% correct C code.
On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.
> Memory safety is just a tiny part of over all security.
70%[1][2] is tiny?
[1]: https://www.zdnet.com/article/microsoft-70-percent-of-all-se... [2]: https://www.chromium.org/Home/chromium-security/memory-safet...
> On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.
Isn't it the other way around? Rust guarantees lack of undefined behavior in safe code. If you have undefined behavior in your code your bug might become a heisenbug, or make the rest of your program behave weird, or the bug might simply be dormant until a very specific situation occurs (i.e. be "soundless" as you say).
If you're going to automatically translate your code from one language to another then a memory-safe target language (whether it's Rust, Java, C# or something else) is the only sane, reasonable choice. And if you want C or C++-like performance (i.e. you want to maximize performance) then you're pretty much left with Rust on the table.
> Memory safety is just a tiny part of over all security.
No, it's a pretty massive part with disproportionate severity.
> If a LLM can transcode correctly, then it should also output 100% correct C code.
Translating code seems to largely rely on having a strong suite of existing tests, not on ability to code correctly.
It's unclear if LLMs are great at writing safe C code, it's much clearer that they can meet targets with external feedback properties like "test passes/fails".
> On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.
This is very unclear to me.
But current LLMs have a context window limitation, so you can't fit your whole source code into the context, that's why compilers guide the LLMs when they are producing code and that's where Rust compiler shines, it has very good diagnostics that help fix the issues with a few iterations.
So while LLMs are good at writing walls of code, they do not produce good code, just good enough and sometimes it is wrong (here is where Rust can help a bit by checking that the program is sound, but for the most part you should also validate the logic).
The dream language for LLMs would be one that has some kind of proving that function inputs/outputs are what you expect (I think it's called proof theory, but it's not my area of expertise, so I could be wrong), you kind of can emulate this with new types[0].
[0] https://doc.rust-lang.org/rust-by-example/generics/new_types...
> If a LLM can transcode correctly, then it should also output 100% correct C code
An LLM can't (currently) transcode correctly in a vacuum. It needs tight guardrails to keep it on the straight-and-narrow (such as an existing conformance test suite that is extremely comprehensive).
The value of transcoding to Rust specifically is that the compiler gives you a pretty substantial set of guardrails "for free" - in a C port, your conformance test suite would also need to test every aspect of memory safety and fearless concurrency...
> If a LLM can transcode correctly, then it should also output 100% correct C code.
Well LLM's cannot transcode perfectly correctly, so the fact that Rust has lots of static checking is really important. Not just for memory safety - Rust helps with many other classes of bugs too.
> then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.
I think what you're saying here is that LLM's often cheat to solve the immediate error, e.g. by using `unsafe` where you really shouldn't, or just making a test not test anything. That's definitely possible.
> Speaks volumes to the strengths of the language, also speaks volumes that LLMs lift the barrier of entry for Rust programming, the borrow checker woes can be offloaded to the model, you focus on all the other programming logic.
I get the opposite impression. If they aren't confident enough to write it by hand, I think it means the language is either hard to write, hard to read, or both. And by delegating to a LLM, there's no "barrier of entry" being lifted, it's just saving you typing time (like it would if it was being translated to C or Kotlin). If they actually decide to "focus on all the other programming logic" and they aren't just vibe coding this, they'll still need to be able to understand and reason about the code.
> you focus on all the other programming logic
Does that actually happen?
For a model, yeah absolutely. You'll spend virtually 0 tokens on memory safety, which means your token budget gets allocated elsewhere. If you wrote a C codebase you'd need to allocate some portion of your budget towards memory safety.
They're not talking about the model, and they're not talking about token budgets.
This entire topic is about models, the grandparent post is about models augmenting human work, and my post is about models. I think it's fine.
> LLMs lift the barrier of entry for Rust programming
I think you actually meant "lower the barrier" (which would make it easier to pass the barrier, while lifting it makes it harder)?
This depends whether you have one of those barriers made of bollards that raise out of the ground (expensive, hard to retrofit on an existing parking structure), or the kind where an arm lowers across the road (cheap, trivial to retrofit)
I think such barriers are usually considered permanent and must always be overcome. You get over a barrier. So it is more like a wall or hurdle. In the metaphors of difficulty it is assumed there will always be some residual difficulty so there will still be a barrier, but one that is easier to get over, so it is replaced with a lower one.
Lift the barrier as in remove it completely
Not really, any Standard ML derived language would do.
Also I think this is all temporary, just like devs still did not believe on optimising compilers and checked each line of generated Assembly code, during the 1960's.
Eventually it will be natural language, and all languages will be kind of irrelevant.
Soon: Microsoft announces entire TypeScript language ported to Rust using LLM, with a 1M LoC merged after a week of intense vibe coding. And nobody would be surprised.
Are people actually using the react compiler?
Haven't heard about since ages ago when it was extremely slow
Yes absolutely.
It's brilliant: all useMemo and useCallback can be removed and you get the same runtime performance and then some, at the cost of only a slight increase in code size.
A small downside at the moment is the build time. This change will hopefully help address that because it will no longer depend on babel.
I haven't tried the compiler yet, but I been very skeptical of the automatic memoization features. Both in that sometimes the default strategy to decide when to memoize is not good enough but also the hidden flow to trigger the memoization causing hard to spot performance regressions.
I would be interest to hear how it worked out for you.
It really does work very well in practice. A few things really help:
- Lints [1] that flag code that cannot be (correctly) optimised. Usually this is obscure code that is too smart for its own good. But the compiler leaves it alone and flags it for review, so most things just keep working.
- Lints that flag code that violate the rules of hooks. These rules became more critical to follow: failure to do so may break rendering. But non-compliant code can be easily be excluded from compilation [2], so you do not have to fix everything at once.
- Popular libraries that are not compatible (yet) are flagged and excluded automatically [3].
The compiler is better than manual memoization, because 1) it is hard not to forget memoizations, and 2) the compiler's output memoizes more granularly than manual memoization realistically could.
I have not found performance regressions. Not saying they're not possible; but we haven't encountered them.
We have a very performance-sensitive project that used preact (chosen for performance) via its compatibility layer, that we switched to React + React compiler. Performance is noticeably better than with preact. Whereas previously the React-only version was incredibly slow even with carefully placed memoizations, because they were very hard to get right.
[1]: https://react.dev/learn/react-compiler/installation#eslint-i...
[2]: https://react.dev/learn/react-compiler/incremental-adoption
[3]: https://react.dev/reference/eslint-plugin-react-hooks/lints/...
Very insightful, thanks. I just delved into it, starting here: https://react.dev/learn/react-compiler/introduction
I think the reason you haven't heard about it is that it just works. It's fast - with Vite 8 my moderately large app compiles in ~800ms, which includes typescript, react compiler etc.
I also took a step to clean out all memo, useMemo, useCallback across the app and so far have not run into any issues from doing this.
My company tried it but reverted the changes. The biggest reasons - it's not compatible with mobx and we didn't notice any perf gains on an existing codebase.
We have used React Compiler in production for a large ecom / media website for about a year. Performance has been fine overall, and we haven't ran into any major bugs attributable to it in that time.
We started using it for unifi.ui.com and the render performance gain has been massive.
Yes, and no. For some of us, there are projects with Next.js we cannot get away from, but those use Vercel stuff, also written in Rust.
Not sure how they relate to each other.
Next.js supports React Compiler: https://nextjs.org/docs/app/api-reference/config/next-config...
These ports make me question the creators a little. They chose the wrong language to begin with, and then used an LLM to try to fix their mistake.
I'm curious how reviews happen for such huge PRs (120k lines). Do reviewers sit and go through all these changes over days?
If I had to guess, some humans skim things quickly for structural red flags, a bunch of LLMs do reviews based on various humans prompting to look for mistakes/ bugs, and then "tests pass == the code is good to merge".
The reviews don't happen...
Trust and move forward?
I think it's fine to experiment, just communicate with your users and make sure its opt-in.
Seems like they kind of did that? The thread seems like people already were waiting on this, so that's positive.
And the great era of rewriting in Rust has begun (again).
Curious but can we use lean4 as port target instead of Rust?
I'm sure its technically possible, you might need to provide a bit more context if you expect anyone to change course here and port it to a programming language approximately no one has heard of rather than Rust though. What makes you think that would be a good idea?
> approximately no one has heard of
Just cause it isn't used for webshit doesn't mean "approximately no one" has heard of it.
Lean is pretty much the most popular language mathematicians use today for computer-assisted proofs. More mature audiences may know about Rocq, Isabelle, etc., but Lean was already popular enough for a few people I know to have written their PhD theses on it about a decade ago.
I think GP is joking about a port to Lean because that would at least produce a formally verifiable output.
Oh, PhDs, you're right, that's not approximately no one... It's probably approximately one.
I like Lean (and more generally dependent types) but ffs Lean has a very, very small userbase for a project like this. GGP would have to really justifyv the benefits for such a switch.
I don’t think lean4 compiled code is as efficient as rust. For verification purposes, there are some tools allowing formal verification of rust code.
Never heard of it, and I nerd out on programming languages. Reminds me of a convo yesterday with my coworkers where I noted I never heard of Sheerpower a language someone who worked there had done, and I have heard of languages so old and niche most people are shocked.
My first programming interview my interviewer was like what the heck are you doing with D? And he noted he has a room full of devs where nobody knows what D is.
So the port makes sense logically but how easy it is to contribute new features to it? Does the complex memory model (arena) impose complexity?
How is using arenas complex? If anything it should make things simpler to understand to people who are not used to manual memory management.
The arena is replacing the javacript garbage collector not memory managament.
I thought arenas were one of the simplest and most easy to deal with and conceptualize memory management strategies around. Arguably easy, even easier to understand and just as easy to manage as GC. Did they do something special?
What is the react compiler written in currently?
Uh, TypeScript?
I think they use something called “flow” last time I’ve checked, it’s like typescript but when I went to visit the website with more information it was so slow it crashed my browser.
Are you sure? The React compiler is a fairly new addition to React, Flow is Facebook's old alternative to Typescript, but Typescript won the ecosystem in terms of broad adoption in the end. I think Flow is barely used today, I would be really surprised if they choose it for a new tool, even for a Facebook project.
You may be thinking about React itself, not the new compiler? I'm sure there must be some flow in there still from back in the day.
You may be right. I think Flow was a predecessor to TypeScript.
I just checked out Flow and woah. First-class syntax sugar for React. Maybe cool. (If it doesn't break catastrophically in a sane build system like Vite)
Isnt the benefit of rust that it's memory safe? Is typescript not?
I think the benefit of rust here is that it's not hosted whereas typescript is
The benefit of Rust over TypeScript is that Rust is faster.
TypeScript is memory-safe, but you can't really control where the memory comes from. In Rust you have structs, traits, references and all sorts of things to control both your memory usage and your memory efficiency, and you just don't really get that in TypeScript. Plus, in Rust it's a lot easier to utilize multithreading -- JS is notoriously tedious to parallelize (message-passing between JS workers is a bit annoying compared to structured concurrency in Rust)
Quite sure performance and not memory safety is the issue here.
Why are they porting the Babel-isms? They should be using Oxc tooling directly, not hanging onto JavaScript parsers, IMHO -- isn't the benefit of porting to Rust that you can use fast native code?
It seems backwards that they are freezing the Babel AST into the interoperability contract and only using the more efficient native representations in an isolated fashion -- shouldn't it be the other way around?
OXC is not the only consumer, so using the OXC AST wouldn't particularly make sense? I thought it was pretty well explained in the PR:
> Note that the conversion from any AST into our HIR is complex, and we can only maintain one version. Hence we've aligned on using a Babel-like AST as our public API. Another key point is that we don't yet implement our own scope analysis (since the TS version of the compiler relied on Babel's scope analysis), so for now we require that the scope data be serialized. It's a denormalized graph, and some metadata has to be stored to associate nodes with scopes. We're open to feedback about the AST and scope representation - we iterated a bit just to get things to work, but it can be more optimal.
I saw, I just don't understand the rationale for picking Babel over OXC or something else as the interchange format -- other than "we were already doing it this way". After all, you know what they say about temporary solutions.
So isn't not changing more sensible than changing to an arbitrary alternative?
The current developers surely are more familiar with the Babel representation than OXC, so why switch?
What I mean is, if you're going to rewrite it in Rust, why rewrite Babel rather than leaning on the existing ecosystem? I know they're not actually rewriting Babel, just reusing the semantic layout of its AST, but it's feeling a bit like the MediaWiki parser situation to me (roughly "if we started from scratch today, we wouldn't choose to have it this way, but we started a different way before, and it's been a difficult path to get to where we want to be"). Maybe that's a fairly remote analogy but it feels similar.
> if we started from scratch today, we wouldn't choose to have it this way, but we started a different way before, and it's been a difficult path to get to where we want to be"
This is just how software development for a large public project goes. If you want to land big changes in a finite amount of time, you take the path that breaks the least number of things along the way.
Once the whole ecosystem is rust-based, they can always trim out some of the redundant intermediate representations for performance gains.
now we need to port angular compiler to rust!
We should compile Firefox to wasm, and run Firefox inside Firefox so we can Rust while we Rust
I can hear Gary Bernhardt saying 'YavaScript'[1] in my mind
[1]: https://www.destroyallsoftware.com/talks/wat
Yo dawg I heard you like to rust