> As a C# advocate I have to say, that the C# design team is doing an excellent job. The amount of syntax I see literally 1:1 taken over by dozen other languages is really impressive and evidence for that.
That would be the case for pretty much any language that has lots of features (provided that most of those features aren't completely terrible). A good design (at least for a mainstream language) also strives to minimise the number of features, not adding everything you can but only adding things you absolutely need. In the case of C#, many of its features are not widely adopted, and Java in particular will never adopt them.
Java's philosophy has always been to wrap an innovative runtime in a conservative language that only adds features late, after they've proven their worth elsewhere and when most mainstream programmers are ready for them, with the realisation that every added feature adds a cost to learning the language. That strategy has worked very well for Java, but .NET has a different strategy (a more adventurous language built on top of a less adventurous runtime). We'd rather spend two years thinking about how to avoid adding a new language feature than spend six months adding it. This "last-mover" strategy has helped us maintain our philosophy and keep the number of features small compared to C#. We strive to only add features that have a big bang-for-the buck and that, preferably, solve many problems at once, rather than add many features, each addressing a relatively small problem. For example, virtual threads have allowed us to avoid adopting async/await; records are allowing us to avoid adopting properties, and will likely help us avoid adding named and default parameters as a separate feature (which, in languages like C#, Swift, and Kotlin breaks binary compatibility/separate compilation).
I posted that in parallel. C# tries to be both, a system and application language. Java does not try that. Therefore, they can skip all the memory related topics quite quickly. And that wades out like 80% of the average joe unused features.
I would rather that they would give more support to F#, and improving the story on the Common Language Runtime between all existing MS languages, instead of rebooting the whole experience into C# Language Runtime.
F# goes right up with D as "most under-rated/under-recognized language of all time"
A lot of its features for functional programming got swallowed up in later C# versions, and it's the Red-Headed Stepchild of the CLR (let's pretend VB.NET doesn't exist).
MS allows it to exist but it's a second-class citizen on the CLR, and, I think, always will be =(
their numbers are simple .... C# has millions of developers, VB.NET 100ks and F# 10ks. They put their focus where their users are. They presented a slide deck once about that.
And F# was created as a research project and is a lot more community driven than C#. So if Microsoft starts putting more people onto that, I think a part of that community will also scream that they should stay out.
There were no users when C#, VB.NET and Managed C++ (replaced by C++/CLI on .NET 2.0), likewise there were no users per se when WinRT was created with another tooling and API surface than its Win32 and .NET counterparts.
I know those numbers, and can even refer to the blog post they were presented, if a big company like Microsoft wants people to use language XYZ, they can make it happen if management cares about it.
However they aren't caring enough to sort out the GUI civil war, so why would the .NET languages by any different, regarding coherent management across the board.
That would be the case for pretty much any language that has lots of features (provided that most of those features aren't completely terrible). A good design (at least for a mainstream language) also strives to minimise the number of features, not adding everything you can but only adding things you absolutely need. In the case of C#, many of its features are not widely adopted, and Java in particular will never adopt them.
Java's philosophy has always been to wrap an innovative runtime in a conservative language that only adds features late, after they've proven their worth elsewhere and when most mainstream programmers are ready for them, with the realisation that every added feature adds a cost to learning the language. That strategy has worked very well for Java, but .NET has a different strategy (a more adventurous language built on top of a less adventurous runtime). We'd rather spend two years thinking about how to avoid adding a new language feature than spend six months adding it. This "last-mover" strategy has helped us maintain our philosophy and keep the number of features small compared to C#. We strive to only add features that have a big bang-for-the buck and that, preferably, solve many problems at once, rather than add many features, each addressing a relatively small problem. For example, virtual threads have allowed us to avoid adopting async/await; records are allowing us to avoid adopting properties, and will likely help us avoid adding named and default parameters as a separate feature (which, in languages like C#, Swift, and Kotlin breaks binary compatibility/separate compilation).