In general, being successful and popular had little to do with how well a PL is designed. Visual Basic, PHP, and even C are some historical examples that I have plenty of personal experience with.
Perhaps, but it is fairly easy to design a product for a small, self-selecting group of fans who find the aesthetics appealing and so declare the design good for their taste. Unless a language becomes heavily used in codebases that are maintained for years by a large variety of programmers, it's hard to tell how well it is actually designed as a mass-appeal product.
Two of the three languages you mentioned weren't able to attain nearly the same success as Java for as long a duration. I'd give C a similar success score because what it lacks in popularity it still makes up for in longevity, being almost twice as old. There are good reasons for why C is still as popular as it is. For example, in its domain -- which requires compilation to exotic architectures -- "good design" entails being able to easily implement efficient compilers.
And to be clear, I'm not advocating for aesthetics here. It's not like C# is a model of purity, either; but I would say that their choices over the years have been more pragmatic overall from the perspective of someone who needs to write readable, good quality code without jumping through too many hoops or getting lost in the verbiage.
I personally don’t agree with that, C# is very “impulsive” at adding new features, which sounds cool in isolation, but makes the language significantly more complex to understand, and has non-intuitive interactions with other features.
I think C# is quick at going the C++ way, and there is no return from there if we guarantee compatibility.
I much prefer Java’s approach, where yeah, at times one might lack some syntactic sugar/nicety (often greatly overcome by IDE/tooling’s advancements), but over time they do add important ones, but only commit to features that have been earnestly tried and sustainable.
To be fair to Microsoft, they have favoured rich, complex languages for a long time now. They were probably the biggest champions of C++ and TypeScript also doesn't seem to be going down a particularly minimalistic route (an understatement). They're fans of rich languages, and while such languages are not my cup of tea, they do have a large audience (although I think it's a large minority audience).
My point is that when people say that one language is technically superior to another, what they really mean is that it's superior in the technical aspects that they themselves value more than the aspects where the other language is technically superior. This is all fine, except that these personal preferences aren't distributed equally. This is a little like the Betamax vs. VHS debate. Sure, Betamax had a superior picture quality that some valued, but VHS had a superior recording time, which others valued but that latter group was bigger.
As for C# -- strong disagree there. I think they're making the classic mistake of trying to solve every problem in the language and soon, resulting in a pretty haphazard collection of features, quite a few of them are anti-features, making up a pretty complicated language. For example, they have both properties and records, while in Java we figured that by adding records we'll both direct people toward a more data-oriented form of programming and at the same time make the problem of writing setters so much less annoying to the point it shouldn't be addressed by the language (while properties have the opposite effect of encouraging mutation). They've painted themselves into a very tight corner with async/await (the same with P/Invoke, which constrained their runtime's design making it harder to add user-mode threads), and I think they've made a big security mistake with interpolation -- something we're trying to avoid with a substantially different design. Also, while richer languages do have a lot of fans, all else being equal more people seem to prefer languages with fewer features. Our hypothesis is that it's better to spend a few years thinking how to avoid adding a language feature (like async/await or properties) than to spend a few months adding it.
Also, every feature you add constrains you a little in the future (and every language makes this tradeoff early when it's trying to acquire users, but once it's established you need to be more careful). That's why we try to keep the abstraction level high at the expense of a quicker and tighter fit to a particular environment. This delays some things, but we believe it keeps us more flexible to adapt to future changes. It's like having an adaptation budget that you don't want to fully spend on your current environment (I think P/Invoke and properties are such examples of overfitting that pays well in the short term and make you less adaptable in the long term). The complexity budget is another you want to conserve. Add a language feature to make every problem easier, and over time you find yourself not only constrained, but with a pretty complex language that few want to learn.
Green threads experiment proved net negative in terms of benefit but the follow-up work on modernizing the implementation details of async/await itself was very successful:
Issue https://github.com/dotnet/runtime/issues/94620
Technical details https://github.com/dotnet/runtimelab/blob/feature/async2-exp...
The result is such that regardless of p/invoke existence green threads would have been a worse tradeoff.
It also seems that common practices in Java indicate that properties are not a mistake as showcased by popularity of Lombok and dozens of other libraries to generate builders and property-like methods (or, worse, Java developers having to write them by hand). In addition, properties existed in C# since its inception, that's...not a few years.
Not entirely sure about string interpolation but if you are alluding to `var text = $"Time: {DateTime.Now}";`, then it's a non-issue - APIs that care about it in complex contexts like querying a DB or logging can handle it with interpolated string handler API which allows to pass string interpolation expression to methods accepting interpolated string handler types, which can then, for example, generate parametrized query with sanitized inputs, without any friction for the user. Something that Java does not seem to sufficiently appreciate.
Example: https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...
We put a lot of thought into which features we want to add to the Java platform and in what form, and also consider what other languages have done. Sometimes we choose to make different tradeoffs based on what we think are the right tradeoffs for most Java users (a tradeoff that's right for language X may be wrong for language Y [1]), and sometimes we disagree on aesthetics or technical merit. But the choices we've made have worked well for Java. We're well aware of differing opinions, but it seems that we're managing to align with the majority opinions (don't confuse "popular" with "majority"; something like Lombok is quite popular in absolute terms, but is still liked by a minority, i.e. it is less popular than not using it; Kotlin is also quite popular, but it is still more than ten times less popular than Java so does that mean we should follow its decisions?). At the adoption levels enjoyed by JS, Python, and Java, something could be hugely popular in absolute terms yet liked by a minority.
In our primary domain of serious server-side software, no other language has done better (or as well), and we and our users are happy, for the most part, with the choices we've made (except maybe for choices made very early on, but that's true for all languages). The mere fact that sometimes not everyone agrees with our choices (let's be honest, programmers rarely agree on anything) doesn't mean we should change them, especially as languages that go a different way don't seem to be doing as well. Still, different programmers will continue liking different things, and most will continue insisting that their preferences -- however popular -- are somehow "objectively" better with or without bottom-line metrics to support their beliefs.
In general, thinking about a programming language from the perspective of a programmer situated in specific circumstances can be quite different from thinking about a programming language from the perspective of the language maintainer, who needs to take into account different and often conflicting needs of many programmers situated in a variety of different circumstances. The wider the market you're targeting, the more aspects there are to consider and the closer attention needs to be paid to the distribution of programmer preferences.
[1]: E.g. the technical constraints that impact the design and performance of user-mode threads in Rust or C++ are fundamentally different from those that affect Java (re. e.g. the cost of allocating memory, and where pointers are allowed to point). The constraints around async/await in JS -- where a lot of code is already written under the assumption of no intervention -- are also very different from those in Java, where threads have existed from day one.
Ah, that must be why I see FooMethod and FooMethodAsync side-by-side in C# all the time.