5 ms·

And Java has some advantages that are hard to beat. It performs better than Go and builds just as fast (at least when not using some popular build tools) while

by pron 7mo ago

And Java has some advantages that are hard to beat. It performs better than Go and builds just as fast (at least when not using some popular build tools) while offering unmatched deep, low-overhead observability. People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.

Capricorn2481 7mo ago
> and builds just as fast Source? I'm not saying you're lying but I have never seen any Java project build as fast as Go
- pron 7mo ago
  Use javac directly, in a recent JDK, to compile lots of files at once (i.e. one invocation of javac to compile multiple files) and you'll see. The speed is over 100,000 lines/sec: https://mill-build.org/blog/1-java-compile.html https://mill-build.org/blog/1-java-compile.html
  - voidfunc 7mo ago
    Seriously a need for a new build tool in Java that doesn't fuck around too much.
    - vips7L 7mo ago
      Check out mill from the link. It’s quite good.
      - voidfunc 7mo ago
        Oh sweet. Former Java dev turned Go dev like a decade ago, this looks close to what I want.
    - nekitamo 7mo ago
      100% this. Ant was bad in many ways, but at least it was lightning fast. Gradle is just tragic.
      - vips7L 7mo ago
        Try mill from the link! https://mill-build.org/mill/index.html https://mill-build.org/mill/index.html
HendrikHensen 7mo ago
> It performs better than Go Do you have some sources or experiences to share on this topic? I'm very curious. My experience is the complete opposite. At my previous job there was a Java web application and running in Kubernetes (1 vCPU and 1Gi of memory) was able to deal with at most 80 requests per second, using up almost the full 1 vCPU and ~600-700MiB of memory. That was a bit disappointing, since we were supposed to support at most ~1000rps on this API, 13+ pods is a lot, and we felt "software could do better". A reactive guru from another team told us we should use a reactive stack, so he came in and rebuilt the app using the reactive stack. Now it was doing about 120rps on one pod (about the same memory usage), which was a good improvement, but still disappointing. One guy on the team was motivated to rewrite the API in Go as a proof of concept, and we were blown away. With the same 1 vCPU it was now able to handle 400 requests per second, while using ~100-200MiB of memory, and having approximately 20% better response times. > builds just as fast (at least when not using some popular build tools) I find this a little bit of a cop-out, because almost everyone is using the popular build tools. And it's quite a chore to build a full application without those popular build tools. With Go, all batteries for building are included.
- gf000 7mo ago
  Well, what frameworks were used? Also what is behind the web requests, what were they doing? Because it's comparing mostly frameworks, not languages. As for the build tools, unfortunately the scene is not the best on Java - but javac itself is indeed fast.
  - HendrikHensen 7mo ago
    Yeah javac is pretty great. I was doing Kotlin for some time and I was getting very annoying by how much slower and slower running tests and doing full builds became. I thought it was some issue with the JVM ecosystem. Then I started a project with pure Java and I was blown away by how fast it was. Unit tests in my IDE running as fast as I'm used to in Go. And indeed I was surprised by the speed of the compilation step of the build too. Perhaps Kotlin is doing better now, haven't touched it in a few years, but yeah, Java made some great steps there in the past decades.
- 7mo ago
Mawr 7mo ago
> It performs better than Go > and its optimising compiler and GCs blow Go out of the water without breaking a sweat. Well, dandy! Since the performance gap is that big, it should be trivial to get hard data backing that up. Mind linking some representative benchmarks? Dang, I just can't wait, same resource usage for Go and Java (RAM in particular, if you would), and Java performance that "blows Go out of the water". > and builds just as fast Oh? But you're comparing apples to oranges. Go builds its source into a machine code executable, all optimizations are applied at this step. This then gets directly executed by the CPU. Java "builds" its source into bytecode. It's a trivial transformation that then needs to actually be compiled and optimized by a virtual machine at runtime before the CPU can run it. So then, what build time does Java have when doing AOT compilation? Again, hard numbers please, thanks. > while offering unmatched deep, low-overhead observability. > People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language. Very believable statements, given that you literally work on Java for Oracle :) No need to bother to make a disclaimer about that I guess. Shameless.
- gf000 7mo ago
  > all optimizations You might want to take a look at what actually happens here. The only reason Go can compile this fast is that it does barely any optimizations. And yeah, javac also does a literal transfomation to Java byte code, no difference here with Go. One will just get a second chance of actually getting optimized via a JIT compiler. And Java AOT is not doing the same as Go, so again, apples to oranges. It does a complete closed universe build of the program, which requires knowing what classes are ever reachable, and then running their initializers at build time, so they can be burnt into a binary in an initialized state. There used to be a GNU java compiler doing pretty much what Go did, it's not hard to build, it just wouldn't be compatible with "normal Java", so the use cases would be limited.

