[everyone]

I'm a very experienced Unity C# programmer, and I certainly don't equate "good" with using all the new fancy features of a language.

Fancy features are less maintainable imo. Less programmers will know about them and they're less likely to have equivalents in other languages.

Making something more exotic / confusing / hard to parse is defo not worth saving a few lines of code.. I'd much rather see a longer function using absolute bog standard elements of the language (and thus being clear, easy to comprehend for everyone, easy to modify at any point) rather than a super short, super "elegant", super "clever" solution.

[drzaiusx11]

Languages that seem to indefinitely grow more features over time (like c++, c#, rust, etc) evitably become bucketed by epochs unless the consuming application code also operate across the same time scales. Feature deprecations tend to go hand in hand with newer features, leaving you with basically "multiple sublanguages" in a supposed single language, exacerbating fragmentation of the community. I don't want to have the mental load of contextually understanding "which" sublanguages I need to care about depending on the year a consuming application was written. This is why I tend not to reach for new fangled features and stay with the core runtime stuff in evergreen langs.

[jayd16]

I don't know... I feel like a lot of these features do increase developer intent without breaking muscle memory. Properties are got and set like fields. Record types feel like classes with restrictions so the linter can warn you about broken assumptions. etc etc.

Others increase readability. A LINQ statement is a lot easier to parse than a long block inside a foreach.

New doesn't mean good but a lot of these are new and good.

[everyone]

I disagree about LINQ. You can easily do the same job in a little function with only stuff people learn in week 1 of programming, just for and if else and arrays. It's very clear precisely what's happening in this case, and its easy to alter. (Everyone is gonna know that stuff, not everyone is gonna be using LINQ regularly enough to understand it completely)

LINQ on the other hand is like another language entirely, awkwardly squished into your C#, reminds me of SQL code inside a big string inside another language's code. It's also not clear what it's actually doing which can be death for performance in games as LINQ usually allocates shittonnes of new stuff. (I'm certainly not advocating for premature optimisation, but I defo am advocating for knowing precisely what you are writing) The benefit of LINQ is that its a bit faster to write compared to a little function, but length-of-time-it-takes-to-actually-write-code is very rarely an important constraint in my experience.

[hacker_13]

It's why Golang is my favorite language now. I am not learning 30 ways to learn the same thing :)