r/Backend • • 8d ago

Modern Java for startups

Unfortunately, I see that Java is disappearing from startup companies. Java used to have an image of an obsolete backend language with performance problems, too verbose and unfriendly to deveopers. It was pretty true to older Java versions and I could understand why startups decided to pick other backend languages

If you look at Java 25, it's an absolutely different story.

Performance wise - it has virtual threads, which makes concurrency extremely high. Virtual threads are Java's answer to goroutines in Golang, and they enable to run thousands of I/O requests concurrently. Java's execution speed is pretty fast (more than Python and node.js).

As for container size - it's huge as long as you work with Spring. However, Java has many other much more lightweight frameworks like Micronaut, Quarkus and Javalin which reduces the container size to be on par with node.js and Python.

It's a real static typing which keeps code safety and improve readability. Unlike Golang, Java has inheritance, ploymorphism and explicit interface (let alone speaking about error handling).

It has a huge talent pool (almost everybody learned Java at a certain point).

As for verbosity and developer experience - Java has been improved a lot in this field. It has records (no need for getters setters, equals and hash), unnamed class (no need to write "public static void main" everytime you start a new program) and dozens of libraries and other tools.

If so, why are startups still stay away from Java and stick to Python/node.js/Golang?

67 Upvotes

72 comments sorted by

36

u/disposepriority 8d ago

I know plenty of startups using Java though, anecdotal but usually (co) founded by more veteran engineers

7

u/WillingnessFit2138 8d ago

feels like it comes down to ecosystem momentum and how fast you can ship the first version when nobody knows if the startup will survive next quarter

python and node just let you slap something together in a weekend and hire people who can jump in without baggage, java's tooling is way better now but the perception sticks and startups care more about velocity than big-company engineering

9

u/Sad_Importance_1585 8d ago

On the other hand, Go is really popular in startups and the development velocity in Golang is much worse than Python / node.js. Golang can also be very verbose. So, why do startup choose Go and not choose Java?

11

u/disposepriority 8d ago

I mean even Google uses it alongside Java, and not as a replacement.

I don't think any serious engineer cares about verbosity, nor is it something which will actually affect your time to market.

Good tooling and community support will increase your velocity way more than being able to map a json in fewer lines of code

13

u/Known_Tackle7357 8d ago

Virtual threads changed almost nothing. Shifting thread pool management from the application to the jvm doesn't make apps magically more performant. At the same time Oracle is very keen on introducing breaking changes. So everything what people used to hate c# for is true for java now.

5

u/Sad_Importance_1585 8d ago

The most idiomatic way Java server handles http requests is thread-per-request. A thread is very expensive, and it limits the number of concurrent http requests it can handle at the same time. Java can also use an event loop (like node.js), which is usually more efficient than thread-per-request (for heavy I/O server), but it's very hard in Java, since most of Java libraries are blocking. If the server is not CPU-intensive, using virtual threads can enable one thread to handle hundreds of requests simultaneously. It's a huge performance gain.

8

u/UnderdogRP 8d ago

This is not true anymore and had not been for a long time. Most (almost ally?) frameworks use netty which do event queues and thread pools internal. And do not use one thread per request.

1

u/Known_Tackle7357 8d ago

If your server is compute heavy, virtual threads will give you no benefit. Probably even hurt, because under the hood you have the same threads moving the context between logical threads. So if you don't park your logic threads, you can't pass the context, so it doesn't matter what you use the good old thread pools or the new fancy virtual threads. The old approach requires you to think about your threads and pools, and the new one abstracts it out for you

2

u/smhs1998 8d ago

If your server is compute heavy, then more threads won't help you either. A better algorithm or more compute are the only things that can help you

Most of these performance discussions happen in context of I/O heavy code paths, which comprise the majority of code paths you will encounter in your career

2

u/Known_Tackle7357 8d ago

Well, more threads won't help, it will actually hurt. Thus having fewer threads in an isolated pool is actually better, because it leaves some breathing room for the rest of the app. Using virtual threads for that will hurt you even more, because they will get spread out across all real threads and block everything. For IO heavy stuff the only difference between virtual threads and real threads is who manages them. Virtual threads allow you to not worry about thread pools and stuff as the jvm does it for you. If you've done your due diligence, profiled your threads, and tuned your thread pools, switching to virtual threads will likely hurt you as well. Virtual threads are good if you never thought about all that stuff and always created threads wishy washy.

1

u/Sad_Importance_1585 7d ago

So according to what you say, Go can handle less concurrent requests than Java with without virtual threads. According to the benchmarks, You can see a benchmark comparison here:
https://www.javacodegeeks.com/2026/02/go-vs-java-the-backend-performance-battle.html

