5 ms·

Absolutely agree. Modern C# language design feels very much lacking in vision or direction. It's mostly a bunch of shiny-looking language features being bolted

Absolutely agree. Modern C# language design feels very much lacking in vision or direction. It's mostly a bunch of shiny-looking language features being bolted on, all in ways that make the language massively more complex. Just look at this feature: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-15#collection-expression-arguments https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... Was this needed? Was this necessary? It's reusing an existing keyword, fine. It's not hard to understand. But it adds a new syntax to a language that's already filled to the brim, just to save a few keystrokes? Try teaching someone C# nowadays. Completely impossible. Really, I wish they would've given F# just a tenth of the love that C# got over the years. It has issues but it could've been so much more.

raincole 6mo ago
> Try teaching someone C# nowadays. Completely impossible. Really, I wish they would've given F# just a tenth of the love that C# got over the years If they actually put effort in F#, it would have reached "unteachable" state already :)
- NanoCoaster 6mo ago
  Haha, yeah, maybe :) I would've loved an F# that found a way to improve on the performance issues, especially when using computation expressions. That and, either, a deeper integration of .NETs native OOP subtyping, or some form of OCaml-like module system, would have been enough to make it an almost perfect language for my tastes. Obviously, these are big, and maybe impossible, issues. But Microsoft as a whole never really dedicated enough resources to find out. I feel for the people still working on it, their work is definitely appreciated :)
  - LunicLynx 6mo ago
    My knowledge on functional languages is limited, but as I understand it, it’s possible to formulate expressions that are basically NP problems? And hence impossible to speed up? So is it a F# issue or inherent to functional programming?
    - NanoCoaster 6mo ago
      AFAIK it was a much more down-to-earth thing. The implementation of computation expressions in F# compiled down to lots of function objects that were not very GC-friendly. Or something like that. To be honest, I never looked that deeply at it :) Looking at it, the MS docs contain something about this exact topic, so maybe it's better nowadays: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions#compiling-computation-expressions-efficiently https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... Sadly, I haven't used F# for years at this point so I can't speak to the current state.
      - throw234234234 6mo ago
        F# has since gotten Functional State machines which make many computation expressions more efficient (https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0/FS-1087-resumable-code.md https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0...). Been there a while. I actually think F# has received some "love" over the recent years contrary to some on this forum; that feature being an example. My view, maybe unpopular but in the age of AI maybe less so, is there is a diminishing returns to language features anyway w.r.t complexity and the use cases that new feature will actually apply for. F# in my mind and many other languages now for that matter is pretty much there or are almost there; the languages are converging. When I used F# I liked how it unified features and tried to keep things simple. Features didn't feel "tacked on" mostly with some later exceptions. Last time I used F# a few libraries started adopting this for their CE's (e.g. IcedTasks library, etc).
