I want to highlight a few ideas that perhaps I didn't cover very well in the article:
* static linking -- the concept of static linking appears in total 7 times in the article, once in the summary, once qualified with "if possible", three times as comments on a few example projects that do happen to employ it, and once discussing Go's advantage; the article is not about static linking!
* dynamic liking -- it is completely fine, just don't depend on non-mainstream libraries, and don't require the version released yesterday as most stable distributions won't have it (for the next couple of years);
* packaging and dependency minimalism -- as I've noted on Lobsters (<https://lobste.rs/s/adr60v/single_binary_executable_packages...>), the article is mainly about the simplicity of building, packaging, publishing, deploying; try to read it both from the point of view of the developer and the user;
I think you could add an entry to the "Languages suitable for single binary executables" section; these days, .NET (C#, F#) single-file applications work very well. This is a fairly recent development (single-file support has been good for ~1.5 years now) but I've been very satisfied. https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
I want to highlight a few ideas that perhaps I didn't cover very well in the article:
* static linking -- the concept of static linking appears in total 7 times in the article, once in the summary, once qualified with "if possible", three times as comments on a few example projects that do happen to employ it, and once discussing Go's advantage; the article is not about static linking!
* dynamic liking -- it is completely fine, just don't depend on non-mainstream libraries, and don't require the version released yesterday as most stable distributions won't have it (for the next couple of years);
* packaging and dependency minimalism -- as I've noted on Lobsters (<https://lobste.rs/s/adr60v/single_binary_executable_packages...>), the article is mainly about the simplicity of building, packaging, publishing, deploying; try to read it both from the point of view of the developer and the user;