>but you also get a self-contained binary executing without the requirement of an external runtime environment.

I'm not sure whether we're talking about the same thing, but you can publish Self-Contained App (basically your app and framework together) and you don't have to install anything.

This is technically true, but it's a difference of a 5 MB executable vs a 50 MB.

Is it, actually? I mean, yes of course its 45MB difference, but does this matter? We are not talking about applications downloaded to a browser (webapp) or to a mobile phone. In a time where I download >50GB+ games on Steam and deploy from CI/CD server or docker registries to my servers, is a size of 50MB or 100MB really a showstopper?

Don't get me wrong, I totally love 4k and 64k demos and am always fascinated what could be packed into such small binaries, but in my professional life I think developer productivity, code quality and tooling is way more important than filesize. This is of course different if you are a webdev that ships .js, or an App developer publishing to Appstores.

The only environments where self-contained deployment matters are the ones you mentioned: browser, mobile phone, and also desktop. So yes, 45mb is a big difference (actually my app is 250mb).

In the .NET context, browser-targeted deployments can have a minimal download overhead of around 2 MB, which is a far cry from 50 MB. How? Blazor. For details, see https://blog.ndepend.com/blazor-internals-you-need-to-know.

That's 2Mb front-end which is quite heavy.

How 2 MB could be considered heavy, when visiting most websites results in much larger sizes of downloaded resources?

tell that to websites auto-playing videos (in muted state) or even better, using videos as page background that play without interop.

.NET has trimming now, so it is 5 MB? (Possibly less!)

Nope.

Running this command:

    dotnet publish `
    -p:Configuration=Release `
    -p:PublishSingleFile=true `
    -p:PublishTrimmed=true `
    -p:RuntimeIdentifier=win-x64

gives an 11 MB file, that still requires 4 DLL as well.

Go seems nice, but don’t you think writing business logic feels very tedious compared to C#? Generics and linq speed development time up for me significantly.

I can't think of anything other than Java that's as tedious to write as C#/ASP.Net. With Java and C# code you spend a siginifcant amount of your time messing with the complexities of the language itself instead of dealing with your business problem. The mixture of generics and static typing is particularly pernicious. I really hope Go 2.0 doesn't end-up going down the generics rabbit hole.

Can you give some concrete examples of how C# is tedious compared to go?

Things like

  var filtered = purchases.Where(x => x.Name.Contains("Sean"));

and

  var grouped = purchases.GroupBy(x => x.Buyer).Where(x => x.ToList().Count > 10).ToDictionary(x => x.Buyer, x => x.ToList());

etc. come up a lot in day to day programming and always feel tedious to me in go. The first example in go looks something like

    filtered := []purchase{}
    for i := range purchases {
        if purchases[i].buyer == "Sean" {
            filtered = append(filtered, purchases[i])
        }
    }

and it only gets worse as the domain gets more complicated. I don't really know what your background is where you feel that static typing and generics are complicated. I write C# every day and spend 0% of my time fighting the language.

Same experience here for Java. I always have a hard time understanding the arguments against it. The platform and tooling far exceed that of Go and I've never found the writing of actual code to be anywhere near the bottle neck in the entire development process. And while I've never worked professionally with C#/.NET, I imagine it's a very similar experience.

I have to agree with Xeronate on this one, a lack of generics makes writing business logic in Go quite annoying. Generics and the monad-esque values it enables make it much easier to model your logic properly.

I like Go for services that just need to push bytes around to various places but otherwise it does get quite tedious for complex logic.

What types of services don't have complex business logic? Just trying to expand my horizons. I guess like a video transcoding service or something like maybe.

Something like a WebSocket server, a load balancer, message queue, that sort of thing.

It's not that those aren't also complex, but there's less "business" in the logic, if that makes sense. Something that doesn't handle arbitrary user input or deal with the messiness of humans, like first/last names, dates and timezones, etc.

As an example, I had once written a WebSocket server in go which took a program as input, ran it in a heavily stripped down docker container, and streamed the stdout back to the client. Go was perfect for that use case. (though to be honest I'd pick Rust now because I'm past the learning curve on it)

You don't need the .NET runtime installed on the target host.

C# doesn't require classes with the latest release.

In what capacity are you using Go that made it a good replacement for C#? Microservices? If so, which framework are you using?

I have migrated from C# to Node.js, my code is now 20x times shorter (from 800 files to 40 files), simpler to read and maintain, there is 100x more packages available on NPM compared to nuget. Performance is stellar, even better than in C# for my use case (Mega tons of concurrent queries executed in 1-5ms avg)

And also I don't have to fight against the language to do what I want to do ... No classes, no types, no constraints.

Every rewrite yields better results, even if you'd have rewritten your code in (modern) C# again.

> my code is now 20x times shorter (from 800 files to 40 files)

Well, do you have all of the bells an whistles that you had with .NET? I mean, you can shrink a .NET API down to pretty much just 1 file if you really want to. The question is if you should.

WebHost.CreateDefaultBuilder().Configure(app => app.Run(c => c.Response.WriteAsync("Hello world!"))).Build().Run();

>20x times shorter

that's giant, but I don't think that "just" language / environment difference makes this huge difference

I would say 2x-5x shorter is pretty realistic.

I would say that that C# code that can get 2x-5x reduction in size by being rewritten in JS is terribly bloated (not taking into account the case where you just remove code because there is now a library available for what you had to do yourself before).

yeah javascript is pretty short. unfortunatly I do not know how people love it. npm/yarn and javascript dependency management is the worst thing i've ever seen and it is slow and pulls in millions of files, just for a small project.

Huh, that's quite a dramatic code size reduction. Which percentage of this codebase was in tests and boilerplate code for stuff like helper data classes?