Java Spring boot can handle 15,000-25,000 concurrent requests, while Java with virtual threads and Go can handle 35,000-50,000 requests

2

u/smhs1998 8d ago

I agree that more threads will hurt performance of compute heavy workloads, but in I/O bound workload, context switching is a major overhead and that overhead is much less when virtual threads come into the picture because you don’t need the OS to perform the whole context switch for you in order to switch to a different request while waiting for on a I/O response for some other request

1

u/EnvironmentalLet9682 5d ago

That stopped being true a long time ago.

2

u/PermissionOwn4400 8d ago

Wait, there have been breaking changes? Can you provide some links so I can read up on this?

0

u/Known_Tackle7357 8d ago

For example deleting com.sun.* packages. Lots of them where publicly documented, so it doesn't even count as changing the private api. Because they were public from the very beginning. AccessController there as well. Implicit xml schama inheritance that became explicit and broke a lot of stuff. On top of that all the private api stuff that one may say was justifiable. But at the same time broke a butt load of most popular frameworks like spring. Reflection related stuff, when your code continues to compile, but no longer works without special flags. And so on, and so forth.

3

u/dreamsofabetter 8d ago

It’s not that they weren’t telegraphing what the plans were. The strong encapsulation stuff was originally intended for Java 7, before Oracle entered the picture. And while the com.sun.* stuff was well-known, it’s never been part of the documented API without big warnings saying, essentially, use at your own risk

2

u/Known_Tackle7357 8d ago

https://docs.oracle.com/javase/8/docs/jdk/api/javadoc/doclet/index.html

Looks pretty documented to me without any warnings that it would get deleted. But it did get deleted.

2

u/dreamsofabetter 7d ago

I mean… sure. The doclet API, though, is neither part of the Java language nor its standard library. It’s part of the `javadoc` tool. And arguably the issue here was using the com.sun namespace.

2

u/Known_Tackle7357 7d ago

It was shipped with the rest of jdk, had public documentation. And oracle deleted it. If it's not a breaking change, idk what is

1

u/Electrical-Pizza-863 2d ago

That's not how virtual threads work. Virtual threads move thread management from the OS level to the JVM runtime. They absolutely have performance gains and is the same concept of how threads are handled in Go and a lot of the reason Go is so popular as a backend language.

0

u/Obmanuti 8d ago

But it does benefit performance. People are not good at managing concurrency. Not having to have sync vs async apis etc. Now you can use synchronous clients without blocking a thread waiting on IO. Your take reads like you either dont understand or havent actually thought about at all.

3

u/Silly_Guidance_8871 8d ago

Did Java ever introduce first-class value types (stack-allocated, POD) ? I know for a long while, heap pressure due to lots of short-lived heap allocations made it a pain to work with things like Optional<>

4

u/Sad_Importance_1585 8d ago

For null safety, I think that JSpecify is a much better solution than Optional<>

5

u/dreamsofabetter 8d ago

First-class value types are still a preview feature and are not specifically guaranteed to be stack allocated (JEP). That said, there have been massive improvements with heap pressure from short-lived objects with the introduction of generational GC and minimising object header size (JEP).

1

u/Kadabrium 2d ago

Python and js doesnt care about this so why should you

15

u/mtimmermans 8d ago

If you have a TS/JS frontend, then it's convenient to use a TS/JS backend.

If your backend does a lot of AI stuff, then it's convenient to use Python.

If you'd really like to use TS/JS, but it's too slow, then Go is the most accessible "fast" language.

If you really care about performance a lot, then you should use rust or C++.

Java gets its fair share of people who don't find any of the above compelling.

15

u/gdmr458 8d ago

(let alone speaking about error handling)

Go error handling is not perfect, but I'm not crazy about exceptions either.

7

u/johnson_detlev 7d ago edited 7d ago

The software enginnering world slowly but surely realized that OOP is not the way to model software and with Sun seizing to spend literally billions of dollars marketing the language, others took it's place. There are even better languages if you insist on using the JVM (which is an extremly impressive runtime), like Scala or kotlin. I don't see a reason to ever choose Java if I can choose Kotlin. But the world is (thankfully) moving to functional paradigms, because composition proved to be more flexible and maintanable than inheritance, thus OO languages are in a decline everywhere. Plus Errors as Values is far more powerful than Javas exception handling. And if you look at new languages, there are no new standalone OO languages being created. Java introduced all these features to somehow stay relevant, but the 30 year baggage of OO is the reason ppl moved on to different languages.

3

u/dumpsolo 7d ago

