
Deep Dive Into C# 9 - alugili
https://www.c-sharpcorner.com/article/deev-dive-into-c-sharp-9/
======
_hao
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

~~~
davedx
Similar experience here. Joined company as a front end developer but our team
generally needs a lot more back end work than front end, so I decided to give
it a try. Because it's .net core I can work on it just fine on my MacBook, I
have MSSQL in a docker image and do development in Rider. Within a relatively
short time I was also contributing and nowadays I'm more back end than front
end.

C# is a great language indeed.

------
headmelted
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.

~~~
jimbobimbo
Initonly is a great feature that prevents ctors from growing into the
unmaintainable soup of optional args, which inevitably happens as class gets
used more while being worked on at the same time.

~~~
copperx
What are ctors? And were they introduced with initonly?

~~~
ResidentSleeper
The term ctor refers to good old type constructors. It's a common
abbreviation, and it's even the keyword for defining constructors in .Net IL.

------
dep_b
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.

~~~
GordonS
I work with C# daily, and I don't really feel like this. In general, I really
like how C# has evolved over the years.

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.

~~~
tigershark
I don’t like the new record and DU features at all. They just tried to copy F#
but the implementation is ridiculously verbose and heavy. Much better if they
used all those efforts to finally introduce type classes or something
equivalent in F#.

~~~
GordonS
I meant I like the features that have actually made it into the spec so far -
all the stuff in the article is still at the proposal stage.

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.

------
dustinmoris
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.

~~~
NicoJuicy
You don't have to, asp.net mvc still works. WPF, ..

I think the big changes between .net framework and . Net Core weren't that big
for a project.

And it got a lot faster.

~~~
dustinmoris
I'm not talking about the changes between .NET and .NET Core. As far as I'm
concerned .NET doesn't exist to me anymore and it's not even worth talking
about.

I am angry that .NET Core keeps changing faster than Kim Kardashian changes
her outfits. First they focused on making .NET Core all about ASP.NET with a
clear focus on MVC and making everything super granular. Then they didn't like
how granular it was and started to put lots of featurs into smaller pacakges
again. Then they keep re-inventing things. First introduce Newtonsoft Json
into the default .NET Core stack. Then rewrite everything. The webhost model
keeps constnantly changing. The ASP.NET Core team now is realising that people
hate MVC and they are splitting out more features from MVC into more basic
ASP.NET Core features, which is why routing has completely changed again with
endpoint routing. Honestly nothing is constant, not even for 6 months. Every
version of .NET Core almost requires a developer to completely rewrite their
Startup.cs class. It's just ridiculous.

The reason for all of this is old MSFT thinking. It's not bloody rocket
science, people have been saying it for years that they don't want to be
forced into MVC, they want things to be more lightweight, bla bla bla. But
obviously MSFT cares more about making a shit hello world demo at BUILD and
therefore they first must hack together ASP.NET Core which was mostly just
about MVC before being allowed to build the core platform to something that is
actually useful to others.

They'll constantly keep changing the fundamentals, moving the carpet under
developers feet and distracting businesses with stupid useless excercises or
rewriting shit instead of just creating a stable base platform on which people
can freely build applications and actually focus on their own apps.

~~~
Roonerelli
that is quite a rant for someone who feels its not even worth talking about

~~~
Nelkins
I think he meant specifically .NET framework, the older .NET runtime.

------
PeterStuer
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 ....

~~~
erokar
This doesn't happen to every language. C# is extreme in this regard.

And there are languages that are deliberately conservative about adding new
features, like Go, Elixir and even Python to some extent. Though I think Go is
too far on the other end of the spectrum, I always prefer languages with a
small, simple core.

C# seems to just constantly throw everything new in.

~~~
thomasz
It really isn't that extreme. Change happens to almost all widely used
languages. Just look how c++, java, js and php have changed in the last 20
years. Furthermore, the designers do not constantly throw in new stuff. The
change is rather gradual, and the features that are introduced have all been
proven to work in other, more experimental languages, most often whole decades
after they were introduced.

~~~
erokar
C# is certainly on the maximalist end of the spectrum. It already has classes
and structs and now adds records. That's at least one, possibly two, too many
in my book.

But hey, some seem to prefer to have all these different ways of doing things
and I'm not the one to tell them what to like or not. I don't have to use C#
myself.

~~~
thomasz
The proposed record types are just regular types with minimal changes to the
initialization syntax. It's not like the divide between value types
(``struct`` ) and reference types (``class``), which indeed have quite
different semantics. You can argue that this is too much, but IMHO you need
some way to guarantee that value types will behave like primitives without
introducing a massive burden on the gc.

------
branko_d
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...](https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-
types/)

 _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._

~~~
Mindless2112
Feel free to express your support at [1]. Although I'm not very optimistic
that NRT in 7.x will happen, more support would help.

[1]
[https://github.com/dotnet/csharplang/issues/2995](https://github.com/dotnet/csharplang/issues/2995)

------
LandR
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.

~~~
sedatk
F# is intentionally cumbersome for imperative/OOP programming which makes it
impractical for many project types.

~~~
adgasf
Not at all. The class definition syntax is very terse and you can use the
mutable keyword for imperative programming.

In fact, I think F# is a _better_ imperative language than C#, if you choose
to use it that way.

~~~
StreamBright
Yep this is my experience as well. isNull make it easy to pattern match on
null, the only thing I really needed to have a terse way of dealing with
outside word, either C# modules or IO that can have nulls. I was shocked how
smooth everything is. I was productive maybe in 2 days without prior knowledge
of the entire MS/.NET/C# world. The reason why I chose F# was because of the
similarity to OCaml's syntax.

------
cm2187
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.

~~~
bathtub365
I’d rather they leave this kind of functionality to libraries than to include
every possible thing they think people will use the language for.

~~~
cm2187
The “battery included” approach worked well for python. Yeah sure, you can
always create your own dlls and load a bunch of nuget packages every time. But
it’s cumbersome for small projects and it makes code snippets non shareable.

------
namelosw
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.

------
ijidak
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.

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

~~~
kevingadd
It looks like records can also be structs, so it's a matter of taste (and
competence) whether you make your records classes. See mentions here
[https://github.com/dotnet/csharplang/blob/master/proposals/r...](https://github.com/dotnet/csharplang/blob/master/proposals/records.md)
of the ability to make them structs, not just classes.

~~~
fiveminds
yes records can be class or structs

------
jakobmi
What's the difference between initonly and const?

~~~
arethuza
Const is fixed at compile time, it looks like initonly is like readonly but
can be used outside of a constructor.

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

~~~
mcraiha
Most of these are just syntactic sugar, since compilers can just generate IL
that is compatible with existing CLR. So language server and compiler update
should be enough in most cases.

But e.g. native ints will most likely require CLR update since I assume you
can use native ints with reflection.

