Deep Dive Into C# 9

As a dev that has worked with C# for the last 3 years I gotta say it's really amazing how productive you can be with it and how easy it was for me to pick it up when I joined the company I worked for at the time. Fun fact is that I didn't know it was a C# shop before going to the interview. During the interview I iterated multiple times that I don't know C# but have a vague idea (coming from a C++ background and done some projects with Java). I got the job and was doing normal feature work and bug fixing in the first week.

I really enjoy the language and the functional features that seep from F# are great. Right now C# is my goto language for fast prototyping of anything really. At this point I trust Microsoft to push the language in the right direction.

EDIT: A bit more detail and typos

I’m not sure we need initonly.

Constructors are a design pattern that works and is intuitive at this point. Fair enough there are differences, but the overlap in use case is significant enough that I don’t think it warrants a rival implementation of a core language feature.

The irony of me complaining about it is that I’d much prefer we get proper object composition by letting extension methods support extended state, which would rival dependency injection in its current form.

This would overturn the apple cart even more but it’s long overdue - I implemented this years ago by using conditional weak tables but didn’t trust it even in my own work solely because if MS isn’t standing over the implementation then I’ve no way of knowing how the GC is going to handle orphaned references over time.

Example:

A car has five (obvious) wheels, only four of which have tyres and rims.

Modelling this from interfaces and injected dependencies on a parent class is a laborious anti-pattern that C# still forces me into.

I love C#, but this could be so much better.

I like all the new features C# is getting over the years but the language is getting gigantic, almost like C++. It's perfectly possible to write code that looks almost alien to somebody that has 5 years of professional experience with the language. Also the null-hardening is a bit bulky compared to languages that had it from the get-go.

Quite honestly it really pisses me off how C# is evolving and to me this is a clear indication that Microsoft has still a largely wrong mindset in divdev.

C# was once a great language, but today it is so bloated with features that there is no clear way anymore on doing a single thing. Everything in C# has 3-10 different ways of doing it with huge BUTs, making the language harder and harder to learn for beginners.

It doesn't even make sense to make C# more funcitonal. It's trying to be too many things at the same time. It's almost like an obsession which Microsoft has with C#. Everything great they see somewhere they just shoehorn it into C# and actually really harming the language. What happened to just being a good OO language. .NET already has two other languages, one is functional and you can use F# and C# side by side in a project. What is the purpose of mudding C# to a point where nobody really knows anymore how to write clean and good C# code?

Honestly, I see C# developers constantly re-writing and re-designing their code for the sake of rewriting because there's constantly a new way of doing something. C# developers are like Java developers, spending so much time thinking how to write a feature instaed of just getting on with the work.

.NET Core is great, but .NET, C# and Microsoft in general is still the same old shit plagued by the same old MSFT mindset.

If developers want to write great applications then choose anything but .NET (Core), because in C# you'll constantly be chasing and re-writing existing code because things change for the sake of changing without really making the application any better.

.NET Core itself and ASP.NET Core is still changing so much that it's just tiring.

It's not specific to C#.

Every language seems to start out as a crisp new tool for solving a well chosen specific set of problems. Then over the years with each release a new set of use/edge cases get covered by introducing new concepts and syntax. And while each of these has its own merits, in aggregate they turn the system gradually into an unapproachable behemoth of opaque incantations.

And so the wheel turns and we all start over the process with a crisp new language that targets a well chosen smaller set of use cases ....

What bugs me is the too-strong coupling between the language and the run-time environment.

(Non-)nullable references are a perfect example. They could have been supported on the old .NET Framework, but MS chose to only officially support them under .NET Core (will be .NET 5 soon).

I have a library that is used in both "legacy" (.NET Framework, never to be ported to .NET Core) and "new" (.NET Core or soon-to-be .NET Core) projects. It makes perfect sense to annotate it for nullability and it doesn't need any of the other C# 8 features that depend on .NET Core. But I can't (officially) do it, even though Mads Torgersen himself wrote:

https://devblogs.microsoft.com/dotnet/embracing-nullable-ref...

You also have to set the language version to C# 8.0, of course, and that is not a supported scenario when one of the target versions is below .NET Core 3.0. However, you can still do it manually in your project settings, and unlike many C# 8.0 features, the NRT feature specifically happens to not depend on specific elements of .NET Core 3.1.

And C# edges closer still to F#

F# should be Microsofts main language, not C# It's a great language that doesn't get enough attention IMO.

I'd much rather prefer them to spend their time to add stuff to the CLR to remove the boiler code required for simple things.

We need more of the likes of "System.IO.File.ReadAllLines()", one liner functions that take care of the most common things. Like if you want to encrypt with AES you need a 8-10 lines of codes, if you want to convert a byte array to a hex string or do case insensitive string comparisons, you need to create your own helper functions, etc. Until recently there was no json serializer out of the box.

For some of the features mentioned here, I can only wonder how many developers will really use them, while the cost is to make the syntax even more cryptic to a beginner.

New mainstream languages like TypeScript, Rust, Kotlin, etc. People just opened the Pandora box of advanced types like discriminated union and intersection types.

There's no turning back. People will soon find they need more and more type operators, generics, and all kinds of type-level things. Each concrete operator or construct solves several specific type problems, and then introduces new ones. Until people realize dependent type is a thing.

Initonly seems to be a fix for what readonly should have been.

I never understood why readonly did not allow during initialization, especially since initializing values is often used in place of a proper constructor, and is understood to be something that happens at construction.

But there must have been a use case they were targeting that I'm just not familiar with.

When I first tried to use readonly, I actually expected it to behave the way initonly would now.

I dislike that they (want to) implemented records with classes instead of special casing some kind of struct.

What's the difference between initonly and const?

what I'd like to know is whether new C# 9 will require VS upgrade and/or .Net Core upgrade above 3.