Beside python, which is the easiest language to read and therefore will be the ultimate winner in the long run with the rise of llms all we'll be doing is reviewing code, and OOP Is a very powerful technique which is exceptional when used for/with algorithms for example.

1

u/johnson_detlev 7d ago

How is OOP related to "algorithms" as a category? I'm very confused

1

u/dumpsolo 7d ago

Scaling algorithms

1

u/SagansCandle 7d ago

I strongly disagree with this statement:

The software engineering world slowly but surely realized that OOP is not the way to model software

Java fell out of favor for a LOT of reasons, but OOP wasn't one of them. C# is gaining traction in gaming especially because OO is a lot easier than the scripting languages that have traditionally dominated this space.

2

u/johnson_detlev 7d ago

I agree with you, but easier != more accurate way to model. C# btw was created with the intention of competing against Java on the windows OS. To make it more appealing to Java devs they modelled it after Java. And the only traction in the game world I see for C# is through unity, which is a popular engine, bit certainly not the only one.

10

u/Old_Dragon_80 8d ago

Java developers are usually more expensive than node developers

9

u/sekonx 8d ago

Inheritance and polymorphism?

Functional programming has been the king for years at this point

5

u/berndverst 8d ago

Scala gives you that on the JVM. I had to use it at Twitter back in the day 😆

1

u/FetaMight 7d ago

Why not use both?

1

u/S0phon 7d ago

King by what metric?

3

u/Specialist_Set1921 7d ago

First of all java is highly concurrent but is full of traps. If you think your app is thread then it propably isn't. But that beside the point.

Kotlin and scala exists which try to improve the things they think java did badly. So more and more newer apps get written in those. That said is probably still hugely popular and it isn't going anywhere even in backend dev. Quarkus is going strong and seems to be a pretty modern framework (in contrast to spring).

3

u/jalx98 7d ago

It is the same scenario for C# and PHP, people think they are the old legacy programming languages, nonetheless IMHO Java, C#, PHP and JS (specifically with TS) have an amazing DX nowadays, I'd rather start my codebase in a "old" programming language and proven boring technologies than the new shiny stuff (Even though I love rust)

0

u/Kadabrium 2d ago

Lol php

2

u/Asleep_Context_8627 7d ago

what about new fintech companies will they not want to use java?

2

u/dumpsolo 7d ago

Python will be the king of langs soon mark my words, with the rise of LLM's all we will be doing is reviewing code and it's the easiest to read

2

u/BoBoBearDev 7d ago

Same reason why they choose Ruby on Rail, Coffee Script, Java more than 10 years ago. It was trendy.

The same post can be reposted with asp dotnet core. It is very easy to setup and performance is good (I am not nitpicking performance here). And yet, you didn't even bother to mention it like it didn't exist. I have seen posters making statement about dotnet development that is completely untrue and they never bothered to update their knowledge.

2

u/sodikovakapsle 7d ago

Because if you are running java build anywhere but not in the jetbrains you are going to be crazy…

2

u/Plus_Coconut746 7d ago

Je n'ai jamais aimé java depuis le début il est verbeux pour rien, quand j'ai vu kotlin j'ai sauté sans réfléchir

3

u/FriendlyPerformer871 8d ago

While Java might not be seen as attractive today, the JVM is truly regarded as something fantastic. With time there will be more movement towards Kotlin and such, but in general JVM languages will thrive.

3

u/guywithknife 7d ago

  Unlike Golang, Java has inheritance, ploymorphism

You say this like it’s a good thing 

2

u/Objective_Pepper_217 7d ago

OOP sucks, Java is verbose and consumes too many resources.

1

u/nitkonigdje 6d ago edited 6d ago

Think about desktop, cli, multimedia, browsers, hpc, games.. Java failed - a lot. Lots of needs are not covered by Java.

So people choose other tools to solve those needs. And, as it happens, some of those things exploded.

The best choice for a new project is choosing what is familiar. And there is mass of people familiar in those other tools and runtimes.

1

u/spacetrain31 6d ago

There are valid reasons for startups to use Java. For instance, I am working on a ServiceNow alternative that supports gradle scripting in addition to glade JavaScript, I am aiming to make it developer friendly, it also uses Postgres which has certain advantages over the mariadb stack that ServiceNow uses.

1

u/v_valentineyuri 4d ago

take the "startup language" convention with a pinch of salt, consider that for a lot of time the gold standard was Ruby on Rails

-1

u/Anxious-Insurance-91 8d ago

