I think it helps a lot if you use Rider, or Visual Studio with ReSharper, as they will automatically make suggestions to use new language features when appropriate - that way you always get exposed to new syntax.
I do agree that the syntax proposed thus far for records and discriminated unions is far from pretty, but I can't see it making it into the spec like that.
I completely agree - I rather like how C# and .Net is progressing - sure there are new features every so often that take time to learn but isn't that the same for absolutely everything.
Now, for someone new the features set, the various keyword overloads and the magic syntactic sugar can make it hard to tame. Back then, It was mostly a (slightly) better Java. It has evolved into something totally different, that often tries to mimic F# while still keeping the familiar curly-race syntax, which makes things awkward at time. C# is my main language, but sometime I feel like there should be a fork, with a legacy C# that keep being ported to new frameworks and platforms, and a new branch where feature creep can continue go wild.
You don't have to use language features you dislike. If you want to prevent them being used, you can set the c# language level to an old version using the LangVersion element in your csproj file.
if working in a team, your team members are unlikely to thank you!
For us, the language features we can use internally are dictated by our own compiler to translate the code to JS and Java and yes, a null check is somewhat verbose compared to ?., but in such cases it can be important to restrict the language level, even if you could locally use a newer one. We're also, for compat reasons, building the code on the build server with basically VS 2010 to ensure that there's nothing in it that .NET 4.0 can't handle. Customers can sometimes be very_ conservative and value this kind of thing.
If you want to prevent them being used, you can[0] set the c# language level to an old version using the LangVersion element in your csproj file.
[0] if working in a team, your team members are unlikely to thank you!
It's been an... interesting ride.
C# still has a lot to go to catch up with C++, on the language level.
On the other hand, contrary to common beliefs regarding C++'s complexity, no one is able to master the complete standard library of either Java or .NET, let alone the major frameworks that also get used alongside them.
The only thing about Java that I really like is that you can not use it in it's ecosystem while not feeling like a second class citizen. Kotlin (I didn't use the other JVM languages so far) feels 100% supported while F# in Visual Studio is kind of rough.
Java itself: hope I never have to work with it.
Platform languages always win long term, adopting what matters from guest languages, while exposing the platform without any additional FFI, IDE plugins, build tools, idiomatic wrapper libraries, new layers to debug,...
It’s like that with a lot of our systems, and it’s pushed us more and more from C# to Python where a lot of things are just easier.
We had similar issues with the AD APIs in .NET. You’d think Microsoft would have extensive AD integration support for C#, but you’d be wrong. It’s nothing you can’t fix by overriding the standard libraries with extensions of your own, but it’s a lot of work. Which is kind of the opposite of why you’d pick C#. At least in my opinion, you pick it because it comes with a powerful IDE and powerful standard libraries, but it turns out that it doesn’t actually do that once you dig a little deeper than standard CRUD applications.
Either you freeze the language and let it stagnate or you keep adding features without removing them and suffer from bloat.
Seems like the slow churn of high level languages is inevitable while maintaining backwards compatibility.
I feel like there’s probably a good analogy with evolution of human languages and cultures around them. How many of us can read Beowulf in the original?
I think these days you must force a specific code style according to a specific C# version otherwise you're going to have a mess. Harder to read for those used to older c# version while also hard to read for those used to newer c# versions.
You can have a valid reason to have c# classes that just use lambda to implement interfaces, a valid reason to have an interface with methods implementation, and a valid reason to do classic c#. In the end, you still have a mess.
I hope that someone makes a tool that helps make the code consistent and let developers avoid the suffering of thinking "but why is this like this??? oh wait... this the other c# version feature which I never used before.... I guess it's okay? ¯\_(ツ)_/¯