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

121–128 of 128 posts

Re: Port React Compiler to Rust

#121

Post by insanitybit »

pjmlp wrote: post #113
insanitybit wrote: post #108

Earlier quoted context omitted.

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

They are absolutely not OOP and if you want to say they are then I won't stop you but you're going to look very silly.

Re: Port React Compiler to Rust

#122

Post by xdavidliu »

xedrac wrote: post #89
herrkanin wrote: post #70

Earlier quoted context omitted.

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

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

only if it is not littered with unsafe blocks

Re: Port React Compiler to Rust

#123

Post by jcelerier »

HeavyStorm wrote: post #12
koito17 wrote: post #7

Earlier quoted context omitted.

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

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.

Apparently roughly ~150k math PhDs live on earth right now, assuming they all know Lean that's between 0.001% and 0.002% of earth population so quite closer to no one than one

Re: Port React Compiler to Rust

#124

Post by za3faran »

CamouflagedKiwi wrote: post #64
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…

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

Golang and rust should not be grouped into the same category though. The former is closer to Java/C#, and gets beaten by them in large systems.

Re: Port React Compiler to Rust

#125

Post by pjmlp »

insanitybit wrote: post #121
pjmlp wrote: post #113

Earlier quoted context omitted.

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

They are absolutely not OOP and if you want to say they are then I won't stop you but you're going to look very silly.

Ah, the silliness of computer science type theory research, what do they know with their silly Turing awards and SIGPLAN papers.

Usually only looked in high regard when the content supports the message, proudly ignored otherwise.

Re: Port React Compiler to Rust

#126

Post by Klaster_1 »

AbuAssar wrote: post #17

now we need to port angular compiler to rust!

A couple of months ago, I experimented with this - took tsgo and ported tsc to go with Claude. The main issue why this still didn't happen yet is because tsgo doesn't expose plugin API externally, but it's still there, so you can just co-locate your plugin as extra Go module and compile everything together. Managed to get my fairly large Angular app to compile and even run unit tests. Cold compile time went down about 2x - so the benefits are there, but not as dramatic. I think this would still need architecture level optimizations that enable build parallelization, but that also requires making some changes to framework API so components can be isolated-compiled or something.

Re: Port React Compiler to Rust

#127

Post by nirui »

kouteiheika wrote: post #67
nirui wrote: post #40

Earlier quoted context omitted.

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

> If you have undefined behavior in your code your bug might become a heisenbug

OR, the OS might kick in and throw a segmentation fault etc, often with some information associated to it.

Again, if a LLM can output 100% correct code, no bug of whatever kind should exist. Seeing a segfault could just invalidate that assumption completely and definitively. That's the point.

> Rust guarantees lack of undefined behavior in safe code

And that don't guarantee heisenbug-free, that just means your heisenbug was fully checked by Rust compiler and is now managed by the language runtime/facilities.

So, now instead of a crashed program and a "sever" DoS vulnerably, you got a disconnected user every time they trigger the bug. The user might assume it's the network, so does your logging stack. After a few times, the user starts bitching about your stupid network, and left for your competitor's product, while you busily trying to figure out why the network suddenly ain't as good as it used to.

> 70%[1][2] is tiny?

It really depends on how they define what counts as "vulnerably", or in Chrome's case, "'high severity' security bugs" which is very specific. Microsoft probably have many decades-old code written before the invention of better checkers, that contributed to the problem.

Re: Port React Compiler to Rust

#128

Post by casey2 »

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.

This has been the case with IDEs as well. The most productive programmers have always delivered despite the tools they are forced to use not because of them. The less productive programs fail to learn because they are handheld by tooling.
Post reply on HN