LunicLynx 6mo ago
You are looking at it from what you know about C#, the goal is how can you reduce (delete) all this to make the language more accessible. For you it may be fine to write: List<string> strs = new List<string>(); And sure if you have been using C# for years you know all the things going on here. But it shouldn’t be an argument that: List<string> strs = []; Is substentionally easier to grasp. And that has been the theme of all changes. The example you point out is the advanced case, someone only needs in a very specific case. It does not have a lot todo with learning the language. The language design team is really making sure that the features work well throughout and I think that does deserve some credit.
- NanoCoaster 6mo ago
  I'm 100% on board with the [] syntax. I'm not on board with adding the syntax for passing arguments to the constructor within that syntax. I agree that = [] is perfectly fine syntax. But I would definitely argue that: [with(capacity: values.Length * 2), .. is non-intuitive and unnecessary. What other language is there that has this syntax? Alternatively, is this a natural way of writing this? I wouldn't say so. My main language in my free time is Rust, a few years ago it was F#. So, I'm absolutely open to other syntax ideas. But I feel that there has to be a direction, things have to work together to make a language feel coherent. Another example would be Clojure, which I started learning a few months ago (before we all got swept up in AI FOMO :D). Clojure as a language feels very coherent, very logical. I'm still a beginner, but every time I learn something about it, it just makes sense. It feels as if I could have guessed that it works this way. I don't get that feeling at all in many of the new features of C#. > The example you point out is the advanced case, someone only needs in a very specific case. It does not have a lot todo with learning the language. I disagree. When learning the language, you're going to have to read other people's code and understand it. It's the same basic principle, but, I'd argue, much worse in C++. Yes, in theory, you don't have to understand SFINAE and template metaprogramming and (now) concepts and all those things. You could just work in a subset of C++ that doesn't use those things. But in practice, you're always going to have issues if you don't.
  - HauntingPin 6mo ago
Pay08 6mo ago
This is why I have always been leery of C# and continued using Java instead. C#s development has always seemed very haphazard and kitchen sink mentality to me.
twisteriffic 6mo ago
> Try teaching someone C# nowadays. Completely impossible. That isn't a reasonable take. Failing to teach a language by enumerating all its features is an indictment of the instructor and not the language.
- NanoCoaster 6mo ago
  I guess I overdramatized the situation a bit :) It's a passionate topic for me; as somebody who has been using C# at work for 10 years now, I'm just not happy with the direction the language has been taking. You're right, it's not impossible and in general it's not among the hardest languages to teach. But I would argue, it is heading that way. There are already so many ways to do things in C#. For example, try explaining the difference between fields and properties; sounds easy, but making it really stick is quite a challenge. And that's one of the simplest cases (and a feature I'm 100% in favor of). And you will have to explain it at some point, because real codebases contain these features so at some point, it'll need to be taught. Learning a language doesn't stop when you can write a simple application, it continues up until at least you're comfortable with most of its features and their practical use. The quicker one can get people to that point, the easier the language is to teach, I'd argue. One might also argue that learning never really stops, but that's beside the point :) In general, my issue isn't any specific feature. C# has many features that are non-trivial to learn but still great: value types, generics, expression trees. Source generators are relatively new and I like them! I like most of the things they're doing in the standard library or the runtime. Spans everywhere is a nice improvement, most new APIs are sensible and nice to use and the runtime just keeps getting faster every release. Great. It's more the pure C# language side I have an issue with. But every language has a budget of innovation and cognitive load that you can expect people to deal with, and C# is not using its budget very wisely in my opinion.
  - Metasyntactic 6mo ago
    > I guess I overdramatized the situation a bit :) It's a passionate topic for me; as somebody who has been using C# at work for 10 years now, I'm just not happy with the direction the language has been taking. You should come engage with us on this then :) We do all our design in the open on github. And a lot of us are available to chat and discuss all this stuff in Discord and the like :) > C# is not using its budget very wisely in my opinion. I can promise you. Every feature you think are great had similar detractors over the years. Every Single One :)
deleted 6mo ago
[deleted]
jayd16 6mo ago
> Try teaching someone C# nowadays Do you actually have a datapoint of someone failing to understand C# or are you just hyperbolically saying its a big language? The tooling, the ecosystem, the linting, the frameworks. Its a very easy language to get into...
- mrsmrtss 6mo ago
  Exactly, we have had many interns with zero C# experience become fluent in a couple of months and those with prior TypeScript or Java experience get there even faster. A good IDE (like Rider) helps also.
Metasyntactic 6mo ago
Hi there! One of the C# language designers here, working on unions. And the author of that feature :D So I'm happy to discuss the thinking here. It's not about saving keystrokes. It's about our decision that users shouldn't have 7 (yes 7) different ways of creating collections. They should just be able to target at least 99% of all cases where a collection is needed, with one simple and uniform syntax across all those cases. When we created and introduced collection expressions, it was able to get close to that goal. But there were still cases left out, leaving people in the unenviable position of having to keep their code inconsistent. This feature was tiny, and is really intended for those few percent of cases where you were stuck having to do things the much more complex way (see things like immutable builders as an example), just to do something simple, like adding an `IEqualityComparer<>`. This was also something that would become even more relevant as we add `k:v` support to our collections to be able to make dictionaries.
pjmlp 6mo ago
I think they now have an issue getting new language features every year, this is how it comes to be.

