Go still has a better deployment story. Single static binary deployment are king. On .Net 8 I was hitting random compatibility issues with single binary application bundles, with System.Data.SQLite, and other libraries. (had to use that one and not he Microsoft one for some legacy compatibility reason, maybe around Guid handling maybe)

Is cp -r/xcopy/robocopy a folder (with or without tar/zip wrappers) that much harder than single file deployment?

yes.

In .NET 5+ you shouldn't need to install runtimes, though. Self-contained folder full of DLLs output is the default publishing build today and very reliable at this point (and doesn't have the same restrictions as trying to AOT compile and treeshake everything into a single self-contained EXE).

Obviously, there's a trade off in size having a whole folder of files, some of which would be redundant with other applications, but folder of files using xcopy only deployments have seemed to become the standard in .NET. (Or perhaps more commonly, folder full of files added to a minimal "no runtime" Docker container overlay.)

I don't think I've ever seen a global install of a .NET 5+ runtime. I wouldn't be surprised if some Enterprise was doing it for some belief in HD space savings, but I've certainly not seen it. Just file folder deploys.

From your description you certainly weren't using AOT compilation, and forgetting about CGO.

Static linking as the only way in most platforms, we moved into other mechanisms for a reason.

In Go the only way to do plugins, without shipping everything as source code is to use microservices, the more fashionable name for multiple process with OS IPC.

I'd presume you can still do dlopen despite your binary being statically linked... but I have not expermented in the topic, I did dlopen in Linux libc, and Assembly.Load and P/Invoke in .Net (no AOT).

I wasn't using AOT, it was not something I needed/wanted, but for a TypeScript compiler it would make more sense. I only tried single file binary compilation, as I didn't want to deploy the runtimes, wanted to have them embedded to the air-gapped systems in a simple copy and runway (no installers, etc).

Yeah, but that beats the purpose of static linking in first place, especially if the plugins require access to the host process APIs.

Doable, but requires a bit more of extra work, and Go plugin package is basically abandoned, it was not yet been removed due to backwards compatibility.

> still plenty of lacking language features

Fans of Go (myself included) prefer this. The small feature set is a feature, not a bug.

The history of generics and Go is enough to keep me away from that mess of a language forever.

Go seems actively hostile to it's users, especially in comparison to C#.

with Go, they have made one commitment. The language will always be backwards compatible. So code written in today's go should still be able to be compiled in 30 years using the compiler of the day. That means when adding new language features, they are very, very, very particular and stubborn about it.

Every mature programming language places a very high priority including C#. Microsoft introduced generics, LINQ, async/await, pattern matching, records, nullable reference types, and numerous other features while maintaining a very high degree of backwards compatibility.

But either way, this merely provides an excuse as to why Go is actively hostile to it's users. Backwards compatibility and language evolution are not mutually exclusive.

I thought they changed how variables are captured in for loops at one point didn't they?

There have been changes in Go already, even if minimal.

Migrating to Go was easier because it was easier to port the code instead of doing a rewrite. Go matched the easiest to the way the code was written. C#, F# or Rust would have required a re-write instead of just simple changes.

https://devblogs.microsoft.com/typescript/typescript-native-...