8 ms·

These days, Java is mostly used in greenfield software that has to be very reliable, very performant, and last for many years. So it's often the first choice fo

• astrodust 27d ago
  Why not Go, Rust, or C#?
  • pron 27d ago
    They lack in performance, stability (compatibility), observability (telemetry), productivity, or some combination thereof. They are chosen, of course (especially C#; Go and Rust are far behind), but not as much as Java.
    • brabel 27d ago
      I think you have a biased view. The number of stuff written in Rust in the last couple of years has absolutely exploded. For example, I see a lot of projects now that provide SDKs in Rust but don’t bother with Java. And I say this as someone who still writes most of my code ( or tell my LLM to write) in Java.
      • pron 27d ago
        There's a difference between number of programs and number of LOC (the latter is related to the number of people involved). I am not aware of any SDK targeting the industries I mentioned that "doesn't bother with Java". It's not only a popular choice in those industries, it's not only among the top choices, but it's the top choice by a large margin. Look at wanted ads in those industries to see that. Overall, there are only two languages as popular as Java or more, and they are JS and Python: https://www.devjobsscanner.com/blog/top-8-most-demanded-programming-languages/ https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
      • Mawr 27d ago
        Yeah I mean he literally works on Java at Oracle, so may just be a little biased. Doesn't bother to disclose it of course, because what, you don't check everyone's profile in every discussion to make sure they're not biased? What, you don't just know who every user on this site works for? You dummy you :)
        • pron 27d ago
          It's disclosed right there in my profile (I don't see your professional affiliation disclosed in your comment; or your profile, for that matter). Of course, I, like other runtime and compiler people, joined the Java team because we wanted to work on the most advanced compiler and runtime tech. I perfectly understand people who want to work on smaller, newer, potentially insurgent products, but I took the chance to work on the cutting edge of compiler and runtime engineering, and Java is where it's at these days (I'm not saying it's the only one, but it's a very small club).
          • wk_end 27d ago
            GP's snark is unwarranted, but it's probably good practice to disclose your professional affiliation explicitly in comments related to it, even if you have already disclosed it in your profile. I was reading your comments on Java, nodding my head, upvoting, without checking your profile and realizing that you're a member of the Java team. Knowing that doesn't mean I now suddenly disagree with you or anything. But while in an ideal world it doesn't matter who's saying something when evaluating it, there's some human factors at play - I'd like to turn up my internal sense of skepticism when dealing with someone, effectively, selling something their salary depends on; even if you're being entirely earnest, it's ultimately a sales pitch, and I feel bamboozled for not recognizing it - that'd make me appreciate transparency. (FWIW, even though I prefer being coy about my place-of-work, I have no professional relation to this conversation. I've never used Java in my 9-5 and I haven't even really used it in earnest since, like, version 5 back in high school. I think it's always been underrated by the hacker crowd, though!)
            • pron 27d ago
      • deleted 27d ago
        [deleted]
    • akkad33 27d ago
      I don't agree. If anything these newer languages have better tooling and new projects are always built from ground up to support open standards like open telemetry
      • pron 27d ago
        Open telemetry is about how telemetry data is reported, not how it's collected. It's hard to compete with JFR on the breadth and depth of low-overhead, in production telemetry, built into the standard library and the JVM itself.
    • misiek08 27d ago
      Saying that Go lacks in those is just showing how people are making software those days. It’s just terrifying. As to Rust - we all, hopefully, agree that it’s great language, but not for some startup making websites or Mongo based, boring backends. It’s great for the stable, system level products.
      • pron 27d ago
        I don't know what compiler and GC quality has to do with how people are making software these days, and I don't think state-of-the-art optimising compilers and GCs are terrifying at all. Go opts for more traditional, simpler algorithms under the assumption that for many purposes they're good enough. That may be so, but sometimes workloads really are very demanding, and you need the best performance.
      • ssimpson 27d ago
        and the costs they are willing to pay. Go/Rust just kill everything else (except maybe C++) for performance and resource needs. JVM requires so many resources just to run small apps.
        • pron 27d ago
          Quite the opposite, and the reason is that you can't extrapolate from small programs to large ones. Low-level languages (like C++) incur some significant overheads as they grow large (because of essential constraints of low-level languages that prevent them from doing certain optimisations that matter mostly in large programs), and these are exactly the overheads the JVM is designed to reduce. In small or short-lived programs, the situation is different, because Java does have some warmup costs and some fixed memory overheads that matter when you're small or short-lived. Go's compiler and GC are pretty basic, and are certainly good enough for smaller things, but don't scale as well to high workloads. Just the other day a colleague tested Caffeine, an old and well-established Java caching library, and Moka, a Rust caching library with the same workload. Caffeine had the same latency as Moka across all percentiles at twice the throughput.
          • 27d ago
    • unscaled 27d ago
      While Java can outperform Go in some cases, the situation is very much the opposite when it comes to Rust. I also don't see the case for stability. Yes, if you're still on JDK 8, it would probably chug on for a couple of years. But we were talking about greenfield projects and newer JDK go EOL much faster. If you want patches, you'll have to run your app to a newer JDK, which may break a couple of things. Rust (within the same edition) or Go (within the same major version) break less than that. As far as runtime compatibility goes, Rust and Go apps ship with the runtime. This can be better or worse for you, depending on what is your upgrade story, but I don't see a clear winner here. What I would give to Java over Rust is that you will have far fewer dependencies to take care of if you need to upgrade. But the same goes for Go. For observability, I feel that with Rust you have a bit less that you need to observe (no GC to worry about). Tokio tracing is great, but observability requires a bit more effort. The go observability story is far worse. So Java probably has an edge here, but not something that ever felt like a game changer. My impression is that for most of the enterprise shops that love Java, observability means collecting unstructured log files through NFS and trying to find a needle in the haystack with primitive tools, but I've been out of touch with this world for a couple of years. Productivity is something that is dead if you are AI-heavy. Sure, many shops are still wary about AI, and I totally get why, but this is a battle that's already been lost. Without AI, I would say I was about 3 to 4 times more productive in Rust than I was in Java, but ramping up that productivity took at least 1 year of practice. It's not time most companies are willing to spend. With AI, this doesn't matter anymore, for better or worse. I'm not arguing that Java is not chosen often for greenfield projects. It's clearly extremely popular in many circles, especially outside startups and big tech. But I think the reason Java is chosen have little to do with the reasons you've mentioned above and more with organizational preferences.
      • pron 27d ago
        > the situation is very much the opposite when it comes to Rust. It isn't, and the problem isn't Rust specifically, but all low-level languages. They can offer very good performance (often better than Java) when small. But as they evolve over time, or are very large to begin with, they become much harder to keep performant. This is for pretty fundamental constraints of low-level language that I mention in another comment here, and this performance problem with large programs written in low-level languages was well known before Java even existed. The JVM was designed, at least in part, to address it. One of the things that drew me to Java (from years of C++, even though I still work in C++ when I work on the JVM) is precisely how it addresses those performance issues we ran into with C++ five years into a project. > As far as runtime compatibility goes, Rust and Go apps ship with the runtime. This can be better or worse for you, depending on what is your upgrade story, but I don't see a clear winner here. I wasn't talking about "runtime compatibility" but of overall version compatibility. Java has an unmatched compatibility record - not perfect, but better than anything else (with at least a medium-sized standard library). > For observability, I feel that with Rust you have a bit less that you need to observe (no GC to worry about). Memory management is very often a bigger issue without a GC than with a moving GC. Time and again we see Rust or C++ programs spend 30-50% on memory management. > Productivity is something that is dead if you are AI-heavy. Really? Have you had AI write a good medium-sized (say 100-500 KLOC) program or maintain one over a long period of time without very close reviews? The only people I've seen who don't know about the ticking time-bomb agents leave in the codebase are the people who don't look. > With AI, this doesn't matter anymore, for better or worse. You may be talking about small programs. I agree that for small programs, low-level languages can offer excellent performance, and AI can be okayish, and you can get some observability you can live with, but I'm talking about large programs. > But I think the reason Java is chosen have little to do with the reasons you've mentioned above and more with organizational preferences. Those organisational preferences are due to a long record of delivering on the things I mentioned. Java has an exceptionally low "regret factor", i.e. people who regret choosing it five, ten, or fifteen years into a project (which is when the problems usually start).
  • Almondsetat 27d ago
    Go and Rust have much worse tooling for enterprise-level collaboration
    • doublepg23 27d ago
      Do they? It felt like every dev that worked on our Java behemoth at a previous job was elated to switch to Go.
      • akkad33 27d ago
        I don't think they do. I work in a maven shop and half of the people don't even know what to do when maven fails inexplicably
        • esafak 27d ago
          Haven't they heard of Gradle or Bazel?
    • unscaled 27d ago
      I'm not sure what enterprise-level collaboration means. In my experience, "enterprise" usually means: "Let's use tools that are 10 years behind, buggier than average, and have lots of half-baked features, none of which we need". I'm not sure what kind of tools you mean, but unless you're looking for something that just works exactly the way EJBs do for some mysterious reasons, I don't see why you can't do most "enterprisey" things with Rust or Go. Or Python or TypeScript for that matter.
      • egorfine 27d ago
        > Let's use tools that are 10 years behind Yes and that's exactly what modern tooling is missing. Try to develop for node.js 0.2.12 on today's update of Visual Studio Code. See? No enterprise-level collaboration for ya.
        • dwaite 26d ago
  • dimaaan 27d ago
    Go has null pointer dereference problem. Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker. C# is MS product, which is no-go for some folks. Kotlin probably would be the answer.
    • unscaled 27d ago
      > Go has null pointer dereference problem. Which Java famously does not have. > Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker. In my experience, you do not spend tokens fighting with the borrow checker anymore, newer models are smarter. But it might not be ideal for a lot of CRUD applications. > C# is MS product, which is no-go for some folks. This is 2026, it's not 1996 anymore. .Net works on Linux and Microsoft is as friendly towards open source and open standards as a Big Tech company can be. If anything, it was Oracle which more recently sued another company for using a JDK alternative. And this was a lawsuit that, if accepted, could have put the entire idea of API compatibility in danger and deal a severe blow to the Open Source movement. Anyone who is morally bothered by MS but is unfazed by this is probably just mentally stuck in the 1990s. > Kotlin probably would be the answer. I love Kotlin, but I'm afraid that's not the case. The conservative organizations that choose Java out of inertia, would keep choosing Java over Kotlin, even if Kotlin is a better JVM language which is facing no downside. For anyone who doesn't need to be on the JVM or work with JVM tooling, Kotlin doesn't cut it. It doesn't have null pointer dereference problem in theory... Only it does in practice if you're using any Java API that may return null (all these bang-decorated "Platform types"). Generic type erasure can only be overcome in inline functions with reified types. And building and deploying artifacts without docker is still a mess. I found Kotlin extremely publishing for Java shops in the past, and I've converted multiple departments totaling over hundreds of employees to use Kotlin. But that was before AI. The rationale was simple: Java is an entrenched language that leads to bloated code, slow development cycles and way too many avoidable bugs in productions. Kotlin solves some if these issues, and it's very easy to learn for a Java engineer, while still letting you keep all of your tools and libraries. And as a language (putting ecosystem aside), I find it better than either Go or Typescript, and far more ergonomic than Rust[1]. But all of these arguments die with AI. Rust is just as ergonomic as any other popular language today if you're using an agent, and the fact that an engineer spent their lifetime writing Spring Boot programs in Java you don't have time to let them learn a new stack from scratch doesn't matter anymore. Sure, there are many companies where letting AI write the code is still not acceptable, but most of these workplaces will accept AI agents sooner than they accept Kotlin. I feel a bit sad since I like many ideas about Kotlin (especially how amenable it is for making DSLs) but we've lost that opportunity -- [1] Unless you have to write highly concurrent code without any data races.
