Port React Compiler to Rust(github.com) |
Port React Compiler to Rust(github.com) |
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?
> 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'm not sad to see the pendulum swing away from "javascript everywhere" though.
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.
Haven't heard about since ages ago when it was extremely slow
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 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.
Not sure how they relate to each other.
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.
I think you actually meant "lower the barrier" (which would make it easier to pass the barrier, while lifting it makes it harder)?
Does that actually happen?
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.
Seems like they kind of did that? The thread seems like people already were waiting on this, so that's positive.
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.
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.
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?
> 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.
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.
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...
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.
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)
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.
The current developers surely are more familiar with the Babel representation than OXC, so why switch?
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)