I'm not hugely into Go, but I do get the appeal behind "only one binary output"

I'm doing C# right and end up with several different DLL files, executables, pdb and json. It's so annoying.

Thank god this is an internal tool, not something that needs to be packaged...

Isn't pdb for debugging and can be deleted before 'release'?

- - -

The "one binary" does even more: Your C# binary probably depends on more files (standard library, CLR runtime, whatever) whereas the go binary does not.

@sbiewald I know, slowly C# and .Net is feeling more and more convoluted.
All the different runtimes, versions, some things are in the standard libraries for some runtimes, but not for others so you need some nuger package....

I prefer things being simple.

If you ever need a proof that .NET is convoluted, look here: https://github.com/dotnet/...

@sbiewald I still don't get why there was a need for net framework, core, standard.

Now they want to unify everything under .Net 5, but I doubt they'll get rid of all of the duct tape below

What I am asking myself: Is there any advantage to using a Server over a built binary like Go is creating?

@LotsOfCaffeine core is portable between platforms. As not all APIs are available it was named differently.

I mean fuck efficiency in the name of simplicity?

Dynamic libraries were created for a reason: install them once, all programs can use them.

Is this something that Go ignores? If it does, I'll take it off my list of languages to learn.

PS: You can do this in c and c++ too. You just need to statically link everything to your output.

@AlgoRythm this isn't about dynamically linking in general, or sacrificying efficiency. I like things being efficient, I'm German after all.

This is mainly about the rather confusing state of the .net ecosystem.

As I mentioned before, there are several frameworks/runtimes, some official libraries are available on some runtimes, but not on others and so on. This is just confusing, even though I've been working with the language for quite a while now.

I'm sort of hopeful the upcoming .NET 5 makes the situation a bit better, but time will tell.

And about Go: I'm no Go expert, I only played around with it a bit. But I would guess you can dynamically link libraries.

If you using .net core, you can build everything into a single exe.
In .net framework, the is a tool call ILmerge can do that too.