It's a culture, not language thing. Here is a JSON parser implementation (part of PlantUML) that lacks endless levels of abstraction.

https://github.com/plantuml/plantuml/blob/master/src/main/ja...

▲

porridgeraisin 3 days ago | parent [-]

I'd argue culture solely defines the language.

Is there a full library ecosystem of stuff written like the json parser you shared, which is as complete as the enterprisey library ecosystem? Similarly, SO answers? LLM output? Tutorials? YouTube videos?

I think the answer is no.

It's the same problem with C#. Just adding alternate paradigms means nothing. The only thing that matters is how a majority of code in the ecosystem is structured. In java, that's enterprisey code. Most code is glue code, so you're forced into the majority pattern, lest you want to write endless wrappers...

On the other hand, while typescript supports a lot of the enterprisey nonsense similar to C#, the majority of the ecosystem is written with simple functions, callbacks and options objects. Not in an enterprisey way. I don't need to use decorators to use zod.

People that eschew enterprisey code and prefer simple code can't switch to java or c# until the whole culture changes, regardless of the kitchen sink of features either language adds.

	▲	zerkten 2 days ago \| parent \| next [-]
		>> On the other hand, while typescript supports a lot of the enterprisey nonsense similar to C#, the majority of the ecosystem is written with simple functions, callbacks and options objects. Not in an enterprisey way. Going back to culture, who makes up the Typescript community? While C# devs are attracted to it there are many multiples more devs coming from a JavaScript background. This has a big impact on how the culture developed. Taking a step back. C# devs often need to do frontend work. They could go with what the industry has settled on, React, or go another way. The bulk go with react and some perhaps lament still have to switch their brain to another mode for that work. Frontend is obviously more fragmented, but the scale prevents C# devs from influencing patterns to the extent that they do on the backend. I'd argue similar for Java devs when it comes to frontend. In the case of Blazor, I think C# patterns are a much smaller factor in decision-making. In fact, lots of C# adherents would default to React given it's the industry standard.
	▲	sorokod 3 days ago \| parent \| prev \| next [-]
		I agree with most of what you are saying except for the "solely defines" bit. The culture is a powerful force but individuals are free to make choices and the language allows for these choices.
	▲	troupo 2 days ago \| parent \| prev \| next [-]
		> It's the same problem with C#. Just adding alternate paradigms means nothing. C# is still much better because it has a lot of useful DX improvements: from object initializers to IEnumerable everywhere. It keeps the tower of abstractions lower, and makes working with the tower a better experience. Though I've only worked on microservices written in C# in .net core
	▲	Mawr 3 days ago \| parent \| prev [-]
		Spot on. You can't separate a language from the speakers of it. You can't redo millions of hours of work put into an ecosystem.