by pron 7mo ago

Capricorn2481 7mo ago

> and builds just as fast Source? I'm not saying you're lying but I have never seen any Java project build as fast as Go

pron 7mo ago
Use javac directly, in a recent JDK, to compile lots of files at once (i.e. one invocation of javac to compile multiple files) and you'll see. The speed is over 100,000 lines/sec: https://mill-build.org/blog/1-java-compile.html https://mill-build.org/blog/1-java-compile.html
- voidfunc 7mo ago
  Seriously a need for a new build tool in Java that doesn't fuck around too much.
  - vips7L 7mo ago
    Check out mill from the link. It’s quite good.
    - voidfunc 7mo ago
      Oh sweet. Former Java dev turned Go dev like a decade ago, this looks close to what I want.
  - nekitamo 7mo ago
    100% this. Ant was bad in many ways, but at least it was lightning fast. Gradle is just tragic.
    - vips7L 7mo ago
      Try mill from the link! https://mill-build.org/mill/index.html https://mill-build.org/mill/index.html

HendrikHensen 7mo ago

> It performs better than Go Do you have some sources or experiences to share on this topic? I'm very curious. My experience is the complete opposite. At my previous job there was a Java web application and running in Kubernetes (1 vCPU and 1Gi of memory) was able to deal with at most 80 requests per second, using up almost the full 1 vCPU and ~600-700MiB of memory. That was a bit disappointing, since we were supposed to support at most ~1000rps on this API, 13+ pods is a lot, and we felt "software could do better". A reactive guru from another team told us we should use a reactive stack, so he came in and rebuilt the app using the reactive stack. Now it was doing about 120rps on one pod (about the same memory usage), which was a good improvement, but still disappointing. One guy on the team was motivated to rewrite the API in Go as a proof of concept, and we were blown away. With the same 1 vCPU it was now able to handle 400 requests per second, while using ~100-200MiB of memory, and having approximately 20% better response times. > builds just as fast (at least when not using some popular build tools) I find this a little bit of a cop-out, because almost everyone is using the popular build tools. And it's quite a chore to build a full application without those popular build tools. With Go, all batteries for building are included.

gf000 7mo ago
Well, what frameworks were used? Also what is behind the web requests, what were they doing? Because it's comparing mostly frameworks, not languages. As for the build tools, unfortunately the scene is not the best on Java - but javac itself is indeed fast.
- HendrikHensen 7mo ago
  Yeah javac is pretty great. I was doing Kotlin for some time and I was getting very annoying by how much slower and slower running tests and doing full builds became. I thought it was some issue with the JVM ecosystem. Then I started a project with pure Java and I was blown away by how fast it was. Unit tests in my IDE running as fast as I'm used to in Go. And indeed I was surprised by the speed of the compilation step of the build too. Perhaps Kotlin is doing better now, haven't touched it in a few years, but yeah, Java made some great steps there in the past decades.
7mo ago

Mawr 7mo ago

> It performs better than Go > and its optimising compiler and GCs blow Go out of the water without breaking a sweat. Well, dandy! Since the performance gap is that big, it should be trivial to get hard data backing that up. Mind linking some representative benchmarks? Dang, I just can't wait, same resource usage for Go and Java (RAM in particular, if you would), and Java performance that "blows Go out of the water". > and builds just as fast Oh? But you're comparing apples to oranges. Go builds its source into a machine code executable, all optimizations are applied at this step. This then gets directly executed by the CPU. Java "builds" its source into bytecode. It's a trivial transformation that then needs to actually be compiled and optimized by a virtual machine at runtime before the CPU can run it. So then, what build time does Java have when doing AOT compilation? Again, hard numbers please, thanks. > while offering unmatched deep, low-overhead observability. > People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language. Very believable statements, given that you literally work on Java for Oracle :) No need to bother to make a disclaimer about that I guess. Shameless.

gf000 7mo ago
> all optimizations You might want to take a look at what actually happens here. The only reason Go can compile this fast is that it does barely any optimizations. And yeah, javac also does a literal transfomation to Java byte code, no difference here with Go. One will just get a second chance of actually getting optimized via a JIT compiler. And Java AOT is not doing the same as Go, so again, apples to oranges. It does a complete closed universe build of the program, which requires knowing what classes are ever reachable, and then running their initializers at build time, so they can be burnt into a binary in an initialized state. There used to be a GNU java compiler doing pretty much what Go did, it's not hard to build, it just wouldn't be compatible with "normal Java", so the use cases would be limited.