11 ms·

Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby.

Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine. Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff. What do you get for all of these tradeoffs? Speed, memory safety. But with that you still still have dynamic invocation capabilities (making things like interception possible) and hotswap/live redefinition (things that C/CPP cannot do). Perfect? No, but very practical for the real world use case.

jbellis 1y ago
more like 100x faster than Python/Ruby and that's before you throw in real multithreading
- timbit42 1y ago
  I have heard around 50x, which is about the same as between assembly and BASIC on 8-bit systems.
  - igouy 1y ago
    We could measure programs. https://news.ycombinator.com/item?id=44022366 https://news.ycombinator.com/item?id=44022366
- igouy 1y ago
  Let's not pluck numbers out of thin air. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/comparable.html#geometric-mean https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - jbellis 1y ago
    iirc these benchmarks have such short runtimes that they are not useful for assessing real-world java jit performance
    - igouy 1y ago
      Is that a True Scotsman exclusion? > iirc 49.88—55.68 secs wall clock 7.66 5.51 27.85—27.91 83.79—87.16 10.94—11.09 How long a runtime would be required exactly, on what class-of hardware, to pass the True Scotsman? Please provide alternative benchmarks that you accept.
dragandj 1y ago
Throw in Clojure into the mix, and you get superpowers!
- exabrial 1y ago
  I'm still trying to mentally grok the Clojure model and syntax hah. On my todo list. Clojure users seem to love it though. Do you have a tutorial that could sell it to me?
  - dragandj 1y ago
    Many Clojure tutorials are free! It's difficult to say without knowing nothing about your preference and experience. Everyone's welcome to join Clojure Slack community (for example) which has several tens of thousands of members and dedicated beginners channel. I'm sure if you asked there, you'd get tons of recommendations tailored to you. https://clojurians.slack.com/ https://clojurians.slack.com/ (BTW Clojure, as a Lisp dialect, has almost no syntax. You can learn THAT in 5 minutes. The challenge is in training your programming mind to think in totally new concepts)
  - wry_discontent 1y ago
    Start doing any year of Advent of Code with Clojure and you'll get it. They're really amenable to the REPL.
  - mark_l_watson 1y ago
    My Clojure AI book won't teach you the language, but afterward you read through a tutorial my book contains interesting examples; read it online https://leanpub.com/clojureai/read https://leanpub.com/clojureai/read
  - dan_fornika 1y ago
    "Clojure for the Brave and True" is free online: https://www.braveclojure.com/clojure-for-the-brave-and-true/ https://www.braveclojure.com/clojure-for-the-brave-and-true/
  - Zambyte 1y ago
znpy 1y ago
> Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff. The GC story is just great, however. Pretty much the best you can get in the entire ecosystem of managed-memory languages. You have different GC algorithms implemented, and you can pick and tune the one that best fits your use-case. The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec. Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible.
- nxobject 1y ago
  > The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec. As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.) I have the ability to understand these modern systems abstractly, and I have the ability to write some high-intensity nearly stutter-free gamedev code that balances memory collection and allocation for predicable latency, but not both, at least without mistakes.
  - fidotron 1y ago
    > As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.) The GC would be the least of your problems. Java is neat, but the memory model (on which the GC relies) and lack of operator overloading does mean that for games going for that level of performance would be incredibly tedious. You also have the warm up time, and the various hacks to get around that which exist. Back when J2ME was a thing there was a mini industry of people cranking out games with no object allocation, everything in primitive arrays and so on. I knew of several studios with C and even C++ to Java translators because it was easier to write such code in a subset of those and automatically translate and optimize than it was to write the Java of the same thing by hand.
