3 ms·
Switching from C# to Go for back end development
- GordonS 6y ago> Go’s build output is a single file, whereas dotnet’s is a folder with the built assemblies (including dependencies). Building a docker image and pushing it to microk8s is much faster when all you’re packaging up is a single binary, vs. an entire directory of assemblies. From .NET 5 onwards, you actually have the option of publishing to a single file. Technically you could do this in .NET Core 3 too, but it was really just a self-extracting ZIP.
- GordonS 6y ago> A side effect of the clumsy Streams API in dotnet is that the antipattern of reading a Stream into memory (e.g. with a MemoryStream) is prevalent - we’re guilty of it ourselves, in places. This seems a little unfair to compare bad C# practises to good Go practises. Of course, if you unnecessarily load data into byte arrays, GC is going to be a problem. But you don't have to do that. Even if you're using some 3rd party API that doesn't support streams, you might be able to use pooled byte arrays, or even pass a stackalloc'd Span for small data. The author does a lot of hand-waving about 3rd party libraries, but since they don't actually name them, it's impossible to comment on that This has very seldom been a problem for me personally, but it might depend on the 3rd party libraries that you use - the author does a lot of hand-waving about 3rd party libraries, but since they don't actually name them, it's impossible to comment on that. > There’s also the fact that even idle dotnet processes can consume hundreds of MB of memory This is contrived; it's only true if those idle processes were previously doing a lot of work that made a lot of allocations.