$ dotnet new console -n HelloWorld
$ dotnet publish --project HelloWorld -r osx-arm64 --self-contained -o out -p:PublishTrimmed=true
$ du -sh out
10Mhttps://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h...
.NET 7 will work on NativeAOT for instantaneous startup of especially smaller apps, but I think they’ve already optimized JIT warmups or something — I was pleasantly surprised when I just wrote a .NET 6 console app that read JSON from a server.
One thing though, is that native .dlls are still outside (DetoursServices.dll for example in BuildXL). But still pretty impressive what it can done. That, and the new embedded .pdb (for .NET only, e.g. not native).
I wish "publish" was used more by the place I work for (most of the folks would simply Release (F5) and store what's there in p4). I've only recently discovered about "publish" and that is after haven't worked with .NET for so long...
I might be ignorant here but if you're not specifically pointing out what version DLL's you want, aren't you in fact publishing a dynamically linked executable instead of a statically linked one?
Doesn't these single-file apps rely on the GAC?
> .NET Core and .NET 5 and later versions eliminate the concept of the global assembly cache (GAC)
Also, to keep the size at least somewhat in check, unused parts of the base library are not included in the single-file mode.
(DLL hell stopped being a problem a lot sooner than you probably think, too...)
Does not match my experience at work unfortunately.
Sometimes the issue is that people have tended to conflate "dll hell" and "dependency hell." That's an old pet peeve of mine and I realize it doesn't matter...
Abort, Retry, Fail?
FFFFFFFUUUUUUUUCCCCCCKKKKK!!!!!!
You of course have to choose your target platform for this as it makes .exes for Windows, ELFs for Linux, etc.
If you want you can still choose to distribute IL DLLs and users then use their already installed dotnet on their machine to run them.
https://github.com/jart/cosmopolitan
(but, yeah, you probably want one version per target, even if hacks are cool)
I think the user interest was startup times of lambdas and containers. Therefore Linux was a priority.
I'm a novice at Golang, and I dislike much of the language, except that it's fast and can produce small binaries.
Exactly why I prefer Go to Java and C#.
It seems to me that F# could get a bit more love from HN-style nerds. Obviously, it's more similar to C# than Golang, but specifically error handling can be done in much nicer way using the Result type.
vlang[0] also seems like a nice golang "fork" that I'd be willing to spend time on.
I hope they succeed because it has/promises a really attractive set of features.
Also Java is OO which is... terrible to say the least.
In 2021, the AOT free beer exists, as do JIT caches.
As for OO model, I rather be able to understand which interfaces a type implements by looking at it, instead of producing compiler errors, or have a type by accident supporting a single method interface with complete different semantics.
Not sure what the OO rant is about, it's awesome. It's not like golang isn't (poorly implemented) OO as well (minus explicit inheritance, which embedding is somewhat similar as well).
This is a great! Now I can publish statically linked executables and run it everywhere. I don't have to tolerate Golang and its quirks just to have cross-compilation and static binaries, even though they will be larger in size.