brightball 1y ago
When I got out of college and was still firmly in the "Java is the solution to everything" mentality I didn't realize that my admiration was really for the JVM and the Java App Server tooling that was so much more advanced than anything else at the time. It was basically Docker + K8s for anything running on the JVM more than 2 decades earlier. Java the language eventually drove me away because the productivity was so poor until it started improving around 2006-2007. Now I keep an eye on it for other languages that run on the JVM: JRuby, Clojure, Scala, Groovy, Kotlin, etc. IMO JRuby is the most interesting since you gain access to 2 very mature ecosystems by using it. When Java introduced Project Loom and made it possible to use Ruby's Fibers on the JVM via Virtual Threads it was a win for both. Charles Nutter really doesn't get anywhere close to enough credit for his work there.
- cogman10 1y ago
  Let me extol the virtues of Java the language. You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24. There are exceptions (sun.misc.Unsafe usage, for example) but they are few and far between. Moreso than nearly any other language backwards compatibility has been key to java. Heck, there's a pretty good chance you can take a jar compiled for 1.0 and still use it to this day without recompiling it. Both Ruby and Python, with pedigrees nearly as old as Java's, have made changes to their languages which make things look better, but ultimately break things. Heck, C++ tends to have so many undefined quirks and common compiler extensions that it's not uncommon to see code that only compiles with specific C++ compilers.
  - _ea1k 1y ago
    Yeah, that and the portability are really incredible and underrated. It is funny, because I constantly hear things like "write once, debug everywhere", but I have yet to see an alternative that has a higher probability of working everywhere. Although Python is pretty close, if you exclude Windows (and don't we all want to do that?).
    - bhaak 1y ago
nxobject 1y ago
Third best consistently used over 3 decades adds up to a great, great deal. Although, to be fair, a great deal has been invested in cutting edge GCs for the JVM – some fresh out of research.
tootie 1y ago
The language has/had some rough edges that have been improved over the years, but the developer experience of using a strongly-typed, object-oriented language within a sturdy IDE like Idea is just second to none. The debugging process is so very straightforward. Java became synonymous with enterprisey bloated systems for good reason, but there is no pile of mud Java system that can't be stepped through cleanly with a debugger. I'd also throw in what was possibly their greatest idea that sped adoption and that's javadoc. I'm not sure it was a 100% original idea, but having inline docs baked into the compiler and generating HTML documentation automatically was a real godsend for building libraries and making them usable very quickly. Strong typing also lined up nicely with making the documents hyper-linkable. Java was really made to solve problems for large engineering teams moreso than a single developer at a keyboard.
- Terr_ 1y ago
  I find these discussions have an interior split between the folks who are more concerned with getting the feature out now versus the folks who have had to keep a thousand ancient features running.
  - tootie 1y ago
    True, but it's also true that code spends 99% of it's lifetime in maintenance. That's the reason I am never impressed by tools that make it fast and easy to bootstrap.
- topspin 1y ago
  > javadoc Indeed. Many languages have something similar to Javadoc, yet somehow I haven't encountered anything quite as good as Javadoc, and I can't explain why or exactly how it's better. I admit I haven't tried that hard either. But I suspect it's down to the nature of the language and how, with well designed libraries at least (and not all are, certainly,) there is a nice decomposition of modules, packages, classes/interfaces and methods that leads to everything somehow having a correct place, and the Javadoc just follows. The strong typing is another contributor, where 90% of the time you can just look and the signature and imply what is intended. Finally, the old-fashioned frames based HTML typically used with Javadoc is a great benefit. Also, I've found I experience less reluctance to author Javadoc for some reason. Again, part of this is due to strong types, and much of the legwork being correctly generated in nearly every case. Lombok, when used with moderation, is wonderful. Mockito is magic, of a good kind. Maven still gets it done for me; I've yet to care about any problems Gradle purports to solve, and I think that's down to not creating the problems that Gradle is designed to paper over in the first place. Today, if I had my choice of one thing I'd like to see in Java that doesn't presently exist it's Python's "yield". Yes, there are several ways to achieve this in Java. I want the totally frictionless generators of Python in Java.
badc0ffee 1y ago
> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Fastest at what, exactly?
- jonhohle 1y ago
  I’m slightly surprised there isn’t more KVM/Virtualized bare metal JVM environments. While I haven’t used it in a while, the decade+ I spent running Javan’s in production basically have the entire system over to the JVM (with some overhead for some small non-JVM background daemons). Most things were built not to use POSIX standards, but Java equivalents. Occasionally direct file system access for writes was necessary (logging being a big exception). So giving the entire system to the JVM, performing some warmup prior to a service considering itself “healthy”, and the JVM was reasonably fast. It devoured memory and you couldn’t really do anything else with the host, but you got the Java ecosystem, for better or worse). There was a lot of good tooling that is missing from other platforms, but also a ton of overhead that I am happy to not have to deal with at the moment.
