Port React Compiler to Rust

Posted by boudra 7 hours ago

Comments

Comment by arcadialeak 4 hours ago

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.

Comment by herrkanin 4 hours ago

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

Comment by arcadialeak 3 hours ago

Nevertheless, it's also React team that came up with prefixes like __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED in their codebase because people couldn't stop messing with the internals. So any documentation about the new compiler would be anything but rejected by the community.

Comment by dwb 4 hours ago

Implementation details matter! Especially when reviewing the implementation.

Comment by bwfan123 2 hours ago

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

Comment by xedrac 3 hours ago

While this is true, the fact that it is Rust provides a much greater level of confidence than if it was Python or something.

Comment by absintini 3 hours ago

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.

Comment by phillmv 2 hours ago

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

Comment by rowanG077 2 hours ago

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.

Comment by rvz 2 hours ago

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.

Comment by lioeters 2 hours ago

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.

Comment by bwfan123 1 hour ago

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

Comment by 2 hours ago

Comment by game_the0ry 1 hour ago

It was def ai generated work. If anything, this is a good use of ai.

Comment by molf 5 hours ago

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

Comment by IshKebab 4 hours ago

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

Comment by benjaminleonard 3 hours ago

I think there's a few Rust ones knocking around, some LLM-assisted. I've recently had Claude re-implement the inline parser (https://github.com/oxidecomputer/react-asciidoc) using our large corpus (600+) of AsciiDoc documents

Had it convert it in this and the stock version, compare the output, fix and repeat.

Comment by absintini 4 hours ago

[flagged]

Comment by pjmlp 4 hours ago

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 using on their heyday.

Comment by CamouflagedKiwi 4 hours ago

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.

Comment by pjmlp 4 hours ago

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.

Comment by insanitybit 4 hours ago

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.

Comment by gavinray 1 hour ago

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

Comment by pjmlp 3 hours ago

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.

Comment by insanitybit 2 hours ago

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.

Comment by pjmlp 45 minutes ago

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

Comment by CamouflagedKiwi 4 hours ago

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.

Comment by Aurornis 3 hours ago

> I love it starts with the usual hand waving,

> And then gets merged.

The initial commit attached to that message was the start of the experiment. Are you reading the first message as if it was the last?

It was merged after 3 months and a huge number of incremental commits. The code that was merged was completely different than the code used to open the experimental WIP PR

Why is it a criticism that they started as a work in progress experiment? That’s how experiments work. It’s normal to push code as a work in progress PR and then add to it over time.

Comment by 4 hours ago

Comment by jchw 4 hours ago

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.

Comment by JCTheDenthog 2 hours ago

>If this works and passes all of the tests

Only if the existing tests were actually useful in what they tested and covered.

Comment by jchw 2 hours ago

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.

Comment by olalonde 4 hours ago

Interesting how LLMs are possibly putting an end to the era where we were increasingly trading off machine performance for developer productivity.

Comment by gilgamesh-OG 3 hours ago

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 you can be assured the compiler is working properly; however, if new features need to be added, I'm not sure how easy it will be for them.

Comment by 2 hours ago

Comment by absintini 2 hours ago

Honestly it is a moot point. The benefit of languages like Python compare to Rust still hold. Algorithmic complexity rules the roost. For the hot path, write a C extension that is rigorously tested. Python you can iterate much faster same as any scripting language.

The AI can iterate faster in Python too, guaranteed, because you don’t have any compile time.

Also, this is how AIs already get stuff done: they write SCRIPTS to perform tasks in a sandbox with tool calls. This is the future, dynamic languages, not using static languages.

Comment by Surac 6 hours ago

<something> rewrite to rust using AI sound like meme now.

Comment by giancarlostoro 5 hours ago

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 back in 2008) it wasnt perfect but its nearly there now, mostly for fun, and I did it because for a little while I realized LLMs can be useful for more serious refactors, and figured it might be good for a language rewrite. Sure enough.

I think rewriting tooling that takes text and transforms it in a language like Rust is fine for JS projects, so is Go, which is why TypeScript is migrating to Go. The “free” optimized speed increases are worth it, at the temporary cost of dealing with the migration for a year or two, which with LLMs trims down the initial work into a week effort it seems? Wild.

Comment by bogdanoff_2 2 hours ago

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)

Comment by nirui 5 hours ago

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

Comment by tialaramex 25 minutes ago

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

Comment by insanitybit 4 hours ago

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

Comment by kouteiheika 4 hours ago

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

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.

Comment by norman784 4 hours ago

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

Comment by swiftcoder 4 hours ago

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

Comment by IshKebab 3 hours ago

> If a LLM can transcode correctly, then it should also output 100% correct C code.

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.

Comment by EddieRingle 3 hours ago

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

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.

Comment by fg137 5 hours ago

> you focus on all the other programming logic

Does that actually happen?

Comment by insanitybit 4 hours ago

For a model, yeah absolutely. You'll spend virtually 0 tokens on memory safety, which means your token budget gets allocated elsewhere. If you wrote a C codebase you'd need to allocate some portion of your budget towards memory safety.

