I 100% agree. I have seen enterprise spring applications that throw away all of the speed through huge amounts of hot path object creation, nested loops, absurd amounts of factories, etc. After going through enough AbstractFactoryFactory calls to make object in an n^3 loop, the framework doesn't matter.

▲

switchbak a day ago | parent | next [-]

There really is an unlimited potential for crappy code in the enterprise. I imagine the volume will increase drastically in the age of AI.

▲

the_arun a day ago | parent [-]

Usually languages are not the issue. It is the code that we write. As long as languages help us to find/debug a problem caused by crappy code - we should be good. Coding is kinda creative work. There is no standard to measure creativity or pitfalls of using wrong patterns. The incidents & RCAs usually find these. But most of the times it is already too late to fix core problem.

	▲	tracker1 a day ago \| parent [-]
		Not sure that I agree... I think some of the worst AI code I've had to deal with and the most problematic are when dealing with Java or C#... I've found TS/JS relatively nice and Rust in particular has been very nice in terms of getting output that "works" as long as function/testing is well defined in advance.

▲

throwawey1234 a day ago | parent | prev [-]

In my experience, the same enterprise developers will write complex abstractions in any language. If you have a million coders, 500k will by definition write below average code. And if some of them are elevated to tech leads in enterprise companies, they will spread their "style" to others.

	▲	tracker1 a day ago \| parent [-]
		This is definitely true... as a mod/admin on EchoJS, can't tell you the number of times I've seen unnecessary IoC/DI libraries created in JS/TS to match the style of Java or C#. The reality is that as a scripted environment, there are provisions to override dependencies for testability.... so unless you literally need multiple implementations of a given adapter, you don't need a DI/IoC framework and adding one only detracts from your overall solution. I'm a strong believer in that abstractions should mostly serve to hide relative complexity to make the rest of the application easier to reason with. I'm also a big fan of the first version of anything being done in a scripted language with an emphasis on correct behavior. JS/TS and Python are more adaptable earlier on without committing to Java/C# or even Rust or Go. I understand a desire for homogeny, but that often can hold you back from creating something functional and easy to replace first.