- lamp_book 1y ago
  Having a hard time finding it now, but someone put together a benchmark with two categories - naive and optimized - comparing implementations across languages with a workload vaguely resembling a real-world business application server with a mix of long and short lived objects. Java was at the top of the naive benchmark by a landslide and behind C and C++ (edit: and probably Rust) for the optimized ranking, but with a gap before the rest of the field. With the JVM you basically outsource all the work you need to do in C/C++ to optimize memory management and a typical developer is going to have a hell of a time beating it for non-trivial, heterogenous workloads. The main disadvantage (at least as I understand) is the memory overhead that Java objects incur which prevent it from being fully optimized the way you can with C/C++.
  - lycopodiopsida 1y ago
    I think it was this blog: https://renato.athaydes.com/all-posts https://renato.athaydes.com/all-posts They also tested common lisp!
lelanthran 1y ago
> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. When Java got popular, around 1999-2001, it was not a close third behind C (or C++). At that time, on those machines, the gap between programs written in C and programs written in Java was about the same as the gap right now between programs written in Java and programs written in pure Python.
- pjmlp 1y ago
  And yet many of us embraced Java, it became the chosen language to teach distributed systems in many Portuguese universities around 1998, because of the pain to write portable C or C++ code across UNIX clones. A mix of K&R C, C89, C++ARM compilers catching up with WG21 work, POSIX flavours, and lovely autoconf scripts.
  - lelanthran 1y ago
    > And yet many of us embraced Java, That was my point - performance was never one of the primary considerations for enterprises. They had more important considerations.
    - pjmlp 1y ago
      Also as much as I complain about the lack of JIT tooling in CPython, many people forget that usually most people don't have any issues in polyglot codebases, it isn't a zero-sum game, and various forms of FFI and language bindings exist. That is one of the things I have been doing across JVM/ART, CLR, V8 for decades now, moreso if we include Perl and Tcl into the mix, I seldom write full blown 100% C or C++ code, when I reach to them, is to write native libraries or implement language bindings.
- int_19h 1y ago
  I don't think that's accurate. Java at the time you're describing was already JIT-compiled (HotSpot debuted in 1999), which made it drastically faster than any plain bytecode interpreter. OTOH Python was - and remains - notoriously slow because, despite being compiled to bytecode, said bytecode is extremely high level and many opcodes in it represent potential numerous dict lookups etc.
neonsunset 1y ago
> a close 3rd place behind C/CPP Not anymore, the competition is doing much better these days.
javier2 1y ago
> Java syntax isn't perfect, but it is consistent, and predictable This is something I greatly value with the recent changes to Java. They found a great way to include sealed classes, switch expression, project Loom, records that feels at home in the existing Java syntax. The tooling with heap dump analyzers, thread dump analyzers, GC analyzers is also top notch.
- aardvark179 1y ago
  I think Gavin Bierman is an unsung hero as far as steering the Java language is concerned. I had the privilege to sit next to him in the office when I was working on TruffleRuby, and our conversations on language design were always elucidating, and his ability to gently steer others away from pitfalls was something I wish I could do as well. Hearing the work he and others did to gradually introduce pattern matching without painting themselves into a corner was fascinating and inspiring.
hintymad 1y ago
> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages. Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on writing concurrency code is to use Java's amazing containers. Sometimes, I do miss the java.util.concurrent and JCTools.
- zwnow 1y ago
  Just implement concurrency with actors and u save up on some locks and mutexes... The patterns are available, its up to the community to apply proper concurrency patterns.
  - paulddraper 1y ago
    The x86 instruction set is available as well.
  - PaulDavisThe1st 1y ago
    The only replacement for locks/mutexes is a lock free data structure. Locks are not what make concurrency possible, they are what makes it data-safe. You can use platform threads, user-space threads, language-provided "green" threads, goroutines, continuations or whatever you wish for concurrency management, but that's almost orthogonal to data safety.
    - MaxBarraclough 1y ago
      I'm not sure what you mean here, as far as I'm aware data safety isn't standard terminology.
      - lazide 1y ago
        I think they’re using it in the context of what you’ll get without some degree of locking, which is data corruption and/or other issues. It’s not that you need locking to use threads. You need locking to stop threads from ruining any shared resource/data they are both trying to touch at the same time.
