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.
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.
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.
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.
Does ConditionalWeakTable<TKey,TValue> class from the current .NET do what you want? It can attach arbitrary state to objects, you can do that in extension methods or any other places.
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.
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.
Same feeling. I've started C# by myself around 2008 first with the command line compiler then VS 2008. My skills matured at the same time the language evolve, and while I always lag a few years behind the new features I still can keep up to date.
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.
I used to write C# professionally for many years. Stopped after moving to a new company right about C# 4. I had to pick it up again earlier this yeah and I gotta say... wow. It has so, so much more. Some I like, some kinda meh and I know for sure my old habits are not always the greatest.
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 absolute worst part is all the legacy bits that Microsoft made and later abandoned. We set up a Microsoft Service Center Orchestration service for Windows 2012, and while we’re migrating it to Azure now, the C# library that handled authentication became obsolete in 2014, at least to Microsoft. Which means that even with 100% Microsoft tech, you still have to build your own library extensions if Microsoft moves another direction.
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.
They lost me when they added indexed properties for better office interop, yet neglected core CLR runtime performance optimisations like struct inlining for several years.
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? ¯\_(ツ)_/¯
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.
Long time C# dev and team lead here. Can't say I agree with you.
C# has become a great language for the "functional core, imperative shell" way of doing things. That means it has to be a hybrid language. F# is more tilted toward functional-land, C# is tilted toward imperative/OO-land. Both have their place.
If C# devs are constantly rewriting their code, that means there's no vision for that particular codebase. It's true that there are many different ways to "do C#." So, a developer or team needs to pick a particular way (OO classic, or functional core/imp shell, or functional, or minimal golang-style) and stick to it. It's more of an architectural challenge than you would get with a language that can only do one of those. The upside is, your system can blend approaches as necessary, all within one codebase. Every module of the system is perfectly suited to its task, from philosophy all the way down. Of course there's the danger of it becoming a mess, but the risk is worth the reward IMO. With great power comes great responsibility as they say.
I have been programming in C# for 13 years now. Majority of new features are just syntactic sugar. Code I wrote in 2009 is still running even in 2019. I don't rewrite my applications in a newer version each time there is a new release of .NET Framework. I only use the latest language features on new projects. Problem starts when I am in a support and maintenance job because I quickly fall behind. When I go for interviews, I get asked questions about new features of the language, which I feel is unfair.
I feel sorry for new Developers because I learnt those features bit-by-bit over the years and they are expected to learn them at a go. It is also hard to understand why a syntatic was introduced when you never used the way it used to be done.
I read your comment twice trying to fully understand your perspective. I've been working in C# off an on now for about 10 years and as a guy who "grew up" on version 2, I mostly use the core features, but wow do I love some of the new features. The introduction of Tuples in 7 changed the way I program so dramatically in a positive way - every has their own style for me Tuples as per my example allow me to return a code + the data. I welcome the improvements and think MS is doing an amazing job.
I understood from a Microsoft conference I attended (regrettably I forget the speaker) that their decision to incorporate new features so rapidly was a very conscious decision, based on what I thought to be a quite perceptive look at the landscape - to some extent C# has always been a reaction to Java; a language that often comes under fire for its extremely slow and cautious incorporation of features.
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 ....
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.
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:
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.
For that to happen, functional languages have to take over. Most people are just not into functional programming languages. They prefer imperative programming languages. I feel Microsoft is doing a great job of slowly forcing C#.NET Developers to learn F#. It was so easy for me to learn F#. It was so strange that I was able to understand a functional programming language. I didn't have luck learning other functional languages.
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.
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... of the ability to make them structs, not just classes.
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.
[+] [-] _hao|6 years ago|reply
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|6 years ago|reply
C# is a great language indeed.
[+] [-] headmelted|6 years ago|reply
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|6 years ago|reply
[+] [-] lostmsu|6 years ago|reply
The syntax looks outright ugly in many examples.
[+] [-] Const-me|6 years ago|reply
[+] [-] UK-Al05|6 years ago|reply
[+] [-] dep_b|6 years ago|reply
[+] [-] GordonS|6 years ago|reply
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.
[+] [-] tasogare|6 years ago|reply
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.
[+] [-] BinaryIdiot|6 years ago|reply
It's been an... interesting ride.
[+] [-] pjmlp|6 years ago|reply
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.
[+] [-] moksly|6 years ago|reply
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.
[+] [-] rklaehn|6 years ago|reply
[+] [-] tybit|6 years ago|reply
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.
[+] [-] tumetab1|6 years ago|reply
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? ¯\_(ツ)_/¯
[+] [-] dustinmoris|6 years ago|reply
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.
[+] [-] m_fayer|6 years ago|reply
C# has become a great language for the "functional core, imperative shell" way of doing things. That means it has to be a hybrid language. F# is more tilted toward functional-land, C# is tilted toward imperative/OO-land. Both have their place.
If C# devs are constantly rewriting their code, that means there's no vision for that particular codebase. It's true that there are many different ways to "do C#." So, a developer or team needs to pick a particular way (OO classic, or functional core/imp shell, or functional, or minimal golang-style) and stick to it. It's more of an architectural challenge than you would get with a language that can only do one of those. The upside is, your system can blend approaches as necessary, all within one codebase. Every module of the system is perfectly suited to its task, from philosophy all the way down. Of course there's the danger of it becoming a mess, but the risk is worth the reward IMO. With great power comes great responsibility as they say.
[+] [-] madiathomas|6 years ago|reply
I feel sorry for new Developers because I learnt those features bit-by-bit over the years and they are expected to learn them at a go. It is also hard to understand why a syntatic was introduced when you never used the way it used to be done.
[+] [-] xmichael99|6 years ago|reply
[+] [-] crc32|6 years ago|reply
I understood from a Microsoft conference I attended (regrettably I forget the speaker) that their decision to incorporate new features so rapidly was a very conscious decision, based on what I thought to be a quite perceptive look at the landscape - to some extent C# has always been a reaction to Java; a language that often comes under fire for its extremely slow and cautious incorporation of features.
[+] [-] NicoJuicy|6 years ago|reply
I think the big changes between .net framework and . Net Core weren't that big for a project.
And it got a lot faster.
[+] [-] PeterStuer|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] pjmlp|6 years ago|reply
Programming languages are software products as well, and to stay relevant they need to cover use cases that make developers "buy" them.
[+] [-] branko_d|6 years ago|reply
(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.
[+] [-] Mindless2112|6 years ago|reply
[1] https://github.com/dotnet/csharplang/issues/2995
[+] [-] LandR|6 years ago|reply
F# should be Microsofts main language, not C# It's a great language that doesn't get enough attention IMO.
[+] [-] madiathomas|6 years ago|reply
[+] [-] sedatk|6 years ago|reply
[+] [-] cm2187|6 years ago|reply
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|6 years ago|reply
[+] [-] non-entity|6 years ago|reply
Funny part is VB.NET gas had that for a while
[+] [-] namelosw|6 years ago|reply
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|6 years ago|reply
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|6 years ago|reply
[+] [-] kevingadd|6 years ago|reply
[+] [-] dullgiulio|6 years ago|reply
[+] [-] jakobmi|6 years ago|reply
[+] [-] arethuza|6 years ago|reply
[+] [-] polskibus|6 years ago|reply
[+] [-] mcraiha|6 years ago|reply
But e.g. native ints will most likely require CLR update since I assume you can use native ints with reflection.
[+] [-] fiveminds|6 years ago|reply