Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Port React Compiler to Rust

github.com

Post reply on HN
Print view View original

51–60 of 128 posts

Re: Port React Compiler to Rust

#51

Post by pjmlp »

CamouflagedKiwi wrote: post #49
pjmlp wrote: post #46

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 u…

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.

Re: Port React Compiler to Rust

#52

Post by norman784 »

nirui wrote: post #40
giancarlostoro wrote: post #27

Earlier quoted context omitted.

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 b…

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

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

Re: Port React Compiler to Rust

#53

Post by insanitybit »

nirui wrote: post #40
giancarlostoro wrote: post #27

Earlier quoted context omitted.

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 b…

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

Re: Port React Compiler to Rust

#54

Post by swiftcoder »

nirui wrote: post #40
giancarlostoro wrote: post #27

Earlier quoted context omitted.

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 b…

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

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

Re: Port React Compiler to Rust

#55

Post by DanielHB »

molf wrote: post #16
willsmith72 wrote: post #4

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.

Re: Port React Compiler to Rust

#56

Post by swiftcoder »

rob74 wrote: post #36
giancarlostoro wrote: post #27

Earlier quoted context omitted.

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 b…

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

Re: Port React Compiler to Rust

#57

Post by absintini »

molf wrote: post #33

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

[flagged]

Re: Port React Compiler to Rust

#58

Post by arcadialeak »

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.

Re: Port React Compiler to Rust

#59

Post by jchw »

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.

Post reply on HN