interleave 1y ago
I miss writing Java 1.4 with Eclipse and svn. Even though I am also super-happy with Ruby and Swift today, I know that control-space flow. Good times! Edit: 1.4, not 1.7
Thaxll 1y ago
Java is not ahead of Go, they're on part but often Go is faster while using 2-10x less memory. Value type makes optimization much easier in Go. The fact that you specifically mention Go explains a lot. btw c# is faster than Java, so not third place, it's more a 5th~ https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javavm-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- 999900000999 1y ago
  Doing what? Benchmarks aren’t all that useful since usually the bottleneck is File IO, external api calls, db calls, user latency or a combo of the 4. Go’s main advantage in this matchup would be conciseness. Go code looks so clean and nice, Java doesn’t. I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat. “Fred, you really should just take the job.” “Martha you don’t understand, it’s Java with an Oracle DB.” “Fred, I know it’s bad, I know you still have nightmares about the 4 types of string in Java 8, but it’s not just us now.” With a tear in his eye , fear in his heart. “Martha, if I must… I’ll open Eclipse once more.”
  - vips7L 1y ago
    Go code is far from concise. Java is more expressive than Go in almost every way.
  - noisy_boy 1y ago
    > I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat. I write Java to pay bills and my eyes and fingers thank me everyday for sparing them from a sea of if err != nil. I won't even go(!) into the iota stupidly compared to Java's enums.
    - 999900000999 1y ago
      I want to like Go. I built a small phone app with it. The best way to describe it is incomplete. I think the philosophy is to make things more minimal? A lot of frameworks don’t exactly do everything they need to. I’ll still pick it over Rust, which seems to like punishing the developer.
emmelaich 1y ago
As an SRE, I appreciate the JVM. Out of memory is now the developers problem not mine / the machine's. Only have to deal with gigalines of log4j excreta filling up disks.
- thomashabets2 1y ago
  I know many SREs who basically became full time JVM herders. That thing is a nightmare. But if your organization doesn't assign that work to you, then sure, it's not your problem.
