I wish it was a real "systems" language as well, i.e. not single-threaded/javascript-mindset one. That's why I hope someday we will have a nice cross-platform framework for Swift.
I whish that too, but I'm not holding my breath since Google needs Dart-to-JavaScript compiler, which will continue limiting features Dart can implement. The only way this can change is, if they move to WASM and drop JavaScript target.
Go is frankly the polar opposite of C#. Go compiles to a native binary with no runtime dependencies and it relies on simple garbage collection and static linking. C# runs on the .NET runtime which is heavily managed, gives you JIT, reflection, dynamic code generation and so on. Go views concurrency as fire and forget, C# views it as compose and await. Go is extremely explicit while C# is extremely implicit.
Now, I understand that you may talk about it from a non-technical perspective, but even so, there are major differences. C# is a general purpose language for the cloud/web, and so is Go, but Go is also widely used in other areas like in embeded software. TinyGo is soooooooo much better than working with C/C++ or Rust as an example. Places like that where you wouldn't usually find a transpiled language (other than maybe Python with MicroPython).
C# has AOT compilation which creates a single, native binary. This has gotten so much better with .NET 10 and since the introduction of source generators to deal with reflection issues.
Also, check out nanoFramework for a .NET runtime that can run on MCUs like the ESP32 [1]
Cool, I didn't know this. I see it's been a thing since .NET 8, but it also looks like something that is perhaps mostly meant for hobby projects? Or maybe I'm getting that wrong.
Definitely started that way for me. It was cool to see a console app written in C# be compiled straight to native and run. Since then, a lot of work has been done to make AOT viable for more workloads.
I wouldn't use it for an MVC application yet because a lot of features won't work but there are plenty of other areas that are using it now and one of the biggest examples is Avalonia apps compiling to native.
.NET can be compiled to native binaries. .NET can be used for embedded development.
C# is more expressive and .NET comes with batteries included. Go is more explicit and more verbose.
You can pick up Go faster and is easier to reason about Go code when you first encounter a new project but C# feels like it enables you to develop faster and be more productive.
For web both are excellent and performant, even if they have different philosophy.
What I like about C# is that it becomes more functional and I can even mix F# in the projects if I want even more functional programming.
Cool I didn't know about it's AOT, but it looks very... well hobbyist. Anyway, "Go is more explicit and more verbose" is a feature, but that's a matter of personal taste.
I worked with C# for a decade, I'll likely never work with it again if I can help it. Not because it's bad, it's better than it's ever been. But because I really dislike the way they include their batteries. It leads to long debugging and refactoring sessions when tired people have written what is not their best work on years worth of thursday afternoons. I think people who like implicit frameworks must have been good enough to work in places that had better quality than the places I've worked.
