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.
> Coding language is just an implementation detail
Sure, but what machine model do the public contract docs and RFCs target ? While the specific coding language is a detail, programming languages target a precise machine model. There is no machine model for english prompts and spec docs. So expect fuzziness - he-said-she-said bugs in your code - things that the LLM made up because the RFCs were not precise. And by the time you add precision to the specs, it has morphed into a new programming language with a machine model. In this usecase, since it is a port, the impact is mitigated because it is a clone of some existing functionality.
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
That's obviously true. On the other hand its also true this is more likely to work because it is rust compared to python or js for example. And that's not only because of memory safety. It's because static typing gives an automatic proof of a certain level of correctness of the code. That correctness is correlated with correct business logic bugs. So it is valid argument to make.
Of course that doesn't mean that there are no businesses logic bugs.
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.
Part of the problem is that of human alienation. By excluding humans in the construction process, it has taken away any skin-in-the-game for humans. So, there could be a point where some bugs become unresolvable because LLMs dont have an adequate causal model and fixes by trial-and-error wont work in cases where root-causes are not properly addressed - and the project gets abandoned as a result. Witness the C compiler in rust [1], what happened to that after the initial press releases ?
This has been the case with IDEs as well. The most productive programmers have always delivered despite the tools they are forced to use not because of them. The less productive programs fail to learn because they are handheld by tooling.
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 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.
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.
Yes, languages from decades ago continue to support OOP. I don't know what your point is. As I said, the industry has moved on from the OOP-craze and so the languages that hamstring you into everything being OOP are not as interesting to people these days.
Go and Rust also do OOP, even if it isn't the Java OOP model everyone only knows about.
In fact both languages conveniently map to COM object model, and Microsoft is putting that to good effect.
Than we have Swift and Kotlin, plenty of OOP on those Apple and Google frameworks.
Zig, Odin, remain to be seen how industry relevant they will be, and yet examples of structs with function pointers abound among their projects, C OOP style.
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.
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.
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.
Sure but it certainly seems that way. There were already thousands and this PR adds a fair bit more too.
It is possible to have thousands of tests and a lot of blind spots, but it's easier to get a grip on that using instrumentation like code coverage and indeed by using LLMs to prod at edge cases.
I am OK with trusting that it is likely the React team understands how to rigorously test based on how well-tested React itself is.
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.
It depends... about the hardest part for me to keep track of in Rust is complex lifetimes... you can do things and organize in ways to reduce this cognitive overhead, but it may result in slightly less performant code.
The real boost to AI, is it can do a lot of things pretty easily, that you might not on your own... really thorough test suites, or even standing up a demo application just to test a single complex component. The latter I've done a few times now.
Rust itself seems to be very well supported by the coding models and is a pretty sane language to use. I cannot really comment on Go, as I've been using a lot more Rust as I have been targeting stand alone and wasm targets respectively, the latter really isn't a good structure for Go. I can say that C# is a really mixed bag, and would assume Java is similar.
Dynamic languages like python or JS might be faster to build, but they’re certainly not easier to maintain. The type system still exists, it just changes at runtime (JS) and exists purely in your head (both of them). The value of static analysis, like reading code, goes down significantly.
As codebases grow it only gets worse, as more of your mind is filled with building a mental model of the type system.
That’s why you end up seeing crazy defensive coding practices in these languages. In PHP, I often see isset and instanceof spammed everywhere because nobody can garauntee that thing X is actually X all the time.
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.
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.
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.
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.
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.
Just because something is written in Rust, doesn't mean it's good Rust.
I have noticed, in general, LLMs tend to "fix" problems by shoving them under the rug (like adding a cast) or writing a super-local "fix" instead of taking the time to understand the deeper problem or structure.
In Rust, when you get stuck in a complicated borrow-checking problem, Rust people will tell you it's a Good Thing(tm) because it forces you to think about the higher level architecture of your code. An LLM, on the other hand, might bash its head a couple of times trying to "fix" the problem, and then just throw in a Refcell (or other workaround), see that it compiles, and call it a day.
Refcells "move borrow checking to runtime", meaning that the code will compile, and will crash at runtime if the object is tried to be accessed from two different places at the same time. In most "normal" programming languages it's not an issue -- but it's a crash in Rust.
Now, maybe the models have gotten better, and maybe you can get around this problem by using a good system prompt/"tools" and a good testing methodology. What I am saying however is that you shouldn't automatically take "rewritten to Rust by AI" at face value of it being good Rust code, or a testimonial of "Rust and AI being a good match". (Go is better I think)
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.
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.
> 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.
> If you have undefined behavior in your code your bug might become a heisenbug
OR, the OS might kick in and throw a segmentation fault etc, often with some information associated to it.
Again, if a LLM can output 100% correct code, no bug of whatever kind should exist. Seeing a segfault could just invalidate that assumption completely and definitively. That's the point.
> Rust guarantees lack of undefined behavior in safe code
And that don't guarantee heisenbug-free, that just means your heisenbug was fully checked by Rust compiler and is now managed by the language runtime/facilities.
So, now instead of a crashed program and a "sever" DoS vulnerably, you got a disconnected user every time they trigger the bug. The user might assume it's the network, so does your logging stack. After a few times, the user starts bitching about your stupid network, and left for your competitor's product, while you busily trying to figure out why the network suddenly ain't as good as it used to.
> 70%[1][2] is tiny?
It really depends on how they define what counts as "vulnerably", or in Chrome's case, "'high severity' security bugs" which is very specific. Microsoft probably have many decades-old code written before the invention of better checkers, that contributed to the problem.
> Memory safety is just a tiny part of over all security
Sure, in the same way that foundations are just a tiny part of house construction.
Foundations come first, it's great if you've got more on top, I recommend it actually, but if you don't have the foundations it's not even worth having the discussion about what else you built, it's all worthless.
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.
Let's expand the actual quote we're responding to:
> the borrow checker woes can be offloaded to the model, you focus on all the other programming logic
Then the person you responded to asked if "you" really do "focus on all the other programming logic", given that "the model" deals with the borrow checker. In other words, they're asking about the work the actual human is doing at that point. You then replied talking about the model again and token budgets. In effect, you brushed the question under the rug and imply that _everything_ is offloaded to the model, no focus by the human required.
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.
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
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.
Apparently roughly ~150k math PhDs live on earth right now, assuming they all know Lean that's between 0.001% and 0.002% of earth population so quite closer to no one than one
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.
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 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?
The test suite gets you through the port. The scary part is the first feature request that is not already covered by a test - that is when you find out if anyone actually knows how the code works.
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.
A couple of months ago, I experimented with this - took tsgo and ported tsc to go with Claude. The main issue why this still didn't happen yet is because tsgo doesn't expose plugin API externally, but it's still there, so you can just co-locate your plugin as extra Go module and compile everything together. Managed to get my fairly large Angular app to compile and even run unit tests. Cold compile time went down about 2x - so the benefits are there, but not as dramatic. I think this would still need architecture level optimizations that enable build parallelization, but that also requires making some changes to framework API so components can be isolated-compiled or something.
This feels like a bad take, IMO. Starting with something that gets you up and running quickly, then transferring to something else when things are more settled is a pretty standard practice.
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.
> Coding language is just an implementation detail
Sure, but what machine model do the public contract docs and RFCs target ? While the specific coding language is a detail, programming languages target a precise machine model. There is no machine model for english prompts and spec docs. So expect fuzziness - he-said-she-said bugs in your code - things that the LLM made up because the RFCs were not precise. And by the time you add precision to the specs, it has morphed into a new programming language with a machine model. In this usecase, since it is a port, the impact is mitigated because it is a clone of some existing functionality.
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
That's obviously true. On the other hand its also true this is more likely to work because it is rust compared to python or js for example. And that's not only because of memory safety. It's because static typing gives an automatic proof of a certain level of correctness of the code. That correctness is correlated with correct business logic bugs. So it is valid argument to make.
Of course that doesn't mean that there are no businesses logic bugs.
only if it is not littered with unsafe blocks
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.
Part of the problem is that of human alienation. By excluding humans in the construction process, it has taken away any skin-in-the-game for humans. So, there could be a point where some bugs become unresolvable because LLMs dont have an adequate causal model and fixes by trial-and-error wont work in cases where root-causes are not properly addressed - and the project gets abandoned as a result. Witness the C compiler in rust [1], what happened to that after the initial press releases ?
[1] https://github.com/anthropics/claudes-c-compiler
This has been the case with IDEs as well. The most productive programmers have always delivered despite the tools they are forced to use not because of them. The less productive programs fail to learn because they are handheld by tooling.
It was def ai generated work. If anything, this is a good use of ai.
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.
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.
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.
AOT Java on Graal is quite mature at this point
AOT .NET is an official first party distribution target that in my experience is on par with building a Go binary
Don't knock it till you try it
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.
Yes, languages from decades ago continue to support OOP. I don't know what your point is. As I said, the industry has moved on from the OOP-craze and so the languages that hamstring you into everything being OOP are not as interesting to people these days.
I don't see what Python has to do with anything.
Go and Rust also do OOP, even if it isn't the Java OOP model everyone only knows about.
In fact both languages conveniently map to COM object model, and Microsoft is putting that to good effect.
Than we have Swift and Kotlin, plenty of OOP on those Apple and Google frameworks.
Zig, Odin, remain to be seen how industry relevant they will be, and yet examples of structs with function pointers abound among their projects, C OOP style.
So....
They are absolutely not OOP and if you want to say they are then I won't stop you but you're going to look very silly.
Ah, the silliness of computer science type theory research, what do they know with their silly Turing awards and SIGPLAN papers.
Usually only looked in high regard when the content supports the message, proudly ignored otherwise.
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.
Golang and rust should not be grouped into the same category though. The former is closer to Java/C#, and gets beaten by them in large systems.
> 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.
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.
Sure but it certainly seems that way. There were already thousands and this PR adds a fair bit more too.
It is possible to have thousands of tests and a lot of blind spots, but it's easier to get a grip on that using instrumentation like code coverage and indeed by using LLMs to prod at edge cases.
I am OK with trusting that it is likely the React team understands how to rigorously test based on how well-tested React itself is.
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.
It depends... about the hardest part for me to keep track of in Rust is complex lifetimes... you can do things and organize in ways to reduce this cognitive overhead, but it may result in slightly less performant code.
The real boost to AI, is it can do a lot of things pretty easily, that you might not on your own... really thorough test suites, or even standing up a demo application just to test a single complex component. The latter I've done a few times now.
Rust itself seems to be very well supported by the coding models and is a pretty sane language to use. I cannot really comment on Go, as I've been using a lot more Rust as I have been targeting stand alone and wasm targets respectively, the latter really isn't a good structure for Go. I can say that C# is a really mixed bag, and would assume Java is similar.
Dynamic languages like python or JS might be faster to build, but they’re certainly not easier to maintain. The type system still exists, it just changes at runtime (JS) and exists purely in your head (both of them). The value of static analysis, like reading code, goes down significantly.
As codebases grow it only gets worse, as more of your mind is filled with building a mental model of the type system.
That’s why you end up seeing crazy defensive coding practices in these languages. In PHP, I often see isset and instanceof spammed everywhere because nobody can garauntee that thing X is actually X all the time.
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.
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.
Very insightful, thanks. I just delved into it, starting here: https://react.dev/learn/react-compiler/introduction
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/...
I was thinking mainly cases like this
const nestedDependency = { a: { b: { c: 'c' } } }
useMemo(() => nestedDependency.a.b.c, [nestedDependency])
vs
useMemo(() => nestedDependency.a.b.c, [nestedDependency.a.b.c])
neither triggers react hook lint warnings, although I guess this is more relevant to useEffect than memoization.
If you’re interested in what a specific piece of code compiles to, it’s worth checking out the online compiler playground [1]
https://playground.react.dev/
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.
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.
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 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...
<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.
Just because something is written in Rust, doesn't mean it's good Rust.
I have noticed, in general, LLMs tend to "fix" problems by shoving them under the rug (like adding a cast) or writing a super-local "fix" instead of taking the time to understand the deeper problem or structure.
In Rust, when you get stuck in a complicated borrow-checking problem, Rust people will tell you it's a Good Thing(tm) because it forces you to think about the higher level architecture of your code. An LLM, on the other hand, might bash its head a couple of times trying to "fix" the problem, and then just throw in a Refcell (or other workaround), see that it compiles, and call it a day.
Refcells "move borrow checking to runtime", meaning that the code will compile, and will crash at runtime if the object is tried to be accessed from two different places at the same time. In most "normal" programming languages it's not an issue -- but it's a crash in Rust.
Now, maybe the models have gotten better, and maybe you can get around this problem by using a good system prompt/"tools" and a good testing methodology. What I am saying however is that you shouldn't automatically take "rewritten to Rust by AI" at face value of it being good Rust code, or a testimonial of "Rust and AI being a good match". (Go is better I think)
> 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.
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.
> 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.
> If you have undefined behavior in your code your bug might become a heisenbug
OR, the OS might kick in and throw a segmentation fault etc, often with some information associated to it.
Again, if a LLM can output 100% correct code, no bug of whatever kind should exist. Seeing a segfault could just invalidate that assumption completely and definitively. That's the point.
> Rust guarantees lack of undefined behavior in safe code
And that don't guarantee heisenbug-free, that just means your heisenbug was fully checked by Rust compiler and is now managed by the language runtime/facilities.
So, now instead of a crashed program and a "sever" DoS vulnerably, you got a disconnected user every time they trigger the bug. The user might assume it's the network, so does your logging stack. After a few times, the user starts bitching about your stupid network, and left for your competitor's product, while you busily trying to figure out why the network suddenly ain't as good as it used to.
> 70%[1][2] is tiny?
It really depends on how they define what counts as "vulnerably", or in Chrome's case, "'high severity' security bugs" which is very specific. Microsoft probably have many decades-old code written before the invention of better checkers, that contributed to the problem.
> Memory safety is just a tiny part of over all security
Sure, in the same way that foundations are just a tiny part of house construction.
Foundations come first, it's great if you've got more on top, I recommend it actually, but if you don't have the foundations it's not even worth having the discussion about what else you built, it's all worthless.
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.
Let's expand the actual quote we're responding to:
> the borrow checker woes can be offloaded to the model, you focus on all the other programming logic
Then the person you responded to asked if "you" really do "focus on all the other programming logic", given that "the model" deals with the borrow checker. In other words, they're asking about the work the actual human is doing at that point. You then replied talking about the model again and token budgets. In effect, you brushed the question under the rug and imply that _everything_ is offloaded to the model, no focus by the human required.
I think it's perfectly reasonable to provide an analog to substantiate an overall point.
> 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.
The day after, Microsoft announces the depreciation of the TS compilers as all programs get written in rust with IA from now on.
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
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.
Apparently roughly ~150k math PhDs live on earth right now, assuming they all know Lean that's between 0.001% and 0.002% of earth population so quite closer to no one than one
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.
I'm curious how reviews happen for such huge PRs (120k lines). Do reviewers sit and go through all these changes over days?
The reviews don't happen...
Trust and move forward?
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 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.
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?
The test suite gets you through the port. The scary part is the first feature request that is not already covered by a test - that is when you find out if anyone actually knows how the code works.
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.
And the great era of rewriting in Rust has begun (again).
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!
A couple of months ago, I experimented with this - took tsgo and ported tsc to go with Claude. The main issue why this still didn't happen yet is because tsgo doesn't expose plugin API externally, but it's still there, so you can just co-locate your plugin as extra Go module and compile everything together. Managed to get my fairly large Angular app to compile and even run unit tests. Cold compile time went down about 2x - so the benefits are there, but not as dramatic. I think this would still need architecture level optimizations that enable build parallelization, but that also requires making some changes to framework API so components can be isolated-compiled or something.
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
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.
This feels like a bad take, IMO. Starting with something that gets you up and running quickly, then transferring to something else when things are more settled is a pretty standard practice.