MStrehovsky

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.

Is AOT compiling your binaries [1] an option for you? The starting size of AOT compiled C# can beat Go in size [2] and from there it really depends on what you do and how you do it. Some simple ASP.NET server with https and routing can comfortably fit under 10 MB and there are compilation options that can help optimize further [3].

[1] https://learn.microsoft.com/dotnet/core/deploying/native-aot... [2] https://github.com/MichalStrehovsky/sizegame?tab=readme-ov-f... [3] https://learn.microsoft.com/dotnet/core/deploying/native-aot...

> Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted.

The tooling already generates warnings for any spot in the program that uses reflection _in a way that cannot be statically analyzed_. Fixing code to make it work with trimming is equivalent to fixing warnings. Here are a couple case studies: https://devblogs.microsoft.com/dotnet/creating-aot-compatibl...

Someone with an iPhone told me the webm video embedded in the article still doesn't work on iPhones in 2024 so here's another link to the video: https://twitter.com/MStrehovsky/status/1742101904250060842

It's a webm, looks like Apple still didn't implement it on iPhones. Here is another version of the video on a website that may work better on iPhones: https://twitter.com/MStrehovsky/status/1742101904250060842

The repo does mention the Pi. I just forgot to talk about the Pi specifically in the article, sorry. https://github.com/MichalStrehovsky/uefimaze

Here's an example [1] of a device driver in C#. It is possible. It is also not recommended.

[1] https://github.com/VollRagm/KernelSharp

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.

This is using Microsoft's standard libraries and compiler parts. All of .NET is MIT licensed so this kind of remixing is super easy.

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.

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.

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.

I want bflat to be able to crosscompile from anything to anything.

Apple's platforms are difficult to crosscompile for - most instructions I've seen that need to reach dependencies beyond what libc offers require one to copy files from an Xcode installation and pray one didn't break EULAs. I don't even know where to start if I want to build from Linux or Windows to target macOS without a mac.

Then there's a philosophical issue that I have where Apple essentially would like everyone to pay up if they want to distribute software that targets their platforms (required code signing, etc.), and breaking backwards compat all the time (essentially treating developers like a resource to be exploited). This practice needs to go away. I know bflat not being available for macOS won't change that, but we need to start somewhere...

Some executable file formats have time stamps in them.

bflat follows the platform convention that respects this and writes current date/time in the file header by default.

It is also a platform convention to offer options to set these to something stable (e.g. `/Brepro` on lld-link, or `--deterministic` for bflat) if one wants stable output.

dflat could imply it has something do to with dlang.

bflat triggers a lot of engagement on Twitter and elsewhere because everyone wants to correct it. Couldn't have chosen a better name.

bflat author here - happy to answer questions.

I think at this point https://flattened.net/ is a better introduction to bflat than the repo. The repo also links to it, but wanted to highlight it.

> 212kB

Here's a 11 kB bootable x86-64 version of the game written in C# https://github.com/kant2002/SeeSharpSnake/tree/kant/uefi#run....

There's an accompanying article with a video at the bottom https://codevision.medium.com/running-c-snake-inside-uefi-df....

(Author here, I hang out on HN.)

Yup. There's really not much extra code in bflat compared to what's in the dotnet/runtimelab repo (in the NativeAOT branch). This just packages things differently so that one doesn't need the .NET SDK (plus Windows SDK if targeting Windows). The 100 MB bflat ZIP is all that's needed to target Windows or Linux.

Pass the multiple files to `bflat build`. Or if you run `bflat build` without arguments, it will compile all *.cs files in the current directory. Not great, but works for now.

As a C# dev I'm sometimes envious of the experience that Go devs have around building small selfcontained executables. Type a few lines into a .go file, `go build` the file and you have an executable that you can give to anyone and it runs (be it Ubuntu/Alpine/whatever). Yeah, with the default deployment model of C# it's nice that you don't have to worry about security vulnerabilities in your networking stack being unpatched until you rebuild your app (the networking stack is part of a runtime or other libraries that can be serviced independently from the app), but also not everything you build with C# is an internet-facing web server... and not everyone wants to carry a 20 MB runtime with a prerequisite list with their app.

.NET made huge progress since .NET Core (Linux support, single executable support, etc.) and I think it's getting where I would like to see it, but I decided to "help it" a little with a different take on the tooling. It's a prototype.

I took the experimental .NET AOT compiler (from Microsoft's NativeAOT project), mixed it with Roslyn (the official C# compiler) and built a standalone compiler/tool. I took out everything that people usually associate with C# (MSBuild, NuGet, the `dotnet` CLI) and left just the bare minimum: language and libraries.

  $ echo 'System.Console.WriteLine("Hello world");' >hello.cs
  $ bflat build hello.cs
  $ ./hello
  Hello world

The compiler can also crosscompile - just pass `--os` and `--arch` to specify the architecture.

It produces selfcontained native executables starting at ~730 kB for a Hello World referencing System.Console (uncompressed).

The compiler is self-hosted, so hopefully that's a good enough proof that it can already be used to build things.

The compiler comes in a ZIP file that you just extract and put on your PATH. It doesn't depend on anything else (no SDKs, no sysroot, no other tools).

You can target Linux already but there's no Linux version of the compiler itself because of some integration problems I still need to sort our (see Issues in the repo).

Disclaimer: I work at Microsoft, but this project is my freetime activity I whipped out without consulting anyone at work.

Ironic that this news from Poland comes a day after activists go on trial for replacing halos with rainbows in a picture in Poland: https://www.dailymail.co.uk/news/article-9142821/Poland-tria...

Here's another Snake game that can fit in a QR code, this one written in C#: https://twitter.com/MStrehovsky/status/1214955696556515331

(It doesn't need a .NET runtime; it's fully self-contained and runs on Windows as a native app.)

(Author of the "C# on Windows 3.11" hack here - and a Slovak.)

I would say the concentration of Czech/Slovak people around .NET at MS is a result of accidents and networking. I got into the team thanks to a friend of a friend who heard I was interested. But yeah, it's a surprising number given the size of the population of Slovakia and Czech republic.

There's a newly opened .NET development center in Prague so the number is likely going to grow (they do hire from all over the world though): https://karelz.github.io/hiring_prague_net/.

My tweet has the "friend" link that should avoid the Medium paywall (sorry): https://twitter.com/MStrehovsky/status/1213034748848807937

I spent more time doing the Snake logic than adding the soup of weird things around it to make it small.

I had the weird things lying around from when I did an EFI boot application in C# last year: https://github.com/MichalStrehovsky/zerosharp/tree/master/ef...

I won't lie - being one of the architects of the CoreRT ahead of time compiler helped too :)