Live data from Hacker News

Port React Compiler to Rust

github.com

61–70 of 128 posts

Re: Port React Compiler to Rust

#63
post #22

Earlier quoted context omitted.

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

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

Re: Port React Compiler to Rust

#64
post #51

Earlier quoted context omitted.

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…

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.

Re: Port React Compiler to Rust

#65

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

Re: Port React Compiler to Rust

#66
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

I'd love to see Asciidoctor vibe-ported to Rust! Have either of these people detailed their methodology & costs?

Re: Port React Compiler to Rust

#67
post #40

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.

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.

Re: Port React Compiler to Rust

#68

Are people actually using the react compiler? Haven't heard about since ages ago when it was extremely slow

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.

Re: Port React Compiler to Rust

#70

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…

The public contract previously discussed in RFCs and conference talks hasn't changed. Coding language is just an implementation detail.
Post reply on HN