5 ms·

C# is a lovely language to work with. The only issue I have is with the .NET ... that is, building self-contained binaries to distribute. For comparison: * H

• pjmlp 3y ago
  Usually that means you aren't using trimming, .NET speak for dead code removal during linking. Also remember that standard .NET runtime does a little bit more than Go's runtime, so it might happen that even with trimming, for basic applications Go ends up having an upper hand on file size. On the other hand, I have had Go static binaries grow up to 200 MB and being require to use UPX to make it manageable, e.g. trivy.
  • leeman2016 3y ago
    You're right. But even with trimming I get around 10x the size of the Go binary
    • pjmlp 3y ago
      Since I edited my comment, see my additional remarks regarding runtime capabilities, and the counterpoint of big Go binaries. Also note that triming only works properly if the libraries have taken the effort to be trimmable, as the linker errs on the safe side and won't trim unless certain that it is really dead code, and not called via reflection.
    • neonsunset 3y ago
      dotnet publish -c release -p:PublishAot=true
• neonsunset 3y ago
  This is an unfair comparison of apples to oranges by building the binary with the wrong flags. .NET produces smaller binaries than Go with NativeAOT (despite including more features).
  • leeman2016 3y ago
    Yea, I missed trimming. But still NativeAOT results in 10x the size of the Go binary in Windows (win-x64)
    • neonsunset 3y ago
      Two aspects: - There is no point in chasing smallest possible binary size if it trades off performance and features one wants to use in production scenario, or comes with other tradeoffs that sacrifice developer productivity. I don't see anyone complaining about the size of GraalVM native images. As long as binaries are reasonably sized, it's not an issue. - dotnet publish -c release -p:PublishAot=true definitely produces smaller binaries than Go as of .NET 8 (and no, you cannot use the argument that it's not released yet - it's in RC.2 which is intended for evaluation for adopting .NET 8 scheduled for release next month)
      • leeman2016 3y ago
        That's awesome, honestly. Can't wait.
• leeman2016 3y ago
  Let me give a real world example from my own experience. I have built a Win32 desktop app with its core logic in Go; and then re-built from scratch using .NET (v7). The core logic involved a fairly complicated keyboard input processing based on bunch of config files. - Final binary of .NET ~ 14 MB - Final binary of Go ~ 2 MB
• benibela 3y ago
  I was making Windows 98 apps with Delphi 4, and they were 350 KB large And I was upset that they were so big. Sometimes I used UPX. Or I kicked out all Delphi GUI libraries, and created the GUI with the Win32 API calls directly. I got 50 KB Hello Worlds.
  • Borg3 3y ago
    50kB hello worlds? Uhm.. thats still big. 15k May 3 2019 quickrun.exe* Win32 GUI Application that spawns Window and ask for alias to run. Pure Win32 API, written in C (Mingw). I literaly looled at 11MB hello world of .net or 1.2MB Go..
    • benibela 3y ago
      Well, it is what I remembered I do not have Windows 98 anymore. But I still have Delphi 4 installed under Wine, so I just tried it out. Just showing a messagebox from windows gives 16k Using the sysutils unit though, puts it at over 40k. And with classes, it becomes 57k. Not sure what they pull in. sysutils contains number/datetime parsing and formatting, and exception handling. classes has basic containers and object oriented file handling.
      • Borg3 3y ago
        Ahh, Delphi. Then I suppose its all right for it. Still, much better compared to Go or Java :D
  • pjmlp 3y ago
    If only Borland's management didn't decide to focus mostly on enterprise customers.
• metaltyphoon 3y ago
  Idk the last time you tried but a hello world in C# using .Net 8 is smaller than a Go hello world, for what it’s worth.