The test suite gets you through the port. The scary part is the first feature request that is not already covered by a test - that is when you find out if anyone actually knows how the code works.
Port React Compiler to Rust
101–110 of 128 posts
Re: Port React Compiler to Rust
#102rewrite 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…
Just because something is written in Rust, doesn't mean it's good Rust.
I have noticed, in general, LLMs tend to "fix" problems by shoving them under the rug (like adding a cast) or writing a super-local "fix" instead of taking the time to understand the deeper problem or structure.
In Rust, when you get stuck in a complicated borrow-checking problem, Rust people will tell you it's a Good Thing(tm) because it forces you to think about the higher level architecture of your code. An LLM, on the other hand, might bash its head a couple of times trying to "fix" the problem, and then just throw in a Refcell (or other workaround), see that it compiles, and call it a day.
Refcells "move borrow checking to runtime", meaning that the code will compile, and will crash at runtime if the object is tried to be accessed from two different places at the same time. In most "normal" programming languages it's not an issue -- but it's a crash in Rust.
Now, maybe the models have gotten better, and maybe you can get around this problem by using a good system prompt/"tools" and a good testing methodology. What I am saying however is that you shouldn't automatically take "rewritten to Rust by AI" at face value of it being good Rust code, or a testimonial of "Rust and AI being a good match". (Go is better I think)
Re: Port React Compiler to Rust
#103If 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'…
>If this works and passes all of the tests Only if the existing tests were actually useful in what they tested and covered.
Sure but it certainly seems that way. There were already thousands and this PR adds a fair bit more too.
It is possible to have thousands of tests and a lot of blind spots, but it's easier to get a grip on that using instrumentation like code coverage and indeed by using LLMs to prod at edge cases.
I am OK with trusting that it is likely the React team understands how to rigorously test based on how well-tested React itself is.
Re: Port React Compiler to Rust
#104Earlier 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.
[deleted]
Re: Port React Compiler to Rust
#105Earlier quoted context omitted.
Confidence about what? That it works properly? Hopefully? Why don’t you read the 120k lines of code and tell us all how it works.
i feel like ppl have magical beliefs about type systems. just because it's _probably_ (did it use unsafe?) memory-safe doesn't mean it does what you want it to do
That's obviously true. On the other hand its also true this is more likely to work because it is rust compared to python or js for example. And that's not only because of memory safety. It's because static typing gives an automatic proof of a certain level of correctness of the code. That correctness is correlated with correct business logic bugs. So it is valid argument to make.
Of course that doesn't mean that there are no businesses logic bugs.
Re: Port React Compiler to Rust
#106It'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.
> Coding language is just an implementation detail
Sure, but what machine model do the public contract docs and RFCs target ? While the specific coding language is a detail, programming languages target a precise machine model. There is no machine model for english prompts and spec docs. So expect fuzziness - he-said-she-said bugs in your code - things that the LLM made up because the RFCs were not precise. And by the time you add precision to the specs, it has morphed into a new programming language with a machine model. In this usecase, since it is a port, the impact is mitigated because it is a clone of some existing functionality.
Re: Port React Compiler to Rust
#107These ports make me question the creators a little. They chose the wrong language to begin with, and then used an LLM to try to fix their mistake.
This feels like a bad take, IMO. Starting with something that gets you up and running quickly, then transferring to something else when things are more settled is a pretty standard practice.
Re: Port React Compiler to Rust
#108Earlier quoted context omitted.
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.
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.
Re: Port React Compiler to Rust
#109It'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…
It was def ai generated work. If anything, this is a good use of ai.
Re: Port React Compiler to Rust
#110Earlier quoted context omitted.
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.
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.