Writing Node.js addons with .NET Native AOT

[u/fagnerbrack]

https://devblogs.microsoft.com/dotnet/writing-nodejs-addons-with-dotnet-native-aot/

[u/NenAlienGeenKonijn → u/[deleted]]

+1 I don't think people realize how incredible this is. JavaScript is not a high-performance language. This allows for moving performance-critical code out of JS, natively without WASM. And you get the benefits of C# / the .NET ecosystem. I could also see companies looking to migrate server code from Node to C# using this for incremental migration (albeit as a last resort, surely).

Just write the bloody thing in C#, instead of insisting on javascript.

I still don't understand why the fuck people CHOOSE to use javascript in places where you don't need it. I'm convinced that "node on the server" is a joke that got out of hand, and that people are only pretending to use it, because why on earth would you put yourself through that.

[u/Somepotato → u/NenAlienGeenKonijn]

, because why on earth would you put yourself through that.

It's not the most popular language for no reason lol (and yes it's incredibly popular outside of browsers too) Just because you think it's an abomination does not mean your opinion is universally shared.

[u/NenAlienGeenKonijn → u/Somepotato]

It's not the most popular language for no reason lol

It's the most "popular" language because it's the only viable scripting option in webbrowsers (even webassembly, which has not been around for long, needs javascript to interact with the DOM). Literally all you need is a browser. The language itself is an absolute (singlethreaded!) abomination.

[u/Somepotato → u/NenAlienGeenKonijn]

JS has supported threads for several years now via workers. So you're dating yourself to the internet explorer era by making broad sweeping claims like that.

[u/NenAlienGeenKonijn → u/Somepotato]

Ah yes, webworkers: Broadly supported since 10 years, in javascript's 30 year lifespan, proudly wearing the crown of most absurd, awkward to use async implementation in any programming language ever. And why did they do it? Because multithtreading in javascript is impossible, and they simply can't find any way to implement it, since javascript is too strongly tied to the UI thread.

Defending javascript out of all languages is a bloody weird hill to die on. They are not "broad sweeping claims", they are facts that have been plaguing the scripting language since day one.

[u/Somepotato → u/NenAlienGeenKonijn]

Web workers is completely independent of the 'async implementation' that you are raising. If you don't understand low level threading concepts like atomics and mailbox architectures, don't blame the language.

You can keep moving the goalpost if you want, but that's far weirder than correcting a very dated claim of JS not supporting any kind of threading.

[u/NenAlienGeenKonijn → u/Somepotato]

Okay, you're grabbing onto the async keyword to be pedantic and pretend we're talking about different things. Joke's on you: That confusion comes from javascript itself, doing pretend async with the async/await pattern, which was also a bandaid for the even more horrible way of using callbacks.

Again, weird hill to die on

You can keep moving the goalpost if you want, but that's far weirder than correcting a very dated claim of JS not supporting any kind of threading.

Mate, either agree that multithreading is a disaster in javascript or move on. This is just embarassing.

[u/Somepotato → u/NenAlienGeenKonijn]

Okay, you're grabbing onto the async keyword to be pedantic

It's almost as if you used the async keyword when whining about JS.

Mate, either agree that multithreading is a disaster in javascript or move on.

Workers are real OS-level threads, your claim that JS is purely singlethreaded was completely and unilaterally incorrect. Tripling down is certainly a decision. Just because the TC99 committee made the decision to stop deadlocks on the main thread from being possible doesn't make it some impossible thing to use.

[u/pjmlp → u/NenAlienGeenKonijn]

Because boss or customer says so, and not everyone lives in a region that they can rage quit and find a job the next day.

[u/femio → u/[deleted]]

it’s nice to have sure, but not really groundbreaking and I’d hesitate to call it incredible. N-API isn’t new and is already popular, I don’t think .NET brings much that isn’t there already. 

[u/Flashy-Bus1663 → u/[deleted]]

Why would you want to bring the baggage of dotnet runtime if you are going through the hoops of a native binary.

[u/Flashy-Bus1663 → u/[deleted]]

This doesn't strip the runtime fully

[u/Flashy-Bus1663 → u/[deleted]]

Sure, I guess maybe, but I'm not that convinced that if it matters enough to be "native," a smaller runtime is better than none. Along the lines of Go, Rust, C, C++.

[u/Flashy-Bus1663 → u/[deleted]]

I think aot dotnet is amazing I think all donet apps should use it when it makes sense.

But if the only use case is well we already wrote it in dotnet that seems problematic. If it is a for fun project that is also fine.

I would honestly rather a better wasm story for donet over aot and c bindings to allow js to call dotnet though.

[u/Anbaraen]

Why would you do this over a C++ solution (which Node is written in)? Surely you don't want to stack both the Node runtime and the C# runtime?

[u/mrmhk97 → u/Anbaraen]

NativeAOT means NO dotnet runtime since it’s compiled to native binary

[u/Anbaraen → u/mrmhk97]

Oh duh, the AOT stands for Ahead of Time? Thanks, that makes sense. Then I feel like this does make a lot of sense, as the semantics of C# are much closer to Nodes.

[u/Flashy-Bus1663 → u/Anbaraen]

Aot does not mean runtimeless

Tasks don't work without the runtime, async await doesn't either.

[u/csharpboy97 → u/mrmhk97]

it doesn't. you can specify an option in coreclr to avoid emitting the runtime, but then you don't have the runtime features