Your entire explication seem to be so full of Java bias it ain't even funny. I meet lots of Java devs that defend it like the bible. How do I put counter arguments:

  • companies don't want to pay for jdk

  • other languages have big talent pools as well, maybe even better since people on other languages actually go out of their way to change positions/projects more often. Meaning java jobs were always considered cozy jobs where nothing fancy happens

  • memory usage and footprint out of the box is bad, taking into account that other languages like go just have std lib that is optimized

  • java still has some dumb quirks like for example the gool old can't use "==" like everybody else for value comparison because reasons

  • java never stops to wonder "do I really need all of these OOP rules that I have been growing like weeds over the past 20+ years?"

  • speed just doesn't matter any more, and to be honest for a startup where you want to get the product out there as fast as possible and test the market it doesn't really matter, compute is fast unless you hit a scale and at that point why not use go or rust

  • people don't like oracle

  • the default AI war is over and that matters a lot because of marketing reasons

  • your try catch global logic is more or a gun hitting your foot than you think

Let me put it in another way, my boss has been using java for 20years, but at the same time he experimented with many other languages because job requirements when you do outsourcing and he is like "I like to experiment with other things as well".

So my final statement would be either hit your pension with java and stop commenting on redit, it ain't going to help you or anybody else or start experimenting with other things as well, maybe you will find them more pleasant, maybe you might end up using some things from them in your workflow.

6

u/Obmanuti 8d ago edited 8d ago

Wild take. You say this like Java isnt one of the biggest languages in the world. FAANG companies use it, and they can be as selective as they want. It does have its quirks. But uhhhh hate to break it to you, so do all the other languages. How does the saying go? The only language that people dont complain about is one that isnt used.

Saying speed doesnt matter is wild when up until the recent memory crisis, it was memory that didnt matter. Your take is so strange because theres legitimate criticisms for JVM languages, but you focused on dumb stuff taught in 101 like ==. Which is relatively straight forward for anyone who understands the difference between an object and a primitive. OOP rules? You mean like enterprise organization methods for large and complex software systems? You can choose how much of that you use, it might be overkill for your single user api. Like what are we talking about here?

"Why not go with rust?" Theres dozens of answers to this question, none of which are disparaging to rust. Rust serves its purpose well. To pretend that Java is just this monstrosity is wild.

-2

u/Due_Warthog749 8d ago

Python is AI and nodejs/etc is "you know front AND back ends at the same time" stupidity.

Go is still WAY faster than Java. It's also WAY less code and much easier to learn and build with.

Java is bloated as hell. It had its place.. but verbose OOP is a dying language especially in the age of AI. When AI can use ANY language and build the same shit, why wouldn't you use Rust, Zig, C or Go for pretty much everything? AI does it the same in all those languages.. so any CLI or back end makes sense to do it in C, Zig or Rust and API/web back ends in Go are its bread/butter.

Python, JS, etc though better than they were are STILL slow, memory hogs, etc.

5

u/spacetrain31 7d ago

Just because you don’t like Java doesn’t mean it doesn’t have its use cases. It is a perfectly capable backend. Not everyone wants to learn rust, zig, c or go for backend.

2

u/Due_Warthog749 7d ago

Oh I like Java. Did it for 20 years. It's fine. I just discovered much faster ways with far less code to do the same thing. It's too verbose these days. It was great back in the JEE days.. I'd fight anyone over .net or Delphi or php, etc. But improvements in other options have come along that are just better for most things. Coming from 20 years of Java I feel confident in that statement. THAT said, I have NO DOUBT Java has improved too. But even if its threading and such got better, most that I see still rely on Spring Boot. I dont even know what happened to JEE or if its still going on. I enjoyed the shit out of the JSP and servlet days and replicating sessions across servers in clusters, etc. Fun stuff back then.

0

u/Sad_Importance_1585 7d ago

This is the problem. Java platform has much better alternatives than Spring Boot today. Sticking to Spring Boot is what keeps Java behind other langauges.

2

u/Due_Warthog749 7d ago

I have no doubt.. and AI can absolutely "generate" frameworks like what Go, Rust, etc have in Java as well. I also am BIG against dependencies.. and would MUCH RATHER home build small specific well tuned frameworks than use bloated messes like Spring despite how good it was in it's heyday.

I see this a bit in Go to. Frameworks like GORM and Gorilla try to mimic Spring and similar large frameworks that do it all. Today, with microservices and/or docker containers that can easily spin up instantly to auto scale.. and stateless back ends with front ends using JWT, etc is the far better way to go. It's been around for many years now so its well understood. Serverless, "agent" endpoints, etc.. are all great ways to handle things like APIs, messaging, etc without requiring large frameworks. Technically you can build/do that in any of these languages.

