4 ms·

Java is too slow. Just because modern hardware allows for software to be very heavy doesn't mean that it should be acceptable for you as a developer to produce

Java is too slow. Just because modern hardware allows for software to be very heavy doesn't mean that it should be acceptable for you as a developer to produce heavy software.

oweiler 6y ago
Which type of slow?
- ta988 6y ago
  Don't engage just someone repeating the same FUD from 20 years ago...
patates 6y ago
I'm sincerely wondering how you came to that conclusion. Java has one of the fastest VMs, but maybe you mean the startup speed?
- throw2838 6y ago
  Slow startup from command line
  - pjmlp 6y ago
    All free JDKs now offer AOT compilers and JIT caches.
  - coldtea 6y ago
    Which is relevant for a server how?
    - forgetfulness 6y ago
      This is on the comment thread of a tool to make client-side applications. However, it's all besides the point because this tool takes Java (JVM) bytecode and translates it to WebAssembly, there's no JVM involved for end users at any point.
  - JAlexoid 6y ago
    Is sub 100ms not enough these day? Sure... IntelliJ IDEA startup isn't instant. Atom's startup isn't instant. QT Creator's startup isn't instant. GIMP starts in a few seconds... etc.
- pharmakom 6y ago
  JVMs that most people use are optimised for repeated execution of the same code paths on long running processes. If this isn’t your use-case then lots of tuning work is required.
  - pjmlp 6y ago
    Like using the AOT compiler or JIT caches provided in recent versions, they are no longer features only available to customers of commercial JDKs.
    - skjfdoslifjeifj 6y ago
      The free AOT compilers have atrocious compile times (far, far worse than even Rust or Scala) and don't support all of the features so library support is extremely fragile. A lot of extremely popular Java libraries make extensive use of runtime reflection and none of the AOT compilers handle it well without a lot of extremely error prone manual configuration. I actually like Java and the JVM but if AOT compilation and efficient memory usage is what you want Java is definitely not the language to use.
      - imtringued 6y ago
        Yes, GraalVM requires a new sub ecosystem of libraries that are built with it's native image feature in mind. That means no more Spring, no more Hibernate and so on. Old codebases will not benefit and new code base require abandoning your existing Java expertise.
        pjmlp 6y ago
        They work perfectly fine with JIT caches. Plus not everyone is fan of Spring and Hirbenate. The first I used only once in 20 years of Java projects, the second is the first to go away when I get called to optimise database performance in Java applications.
        skjfdoslifjeifj 6y ago
        I agree. My main issue is with the Java zealots that come into the discussion and make it seem like anyone can just take their existing Java application and use it with an AOT compiler. The reality is that you will most likely have to make changes to your code, do a significant amount of configuration, and heavily modify or remove dependencies. Furthermore, you are isolating yourself from the huge Java community because very few people are using any of the existing AOT Java compilers. They try to paint an extremely rosy picture of the current situation when the reality is that it's a very long way from the experience you get in Rust, Go, D, C, C++, Haskell, Ocaml or any of the languages where AOT is considered the default.
speedgoose 6y ago
I complain all the time about the memory consumption of Java software, they behave like they are the only ones running on a computer, but not the speed. The JVM is actually pretty fast. For sure it's a bit slower than native code but if your Java code is slow, I'm sorry but it's your code and using C++, C, Rust or whatever else faster will not make your code fast.
- KronisLV 6y ago
  Yep, here are some sources to back up the claim that Java performance is pretty okay. TechEmpower benchmarks: https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r19&hw=... Language benchmarks game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And just because i found it pretty interesting, here's a summary of a study that not only measures memory consumption and execution time, but also how much energy certain languages required: https://jaxenter.com/energy-efficient-programming-languages-137264.html https://jaxenter.com/energy-efficient-programming-languages-...
- imtringued 6y ago
  My biggest issue with the JVM is the RAM consumption. Every other language, even JS beats it. GraalVM's native image feature is the only way to fix this and that is pretty sad that it took them multiple decades to fix such a glaring flaw.
  - kaba0 6y ago
    Did you set a heap size for your app? Because the JVM has an eager way of consuming RAM (since then it doesn’t have to do useless work with garbage collection) - and the defaults are closer to a server config.
