Hacker News Reader

Comment by wg0 | Hacker News Reader

Why would they write such a critical piece of software in C# or Java for that matter what requires a whole runtime + VM installed.

View on HN

You're behind the times:

> Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

While there are limitations, this is an active area of work for future versions of .NET.

This is the best case scenario and lots of stuff would be left out, you can't use all of the APIs as is noted in the documentation.

Garnet doesn’t use those however. A lot of older libraries that do runtime code emit or unbound reflection don’t work, but a lot of others do even though they were written more than 10 years ago and were adapted to netstandard2.0 target. Either way it does not benefit much from NativeAOT given it’s expected to be long-running where JIT is more advantageous.

You can still use a lot more APIs from AOT C# than from C/C++/Zig/Rust :)

I don't think this is an issue. You can bundle a stripped down runtime with C# binaries. If you want, you can even build it all into a single binary.

At this point C# little to nothing common with Java and builds a perfectly runnable binaries. C# is extremely capable and strong and arguably is one of the best dev platforms there is.

(On the other hand, call me an old fart, but my trust in Microsoft has been completely eroded in early millennium and did not came back.)

???

The JVM and the .NET clr are just runtime JIT engines. It’s not like they ship with a full O/S and a hypervisor.

VM is an overloaded term, it both means virtual computers that run some OS kernels, and runtime that runs some usually* user-space code.

* compare with eBPF

It is not about the hypervisor but a solution that pitches itself as a memory cache relies on GC is the main thing I am pointing out.

Rust would have been a better choice.

Why not?

And .NET can bundle the runtime, even in a single binary if you prefer that.

> Why not?

The bootstrapping path does not exist. There is (afaik) no way to go from C compiler to working dotnet environment. You are supposed to just download binary blobs from m$soft.

https://github.com/dotnet/dotnet exists for "complete" source build that stitches together SDK, Roslyn, runtime and other dependencies. In fact, it is required by certain Linux distributions for publishing in their feeds, to be built from source in full. All components above can be built and used individually (usually), which is what contributors also do. For example, you can clone and build https://github.com/dotnet/runtime and use the produced artifacts to execute .NET assemblies or build .NET binaries.

Thanks for the information. It seems to contain only versions 8 and 9, so I guess what I said was valid only for the previous ones.

The repository looks promising, however the build.sh trying to reach to the internet during the build is disappointing. I would expect that to not help with having reproducible results. I need to look into how distributions approach this.

Domains that require network-isolated builds usually maintain internal mirrors with corresponding dependencies. It is unreasonable to expect from a project of this size to have all tooling it depends on to be available within repository files (moreover, it should build on multiple ISAs and OSes). I doubt you can build LLVM this way or, let's say, OpenJDK.

Well for example golang builds offline just fine, which seems similar in scope? Runtime-based language targeting multiple architectures and operating systems.

Because C# is a nice language that can be fast and C++ is a shit language that can be fast.

And yet the benchmarks are better than C or C++ alternatives, somehow.

Reply on news.ycombinator.com