Recent submissions

Comment · 1 year ago
Do you have data backing that up? Per https://github.com/MichalStrehovsky/sizegame:

C#: 945 kB Go: 2174 kB

Both are EXEs you just copy to the machine, no separate runtime needed, talks directly to the OS.

Comment · 2 years ago
Comment · 2 years ago
Comment · 2 years ago
Comment · 2 years ago
Comment · 2 years ago
Comment · 3 years ago
Comment · 3 years ago
I also like the less heavyweight approach where one can compose tools to do things. The existing .NET tooling is so entwined with MSBuild that one can't even (easily) invoke the C# compiler without an MSBuild project file.

Don't get me wrong, I like MSBuild and even bflat is built with MSBuild (wrote a custom target to invoke bflat from MSBuild), but sometimes I really just want to write a Makefile and be done with it instead of fiddling with MSBuild targets.

bflat integrates nicely with Make or other build systems - pass `-c` to generate object files (link it later with the commands bflat would use - use `-x` to see the commands), or use `bflat build-il` to create .NET assemblies and pass those as a reference (`-r`) to `bflat build` later.

Comment · 3 years ago
This is using Microsoft's standard libraries and compiler parts. All of .NET is MIT licensed so this kind of remixing is super easy.
Comment · 3 years ago
ZeroSharp is done by the same person as bflat (me). These ZeroSharp samples get broken all the time because they bend the MSBuild targets that ship with .NET to an extreme. Bflat is a more supportable route and has a couple extra customizations to the compiler specifically for these scenarios.
Comment · 3 years ago
The crosscompilation on Go to mac is pretty limited. That's why I wrote "need to reach dependencies beyond what libc offers". If you crosscompile Go from Linux to mac, you'll actually get a different binary than if you compile on mac natively (DNS resolution will use Go's home baked version instead of the one provided by the OS). CGo also doesn't work if you crosscompile.

It's a bunch of work to even get a hobbled version of crosscompilation to macOS running.

Comment · 3 years ago
TL;DR: It's work.

The way exceptions are done in .NET is by keeping track of extra metadata to be able to unwind methods (remove them from the execution stack) and execute handlers. That way the overhead of exception handling is close to zero if no exception is ever thrown. This requires quite a bit of infrastructure.

Propagating exceptions as error codes would come with execution time costs even if no exception is thrown and would have to be written from scratch (since .NET doesn't do it this way).

Either approach requires more investment than I'd want to put into it right now.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton