Aesthetic language features just make code harder to read

This post will attempt to address my animosity towards aesthetic language changes in certain computer languages. Inspired by a work thing and also inspired by a reddit user who deemed that typing "go run main.go" is too many characters because you can just write "go run ." (lol) and really had an issue with anyone doing that! It was shocking.

I won't update my code to new language features in C# ever. Why?

Least common denominator

I want to be able to use the same code in all of my projects by probably just copying and pasting it, even though that's not ideal. But say it's a small feature not worthy of its own project. I can copy and paste and since I pretty much write code with the intention of being able to use it in other places from the start, it should just work with minimal edits. Ideally.

Doing a lot of Go, you do tend to write a thing once and copy it over. This is fine because most things don't need their own repo. I have a snippet for reading a csv file, just copy those few lines of code and you're good. Or starting a new http server. The benefit is that all of the code is there and not abstracted away in some github repo, in case I need it to work slightly differently.

Enter C# and just constant language updates. A few weeks ago, I was trying to reference code that uses a "==?" operator or something dumb like that. It was in a third party library for dealing with ElasticSearch. The main developer wanted me to reference the projects in the solution, e.g. build them when the rest of the solution builds. But since they're using new language features that didn't compile with the current version of .NET we were on, I objected very heavily. Instead I added the projects to our git repo inside a folder, they compile in their own solution file, and put the DLLs in a location that our project references. By DLL. Not ideal, but as I said, the alternative is way less ideal. If we want to update our version in the future, we'll have all of these differences in the code aside from what changes I had to make (I did have to fix some things in the third party project). If that project was written with my philosophy of never using new language features and keeping to the least common denominator, it wouldn't be an issue.

The main issue about aesthetic language features, is that they seem to lessen the amount of code that is needed to type. But that solves literally nothing.

Code is read more than it is written

And that's the main thing. And with the reddit poster who was chastising people for typing "go run main.go" instead of "go run .".  I never see typing as a problem. I'm old and I've been typing on a computer for decades, I have no carpal tunnel (knocking feverishly on wood), I'm a pretty fast typer, and I can compress logic into some smallish code as to not be typing a lot of code. Afterall, the goal of coding is to write as little code as possible. But I'll add to that, + while making it still readable. Code is written once but it is read thousands of times probably!

So, no, I won't be converting all of my code to be using new syntax features. Ever. If my old code still works, I will continue to happily hack away code that looks like it was written in 2005. I will type out my ternary operator or null checks to the bitter end. I want the code to be explicitly defined with NO MAGIC. I can't see a reason anyone would argue to only use new language features when the old way still works. Therefore, my opinion must be correct ;)

It's not a feature of my favorite language

My favorite language is Go. It has been the same since I started using it in 2015 with the exception of adding generics (which are optional). There has been a lot of updates to tooling and to the command line, but that's not the language. And some things are a little bit verbose. But I'll never complain about it, and I'll never change my code to incorporate language changes if they ever do have an update for the

if err != nil {
    return err
}

construct.

There was a significant change to the library, and a feature to the runtime, where errors could be wrapped, and you can chain errors together. But that was a library feature, not a language change. It changed how errors were returned, like fmt.Errorf("there was an error in this thing. %w", err)   And I actually did go through and update all of my code to use that! Because the other way to wrap errors was dependent on a third party "pkg/errors" package, and I'd rather mostly use the standard library. Because it's fantastic. Anyway, new features bad, library changes ok, standard library features preferred, typing is fine. The end.