6 ms·

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

by dep_b 7y ago

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.

rklaehn 7y ago
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.
BinaryIdiot 7y ago
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. It's been an... interesting ride.
tasogare 7y ago
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.
- GordonS 7y ago
  > sometime I feel like there should be a fork, with a legacy C# You don't have to use language features you dislike. If you want to prevent them being used, you can set the c# language level to an old version using the LangVersion element in your csproj file. if working in a team, your team members are unlikely to thank you!
  - UK-Al05 7y ago
    Think it's more about preventing use of older features which you don't want. Not stopping use of the new stuff.
    - GordonS 7y ago
      That's not how I read the parent post at all?
  - ygra 7y ago
    Depends. If people on the team are using different versions of Visual Studio or the compiler, they will be thankful that they can still build the code. For us, the language features we can use internally are dictated by our own compiler to translate the code to JS and Java and yes, a null check is somewhat verbose compared to ?., but in such cases it can be important to restrict the language level, even if you could locally use a newer one. We're also, for compat reasons, building the code on the build server with basically VS 2010 to ensure that there's nothing in it that .NET 4.0 can't handle. Customers can sometimes be very_ conservative and value this kind of thing.
    - moron4hire 7y ago
      You can set the language level in your project settings. It's under the assembly information.
  - GordonS 7y ago
    Was on mobile and messed up italics in my parent comment (can't edit it now), it should have read: If you want to prevent them being used, you can[0] set the c# language level to an old version using the LangVersion element in your csproj file. [0] if working in a team, your team members are unlikely to thank you!
moksly 7y ago
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.
- goto11 7y ago
  That seems unrelated to the language of the library though.
  - moksly 7y ago
    The library was a part of .NET version 4.x and was then dropped when Microsoft wanted people to move to Azure. We had similar issues with the AD APIs in .NET. You’d think Microsoft would have extensive AD integration support for C#, but you’d be wrong. It’s nothing you can’t fix by overriding the standard libraries with extensions of your own, but it’s a lot of work. Which is kind of the opposite of why you’d pick C#. At least in my opinion, you pick it because it comes with a powerful IDE and powerful standard libraries, but it turns out that it doesn’t actually do that once you dig a little deeper than standard CRUD applications.
    - goto11 7y ago
      I feel you pain. But how would it have been any different if the library had been in Python?
tybit 7y ago
It seems like a catch 22 for language developers if you want to maintain backwards compatibility. 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.
- reallydontask 7y ago
  Some of the syntatic sugar will work in older versions as long as you've got a new version of Visual Studio, which was quite surprising to me when I realized. The problem is that sometimes it's hard to work out what is syntatic sugar and what isn't.
- quantified 7y ago
  A long-lived code base will end up containing different conventions for doing things based on the era the code was written in. I’m OK with that, the later code will (should) have, per screenful, higher clarity, more functionality and fewer bugs. I feel like there’s probably a good analogy with evolution of human languages and cultures around them. How many of us can read Beowulf in the original?
GordonS 7y ago
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.
- arethuza 7y ago
  "I really like how C# has evolved over the years" I completely agree - I rather like how C# and .Net is progressing - sure there are new features every so often that take time to learn but isn't that the same for absolutely everything.
- tigershark 7y ago
  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 7y ago
    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.
tumetab1 7y ago
Same here. 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? ¯\_(ツ)_/¯
- jolux 7y ago
  Expression-bodied members aren’t lambdas, they are just syntactic sugar for methods returning a single expression.
pjmlp 7y ago
My favourite eco-systems are Java, .NET and C++. 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.
- dep_b 7y ago
  > My favourite eco-systems are Java, .NET and C++. The only thing about Java that I really like is that you can not use it in it's ecosystem while not feeling like a second class citizen. Kotlin (I didn't use the other JVM languages so far) feels 100% supported while F# in Visual Studio is kind of rough. Java itself: hope I never have to work with it.
  - pjmlp 7y ago
    I don't have big hopes for Kotlin beyond Android (aka the KVM since #KotlinFirst). Platform languages always win long term, adopting what matters from guest languages, while exposing the platform without any additional FFI, IDE plugins, build tools, idiomatic wrapper libraries, new layers to debug,...

