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

111–120 of 128 posts

Re: Port React Compiler to Rust

#111

Post by bwfan123 »

lioeters wrote: post #97
rvz wrote: post #94

Earlier quoted context omitted.

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

Re: Port React Compiler to Rust

#112

Post by gavinray »

insanitybit wrote: post #72
pjmlp wrote: post #51

Earlier quoted context omitted.

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…

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

Re: Port React Compiler to Rust

#113

Post by pjmlp »

insanitybit wrote: post #108
pjmlp wrote: post #88

Earlier quoted context omitted.

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

Re: Port React Compiler to Rust

#114

Post by tialaramex »

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

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.

Re: Port React Compiler to Rust

#115

Post by molf »

DanielHB wrote: post #110
molf wrote: post #76

Earlier quoted context omitted.

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

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/

Re: Port React Compiler to Rust

#116

Post by EddieRingle »

insanitybit wrote: post #84
EddieRingle wrote: post #81

Earlier quoted context omitted.

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.

Re: Port React Compiler to Rust

#117

Post by preg_match »

gilgamesh-OG wrote: post #85
olalonde wrote: post #60

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

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.

Re: Port React Compiler to Rust

#118

Post by [deleted] »

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

[deleted]

Re: Port React Compiler to Rust

#119

Post by tracker1 »

gilgamesh-OG wrote: post #85
olalonde wrote: post #60

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

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.

Re: Port React Compiler to Rust

#120

Post by insanitybit »

EddieRingle wrote: post #116
insanitybit wrote: post #84

Earlier quoted context omitted.

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…

I think it's perfectly reasonable to provide an analog to substantiate an overall point.
Post reply on HN