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.
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.
I'd beg to differ on the easy to understand... last time i worked with this stuff like ConfigureAwait only has cargo cults and no real good explanation, and wasn't covered in any recent version of eg. CLR via C#... Distributed tracing and thread management were totally bitten by async, also the way iterators and LINQ were broken... that was when I got off the train, as it broke the best abstractions for line of business code so that instead of designing an IO pipeline lazy developers could simple put Task.Run around blocking IO calls at the bottom of the codebas, and ... yeah, we are back at function coloring.
This brings me to: I winder for what kind of apps did you find it a delight, because for extensive data wrangling leveraging multiple calls it was a pain.
I'm using C# for the backend of a web application, not legacy but .NET Core from the start.
Something which was as easy as an IO call in the middle of a function running on a thread pool becomes a PITA if the IO call is cleverly async-ized (by wrapping the original sync IO method into a Task.Run(), but actually this is the better case!) ad then removed from the public API... (cannot recall the exact library, but it was a pain, as it was some core stuff, maybe vendored by MS themselves)
Also back then it caused us loosing correlation IDs as those were thread locals in traditional pre-async ASP.Net Core (think version 0.9-2.0 when I worked on that part, then up until core 4 and the async mania continuos broke readable calculation code in LINQ, TPL based performant data pipelines, etc...) and with async execution started to migrate between threads... If you needed high performance you already used threads, because it was not a classic web application, but a specialized optimization algorithm with a web api... and if you need more than CRUD, and use all the cores (and SIMD) to squeeze out all performance you have, you hit these problems right away. These all could be solved, but it actually broke stuff, a lot of stuff, as developers jumped on the fad, and it their sync code was turned into a .ConfigureAwait(false /* Microsoft blogs talk a lot about it without a clear explanation, so every cool kid does this */).GetAwaiter().GetResult()... then you some of your threaded code silently broken if you dare used Thread Locals... Faded memories, but that was when they f'ed up the C# language.
Indeed, you need a crapload of ConfigureAwait() in desktop UI code, and it infects all underlying libraries that might have to run inside a desktop app. The worst thing they ever added to our beautiful language. It's a dream to work in ASP.NET without needing to pepper every await with a ConfigureAwait().
That said, I don't agree with the characterization of ConfigureAwait() as un-understandable. We understand it. We just hate it.
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.
For general concurrency where async doesn't suffice, go is nicer than C#, but hopac is nicer than go.
If go had proper concurrentML I am pretty sure I would use go a lot more. Again: this is for hobby projects where I get to choose freely.
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.
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.
Fans of Go (myself included) prefer this. The small feature set is a feature, not a bug.
Go seems actively hostile to it's users, especially in comparison to C#.
But either way, this merely provides an excuse as to why Go is actively hostile to it's users. But backwards compatibility and language evolution are not mutually exclusive.
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.
I don’t have much experience with Go lang but what I have seen, there is lots of things one has to implement on his own. Which has its own merits, but to go from 0 to full fledged enterprise app you need more time.
Go is trying to be like C. Less language features (until recently...), so to solve problems you write more code. Intentionally simple language. Intentionally need a lot of code to implement something substantial. .NET seems more frameworks driven. Go traditionally has eschewed frameworks for doing stuff much like C tends to eschew framework type stuff and prefers smallest dependency reliance as possible.
* = Technically, Windows now supports the UTF-8 "code page" where applications can use UTF-8 natively, but all NT system calls use UTF-16, so the conversion still has to happen somewhere
The Runtime has explored attempting "UTF-8 native" string storage as a platform feature especially for Linux FFI, but yeah Windows using UTF-16 is still a compatibility issue where platforms themselves just don't agree.
Some example.
Open API document generation using type handlers doing this in go was a pain in .net is comes out of the box.
A lot of people underestimate the power of extension methods.
.nets metadata system is compiled time safe where Go is not and this has burnt me a lot.
I really like go for command line tools Small binary sizes I lovely.
go's standard library is significantly more hackable than .nets there have been a few things where I've ended up using Go because to do it in .net would require me maintaining a fork of the standard library.
Go makes composing data insanely simple. where in .NET you can have an equivalency but it will be done via interfaces.
Go's Dark Type System is both great and really annoying.
C#'s stricter type system when it comes to interfaces can be really handy as that can be used as metadata to change how data is processed and enforce compile time checks.
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.
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.
Go's advantage is mostly the fast compile speed, goroutines, profiling, and a very opinionated formatter. Neither has an overwhelming advantage over the other though.
Golang is a fantastic delightful language, but it's still missing a lot of stuff that's existed in C# for years.
However, do you *need* all those .net tricks?
Golang is usually enough for a small project you need to build in a weekend. Scaling it to a mono repo with 200 developers might be a bit difficult
me miss spelling a tag has burnt me so many times.
Go is for me just a, hmm, concurrency programming language. Its popularity stems just from being pushed by Google, and the cosmetics of using braces. Despite what pundits say, it's completely and utterly not like C.
While C# is a successful and comfortable everything-language. It is blazing fast, has amazing tooling, you can get going to prototyping, then enterprise code, its serverside handling is excellent. It has many low level features and built-in data structures. It's I would say preferable for almost any kind of work except scripting. (I really don't like C# scripting.)
PowerShell says hello :)