Sure, I didn't claim that the bad ecosystem makes the language as such bad (although it is still bad, for other reasons). It's just an additional disadvantage of developing software on the Java platform.
That said, I do think some of the bad code out there is an effect of trying to work around flaws or missing features in the language. Libraries like Spring add an additional configuration layer that is practically like an additional language on top of the base language. Instead of coding Java, you're coding Bean configurations and filter chains. Unfortunately all of that comes without useful debugging tools, so you're left scratching your head why the system isn't doing what you want. Log4J is another such complex configuration system that - unfortunately - customers are encouraged to change themselves which leads to confusing failure modes and insufficient user interfaces.
Well it's always about finding a good balance isn't it. Too many features like in C++ has negative consequences. Preferably you want something that lets you do all that you need to do, but not more. The trick to designing a good language is to let developers achieve as much as possible with as few features as possible, while keeping the code easy to reason about and understand.
This is obviously both subjective and highly dependent on what problem you are trying to solve, but I can't think of any situation in my career where C# would not have been a better a choice than Java from a strictly technical perspective. It's not just that the C# language is better, it's that the Java ecosystem is founded on poor design choices that result in code bloat and implicit behavior that is hard to troubleshoot and secure. See e.g. Spring, which automatically picks up and loads any logging library that happens to be in the user's path, even if that is an exploitable version of log4J. Java has become corrupted by enterprise architects. This satirical project demonstrates what I mean.
I say this as someone who is currently developing a FOSS Java library in my spare time, out of frustration with the Java code I had to endure at work.
So why not sell only the cloud version? Does that version somehow prevent management from another cloud key? If not, having the functionality dormant costs nothing.
I think what you need is Britt Hartley and her book No Nonsense Spirituality. She understands the common elements of different religions that are important to us psychologically, and explains how to bring them into your life without the need for faith in a particular deity.
You implied that an egalitarian person doesn't have the goal of furthering equality, did you not?
The Wikipedia article on egalitarianism says:
By promoting equal opportunities, egalitarianism aims to level the playing field and reduce disparities that result from social inequalities.
and
Egalitarian doctrines have supported many modern social movements, including the Enlightenment, feminism, civil rights, and international human rights.
Do you not feel that what you claim and what Wikipedia says are in conflict? At any rate, what I mean by being egalitarian is also to work toward achieving an egalitarian society, and in practice I do work toward that goal.
Sure, I didn't claim that the bad ecosystem makes the language as such bad (although it is still bad, for other reasons). It's just an additional disadvantage of developing software on the Java platform.
That said, I do think some of the bad code out there is an effect of trying to work around flaws or missing features in the language. Libraries like Spring add an additional configuration layer that is practically like an additional language on top of the base language. Instead of coding Java, you're coding Bean configurations and filter chains. Unfortunately all of that comes without useful debugging tools, so you're left scratching your head why the system isn't doing what you want. Log4J is another such complex configuration system that - unfortunately - customers are encouraged to change themselves which leads to confusing failure modes and insufficient user interfaces.