It appears they're using a unique memory model (https://github.com/oxc-project/tsrs/blob/main/docs/PORTING.m...) to overcome the challenge that prevented the TypeScript team from choosing Rust to begin with: Rust has no GC and porting from a GC language to it often requires restructure of data.

Essentially, they fake a GC via never-freed arenas for long-living objects. It's interesting that Rust can do that (hopefully soundly)!

▲

zamalek 6 hours ago | parent | next [-]

From the file:

>Create with P::new(value). p.get() returns &'static T. [...] unless an explicit recycling site proves them dead

It's unsound, the LLM/human is doing the proving. They've hidden unsafe in an abstraction without removing the unsafeness. Using the arena allocator's lifetime would have been safe and easy (bumpalo recommends this AFAIK).

I'm guessing a sycophantic LLM either found or praised this load-bearing seam.

Never deallocating would have been sound (missile memory management: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98... ).

▲

tengbretson 4 hours ago | parent | next [-]

> Never deallocating would have been sound (missile memory management: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98... ).

Calling this a breakthrough in memory management is an understatement. Call up the Turing Award committee. We just discovered a solution to the halting problem! Turns out that for certain applications the answer is unequivocally "yes"

	▲	solyin 8 minutes ago \| parent [-]
		We've have found an engineering solution to some of the cases for the halting problem, yes. It's still not solved science problem though. Science isn't engineering though.

▲

afdbcreid 6 hours ago | parent | prev | next [-]

With sanitizers (https://github.com/oxc-project/tsrs/blob/main/notes/mem-recy...). We're back to C I guess. I hate this project now.

▲

lioeters 5 hours ago | parent | prev [-]

> load-bearing seam

Zing!

▲

jcmontx 6 hours ago | parent | prev [-]

Wouldn't that eat the whole ram?

	▲	panzi 4 hours ago \| parent [-]
		Compilers often just build up more and more data structures in memory until the end when they then release everything more or less at once. With an arena you can then just throw away the whole arena at the end, assuming there are no resource handles that need to be closed in drop(). A long time ago I read an article about someone speeding up a C++ compiler that is itself written in C++ (was it g++? maybe clang?). They simply patched out delete so it did nothing. The compiler used marginally more memory but ran much faster, since releasing all the small objects one by one is just useless work at the end of the compilation. A GCed language has a similar behavior and could therefore be fast in that case. It just builds up all the objects and then when the program exists it doesn't have to GC them all, it just throws away the whole process memory. So I can imagine one could "optimize" a compiler written in a GCed language by deactivating the GC.