71–80 of 128 posts
I'm curious how reviews happen for such huge PRs (120k lines). Do reviewers sit and go through all these changes over days?
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…
And yes, both languages are considered "not cool" since they lean heavily into code structuring that the industry has largely moved past.
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…
> you focus on all the other programming logic Does that actually happen?
Are people actually using the react compiler? Haven't heard about since ages ago when it was extremely slow
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.
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.
Earlier quoted context omitted.
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.
- 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/...
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.
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.
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.
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 b…
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.
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.