pjmlp 1y ago
And, alongside C# for historical reasons, the closest we got in mainstream to the whole Xerox PARC ideals of what a developer workstation is supposed to be like.
KronisLV 1y ago
I really like the JetBrains IDEs, both for Java and .NET, it feels way more pleasant to write code and refactor it than just in something like Visual Studio Code (which still feels better for utility scripts). They have pretty good run profiles that you can put in your repo, pretty good debugger, plenty of suggestions/inspections and customizability. Java, .NET and languages like that also lend themselves pretty well to tools (and even LLMs) understanding what's going on, their runtimes are pretty good and platform differences don't give you too many issues from what I've seen. Though when it comes to the frameworks or libraries you might use (e.g. how often you will see the likes of Spring Boot in enterprise projects) will definitely leave some performance on the table [1] and have plenty of awkward and confusing situations along the way [2], especially if you're unlucky enough to have to work on codebases that have been around for over a decade. Old Java projects really suck sometimes, though maybe that applies to many of the old projects, regardless of tech. Overall, I quite like them and am pretty productive, plus I unironically think that using Maven is pleasant enough (even adding custom repos isn't too convoluted [3]) and the modern approach of self contained .jar files that can just be run with a JDK install instead of separately having to manage Tomcat or GlassFish (or TomEE or Payara nowadays, I guess) is a step in the right direction! Though while I do like packages such as Apache Commons and they're very useful, I also very much enjoy using something like Go more recently, it's easier to get started making simple web apps with it, less ceremony and overhead, more just getting to writing code. [1] https://www.techempower.com/benchmarks/#section=data-r23&l=zik0vz-pa7 https://www.techempower.com/benchmarks/#section=data-r23&l=z... [2] https://blog.kronis.dev/blog/it-works-on-my-docker https://blog.kronis.dev/blog/it-works-on-my-docker (a short rant of mine, but honestly I very much prefer when you have configuration done explicitly in the code, not some layered abstractions with cryptic failure modes; Dropwizard is way nicer in that regard than Spring Boot) [3] https://maven.apache.org/guides/mini/guide-multiple-repositories.html https://maven.apache.org/guides/mini/guide-multiple-reposito... and https://maven.apache.org/guides/mini/guide-mirror-settings.html https://maven.apache.org/guides/mini/guide-mirror-settings.h...
igouy 1y ago
> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Of course, rank depends on what we include or exclude from the rankings, for example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... :versus: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/comparable.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

jbellis 1y ago

more like 100x faster than Python/Ruby and that's before you throw in real multithreading

timbit42 1y ago
I have heard around 50x, which is about the same as between assembly and BASIC on 8-bit systems.
- igouy 1y ago
  We could measure programs. https://news.ycombinator.com/item?id=44022366 https://news.ycombinator.com/item?id=44022366
igouy 1y ago
Let's not pluck numbers out of thin air. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/comparable.html#geometric-mean https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- jbellis 1y ago
  iirc these benchmarks have such short runtimes that they are not useful for assessing real-world java jit performance
  - igouy 1y ago
    Is that a True Scotsman exclusion? > iirc 49.88—55.68 secs wall clock 7.66 5.51 27.85—27.91 83.79—87.16 10.94—11.09 How long a runtime would be required exactly, on what class-of hardware, to pass the True Scotsman? Please provide alternative benchmarks that you accept.

dragandj 1y ago

Throw in Clojure into the mix, and you get superpowers!

exabrial 1y ago
I'm still trying to mentally grok the Clojure model and syntax hah. On my todo list. Clojure users seem to love it though. Do you have a tutorial that could sell it to me?
- dragandj 1y ago
  Many Clojure tutorials are free! It's difficult to say without knowing nothing about your preference and experience. Everyone's welcome to join Clojure Slack community (for example) which has several tens of thousands of members and dedicated beginners channel. I'm sure if you asked there, you'd get tons of recommendations tailored to you. https://clojurians.slack.com/ https://clojurians.slack.com/ (BTW Clojure, as a Lisp dialect, has almost no syntax. You can learn THAT in 5 minutes. The challenge is in training your programming mind to think in totally new concepts)
- wry_discontent 1y ago
  Start doing any year of Advent of Code with Clojure and you'll get it. They're really amenable to the REPL.
- mark_l_watson 1y ago
  My Clojure AI book won't teach you the language, but afterward you read through a tutorial my book contains interesting examples; read it online https://leanpub.com/clojureai/read https://leanpub.com/clojureai/read
- dan_fornika 1y ago
  "Clojure for the Brave and True" is free online: https://www.braveclojure.com/clojure-for-the-brave-and-true/ https://www.braveclojure.com/clojure-for-the-brave-and-true/
- Zambyte 1y ago

znpy 1y ago

> Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff. The GC story is just great, however. Pretty much the best you can get in the entire ecosystem of managed-memory languages. You have different GC algorithms implemented, and you can pick and tune the one that best fits your use-case. The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec. Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible.

nxobject 1y ago
> The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec. As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.) I have the ability to understand these modern systems abstractly, and I have the ability to write some high-intensity nearly stutter-free gamedev code that balances memory collection and allocation for predicable latency, but not both, at least without mistakes.
- fidotron 1y ago
  > As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.) The GC would be the least of your problems. Java is neat, but the memory model (on which the GC relies) and lack of operator overloading does mean that for games going for that level of performance would be incredibly tedious. You also have the warm up time, and the various hacks to get around that which exist. Back when J2ME was a thing there was a mini industry of people cranking out games with no object allocation, everything in primitive arrays and so on. I knew of several studios with C and even C++ to Java translators because it was easier to write such code in a subset of those and automatically translate and optimize than it was to write the Java of the same thing by hand.

brightball 1y ago

When I got out of college and was still firmly in the "Java is the solution to everything" mentality I didn't realize that my admiration was really for the JVM and the Java App Server tooling that was so much more advanced than anything else at the time. It was basically Docker + K8s for anything running on the JVM more than 2 decades earlier. Java the language eventually drove me away because the productivity was so poor until it started improving around 2006-2007. Now I keep an eye on it for other languages that run on the JVM: JRuby, Clojure, Scala, Groovy, Kotlin, etc. IMO JRuby is the most interesting since you gain access to 2 very mature ecosystems by using it. When Java introduced Project Loom and made it possible to use Ruby's Fibers on the JVM via Virtual Threads it was a win for both. Charles Nutter really doesn't get anywhere close to enough credit for his work there.