gman83 6y ago
Yet we're all using Electron apps every day.
pjmlp 6y ago
Yes, xcode is the living proof how blazingly fast an IDE written in native languages is. /s
coldtea 6y ago
It's 2021. 1999 wants its arguments back. At the language/runtime level Java has been faster than anything else we have used on the Web with huge success (faster than PHP, Ruby/Rails, Python, Node, for example) even since 2000, and is as fast or faster than Go. It's also used in HFT - where ultimate speed means a lot. Seriously, your argument sounds like the first year CS student argument of yore, where they hear that assembly is faster, and want to rewrite everything in assembly (fortunately today's first year CS students are more well informed).
- gdubya 6y ago
  It's 2021, but I agree with the rest of your post :)
  - coldtea 6y ago
    Damn, it's the second time I type 2020 past 1st Jan.
hestefisk 6y ago
Slow is pretty relative. What’s your use case? Start up time is not as good as native, agreed. Arithmetic? Hotspot is pretty darn fast. Developer speed? A lot better than C/C++ at least.
karmakaze 6y ago
This idea of 'heavy' is very fuzzy, though I agree. Most of the slowness I encounter though is with specific frameworks, not the language/jvm. I do sometimes use Go for its contiguous memory layout and await JEP 169: Value Objects from Project Valhalla.
- skjfdoslifjeifj 6y ago
  > Most of the slowness I encounter though is with specific frameworks, not the language/jvm Part of the problem is that those also happen to be the frameworks that the vast majority of the community uses. The Java zealots also tend to ignore all of the problems associated with AOT Java compilers and the fact that it will most likely be a few years before value objects are finalized and in a released version of Java. Even then, a ton of Java developers won't be able to use any features beyond Java 8 or 11 since a lot of companies don't want to give up the ability to easily use their libraries on Android.
cangencer 6y ago
I'll do a shameless plug of our modern Java benchmarking story here for the doubters: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1
TeaVMFan 6y ago
Throw away your preconceived notions -- TeaVM beat React at its own game. * Faster startup * Better Lighthouse score * Less code See for yourself: https://renato.athaydes.com/posts/comparing-jvm-alternatives-to-js.html https://renato.athaydes.com/posts/comparing-jvm-alternatives...

Java is too slow. Just because modern hardware allows for software to be very heavy doesn't mean that it should be acceptable for you as a developer to produce heavy software.

oweiler 6y ago

Which type of slow?

ta988 6y ago
Don't engage just someone repeating the same FUD from 20 years ago...

patates 6y ago

I'm sincerely wondering how you came to that conclusion. Java has one of the fastest VMs, but maybe you mean the startup speed?

throw2838 6y ago
Slow startup from command line
- pjmlp 6y ago
  All free JDKs now offer AOT compilers and JIT caches.
- coldtea 6y ago
  Which is relevant for a server how?
  - forgetfulness 6y ago
    This is on the comment thread of a tool to make client-side applications. However, it's all besides the point because this tool takes Java (JVM) bytecode and translates it to WebAssembly, there's no JVM involved for end users at any point.
- JAlexoid 6y ago
  Is sub 100ms not enough these day? Sure... IntelliJ IDEA startup isn't instant. Atom's startup isn't instant. QT Creator's startup isn't instant. GIMP starts in a few seconds... etc.
pharmakom 6y ago
JVMs that most people use are optimised for repeated execution of the same code paths on long running processes. If this isn’t your use-case then lots of tuning work is required.
- pjmlp 6y ago
  Like using the AOT compiler or JIT caches provided in recent versions, they are no longer features only available to customers of commercial JDKs.
  - skjfdoslifjeifj 6y ago
    The free AOT compilers have atrocious compile times (far, far worse than even Rust or Scala) and don't support all of the features so library support is extremely fragile. A lot of extremely popular Java libraries make extensive use of runtime reflection and none of the AOT compilers handle it well without a lot of extremely error prone manual configuration. I actually like Java and the JVM but if AOT compilation and efficient memory usage is what you want Java is definitely not the language to use.
    - imtringued 6y ago
      Yes, GraalVM requires a new sub ecosystem of libraries that are built with it's native image feature in mind. That means no more Spring, no more Hibernate and so on. Old codebases will not benefit and new code base require abandoning your existing Java expertise.
      - pjmlp 6y ago
        They work perfectly fine with JIT caches. Plus not everyone is fan of Spring and Hirbenate. The first I used only once in 20 years of Java projects, the second is the first to go away when I get called to optimise database performance in Java applications.
      - skjfdoslifjeifj 6y ago
        I agree. My main issue is with the Java zealots that come into the discussion and make it seem like anyone can just take their existing Java application and use it with an AOT compiler. The reality is that you will most likely have to make changes to your code, do a significant amount of configuration, and heavily modify or remove dependencies. Furthermore, you are isolating yourself from the huge Java community because very few people are using any of the existing AOT Java compilers. They try to paint an extremely rosy picture of the current situation when the reality is that it's a very long way from the experience you get in Rust, Go, D, C, C++, Haskell, Ocaml or any of the languages where AOT is considered the default.

speedgoose 6y ago

I complain all the time about the memory consumption of Java software, they behave like they are the only ones running on a computer, but not the speed. The JVM is actually pretty fast. For sure it's a bit slower than native code but if your Java code is slow, I'm sorry but it's your code and using C++, C, Rust or whatever else faster will not make your code fast.

KronisLV 6y ago
Yep, here are some sources to back up the claim that Java performance is pretty okay. TechEmpower benchmarks: https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r19&hw=... Language benchmarks game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And just because i found it pretty interesting, here's a summary of a study that not only measures memory consumption and execution time, but also how much energy certain languages required: https://jaxenter.com/energy-efficient-programming-languages-137264.html https://jaxenter.com/energy-efficient-programming-languages-...
imtringued 6y ago
My biggest issue with the JVM is the RAM consumption. Every other language, even JS beats it. GraalVM's native image feature is the only way to fix this and that is pretty sad that it took them multiple decades to fix such a glaring flaw.
- kaba0 6y ago
  Did you set a heap size for your app? Because the JVM has an eager way of consuming RAM (since then it doesn’t have to do useless work with garbage collection) - and the defaults are closer to a server config.

gman83 6y ago

Yet we're all using Electron apps every day.

pjmlp 6y ago

Yes, xcode is the living proof how blazingly fast an IDE written in native languages is. /s

coldtea 6y ago

It's 2021. 1999 wants its arguments back. At the language/runtime level Java has been faster than anything else we have used on the Web with huge success (faster than PHP, Ruby/Rails, Python, Node, for example) even since 2000, and is as fast or faster than Go. It's also used in HFT - where ultimate speed means a lot. Seriously, your argument sounds like the first year CS student argument of yore, where they hear that assembly is faster, and want to rewrite everything in assembly (fortunately today's first year CS students are more well informed).

gdubya 6y ago
It's 2021, but I agree with the rest of your post :)
- coldtea 6y ago
  Damn, it's the second time I type 2020 past 1st Jan.

hestefisk 6y ago

Slow is pretty relative. What’s your use case? Start up time is not as good as native, agreed. Arithmetic? Hotspot is pretty darn fast. Developer speed? A lot better than C/C++ at least.

karmakaze 6y ago

This idea of 'heavy' is very fuzzy, though I agree. Most of the slowness I encounter though is with specific frameworks, not the language/jvm. I do sometimes use Go for its contiguous memory layout and await JEP 169: Value Objects from Project Valhalla.

skjfdoslifjeifj 6y ago
> Most of the slowness I encounter though is with specific frameworks, not the language/jvm Part of the problem is that those also happen to be the frameworks that the vast majority of the community uses. The Java zealots also tend to ignore all of the problems associated with AOT Java compilers and the fact that it will most likely be a few years before value objects are finalized and in a released version of Java. Even then, a ton of Java developers won't be able to use any features beyond Java 8 or 11 since a lot of companies don't want to give up the ability to easily use their libraries on Android.

cangencer 6y ago

I'll do a shameless plug of our modern Java benchmarking story here for the doubters: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1

TeaVMFan 6y ago

Throw away your preconceived notions -- TeaVM beat React at its own game. * Faster startup * Better Lighthouse score * Less code See for yourself: https://renato.athaydes.com/posts/comparing-jvm-alternatives-to-js.html https://renato.athaydes.com/posts/comparing-jvm-alternatives...