[borland]

Yuck. I like both Go and C# a lot, and use them both professionally.

In my experience the strengths of Go are mostly - Deployability via single-file static binaries - Simple syntax that anyone can learn (no exceptions, no classes or inheritance) - Wicked fast compile times

And the strengths of C# are - Powerful language with null-safety and lots of syntax sugar - Runtime-level coroutines so you don't need `async/await` everywhere

G# seems like it has the _worst_ of both worlds, not the best. It's fun to write compilers, and good on them for doing it, but no thank you for real use

[sideway]

> And the strengths of C# are [...] Runtime-level coroutines so you don't need `async/await` everywhere

If I'm not mistaken, that isn't the case. Could you elaborate?

[n4r9]

They might have meant to put that point in the Go section?

[rmuratov]

C# has single-file static binaries

[littlecranky67]

Exactly. To add to this, is called ahead-of-time compilation, and bundles required parts of the .net runtime into the single-binary. Deployment targets thus don't need to ship any .net environment or libraries.

[fabian2k]

AOT is entirely independent of single file binaries. And self-contained binaries that run without the framework installed are again a separate concept. There are some dependencies between these, but they are not the same thing.

AOT is not all that useful yet for many applications as important libraries still don't support it. So more something for things like CLI tools with a small scope.

It's not quite the same as with Go, the binaries get large if you can't trim them. But creating single-file self-contained executables is very much usable and works well otherwise.

[littlecranky67]

> AOT is entirely independent of single file binaries.

splitting hairs, but its is not independent. AoT is a required pre-requisite for single-binary creation. You can't create single-binaries with JIT. And that is the big hurdle, lot of libraries do not support AoT and that is the blocker to create single-file binary. Once you have the AoT figured out, the single-binary creation is easy.

[fabian2k]

Yes, you can. I am using that in production right now. An ASP.NET Core application as a self-contained single-file binary, without AOT.

.NET AOT right now is a very specialized solution that isn't widely applicable. Self-contained and single-file binaries do work pretty much out of the box already.

See the documention here for the PublishSingleFile and SelfContained options:

https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

[YoshiRulz]

Other way around, enabling AoT requires you also enable single-file

[magicalhippo]

Yes but no. It's essentially a self-extracting executable, so adds significant start-up time. It also doesn't work in all cases, for example the database driver files to the DB we use aren't compatible with the single-file deployment method.

[mhh__]

C# is a pretty bad language when you take away the stack it sits atop of. I do mostly like the async but developers put up with a lot of shit to e.g. use the msft networking stack and containers

[Anvoker]

I feel the opposite. It is one of the genuinely competent languages out there, if you're the kind of person that isn't upset about it being a "kitchen sink". Instead, I feel like the ecosystem, community and reputation hold it back. There are nowhere as many useful and popular packages to reach for as Python for example. Unity3D always lags behind in runtime and language version and had amazingly bad package management -- this further hamstrung C#, because the language is never used in a vacuum.

[anton_gogolev]

Care to elaborate on what would make C# a bad language?

[mhh__]

It's a product of an era of OOP when the idea of a program fitting in a developers head was a dangerous reactionary idea.

They have in fairness fixed a lot of the worst aspects of this by adding basically a second language to it but e.g. I massively prefer writing F# if purely because if I want to do something I can just to it rather than first implementing public static DoThing : IDoThing

[orphea]

  public static DoThing : IDoThing

Yeah... Right.

In other words, C# is a bad language because you don't like it?

What does prevent you from "just do it" in C# without extra classes and interfaces?

[mhh__]

The noun to verb ratio is too high. This is a normative statement but it's one I'm willing to make that you apparently can't detect.

[Quothling]

I've worked with C# for a decade, and Go for the past 5ish years and I think the biggest difference between them is in the philosophical design on implicity and explicity. I have a strong dislike for C# like languages these days, but it's not for technical reasons. I think C# is supperior to Go in many ways, but I absolutely hate the implicity in it's design, and this is a personal opinion that is not objective. In this context I can't imagine how you would create a mix of the two that wouldn't violate either approach. Looking at something like this:

> @DllImport("libc", EntryPoint: "strlen", CharSet: CharSet.Ansi)

I would argue that they made something I suspect many Go developers will dislike. I know I absolutely hate it. If I wanted to do things like that I might as well use C#. Then again, these days I'm shifting more and more of my development to either Python (which is objectively an awesome language that also sucks) or Rust. While one of my favorite features of any programming language is the Go modules with single folders and upper and lower cases for private/public. I am becoming a fan of how rust does structs with impl methods.

Anyway...