cogman10 1y ago
Let me extol the virtues of Java the language. You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24. There are exceptions (sun.misc.Unsafe usage, for example) but they are few and far between. Moreso than nearly any other language backwards compatibility has been key to java. Heck, there's a pretty good chance you can take a jar compiled for 1.0 and still use it to this day without recompiling it. Both Ruby and Python, with pedigrees nearly as old as Java's, have made changes to their languages which make things look better, but ultimately break things. Heck, C++ tends to have so many undefined quirks and common compiler extensions that it's not uncommon to see code that only compiles with specific C++ compilers.
- _ea1k 1y ago
  Yeah, that and the portability are really incredible and underrated. It is funny, because I constantly hear things like "write once, debug everywhere", but I have yet to see an alternative that has a higher probability of working everywhere. Although Python is pretty close, if you exclude Windows (and don't we all want to do that?).
  - bhaak 1y ago

nxobject 1y ago

Third best consistently used over 3 decades adds up to a great, great deal. Although, to be fair, a great deal has been invested in cutting edge GCs for the JVM – some fresh out of research.

tootie 1y ago

The language has/had some rough edges that have been improved over the years, but the developer experience of using a strongly-typed, object-oriented language within a sturdy IDE like Idea is just second to none. The debugging process is so very straightforward. Java became synonymous with enterprisey bloated systems for good reason, but there is no pile of mud Java system that can't be stepped through cleanly with a debugger. I'd also throw in what was possibly their greatest idea that sped adoption and that's javadoc. I'm not sure it was a 100% original idea, but having inline docs baked into the compiler and generating HTML documentation automatically was a real godsend for building libraries and making them usable very quickly. Strong typing also lined up nicely with making the documents hyper-linkable. Java was really made to solve problems for large engineering teams moreso than a single developer at a keyboard.

Terr_ 1y ago
I find these discussions have an interior split between the folks who are more concerned with getting the feature out now versus the folks who have had to keep a thousand ancient features running.
- tootie 1y ago
  True, but it's also true that code spends 99% of it's lifetime in maintenance. That's the reason I am never impressed by tools that make it fast and easy to bootstrap.
topspin 1y ago
> javadoc Indeed. Many languages have something similar to Javadoc, yet somehow I haven't encountered anything quite as good as Javadoc, and I can't explain why or exactly how it's better. I admit I haven't tried that hard either. But I suspect it's down to the nature of the language and how, with well designed libraries at least (and not all are, certainly,) there is a nice decomposition of modules, packages, classes/interfaces and methods that leads to everything somehow having a correct place, and the Javadoc just follows. The strong typing is another contributor, where 90% of the time you can just look and the signature and imply what is intended. Finally, the old-fashioned frames based HTML typically used with Javadoc is a great benefit. Also, I've found I experience less reluctance to author Javadoc for some reason. Again, part of this is due to strong types, and much of the legwork being correctly generated in nearly every case. Lombok, when used with moderation, is wonderful. Mockito is magic, of a good kind. Maven still gets it done for me; I've yet to care about any problems Gradle purports to solve, and I think that's down to not creating the problems that Gradle is designed to paper over in the first place. Today, if I had my choice of one thing I'd like to see in Java that doesn't presently exist it's Python's "yield". Yes, there are several ways to achieve this in Java. I want the totally frictionless generators of Python in Java.

badc0ffee 1y ago

> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Fastest at what, exactly?

jonhohle 1y ago
I’m slightly surprised there isn’t more KVM/Virtualized bare metal JVM environments. While I haven’t used it in a while, the decade+ I spent running Javan’s in production basically have the entire system over to the JVM (with some overhead for some small non-JVM background daemons). Most things were built not to use POSIX standards, but Java equivalents. Occasionally direct file system access for writes was necessary (logging being a big exception). So giving the entire system to the JVM, performing some warmup prior to a service considering itself “healthy”, and the JVM was reasonably fast. It devoured memory and you couldn’t really do anything else with the host, but you got the Java ecosystem, for better or worse). There was a lot of good tooling that is missing from other platforms, but also a ton of overhead that I am happy to not have to deal with at the moment.
lamp_book 1y ago
Having a hard time finding it now, but someone put together a benchmark with two categories - naive and optimized - comparing implementations across languages with a workload vaguely resembling a real-world business application server with a mix of long and short lived objects. Java was at the top of the naive benchmark by a landslide and behind C and C++ (edit: and probably Rust) for the optimized ranking, but with a gap before the rest of the field. With the JVM you basically outsource all the work you need to do in C/C++ to optimize memory management and a typical developer is going to have a hell of a time beating it for non-trivial, heterogenous workloads. The main disadvantage (at least as I understand) is the memory overhead that Java objects incur which prevent it from being fully optimized the way you can with C/C++.
- lycopodiopsida 1y ago
  I think it was this blog: https://renato.athaydes.com/all-posts https://renato.athaydes.com/all-posts They also tested common lisp!