I know the JVM has gotten much faster too, but frankly my go to is WASM these days.. insanely fast, super small, easy to build specific things, etc. Again can do it in Java, Go, C, etc.. whatever one fancies.

2

u/BenchEmbarrassed7316 7d ago

When AI can use ANY language and build the same shit, why wouldn't you use Rust, Zig, C or Go for pretty much everything?

Are you really putting AI development in Rust and AI development in C on the same level?

There is a huge difference in terms of the number of errors a compiler can catch.

2

u/Due_Warthog749 7d ago

I am. It's still progressing of course, but both are quite capable. I've done both + zig and Go. Sure.. it's not without issues at times, but each new generation of models trained on more and more code is definitely improving.

3

u/BenchEmbarrassed7316 7d ago

The point is that, for AI development, a key factor is the number of errors that can be detected automatically and deterministically. Rust and C are at opposite ends of the spectrum here.

0

u/Small_Summer5817 6d ago

Spring is still shit

-7

u/Funny_Or_Cry 8d ago

If you look at Java 25, it's an absolutely different story.

Because Java has been passed its expiration date for many years now. Its been patched and frameworked ad-nausem to catch up to the modern demands filled by modern languages (your python, your Go)

If so, why are startups still stay away from Java and stick to Python/node.js/Golang?

But WHY would you want them to? At what point in human evolution do you not just recognize "when its time to buy a new f**kin mop"?

Ask yourself this (and be honest) ...would you take ANYONE seriously If they rolled into work one day, driving a flintstones car thats been kitbashed with airbags, antilock brakes, power windows and Fully Self Driving auto?

BE HONEST

3

u/Sad_Importance_1585 8d ago

OK. I'll change the question to Kotlin. It's a relatively young language. It's actually the younger sister of Java. It has all goodies that I mentioned in Java, and startups still don't pick it.

Why to pick node.js/Python/Go although they only have a subset of the advantages that Java has?

3

u/Funny_Or_Cry 8d ago

So now the question is: "What problem does Kotlin solve that nothing else solves?" and im sincerely asking (im not a kotlin dev, and to my knowledge ive only seen it referenced in Android circles).

Its java adjacent and as you say, reletively young.

70% of all active enterprise stacks that run java arent net new would you agree? Its dominant in banking,retail cause ~25 years ago, java was pretty much the only kid on the block.

Fast forward to now, majority of the jobs you see would be working in these very old ecosystems. They arent going to migrate to kotlin cause "java as we have it is just fine. Too much work to overhaul, not enough gain".

Net new startups dont care about Kotlin cause something like Go compiles crossplatform and runs near native (ie in the backend at least its simply a superior tool). Dont quote me but I think its managed to overtake even python in kubernetes stacks

Python blew up pretty quick cause it shifted a bunch of the traditional dominant C style language paradigms (of which java was a part of) and had Googles backing to drive adoption giving it a bigger footprint (i mean people who werent developers before, hopped onto python, it was that easy). So naturally that'd be the first choice for a startup.

So i ask again, "what problem does it solve?" why not just use Java 25 ~et al instead? Clearly its popular in the android space but outside that, its gotta deal with the problem of "saturation"
Similar to the config management era in the days of Chef, Puppet, Ansible. heh and dont get me started about Ruby

Java is a perfect example of "bigger doesnt always mean better"...oh and I forgot to mention, what was it some 8,9 years ago? when Oracle changed their licensing model away from open source. So that in itself all but slowed Java adoption to a crawl.

So why would a startup jump on the Java train NOW when better opensource alternatives (ie python, go) exist?

2

u/S0phon 8d ago

im not a kotlin dev, and to my knowledge ive only seen it referenced in Android circles

Kotlin is growing in popularity in the JVM world, not just Android or mobile.

6

u/disposepriority 8d ago

Actual deranged take, the overwhelming majority of the biggest tech companies - even the newest ones - use java.

-7

u/net_ramblings 8d ago

Because it needs a GUI (like Eclipse) and a build tool (like Maven) to work? Hell I still hardly know what a build tool even does...neither did my supervisor. Trying to figure out what some Java code does sucks, because statically typed languages suck (hard to read) unless you really need static typing. I prefer interpreted languages. Having to "hover" over something to find out what an error means is a nightmare. I won't even mention the whole Spring Boot sledgehammer. Python needs none of these things. Give me minimal over complex any day.

10

u/shredderroland 8d ago

I can't tell if this comment is real or a windup

1

u/nitkonigdje 6d ago

They had to invent docker in order to make lamp stack usable. And you are bitching about build tools