Hacker News Reader

Comment by stackskipton | Hacker News Reader

Ops person here who has supported Java/SpringBoot applications. I think most of dislike of Java apps comes not from language or framework BUT from fact that most Java using workspaces are filled with mediocracy. They tend to be businesses with products that have extreme moats and thus quality of software barely matters. I imagine most people who would even read this medium article are dreaming of better than that.

View on HN

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.

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

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.

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.

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.

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.

There are certain non-software industries that seem to have strong hiring preferences for workers who started in the industry over computer science chops, and a lot of those tend to use Java. For example, biotechs.

Because most of time, understanding the business logic is harder than writing to the code in these industries.

Java is default since it's what taught to many college graduates with added bonus that's taught to most college grads in Indian subcontinent so outsourcing is much easier.

I think that's generally true of most knowledge domains for anything resembling complex work. Govt, banking, pharma, medical, SaaS all will have a lot of specific requirements that come from deep historical, regulatory or business needs.

I would suggest that the rise of Python is very similar, as it's common in education circles. It's not even that Java as a language is particularly bad, it's how it is used in practice. Though I really do favor C# over Java, there's a similar stigma that comes from the community itself, not the language or it's baseline abilities. And this is a valid criticism.

Getting up to speed on the business logic was arguably the easiest part of my last job where the product was a liquid biopsy. Regardless of industry, you have to learn how to communicate with stakeholders and collect requirements. The existing software being a mess was a much more significant challenge. They also had similar issues on the data science side, where I would argue they did not lean into modern ML nearly enough and instead opted to do the familiar thing.

Alternatively, I think of Java and Spring Boots as being incredibly valuable by letting companies that don't really have software as a core competency to make reasonably performant and structured applications.

Mediocrity will never not exist, and you unlock a lot of value by optimising for it.

Exactly. It allows to build boring stuff at a fraction of what a SV startup would burn using some fancier tech. And most problems in the world are boring stuff.

Reply on news.ycombinator.com