Comment by goto11 | Hacker News Reader

Comment by goto11 | Hacker News Reader

Parent Full thread

Your premise is that you are able to chose a language based on how appropriate it is for a specific use case. This alone shows you are not the typical user of Java!

Java is typically used in larger or long-lived organizations. It is rare to start new projects from scratch. Most development is maintenance and extension of existing systems. Even if you start a greenfield project, it would be most prudent to chose the same platform and language which is already used in the organization. An alternative language would not only have to be better, it would have to be very significantly better to make up for the overhead and headache in maintaining code in multiple languages - never mind the increased difficulty in hiring and training developers.

Geeks tend to evaluate language based on how appropriate they would be for a greenfield project with no organizational baggage. But this is an extremely rare use case for most business.

HN often has reports about startups rewriting everything from scratch every four months, when a new language or platform becomes fashionable. But this is not the world where most developers live.

> Even if you start a greenfield project, it would be most prudent to chose the same platform and language which is already used in the organization.

Anecdotally, I see a trend of greenfield projects moving from Java to NodeJS. I can't think of too many organizations that have zero web presence, and basically any modern web presence requires the use of JS, so there's almost always some JS expertise built into the organization.

> there's almost always some JS expertise built into the organization.

That is usually part of the front-end team that don't do the backend SQL work. Tho team that would get assigned the work for a backend greenfield would be versed in Java.

It’s surprisingly rare for things to split like that. At most companies people will be more skilled at front end or back end work, but it’s rarely a clean separation with front end vs back end teams.

That’s an outgrowth of most projects being quite small. Paying a team or 20+ people to work on one thing is freaking expensive to the point where it needs major benefit or huge company to be worth it. On the other hand maintaining lots of little projects that all automated something can easily pay for a single developer at even fairly small companies. Across tends of thousands of small and midsized companies you get a lot of such teams which grow and shrink, split off and merge over time.

> It’s surprisingly rare for things to split like that.

THIS. The product is blended and so must the teams be. Among all the full-stack developers I've worked with, the "frontend" or "backend" designators tended to describe preference or strength, rather than limitation.

Those are pretty strong assertions with no statistics to back them up. It doesn’t reflect the ecosystem I work in.

I think you underestimate the number of huge companies that see major benefit from large teams working large development efforts.

I don’t know where you would even look for that kind of statistics for companies that might use Java. That said, America has:

1,829,875 companies with 5-9 employees 779,922 companies with 10-19 employees 467,634 companies with 20 - 49 employees 170,749 companies with 50 - 99 employees

Of that a few are pure software companies, but it’s far more common to want to automate something. Which often means outsourcing it, but then they simply can’t afford these kinds of large projects.

At the other end only 23,553 companies have 1,000+ employees. Yet even at that scale it’s not guaranteed to have large development teams in house, a single hospital can have 1000+ employees and use mostly 3rd party software with a few generalists to stitch everything together.

Clearly you’re not going to arrive at a good answer starting from first principles. Industry research groups have the numbers, but they’re locked behind paywalls.

Starting from the other end, the Stackoverflow survey has 50% of devs identifying as full-stack. Most surveys have Java as the #2 programming language, where it’s been for the last 20 years. That says nothing about how those devs are organized among teams, but I don’t think it points to such arrangements being “rare”.

Their 2020 survey has: “About 55% of respondents identify as full-stack developers, and about 20% consider themselves mobile developers.”

I always took that kind of a breakdown to mean most website developers where full stack with embedded etc being their own categories. With majority full stack teams including various specialists as needed, which fits my experience over the last 20 years.

However, Android is Java and is frequently used as a front end. As things grow I normally see teams split by system, so I can see mobile being split off as their own team becoming more common even if it’s the still the minority. That said, it’s teams managing the backend teams which would be considering Java vs NodeJS and based on that 55% I think most teams are familiar with JavaScript.

Development is going the other way at my org. Our JS services quickly became "out of date", and nobody wants to put in the massive effort required to bring them up to modern JS language features, build tools, and libraries.

In contrast, our Java upgrades remain painless. Many of our JS services have been merged back into older Java back ends

Yes of course, don't fix what's not broken.

It's orthogonal to my point though.

Reply on news.ycombinator.com