5 ms·

Java (and C# I believe) can also compile to binaries. And golang has a runtime as well. Now what is the advantage again? The Java can compile to JVM bytecode a

by azth 5y ago

Java (and C# I believe) can also compile to binaries. And golang has a runtime as well. Now what is the advantage again? The Java can compile to JVM bytecode and be better performing than golang, all while having superior introspection and monitoring and debugging abilities. It seems to be a win-win. Only some ideological "closer to the metal" philosophy doesn't apply, so what? If startup times are truly an issue, look at Quarkus[1] and Micronaut[2], and a lot of other frameworks that use GraalVM to compile to native binaries. [1] https://quarkus.io/ https://quarkus.io/ [2] https://micronaut.io/ https://micronaut.io/

sblom 5y ago
No one insulted Java. Why so defensive? Go and Java make different tradeoffs. If you're unreasonably effective in Java and its tradeoffs work for you, that's completely fine. If you have good tools that make Java more like Go when you need Go-like characteristics, that's cool too.
- azth 5y ago
  I'm pointing out the inconsistencies in golang fans arguments which I've seen from the very beginning since it was touted as a "systems programming language" (which has been more or less silently changed since it wasn't true, but it doesn't stop the fans from parroting it). Same goes with many other false claims about the language, which aren't just non demonstrable, but demonstrably false.
  - geodel 5y ago
    Relax. Many people would call Docker/Kubernetes, and various types of databases like CockroachDB as systems. Lot of enterprises call large internal applications as "systems" There is no copyright on "systems programing" and it can be used only for OS kernels and such.
    - codeflo 5y ago
      While I agree it's probably not worth getting angry about, I would agree with the GP that the word "systems programming" traditionally has a meaning that's different from "programming things that might be called systems". What you're describing is often more simply called "backend programming".
    - azth 5y ago
      In that case, Python is also a "systems language", but you don't see people claiming it as such.
      - geodel 5y ago
        Then go ahead and do it. Who knows, it could dissipate a lot of your pent up anger.
        azth 5y ago
        You can stop with the odhominem
fourseventy 5y ago
99% of people run Java on the JVM. Just because you 'can' compile java to native code doesn't mean it really applies in real world situations. Plus as far as I can tell the only compiler that can compile Java to native code (GCJ) is no longer maintained.
- marwis 5y ago
  Nowadays people use GraalVM Native image for AOT compilation.
- pjmlp 5y ago
  PTC, Aicas, WebSphere Real Time, GraalVM, OpenJ9. Additionally, JIT caches are now part of OpenJDK, OpenJ9 and ART.
Thaxll 5y ago
Java does not perform better than Go, they're pretty much on par but I would say that overall Go is faster. As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those. Go has pretty good introspection with pprof it's enough, you don't need something heavy like JFR. For debugging delv is ok, not on part with C++/ Java but it's fine, you can even do remote debugging now. The thing is with Java and to some extend C#, yes they have different runtimes, VM, AOT / JIT etc .. different thing to compile to native binary: none of them are really mature atm and moreover it's even more complexity for the programmer, now he has to choose which runtime or compiler he's going to use, it's crazyness. Same story with the GC Java offers, too much choice, too much burden on the programmer. For app A you're going to use this GC + runtime, app B is going to be different, it really mess up the dev / ops process.
- azth 5y ago
  > Java does not perform better than Go, they're pretty much on par but I would say that overall Go is faster. Real world programs disagree. And for any large program, the JVM is a superior optimizer than golang's compiler. > As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those. I heavily disagree. I deployed services both in golang and Java/JVM languages, and simplicity of the language or runtime has nothing to do with the JVM having superior observability and monitoring. > you don't need something heavy like JFR I wonder why my employer is spending millions of dollars on dev salaries to build something not even remotely comparable to the JFR for their golang programs then. Secondly, the JFR is extremely light weight, and gives you < 1% overhead at runtime. Show me another ecosystem that gives you this out of the box. > Same story with the GC Java offers, too much choice, too much burden on the programmer. It doesn't really. The newer GCs have very few knobs to turn. Compare to when you hit GC issues in golang, the solution is to rewrite code in nonidiomatic ways as we saw with Discord. The first approach is superior.
- dragonwriter 5y ago
  > As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those. Sure, Java has much more need of dev tooling than Go. But the available dev tooling on Java being enough better than the Go tooling to make the language + tooling have a better DX can still (if that is one's experience) be a valid advantage, for anyone not working in an artificially constrained environment where they are forced to code with Notepad and no tooling.
brabel 5y ago
I am mostly a Java guy, but when people claim that Java can also compile to binaries, I really don't like that. It's kind of true... but with so many caveats it's almost a lie. * it compiles so slowly even basic applications can take 10 minutes to compile. What the hell are they doing all that time?!? Go can compile to multiple OSs architectures on the same machine and it takes a couple of seconds even for large code bases!! * you can't use most of the Java ecosystem as reflection is endemic... good luck manually declaring everywhere reflection will be used. * the loss of the JIT hurts peak Java performance a lot. Java runs as fast as Go *once the JVM is warmed up*! Native-image peak performance tends to be some way behind. Not saying GraalVM native-image is useless, it can be used if you have the energy and knowledge to get past the issues... but as someone who konws Go as well as Java, if I am going to the trouble of going native, I'd just use Go without a doubt.
- cle 5y ago
  Also good luck if you need to cross-compile. The Go toolchain for that is seamless, Graal’s is non-existent (because it is fundamentally incompatible with the way native image compilation works).
  - pjmlp 5y ago
    If you are cross compiling while using Java, you really don't get Java.
    - cle 5y ago
      If you are building and distributing executables using Graal native-image, you probably care about cross-compilation.
      - pjmlp 5y ago
        Which is an very good example of not understanding what Java is all about.
        5y ago
k__ 5y ago
It's true. Go is basically Java/C# with its runtime baked into the binary. Also, it's only marginally faster than Java. I never understood Go. I was sold as the C killer and failed, now it's basically an alternative to Erlang/Elixir, but suddenly people started running around and saying "Noooo, it was never meant to be a systems programming language like C!!!"
- azth 5y ago
  golang is not marginally faster than Java however in the real world.

by azth 5y ago

sblom 5y ago

No one insulted Java. Why so defensive? Go and Java make different tradeoffs. If you're unreasonably effective in Java and its tradeoffs work for you, that's completely fine. If you have good tools that make Java more like Go when you need Go-like characteristics, that's cool too.

azth 5y ago
I'm pointing out the inconsistencies in golang fans arguments which I've seen from the very beginning since it was touted as a "systems programming language" (which has been more or less silently changed since it wasn't true, but it doesn't stop the fans from parroting it). Same goes with many other false claims about the language, which aren't just non demonstrable, but demonstrably false.
- geodel 5y ago
  Relax. Many people would call Docker/Kubernetes, and various types of databases like CockroachDB as systems. Lot of enterprises call large internal applications as "systems" There is no copyright on "systems programing" and it can be used only for OS kernels and such.
  - codeflo 5y ago
    While I agree it's probably not worth getting angry about, I would agree with the GP that the word "systems programming" traditionally has a meaning that's different from "programming things that might be called systems". What you're describing is often more simply called "backend programming".
  - azth 5y ago
    In that case, Python is also a "systems language", but you don't see people claiming it as such.
    - geodel 5y ago
      Then go ahead and do it. Who knows, it could dissipate a lot of your pent up anger.
      - azth 5y ago
        You can stop with the odhominem

fourseventy 5y ago

99% of people run Java on the JVM. Just because you 'can' compile java to native code doesn't mean it really applies in real world situations. Plus as far as I can tell the only compiler that can compile Java to native code (GCJ) is no longer maintained.

marwis 5y ago
Nowadays people use GraalVM Native image for AOT compilation.
pjmlp 5y ago
PTC, Aicas, WebSphere Real Time, GraalVM, OpenJ9. Additionally, JIT caches are now part of OpenJDK, OpenJ9 and ART.

Thaxll 5y ago

Java does not perform better than Go, they're pretty much on par but I would say that overall Go is faster. As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those. Go has pretty good introspection with pprof it's enough, you don't need something heavy like JFR. For debugging delv is ok, not on part with C++/ Java but it's fine, you can even do remote debugging now. The thing is with Java and to some extend C#, yes they have different runtimes, VM, AOT / JIT etc .. different thing to compile to native binary: none of them are really mature atm and moreover it's even more complexity for the programmer, now he has to choose which runtime or compiler he's going to use, it's crazyness. Same story with the GC Java offers, too much choice, too much burden on the programmer. For app A you're going to use this GC + runtime, app B is going to be different, it really mess up the dev / ops process.

azth 5y ago
> Java does not perform better than Go, they're pretty much on par but I would say that overall Go is faster. Real world programs disagree. And for any large program, the JVM is a superior optimizer than golang's compiler. > As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those. I heavily disagree. I deployed services both in golang and Java/JVM languages, and simplicity of the language or runtime has nothing to do with the JVM having superior observability and monitoring. > you don't need something heavy like JFR I wonder why my employer is spending millions of dollars on dev salaries to build something not even remotely comparable to the JFR for their golang programs then. Secondly, the JFR is extremely light weight, and gives you < 1% overhead at runtime. Show me another ecosystem that gives you this out of the box. > Same story with the GC Java offers, too much choice, too much burden on the programmer. It doesn't really. The newer GCs have very few knobs to turn. Compare to when you hit GC issues in golang, the solution is to rewrite code in nonidiomatic ways as we saw with Discord. The first approach is superior.
dragonwriter 5y ago
> As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those. Sure, Java has much more need of dev tooling than Go. But the available dev tooling on Java being enough better than the Go tooling to make the language + tooling have a better DX can still (if that is one's experience) be a valid advantage, for anyone not working in an artificially constrained environment where they are forced to code with Notepad and no tooling.

brabel 5y ago

I am mostly a Java guy, but when people claim that Java can also compile to binaries, I really don't like that. It's kind of true... but with so many caveats it's almost a lie. * it compiles so slowly even basic applications can take 10 minutes to compile. What the hell are they doing all that time?!? Go can compile to multiple OSs architectures on the same machine and it takes a couple of seconds even for large code bases!! * you can't use most of the Java ecosystem as reflection is endemic... good luck manually declaring everywhere reflection will be used. * the loss of the JIT hurts peak Java performance a lot. Java runs as fast as Go *once the JVM is warmed up*! Native-image peak performance tends to be some way behind. Not saying GraalVM native-image is useless, it can be used if you have the energy and knowledge to get past the issues... but as someone who konws Go as well as Java, if I am going to the trouble of going native, I'd just use Go without a doubt.

cle 5y ago
Also good luck if you need to cross-compile. The Go toolchain for that is seamless, Graal’s is non-existent (because it is fundamentally incompatible with the way native image compilation works).
- pjmlp 5y ago
  If you are cross compiling while using Java, you really don't get Java.
  - cle 5y ago
    If you are building and distributing executables using Graal native-image, you probably care about cross-compilation.
    - pjmlp 5y ago
      Which is an very good example of not understanding what Java is all about.
      - 5y ago

k__ 5y ago

It's true. Go is basically Java/C# with its runtime baked into the binary. Also, it's only marginally faster than Java. I never understood Go. I was sold as the C killer and failed, now it's basically an alternative to Erlang/Elixir, but suddenly people started running around and saying "Noooo, it was never meant to be a systems programming language like C!!!"

azth 5y ago
golang is not marginally faster than Java however in the real world.