HACKER Q&A
📣 legerdemain

Do you regret choosing Java?


I'm the de facto CTO of something that might become a startup, but for now is just an exploratory project. We have a handful of motivated engineers with various degrees of experience, and we're trying to settle on a tech stack to get started.

We have a pro-Java faction, because Java is easy to hire for, standard, rock-solid, great tooling, yadda yadda yadda.

We also have an anti-Java faction, because Java is bloated and verbose and unpleasant and not modern.

Did you regret choosing Java for a new project or startup? What went well? What went wrong?


  👤 jokethrowaway Accepted Answer ✓
It was a 2d game, we chose Java because there were tons of library available and because everyone knew Java or could learn it easily.

It's a usable language, albeit unpleasant. Also the primitive type system meant we had the weirdest bugs uncaught in production which took forever to debug.

I recently had the chance to build games again and we picked Typescript (for a 3d game) and Rust (for a 2d game).

Typescript is okish, unfortunately most of the libraries we use have patchy type support which translates to a few errors at runtime - but we didn't have many problems.

Rust has been pretty amazing. We're using early stage software (bevy) but the codebase is a pleasure to work with and once it compiles, things really work. One great advantage is using ECS. I tried to prototype the 3d typescript game with and ECS library but, again, lack of typing support in the library meant a lot of pain.

I've been using Rust for pretty much everything lately (from videogames, to running tensorflow, to writing web servers) and I have to say the advantages of using the language shadow the OSS projects being early stage.


👤 twobitshifter
I think it depends on the scope of your project and how many people you will have working on the codebase. I’ve used Java on Android where it was the only choice pre-Kotlin and it definitely helps to keep everything and everyone organized and is well supported through IDEs. Yes, it can be verbose, but it’s less so today, and the code will be something that anyone can work on and continue to work on. OOP has its weaknesses but it does push people towards a direction that helps maintainability. If I had a mega-project to manage, I would choose Java.

Not knowing the alternative languages proposed I can’t comment on their shortcomings in comparison to Java. I can’t think of anything that went wrong from using Java, it’s very performant and other than perhaps garbage collection or startup issues, you won’t find many shortcomings. If your alternative language is closer to the metal than Java, I do agree the hiring will be harder and development will be slower on most teams, because you have expanded what can possibly go wrong and broadened the range of skills.

As far as bloated - it’s that way so that the code you wrote doesn’t have to be.

Verbose - it’s evolved to allow lambdas, implicit casting, and improved case statements.

Unpleasant - Not in any IDE and not if your code quality enforces doc strings- which is one of the best things about Java.

Modern - I assume functional programming is what is asked for here? Java does support lambdas, and map,filter, etc. through the stream api.


👤 jfengel
Remember that "modern" is constantly changing. Whatever "modern" thing you pick is going to be either uncool or defunct tomorrow. Your choice today saddles developers for the rest of the project's lifetime.

Which is fine. There's every reason to think that Go and Rust will be in the "uncool" category rather than the "defunct" category. If they match your requirements and you can assemble the team to use them, they're both fine choices.

But "not modern" for Java also means "durable". It stands the test of time, just like your code will. (And don't kid yourself -- your "prototypes" will be operational code.)

A lot of the features that make Java "bloated and verbose" are also the ones that make it durable. It's a language designed for large projects -- heavyweight for "hello, world", but prized by coders who have experience in revisiting 10 year old software.

Or you could pick Kotlin, which is basically a cleansheeted Java. It uses all the same libraries and frameworks, which are actually more important. It's got some nice language features, most of which Java is also adopting. Either is a fine choice -- Kotlin is a bit cleaner, Java is a bit easier to hire for. The differences aren't all that big.

I've never regretted picking Java, even before modern tooling (I wrote my first Java with vi, and still do sometimes.) The tooling makes it excellent and keeps improving.

There are some frameworks I regret having forced on me, but they're not Java the language. People who can't tell the difference between the language and the framework are not going to advise you well.

No matter what you pick some things will be easier and some harder, and you won't know which. The worst case is that the language dries up. Avoid that case and the language won't be your worst problem.


👤 throwaway197812
I doubt you'll ever come to a consensus by trying to think of pros and cons and make some kind of objective decision. Unless you're comparing languages that are very specialized for a certain domain, or obviously at opposite ends of the "abstraction continuum" (e.g., C vs. Haskell), it's going to come down to taste and the subjective preferences of the individual developers. As you've discovered, some developers want a stable, boring, mature language that doesn't get in the way of solving the problem; others like the hot new language even if they'll have to fight with the wrinkles yet to be worked out, and struggle with an ecosystem that is shifting under their feet.

Just tell them that whoever gets the prototype working first picks the tech stack.


👤 dudul
What is recommended by the anti-Java faction?

Unless your product has some specific needs, Java is a good goto.

I've never seen a company fail because they picked the wrong language anyway.


👤 egor2820
No, I have much experience in Java, there's some cons but other languages have cons either, and I certainly can code faster with good knowledge of general pitfalls.