lelanthran 1y ago

> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. When Java got popular, around 1999-2001, it was not a close third behind C (or C++). At that time, on those machines, the gap between programs written in C and programs written in Java was about the same as the gap right now between programs written in Java and programs written in pure Python.

pjmlp 1y ago
And yet many of us embraced Java, it became the chosen language to teach distributed systems in many Portuguese universities around 1998, because of the pain to write portable C or C++ code across UNIX clones. A mix of K&R C, C89, C++ARM compilers catching up with WG21 work, POSIX flavours, and lovely autoconf scripts.
- lelanthran 1y ago
  > And yet many of us embraced Java, That was my point - performance was never one of the primary considerations for enterprises. They had more important considerations.
  - pjmlp 1y ago
    Also as much as I complain about the lack of JIT tooling in CPython, many people forget that usually most people don't have any issues in polyglot codebases, it isn't a zero-sum game, and various forms of FFI and language bindings exist. That is one of the things I have been doing across JVM/ART, CLR, V8 for decades now, moreso if we include Perl and Tcl into the mix, I seldom write full blown 100% C or C++ code, when I reach to them, is to write native libraries or implement language bindings.
int_19h 1y ago
I don't think that's accurate. Java at the time you're describing was already JIT-compiled (HotSpot debuted in 1999), which made it drastically faster than any plain bytecode interpreter. OTOH Python was - and remains - notoriously slow because, despite being compiled to bytecode, said bytecode is extremely high level and many opcodes in it represent potential numerous dict lookups etc.

neonsunset 1y ago

> a close 3rd place behind C/CPP Not anymore, the competition is doing much better these days.

javier2 1y ago

> Java syntax isn't perfect, but it is consistent, and predictable This is something I greatly value with the recent changes to Java. They found a great way to include sealed classes, switch expression, project Loom, records that feels at home in the existing Java syntax. The tooling with heap dump analyzers, thread dump analyzers, GC analyzers is also top notch.

aardvark179 1y ago
I think Gavin Bierman is an unsung hero as far as steering the Java language is concerned. I had the privilege to sit next to him in the office when I was working on TruffleRuby, and our conversations on language design were always elucidating, and his ability to gently steer others away from pitfalls was something I wish I could do as well. Hearing the work he and others did to gradually introduce pattern matching without painting themselves into a corner was fascinating and inspiring.

hintymad 1y ago

> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages. Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on writing concurrency code is to use Java's amazing containers. Sometimes, I do miss the java.util.concurrent and JCTools.

zwnow 1y ago
Just implement concurrency with actors and u save up on some locks and mutexes... The patterns are available, its up to the community to apply proper concurrency patterns.
- paulddraper 1y ago
  The x86 instruction set is available as well.
- PaulDavisThe1st 1y ago
  The only replacement for locks/mutexes is a lock free data structure. Locks are not what make concurrency possible, they are what makes it data-safe. You can use platform threads, user-space threads, language-provided "green" threads, goroutines, continuations or whatever you wish for concurrency management, but that's almost orthogonal to data safety.
  - MaxBarraclough 1y ago
    I'm not sure what you mean here, as far as I'm aware data safety isn't standard terminology.
    - lazide 1y ago
      I think they’re using it in the context of what you’ll get without some degree of locking, which is data corruption and/or other issues. It’s not that you need locking to use threads. You need locking to stop threads from ruining any shared resource/data they are both trying to touch at the same time.

interleave 1y ago

I miss writing Java 1.4 with Eclipse and svn. Even though I am also super-happy with Ruby and Swift today, I know that control-space flow. Good times! Edit: 1.4, not 1.7

