I worked with C# for a decade, and I think it’s never been better than it is now. I also think it’s a language that’s mostly meant to be sold by Microsoft in 2023 where it’s sort of outlived its usefulness compared to something like Go, or even Java.<p>I live in a very Microsoft happy region of the world, but not a single company that’s managed actual growth is using C#, and the language sort of lives in this “stagnated semi-large company that’s not going anywhere and hasn’t for a long time” space. Which might not have anything to do with C#, but more that the choices over all at those companies (which includes going too heavy in on the Microsoft tech stack) seem to hinder them from growing beyond 100-300 employees. Which on one hand is unimportant for the developers who work there, but often leads to a lot of those developers to “stagnate” as well, which sometimes lead to them having a rough time if they for some reason have to enter the job market at 50+.<p>So in many ways I think C# is very overhyped. Mostly because, why would you ever chose it? I don’t think it really compared with Rust. Rust can compete in the same space as C#, but you’d mostly pick Rust instead of C++, and I see things like Java, Python, Go and Typescript as its main competitors. Java mainly being there because large “boring” enterprise organisations like banks are going to use Java until all of us retire. But if you’d chose between Python, Typescript, Go and C# you just wouldn’t ever pick C#. Even against Java, I’d question why you would ever pick C#? Java is so far ahead of C# on concurrency that it’s painful to watch how C# developers are still stuck using things like await.<p>Yes it’s faster than Typescript and Python, but with Python being capable of powering the web-back ends at Instagram and OpenAI that is sort of a silly point. And Python is just soooo much more efficient in terms of producing things fast. It’s also telling that even Microsoft’s own C# developers pick Python over C# for things like prototyping and smaller applications they need to build fast. Go is king of concurrency and Microservices and you can see stories like Lunar who’ve gone from a Node backend to a Java backend to Go and now can’t imagine not using Go. Then there is Typescript, which today is basically what C# wants to be, and probably will be as the two languages influence each other more and more, but allows you to “full stack” in one language (except for the parts that run on Python and C++/Rust but you’ll have those regardless as some things require the efficiency of C++/Rust and the ML/BI/AI crowd aren’t going away from Python until the moon leaves our orbit). With companies like LEGO running most of their software on Typescript and Node, leaving C# behind, it’s also hard to talk too much about its inefficiency.<p>You can also look in my history and see my ranting about a range of the issues you’re eventually going to run into with the “magic” C# comes with, because a lot of their automatic handling of complexity can break in various ways when you need to use it in ways Microsoft hasn’t build it to support, and sometimes that’s simply using two different Microsoft libraries for C#. Which has nothing to do with the language itself, but let’s not pretend you aren’t going to use EF, Blazor, WebApi or similar if you use C# so it does impact you even if it has nothing to do with the language.<p>I don’t think there is anything wrong with C# though, it’s just that there isn’t really anything “right” with it either. It’s a language that doesn’t do anything other languages doesn’t do better, which includes being a jack-of-all-trades language where it’s also flat out losing to Typescript. If that last statement makes little sense to you, I fully understand, because a good Node development requires and opinionated CI/CD environment where as C# kind of doesn’t. But this is partly also why you’ll find so many C# developers get trapped by the language and end up making glaring mistakes like using IEnumerable instead of IQuerable. Or making what is going to execute as 9 table joins in linq but not wonder why it takes 4 minutes to execute. Which because you can get away with some pretty bad CI/CD pipeline in C# (for a while) ends up going to production.