by dep_b 7y ago

rklaehn 7y ago

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.

BinaryIdiot 7y ago

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. It's been an... interesting ride.

tasogare 7y ago

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.

GordonS 7y ago
> sometime I feel like there should be a fork, with a legacy C# You don't have to use language features you dislike. If you want to prevent them being used, you can set the c# language level to an old version using the LangVersion element in your csproj file. if working in a team, your team members are unlikely to thank you!
- UK-Al05 7y ago
  Think it's more about preventing use of older features which you don't want. Not stopping use of the new stuff.
  - GordonS 7y ago
    That's not how I read the parent post at all?
- ygra 7y ago
  Depends. If people on the team are using different versions of Visual Studio or the compiler, they will be thankful that they can still build the code. For us, the language features we can use internally are dictated by our own compiler to translate the code to JS and Java and yes, a null check is somewhat verbose compared to ?., but in such cases it can be important to restrict the language level, even if you could locally use a newer one. We're also, for compat reasons, building the code on the build server with basically VS 2010 to ensure that there's nothing in it that .NET 4.0 can't handle. Customers can sometimes be very_ conservative and value this kind of thing.
  - moron4hire 7y ago
    You can set the language level in your project settings. It's under the assembly information.
- GordonS 7y ago
  Was on mobile and messed up italics in my parent comment (can't edit it now), it should have read: If you want to prevent them being used, you can[0] set the c# language level to an old version using the LangVersion element in your csproj file. [0] if working in a team, your team members are unlikely to thank you!

moksly 7y ago

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.

goto11 7y ago
That seems unrelated to the language of the library though.
- moksly 7y ago
  The library was a part of .NET version 4.x and was then dropped when Microsoft wanted people to move to Azure. We had similar issues with the AD APIs in .NET. You’d think Microsoft would have extensive AD integration support for C#, but you’d be wrong. It’s nothing you can’t fix by overriding the standard libraries with extensions of your own, but it’s a lot of work. Which is kind of the opposite of why you’d pick C#. At least in my opinion, you pick it because it comes with a powerful IDE and powerful standard libraries, but it turns out that it doesn’t actually do that once you dig a little deeper than standard CRUD applications.
  - goto11 7y ago
    I feel you pain. But how would it have been any different if the library had been in Python?

tybit 7y ago

It seems like a catch 22 for language developers if you want to maintain backwards compatibility. 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.

reallydontask 7y ago
Some of the syntatic sugar will work in older versions as long as you've got a new version of Visual Studio, which was quite surprising to me when I realized. The problem is that sometimes it's hard to work out what is syntatic sugar and what isn't.
quantified 7y ago
A long-lived code base will end up containing different conventions for doing things based on the era the code was written in. I’m OK with that, the later code will (should) have, per screenful, higher clarity, more functionality and fewer bugs. I feel like there’s probably a good analogy with evolution of human languages and cultures around them. How many of us can read Beowulf in the original?

GordonS 7y ago

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.

arethuza 7y ago
"I really like how C# has evolved over the years" I completely agree - I rather like how C# and .Net is progressing - sure there are new features every so often that take time to learn but isn't that the same for absolutely everything.
tigershark 7y ago
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 7y ago
  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.

tumetab1 7y ago

Same here. 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? ¯\_(ツ)_/¯

jolux 7y ago
Expression-bodied members aren’t lambdas, they are just syntactic sugar for methods returning a single expression.

pjmlp 7y ago

My favourite eco-systems are Java, .NET and C++. 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.

dep_b 7y ago
> My favourite eco-systems are Java, .NET and C++. The only thing about Java that I really like is that you can not use it in it's ecosystem while not feeling like a second class citizen. Kotlin (I didn't use the other JVM languages so far) feels 100% supported while F# in Visual Studio is kind of rough. Java itself: hope I never have to work with it.
- pjmlp 7y ago
  I don't have big hopes for Kotlin beyond Android (aka the KVM since #KotlinFirst). Platform languages always win long term, adopting what matters from guest languages, while exposing the platform without any additional FFI, IDE plugins, build tools, idiomatic wrapper libraries, new layers to debug,...