Comment by gertlabs
1 day ago
C# is one of the best languages we evaluated for LLM problem solving. In fact, many strongly typed, lower level languages perform well in our testing (this isn't to say that the solutions are more maintainable, but the LLMs come up with better ideas when writing C# or Rust than Python). Google models especially, for whatever reason, outperform in C#, not Golang.
This is why C# is superior to C++ for game development (not the graphics low level, but the game play higher level).
Being able to use Events, ECS, Reflection, Dynamic code is a god send. I have written game engines in C# and I still find myself defaulting to it anytime I think about Vulkan. I even published my own bindings for it. The best thing about .Net unfortunately is also one of its worst.
The deployment and packaging situation. It’s better than it’s been but it’s still a freaking mess. A mix of undocumented cli commands and wacky xml so that I can get an amalgamated build… or if I wanted to target another OS… or something of that nature. Even adding a project reference to a project, you have to go the long way round and use the cli commands. It’s better than having to install Visual Studio Ultimate but I wish they would put some love into their VSCode extension to give .Net some more powah.
Other than that, if you need Cish speed but need to support a GUI or something, C# is a good choice. If you’re happy with HTML UI, use that and forget C#. The UI cross platform situation is basically MIA.
I respectfully disagree — a lot of conveniences that C# provides produce GC trash which will cause frame spikes. I remember having had to add a non-allocation string.contains alternative at one project. Lambdas and linq also have this problem, or if a string is passed through native-c# boundary. Language itself is really nice though :)
C# is too much of a you hold it wrong language, you can easily avoid the problem you describe, but it is such a pain, i do like the fact that the language constantly improves in all directions so it definitely does not remove its positive sides when you do a thing in the right way
I think you need to revisit your biases
Google is mainly a user of Java, Kotlin, Python and C++.
Go might be have been created by three Google employees, two of which UNIX idols, but the language isn't that widely deployment outside anything to do with Kubernetes.
See how much Go related content shows at Google IO. If I am not mistaken, it got a single talk this year.
Go is actually widely adopted in web backends and desktop apps. You might just miss some scenarios. And from my naive perspective, Go is a strong type alternative than TypeScript though it has a unique idiom syntax, but for most web devs this could be a reason to adopt Go, e.g. Wails instead of Electron in desktop.
Outside Google, yes I guess.
Well I for one, think that using node, Python, Ruby on the backend is an anti pattern anyway.
And I certainly don't want to use a language that makes me feel like coding in Java 5, that was 20 years ago.
It's widely used in Cloud. Within Cloud you there is a policy to use it for all new products.
It certainly isn't reflected on Google IO cloud product talks, though, unless it is something directly related to Kubernetes.