A 10x Faster TypeScript • Hacker News Board

Re: A 10x Faster TypeScript

#941

Post by valcron1000 » Sat, Mar 15, 2025, 6:44 AM UTC

foobarbaz33 wrote: post #930

valcron1000 wrote: post #462

Earlier quoted context omitted.

Pretty much everything: > While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... Only Android is missing from that list (marked as "Experimental"). We could argue about maturity but this is a bit subjective. > Go also has somewhat better control over data layout How? C# supports structs, ref structs (s…

> C# supports structs, That's sort of the problem with C#. It couples the type (struct vs class) with allocation. C# started life by copying 1990's Java "everything-is-a-reference". So it's in a weird place where things were bolted on later to give more control but still needs to support the all-objects-are-refs style. C# is just not ergonomic if you need to care about data layout in memory. Go uses a C-like model. E…

> It couples the type (struct vs class) with allocation

Agree. Where things are allocated is a consumer decision.

> C# is just not ergonomic if you need to care about data layout in memory

I disagree. I work on a public high performance C# code and I don't usually face issues when dealing with memory allocations and data layout. You can perfectly use structs everywhere (value types) and pass references when needed (`ref`).

> Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area.

You can do this perfectly fine in C#, it might not be what some folks consider "idiomatic OOP" but I could not care less about them.

Re: A 10x Faster TypeScript

#942

Post by estebarb » Sat, Mar 15, 2025, 3:06 PM UTC

neonsunset wrote: post #940

estebarb wrote: post #939

Earlier quoted context omitted.

Sadly yes, we have data. We are migrating our C# SDK to Rust in part because customers want a much smaller dependency. And the AoT compiler didn't trimmed as much as we wanted.

(regarding size - there are tools like sizoscope to understand what is taking space, sometimes it’s something silly like rooting a lot of metadata with reflection referencing many assemblies or because of abusing generic virtual members with struct parameters in serialization, obviously if you can use Rust without productivity loss it’s fine, but usually problems like that take an hour or two to solve, or less) But i…

I think we would have preferred continuing with .NET, as no one is Rust expert on the team. But binary size and lack of some SIMD instructions moved the balance to Rust. And then, the PoC had big memory usage improvements, so...

Re: A 10x Faster TypeScript

#943

Post by neonsunset » Sat, Mar 15, 2025, 3:31 PM UTC

estebarb wrote: post #942

neonsunset wrote: post #940

Earlier quoted context omitted.

(regarding size - there are tools like sizoscope to understand what is taking space, sometimes it’s something silly like rooting a lot of metadata with reflection referencing many assemblies or because of abusing generic virtual members with struct parameters in serialization, obviously if you can use Rust without productivity loss it’s fine, but usually problems like that take an hour or two to solve, or less) But i…

I think we would have preferred continuing with .NET, as no one is Rust expert on the team. But binary size and lack of some SIMD instructions moved the balance to Rust. And then, the PoC had big memory usage improvements, so...

What kind of SIMD instructions were not available? I assume something like AVX512GFNI or SHA x86 intrinsics?

I think if you're in domain of using SIMD, besides base RAM usage of 2-5MB you should not see drastic difference unless you have a lot of allocation traffic. But I guess Rust solved most of this, just wanted to note that specific memory and deployment requirements are usually solvable by changing build and GC settings.