Thaxll 1y ago

Java is not ahead of Go, they're on part but often Go is faster while using 2-10x less memory. Value type makes optimization much easier in Go. The fact that you specifically mention Go explains a lot. btw c# is faster than Java, so not third place, it's more a 5th~ https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javavm-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

999900000999 1y ago
Doing what? Benchmarks aren’t all that useful since usually the bottleneck is File IO, external api calls, db calls, user latency or a combo of the 4. Go’s main advantage in this matchup would be conciseness. Go code looks so clean and nice, Java doesn’t. I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat. “Fred, you really should just take the job.” “Martha you don’t understand, it’s Java with an Oracle DB.” “Fred, I know it’s bad, I know you still have nightmares about the 4 types of string in Java 8, but it’s not just us now.” With a tear in his eye , fear in his heart. “Martha, if I must… I’ll open Eclipse once more.”
- vips7L 1y ago
  Go code is far from concise. Java is more expressive than Go in almost every way.
- noisy_boy 1y ago
  > I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat. I write Java to pay bills and my eyes and fingers thank me everyday for sparing them from a sea of if err != nil. I won't even go(!) into the iota stupidly compared to Java's enums.
  - 999900000999 1y ago
    I want to like Go. I built a small phone app with it. The best way to describe it is incomplete. I think the philosophy is to make things more minimal? A lot of frameworks don’t exactly do everything they need to. I’ll still pick it over Rust, which seems to like punishing the developer.

emmelaich 1y ago

As an SRE, I appreciate the JVM. Out of memory is now the developers problem not mine / the machine's. Only have to deal with gigalines of log4j excreta filling up disks.

thomashabets2 1y ago
I know many SREs who basically became full time JVM herders. That thing is a nightmare. But if your organization doesn't assign that work to you, then sure, it's not your problem.

pjmlp 1y ago

And, alongside C# for historical reasons, the closest we got in mainstream to the whole Xerox PARC ideals of what a developer workstation is supposed to be like.

KronisLV 1y ago

I really like the JetBrains IDEs, both for Java and .NET, it feels way more pleasant to write code and refactor it than just in something like Visual Studio Code (which still feels better for utility scripts). They have pretty good run profiles that you can put in your repo, pretty good debugger, plenty of suggestions/inspections and customizability. Java, .NET and languages like that also lend themselves pretty well to tools (and even LLMs) understanding what's going on, their runtimes are pretty good and platform differences don't give you too many issues from what I've seen. Though when it comes to the frameworks or libraries you might use (e.g. how often you will see the likes of Spring Boot in enterprise projects) will definitely leave some performance on the table [1] and have plenty of awkward and confusing situations along the way [2], especially if you're unlucky enough to have to work on codebases that have been around for over a decade. Old Java projects really suck sometimes, though maybe that applies to many of the old projects, regardless of tech. Overall, I quite like them and am pretty productive, plus I unironically think that using Maven is pleasant enough (even adding custom repos isn't too convoluted [3]) and the modern approach of self contained .jar files that can just be run with a JDK install instead of separately having to manage Tomcat or GlassFish (or TomEE or Payara nowadays, I guess) is a step in the right direction! Though while I do like packages such as Apache Commons and they're very useful, I also very much enjoy using something like Go more recently, it's easier to get started making simple web apps with it, less ceremony and overhead, more just getting to writing code. [1] https://www.techempower.com/benchmarks/#section=data-r23&l=zik0vz-pa7 https://www.techempower.com/benchmarks/#section=data-r23&l=z... [2] https://blog.kronis.dev/blog/it-works-on-my-docker https://blog.kronis.dev/blog/it-works-on-my-docker (a short rant of mine, but honestly I very much prefer when you have configuration done explicitly in the code, not some layered abstractions with cryptic failure modes; Dropwizard is way nicer in that regard than Spring Boot) [3] https://maven.apache.org/guides/mini/guide-multiple-repositories.html https://maven.apache.org/guides/mini/guide-multiple-reposito... and https://maven.apache.org/guides/mini/guide-mirror-settings.html https://maven.apache.org/guides/mini/guide-mirror-settings.h...

igouy 1y ago

> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Of course, rank depends on what we include or exclude from the rankings, for example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... :versus: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/comparable.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...