• throwaway91033 27d ago
  I think of Java/Kotlin and Spring as a secret weapon for startups. My workplace was a startup 5 years ago and it's amazing how things just worked as expected, leaving us more time to focus on the product. We have tried a few alternatives over the years, such as a few services in Rust, but the people who implemented those have usually seen the advantage of using a stable ecosystem after a few years. It's unfortunately something you need to experience yourself instead of being told by someone else.
• rohan_ 27d ago
  This is quite the take - i doubt most startups building in these spaces are using Java.
  • chasd00 27d ago
    i can't speak to the others but banking and healthcare is virtually all java top to bottom. The big healthcare EMR/EHR systems are Java and every bank i've ever worked with (i use to do a lot of integrations with the big banks) was all Java. I have friends in those areas and whenever they start up a new project it's still always Java since that's where their skills are and what's on the "approved tech." list.
    • deleted 27d ago
      [deleted]
    • doublepg23 27d ago
      in my healthcare experience (claims processing, medtech) Java existed for sure but it was always as a "legacy" system they were moving away from.
      • wk_end 27d ago
        What were they moving towards?
        • doublepg23 27d ago
          claims processing - TypeScript, lots of ETL tools with Go. medtech - .NET and TypeScript.
        • Mashimo 27d ago
          We embedded angular in our old Java client for hospitals. The user thinks he just opens a new window, but it's chrome in Java, which opens angular frontend, for our Java backend.
      • nitwit005 27d ago
• azuanrb 27d ago
  Any mainstream language can be reliable. Java is a good choice for greenfield projects when it fits the organisation’s existing stack, expertise, or the broader industry ecosystem. Just like any other language. Banks, telcos, etc. aren’t monoliths either. They use plenty of different languages depending on the team, system, and requirements. Java isn’t inherently the choice for greenfield software just because reliability matters.
• wolvesechoes 26d ago
  First, I like reading your comments, as they are pretty illuminating, also in the way they expose how superstitious programmers can be. Second, I wonder where, roughly, would you put a transition from small programs where low-level langs are fine, to programs large enough to heavily benefit from JVM tradeoffs? And how this transition is affected by a stuff like Graal Native?
• dzonga 26d ago
  yeah the performance, reliability & ecosystem of the JVM is unmatched. if you gonna work in a big team or need a project with lots of devs then yeah go for the JVM. but if you're doing things on the smaller / small scale side. - just use JS/TS or python. you benefit from cheap runtimes such as Cloudflare workers.
• cavoirom 25d ago
  But still need to rewrite every 3 years because of the "offshore-development".