Comment by EddieRingle 3 hours ago

They're not talking about the model, and they're not talking about token budgets.

Comment by insanitybit 3 hours ago

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.

Comment by EddieRingle 9 minutes ago

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.

Comment by 3 hours ago

Comment by rob74 5 hours ago

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

Comment by swiftcoder 4 hours ago

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)

Comment by cjbgkagh 2 hours ago

I think such barriers are usually considered permanent and must always be overcome. You get over a barrier. So it is more like a wall or hurdle. In the metaphors of difficulty it is assumed there will always be some residual difficulty so there will still be a barrier, but one that is easier to get over, so it is replaced with a lower one.

Comment by incognito124 5 hours ago

Lift the barrier as in remove it completely

Comment by pjmlp 4 hours ago

Not really, any Standard ML derived language would do.

Also I think this is all temporary, just like devs still did not believe on optimising compilers and checked each line of generated Assembly code, during the 1960's.

Eventually it will be natural language, and all languages will be kind of irrelevant.

Comment by lioeters 3 hours ago

Soon: Microsoft announces entire TypeScript language ported to Rust using LLM, with a 1M LoC merged after a week of intense vibe coding. And nobody would be surprised.

Comment by KolmogorovComp 2 hours ago

The day after, Microsoft announces the depreciation of the TS compilers as all programs get written in rust with IA from now on.

Comment by cindyllm 5 hours ago

[dead]

Comment by willsmith72 6 hours ago

Are people actually using the react compiler?

Haven't heard about since ages ago when it was extremely slow

Comment by molf 6 hours ago

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.

Comment by DanielHB 4 hours ago

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.

Comment by molf 4 hours ago

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

Comment by DanielHB 1 hour ago

I was thinking mainly cases like this

const nestedDependency = { a: { b: { c: 'c' } } }

useMemo(() => nestedDependency.a.b.c, [nestedDependency])

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.

Comment by molf 15 minutes ago

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/

Comment by _the_inflator 5 hours ago

Very insightful, thanks. I just delved into it, starting here: https://react.dev/learn/react-compiler/introduction

Comment by esperent 5 hours ago

I think the reason you haven't heard about it is that it just works. It's fast - with Vite 8 my moderately large app compiles in ~800ms, which includes typescript, react compiler etc.

I also took a step to clean out all memo, useMemo, useCallback across the app and so far have not run into any issues from doing this.

Comment by veidelis 4 hours ago

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.

Comment by paavohtl 6 hours ago

We have used React Compiler in production for a large ecom / media website for about a year. Performance has been fine overall, and we haven't ran into any major bugs attributable to it in that time.

Comment by Ambroos 4 hours ago

We started using it for unifi.ui.com and the render performance gain has been massive.

Comment by pjmlp 4 hours ago

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.

Comment by ameliaquining 4 hours ago

Next.js supports React Compiler: https://nextjs.org/docs/app/api-reference/config/next-config...

Comment by mohsen1 5 hours ago

Shameless plug. I'm writing a TypeScript checker in Rust. It's not a port. I made this with a different architecture that hopefully once is done will be proven to be a better set of trade-off

https://github.com/tsz-org/tsz

Comment by bingemaker 4 hours ago

I'm curious how reviews happen for such huge PRs (120k lines). Do reviewers sit and go through all these changes over days?

Comment by theappsecguy 4 hours ago

The reviews don't happen...

Comment by bingemaker 4 hours ago

Trust and move forward?

Comment by insanitybit 4 hours ago

If I had to guess, some humans skim things quickly for structural red flags, a bunch of LLMs do reviews based on various humans prompting to look for mistakes/ bugs, and then "tests pass == the code is good to merge".

Comment by ramon156 6 hours ago

I think it's fine to experiment, just communicate with your users and make sure its opt-in.

Seems like they kind of did that? The thread seems like people already were waiting on this, so that's positive.

Comment by odie5533 2 hours ago

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

Comment by dust-jacket 2 hours ago

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.

Comment by Trung0246 7 hours ago

Curious but can we use lean4 as port target instead of Rust?

Comment by jon-wood 6 hours ago

I'm sure its technically possible, you might need to provide a bit more context if you expect anyone to change course here and port it to a programming language approximately no one has heard of rather than Rust though. What makes you think that would be a good idea?

Comment by koito17 6 hours ago

> approximately no one has heard of

Just cause it isn't used for webshit doesn't mean "approximately no one" has heard of it.

Lean is pretty much the most popular language mathematicians use today for computer-assisted proofs. More mature audiences may know about Rocq, Isabelle, etc., but Lean was already popular enough for a few people I know to have written their PhD theses on it about a decade ago.

I think GP is joking about a port to Lean because that would at least produce a formally verifiable output.

Comment by HeavyStorm 6 hours ago

Oh, PhDs, you're right, that's not approximately no one... It's probably approximately one.

