For the features that overlap between golang and .Net, can someone please let me know why people choose .Net over golang for non legacy systems? As far as my limited knowledge goes, go is much more efficient in syntax and memory.

The languages are very different. C# has much more powerful abstractions and is a much larger language in general. That is both an advantage and a disadvantage. Modern C# is also very fast, I wouldn't bet on Go winning that comparison.

My experience with Go is a while back, before it got generics. While I liked the overall idea of a language with little syntax and a focus on simplicity, I didn't really like Go in the end. It was a weird mix of too low-level and high level code. It exposed low level details that I don't need to think about in C#, and it is missing convenient abstractions like LINQ.

Personally, I like async/await in C# more than Go concurrency. I know this is heretical here, but I don't care about function coloring or any of the abstract advantages of other concurrency approaches. Async/Await in C# works for me (in non-legacy code) and is easy to understand.

Modern .net is surprisingly performant while also being very high level if needed. So it is very close to being a "learn once" ecosystem. This means you use it to write code for a much broader range of usecases than others, you will have a broader / more mature ecosystem than others, and your potential hiring market is more vast.

Go is not much more efficient, compared to NativeAOT - though it can be faster in some areas. The big reason why someone would want to use C# is that it's a more expressive language. You can even write your DB queries with LINQ (C# lets you express code as data), making them type-safe.

Go isn't as much fun. And is usually slower for my work until I bump up the GC and then it uses roughly the same amount of memory.

I have also found c# async to be lighter than go's concurrency story, and dotnet11 is going to make that much more clear.

Now: I write software for fun, not for money.

I know it's not quite as important in the agentic world, but the .NET tooling (across Visual Studio, JetBrains Rider, and C# Dev Kit for VS Code) is just awesome. Some people might frown upon full-blown IDEs, but sometimes they're just incredibly handy.

The tooling and development UX.

Put things like their remote debugging experiences side-by-side and you will quickly learn why some of us go for the Microsoft tools rather than the others.

That is an urban myth, CLR was designed with support for C++ in mind.

Also Go is at the stage of C# .NET 2.0, and still plenty of lacking language features.

I really think the creator of C# made a disservice to the .NET community by picking Go for the Typescript rewrite.

> go is much more efficient in syntax and memory

I'm going to talk about the second part first. .NET is often deployed with a JIT compiler runtime like Java. That means that hello-world scripts use a lot more memory than Go, but that difference becomes a lot smaller on real-world programs and .NET can use less memory than Go depending on what you're doing.

C#'s concurrency can also be more efficient than Go's since it's coroutine based async/await is a lightweight state machine rather than green threads. That's not to say Go is especially heavy or anything, but it is more overhead.

In terms of "efficient in syntax", Go has a lot fewer features. That's one of Go's biggest strengths and weaknesses.

Here's an example. With Go, you just have struct tags: strings of anything that can be attached to a field in a struct. Let's say you have a User struct and you want to make it so the JSON won't have the user's email in it. You do: Email string `json:"-"`. But what if you mess up and write "jsom" or `json:-` without the quotes? It's basically a meaningless string to the compiler. With C#/.NET, you have annotatons/attributes that are a part of the language and checked as types. You'd do: [JsonIgnore] public string Email. JsonIgnore is an attribute class so your IDE can help you.

There's a lot in Go where the answer kinda becomes "f-it, we'll just use strings instead of having something meaningful." Go talks about how important error handling is, but then you get an error from a function and it's basically just a string. If you're doing good error handling, you want to handle different errors differently, but that's not easy in Go. Frankly, it's not easy in most languages, but this is definitely an area where it felt like Go gave up on creating something good in order to get something out the door quickly enough that Google didn't cancel the project. In a language like Zig, errors are enums and you get exhaustiveness checking. With Go, someone could add another error state to something you're using and you'd never know - or they could change the phrasing of an existing error and you'd silently stop matching on it.

Go's lambda syntax is clunky. func(x MyType) string { x.ToString(); } vs (x) => x.ToString()

There's lots of stuff like that. I'm not arguing that Go is bad, but it has a ton less stuff and that's both a blessing and a curse.

Compare the ecosystems of .NET vs golang. No comparison whatsover. IoT, mobile, web (front and backend), cloud, etc. I think Go lacks variety and is more focused on traditional greybeard areas.

Native interop is much better in .NET, that matters a lot for some systems.

At former jobs, because people know it and switching from .Net <-> Go generally isn't worth the time to learn other language.

Sure, having a runtime is downside but difference in container size for your average CRUD App doesn't really matter. Performance IME is very similar.

Ops type here.

What's go's equivalent of LINQ?

In addition to what the others have said, I also enjoy the extremely robust ringtone reflection system in .NET. I don't know of any other systems that provide more complete detail. Maybe Java, though it's been a while since I've used it. It makes reflection in other languages feel prehistoricaly primitive.