raincole 6mo ago

> Try teaching someone C# nowadays. Completely impossible. Really, I wish they would've given F# just a tenth of the love that C# got over the years If they actually put effort in F#, it would have reached "unteachable" state already :)

NanoCoaster 6mo ago
Haha, yeah, maybe :) I would've loved an F# that found a way to improve on the performance issues, especially when using computation expressions. That and, either, a deeper integration of .NETs native OOP subtyping, or some form of OCaml-like module system, would have been enough to make it an almost perfect language for my tastes. Obviously, these are big, and maybe impossible, issues. But Microsoft as a whole never really dedicated enough resources to find out. I feel for the people still working on it, their work is definitely appreciated :)
- LunicLynx 6mo ago
  My knowledge on functional languages is limited, but as I understand it, it’s possible to formulate expressions that are basically NP problems? And hence impossible to speed up? So is it a F# issue or inherent to functional programming?
  - NanoCoaster 6mo ago
    AFAIK it was a much more down-to-earth thing. The implementation of computation expressions in F# compiled down to lots of function objects that were not very GC-friendly. Or something like that. To be honest, I never looked that deeply at it :) Looking at it, the MS docs contain something about this exact topic, so maybe it's better nowadays: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions#compiling-computation-expressions-efficiently https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... Sadly, I haven't used F# for years at this point so I can't speak to the current state.
    - throw234234234 6mo ago
      F# has since gotten Functional State machines which make many computation expressions more efficient (https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0/FS-1087-resumable-code.md https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0...). Been there a while. I actually think F# has received some "love" over the recent years contrary to some on this forum; that feature being an example. My view, maybe unpopular but in the age of AI maybe less so, is there is a diminishing returns to language features anyway w.r.t complexity and the use cases that new feature will actually apply for. F# in my mind and many other languages now for that matter is pretty much there or are almost there; the languages are converging. When I used F# I liked how it unified features and tried to keep things simple. Features didn't feel "tacked on" mostly with some later exceptions. Last time I used F# a few libraries started adopting this for their CE's (e.g. IcedTasks library, etc).

LunicLynx 6mo ago

You are looking at it from what you know about C#, the goal is how can you reduce (delete) all this to make the language more accessible. For you it may be fine to write: List<string> strs = new List<string>(); And sure if you have been using C# for years you know all the things going on here. But it shouldn’t be an argument that: List<string> strs = []; Is substentionally easier to grasp. And that has been the theme of all changes. The example you point out is the advanced case, someone only needs in a very specific case. It does not have a lot todo with learning the language. The language design team is really making sure that the features work well throughout and I think that does deserve some credit.

