Whether they are right or wrong is largely immaterial (fwiw, I enjoy C# and it has been my bread-and-butter language since ~2005) but I'm not tribal about it like some get. Posts about actual oddities (DateTime), bad design (LINQ + IEnumerable<T> = default interface implementations), or attempts to implement something common from another tool (e.g., list comprehensions) will get you derision and contempt for daring to question the holy C# on /r/csharp and even StackOverflow.
By extension there is a similar toxicity around Visual Studio, and MSSQL somewhat, too. Frequent "Why would you want to use ReSharper!?" or "Rider???? You need to get an employer that can afford Visual Studio." etc.
The community on twitter - where most of alt.net moved - is fantastic. It's the main reason I still use twitter. Surprised that people use reddit for coding and stack overflow for discussion.
Unfortunately there is also the side you're talking about. There are a lot of people who are stuck in the mud, and also a lot of people who are just fed up with baseless religious hate from the Python/Javascript crowd and who have never bothered trying those languages (and thus know that it's just projection) and lash out.
The thing is - just look at the work MS do. For years JSON serialisation sucked so we all used NewtonSoft. Now the framework handles JSON properly. So there's hope yet for things such the Date API learning from Noda - and when it does it's miles ahead of any language where people are dumb enough to use an int32 linked to an arbitrary epoch (from one specific OS variant) to represent date/time.
Way off-topic, but I'm curious about how you approach unit testing.
Coming from Java into a C# job, I'm used to mocking downstream dependencies, and even POJOs in some cases, that a class depends on. C# has stuff like Moq, but you _have to_ wrap everything with an interface to mock it since C# seals by default.
Meanwhile, in JVM land, you can use Kotlin, which still seals classes by default, but allows test compiles to open classes by default so you can still mock them.
Every C# thread I read suggests wrapping all concrete implementations with an interface like I'm coding in the 90's for the sake of decent tests, or they talk about how my code must be written poorly for me to be in this situation. Meanwhile, I'm just trying to get _some_ testing into this code I've inherited.
Also, C# doesn't seal anything by default. The methods are non-virtual by default, but that's a very different thing, and there's a good reason for it when it comes to libraries and versioning.
You mean local time zone? Just use UTC everywhere, nothing else will ever work no matter how you design it. DateTimeOffset miiight work too, but you'll extract UTC from it to do anything meaningful anyway, so it may as well be UTC all the way down.
No can do, and frankly is a _very_ reductive stock response.
Anyone working with Date Times more than even months into the future will have pain. Politics will mess you up. You've made a reservation for 16:00 at that fancy pants restaurant with a 6 month waiting list. But now the government have decided that Daylight Savings are too much hassle, and suddenly your 16:00 reservation is off by an hour (or whatever the DS shift is for your region.)
Then there is industry specific scenarios - logistics for example. They know the plane is landing at 18:00, but we haven't confirmed the TZ yet. Not because the airport doesn't know what timezone it is, but because the carrier hasn't confirmed which airport they are landing at. They just know it's at 18:00. DateTime is utterly terrible with "unknown"
If you want to express an unknown moment of time, no time zone will help you. Also the reminder service specifically doesn't need to be precise to the second. If you forgot your plane and got a reminder about it 1 hour before departure, will you be happy that your reminder is so accurate?
By extension there is a similar toxicity around Visual Studio, and MSSQL somewhat, too. Frequent "Why would you want to use ReSharper!?" or "Rider???? You need to get an employer that can afford Visual Studio." etc.