alt Hacker NewsAbsolutely 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/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.
Replies
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.
> 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...
> 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 :)
> 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.
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.
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.