NanoCoaster 6mo ago
I'm 100% on board with the [] syntax. I'm not on board with adding the syntax for passing arguments to the constructor within that syntax. I agree that = [] is perfectly fine syntax. But I would definitely argue that: [with(capacity: values.Length * 2), .. is non-intuitive and unnecessary. What other language is there that has this syntax? Alternatively, is this a natural way of writing this? I wouldn't say so. My main language in my free time is Rust, a few years ago it was F#. So, I'm absolutely open to other syntax ideas. But I feel that there has to be a direction, things have to work together to make a language feel coherent. Another example would be Clojure, which I started learning a few months ago (before we all got swept up in AI FOMO :D). Clojure as a language feels very coherent, very logical. I'm still a beginner, but every time I learn something about it, it just makes sense. It feels as if I could have guessed that it works this way. I don't get that feeling at all in many of the new features of C#. > The example you point out is the advanced case, someone only needs in a very specific case. It does not have a lot todo with learning the language. I disagree. When learning the language, you're going to have to read other people's code and understand it. It's the same basic principle, but, I'd argue, much worse in C++. Yes, in theory, you don't have to understand SFINAE and template metaprogramming and (now) concepts and all those things. You could just work in a subset of C++ that doesn't use those things. But in practice, you're always going to have issues if you don't.
- HauntingPin 6mo ago

Pay08 6mo ago

This is why I have always been leery of C# and continued using Java instead. C#s development has always seemed very haphazard and kitchen sink mentality to me.

twisteriffic 6mo ago

> Try teaching someone C# nowadays. Completely impossible. That isn't a reasonable take. Failing to teach a language by enumerating all its features is an indictment of the instructor and not the language.

NanoCoaster 6mo ago
I guess I overdramatized the situation a bit :) It's a passionate topic for me; as somebody who has been using C# at work for 10 years now, I'm just not happy with the direction the language has been taking. You're right, it's not impossible and in general it's not among the hardest languages to teach. But I would argue, it is heading that way. There are already so many ways to do things in C#. For example, try explaining the difference between fields and properties; sounds easy, but making it really stick is quite a challenge. And that's one of the simplest cases (and a feature I'm 100% in favor of). And you will have to explain it at some point, because real codebases contain these features so at some point, it'll need to be taught. Learning a language doesn't stop when you can write a simple application, it continues up until at least you're comfortable with most of its features and their practical use. The quicker one can get people to that point, the easier the language is to teach, I'd argue. One might also argue that learning never really stops, but that's beside the point :) In general, my issue isn't any specific feature. C# has many features that are non-trivial to learn but still great: value types, generics, expression trees. Source generators are relatively new and I like them! I like most of the things they're doing in the standard library or the runtime. Spans everywhere is a nice improvement, most new APIs are sensible and nice to use and the runtime just keeps getting faster every release. Great. It's more the pure C# language side I have an issue with. But every language has a budget of innovation and cognitive load that you can expect people to deal with, and C# is not using its budget very wisely in my opinion.
- Metasyntactic 6mo ago
  > I guess I overdramatized the situation a bit :) It's a passionate topic for me; as somebody who has been using C# at work for 10 years now, I'm just not happy with the direction the language has been taking. You should come engage with us on this then :) We do all our design in the open on github. And a lot of us are available to chat and discuss all this stuff in Discord and the like :) > C# is not using its budget very wisely in my opinion. I can promise you. Every feature you think are great had similar detractors over the years. Every Single One :)

deleted 6mo ago

[deleted]

jayd16 6mo ago

> Try teaching someone C# nowadays Do you actually have a datapoint of someone failing to understand C# or are you just hyperbolically saying its a big language? The tooling, the ecosystem, the linting, the frameworks. Its a very easy language to get into...

mrsmrtss 6mo ago
Exactly, we have had many interns with zero C# experience become fluent in a couple of months and those with prior TypeScript or Java experience get there even faster. A good IDE (like Rider) helps also.

Metasyntactic 6mo ago

Hi there! One of the C# language designers here, working on unions. And the author of that feature :D So I'm happy to discuss the thinking here. It's not about saving keystrokes. It's about our decision that users shouldn't have 7 (yes 7) different ways of creating collections. They should just be able to target at least 99% of all cases where a collection is needed, with one simple and uniform syntax across all those cases. When we created and introduced collection expressions, it was able to get close to that goal. But there were still cases left out, leaving people in the unenviable position of having to keep their code inconsistent. This feature was tiny, and is really intended for those few percent of cases where you were stuck having to do things the much more complex way (see things like immutable builders as an example), just to do something simple, like adding an `IEqualityComparer<>`. This was also something that would become even more relevant as we add `k:v` support to our collections to be able to make dictionaries.

pjmlp 6mo ago

I think they now have an issue getting new language features every year, this is how it comes to be.