I like Lean (and more generally dependent types) but ffs Lean has a very, very small userbase for a project like this. GGP would have to really justifyv the benefits for such a switch.

Comment by 6 hours ago

Comment by bhy 6 hours ago

I don’t think lean4 compiled code is as efficient as rust. For verification purposes, there are some tools allowing formal verification of rust code.

Comment by giancarlostoro 5 hours ago

Never heard of it, and I nerd out on programming languages. Reminds me of a convo yesterday with my coworkers where I noted I never heard of Sheerpower a language someone who worked there had done, and I have heard of languages so old and niche most people are shocked.

My first programming interview my interviewer was like what the heck are you doing with D? And he noted he has a room full of devs where nobody knows what D is.

Comment by ryanshrott 2 hours ago

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.

Comment by bhouston 5 hours ago

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?

Comment by awesan 5 hours ago

How is using arenas complex? If anything it should make things simpler to understand to people who are not used to manual memory management.

Comment by pmarin 3 hours ago

The arena is replacing the javacript garbage collector not memory managament.

Comment by logicprog 5 hours ago

I thought arenas were one of the simplest and most easy to deal with and conceptualize memory management strategies around. Arguably easy, even easier to understand and just as easy to manage as GC. Did they do something special?

Comment by voidUpdate 6 hours ago

What is the react compiler written in currently?

Comment by LoganDark 6 hours ago

Uh, TypeScript?

Comment by iammrpayments 6 hours ago

I think they use something called “flow” last time I’ve checked, it’s like typescript but when I went to visit the website with more information it was so slow it crashed my browser.

Comment by __jonas 6 hours ago

Are you sure? The React compiler is a fairly new addition to React, Flow is Facebook's old alternative to Typescript, but Typescript won the ecosystem in terms of broad adoption in the end. I think Flow is barely used today, I would be really surprised if they choose it for a new tool, even for a Facebook project.

You may be thinking about React itself, not the new compiler? I'm sure there must be some flow in there still from back in the day.

Comment by LoganDark 6 hours ago

You may be right. I think Flow was a predecessor to TypeScript.

I just checked out Flow and woah. First-class syntax sugar for React. Maybe cool. (If it doesn't break catastrophically in a sane build system like Vite)

Comment by voidUpdate 6 hours ago

Isnt the benefit of rust that it's memory safe? Is typescript not?

Comment by bandrami 6 hours ago

I think the benefit of rust here is that it's not hosted whereas typescript is

Comment by LoganDark 6 hours ago

The benefit of Rust over TypeScript is that Rust is faster.

TypeScript is memory-safe, but you can't really control where the memory comes from. In Rust you have structs, traits, references and all sorts of things to control both your memory usage and your memory efficiency, and you just don't really get that in TypeScript. Plus, in Rust it's a lot easier to utilize multithreading -- JS is notoriously tedious to parallelize (message-passing between JS workers is a bit annoying compared to structured concurrency in Rust)

Comment by epolanski 5 hours ago

Quite sure performance and not memory safety is the issue here.

Comment by ai_slop_hater 2 hours ago

And the great era of rewriting in Rust has begun (again).

Comment by LoganDark 6 hours ago

Why are they porting the Babel-isms? They should be using Oxc tooling directly, not hanging onto JavaScript parsers, IMHO -- isn't the benefit of porting to Rust that you can use fast native code?

It seems backwards that they are freezing the Babel AST into the interoperability contract and only using the more efficient native representations in an isolated fashion -- shouldn't it be the other way around?

Comment by molf 6 hours ago

OXC is not the only consumer, so using the OXC AST wouldn't particularly make sense? I thought it was pretty well explained in the PR:

> Note that the conversion from any AST into our HIR is complex, and we can only maintain one version. Hence we've aligned on using a Babel-like AST as our public API. Another key point is that we don't yet implement our own scope analysis (since the TS version of the compiler relied on Babel's scope analysis), so for now we require that the scope data be serialized. It's a denormalized graph, and some metadata has to be stored to associate nodes with scopes. We're open to feedback about the AST and scope representation - we iterated a bit just to get things to work, but it can be more optimal.

Comment by LoganDark 6 hours ago

I saw, I just don't understand the rationale for picking Babel over OXC or something else as the interchange format -- other than "we were already doing it this way". After all, you know what they say about temporary solutions.

Comment by molf 6 hours ago

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?

Comment by LoganDark 6 hours ago

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 difficult path to get to where we want to be"). Maybe that's a fairly remote analogy but it feels similar.

Comment by swiftcoder 4 hours ago

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

Comment by AbuAssar 6 hours ago

now we need to port angular compiler to rust!

Comment by flufluflufluffy 5 hours ago

We should compile Firefox to wasm, and run Firefox inside Firefox so we can Rust while we Rust

Comment by swiftcoder 4 hours ago

I can hear Gary Bernhardt saying 'YavaScript'[1] in my mind

[1]: https://www.destroyallsoftware.com/talks/wat

Comment by AbuAssar 5 hours ago

Yo dawg I heard you like to rust

Comment by 5 hours ago