8 ms·

Define "closer to the metal than Java". What exactly does that mean, and how exactly is that an advantage?

by azth 5y ago

PeterCorless 5y ago
"Go performance is excellent since Go compiles to bare metal and there is no runtime between the metal and the language as is the case in other languages I used in this exercise (Java & Clojure: compile to JVM bytecode, and JVM runs the bytecode, Python & Javascript: interpreted languages and the runtime runs the code (though also Python compiles to bytecode)." Source: https://www.karimarttila.fi/languages/2018/11/13/go-good-productivity-with-bare-metal.html https://www.karimarttila.fi/languages/2018/11/13/go-good-pro...
- azth 5y ago
  That statement is misleading. You can also compile Java natively. Secondly, there is most definitely a runtime "between the metal and the language" in golang, the GC being the most obvious. This proves my thoughts that these claims are not valid.
  - nemothekid 5y ago
    >You can also compile Java natively. This is also misleading. You are implying that GraalVM isn't relatively new and that Java native compilation isn't rare. I've yet to see anyone deploy service or CLI tools that are natively compiled in Java. That statement is about as true as saying you can compile Python natively. Just because its possible doesn't mean the language is actually suited for it.
    - azth 5y ago
      I never said it was rare or not. It is possible if you truly need fast startup times. The fact of the matter, the JVM is good enough for the vast majority of the use cases, and is faster than golang so no need to even go there.
      - anthk 5y ago
        >, and is faster than golang Nice joke. Go software runs much snappier and faster than any Java GUI or CLI tool.
        azth 5y ago
        Not a joke. Large real world programs are proof (otherwise, my employer will not be spending millions of dollars on reinventing performance and other toolings already present in the JVM). What golang gui programs are you comparing against? Java CLI tools compiled with GraalVM start up just as fast.
    - Cupprum 5y ago
      >That statement is about as true as saying you can compile Python natively. Python is actually compiled. When you run a file, it firstly compiles the cod into a bytecode, which is saved in ‘.pyc’ files. These are afterwards interpreted by the interpreter.
      - anthk 5y ago
        So does TCL, and yet Go outperforms TCL/TK, even 8.6.
    - pjmlp 5y ago
      You weren't looking into the right plaaces, ExcelsiorJET, PTC, Aicas, Websphere Real Time, Android since version 5 (althought the story here is complicated).
  - anthk 5y ago
    Call me when I can compile some static binary for Windows from OpenBSD such as GOOS=Windows GOARCH=arch32 go build foo.go.
- cpuguy83 5y ago
  There is a runtime between the metal and the language. The runtime is what makes it really nice for writing network services in. It's also what makes it really terrible for lower level things.
Thaxll 5y ago
Go does not have bytecode or a VM, it compiles directly to a binary with a runtime.
- 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.
mustache_kimono 5y ago
Golang can usually more than halve your memory usage? The economics may dictate something more like golang.
- azth 5y ago
  What does that have to do with being "closer to the metal"? Secondly, Java can be tuned, but its default mode of operation is to take up the most amount of memory it can in order to give you higher performance (thoughput and latency). `-Xmx` is a thing. Finally, now with GraalVM going mainstream, and frameworks like Quarkus[1] and Micronaut[2], you are able to compile Java programs to native binaries and also have lower memory usage if that's truly a restriction. [1] https://quarkus.io/ https://quarkus.io/ [2] https://micronaut.io/ https://micronaut.io/
  - mustache_kimono 5y ago
    You also asked what the advantage of golang was and I told you what the advantage was. I'm was not saying "closer to the metal" is the right description, but, if we'd stop being pedantic, I think we know what she/he meant. Some people really don't want to tune VMs. No one is saying Java doesn't have a place too. Jeez, dude.
  - unfocussed_mike 5y ago
    OK -- but you've listed a whole bunch of third party projects and technologies and tools to get Java closer to what Go does _really_ easily out of the box. I like Java (used to _love_ it about 26 years ago... been a decade since I've written any) but Go is actually a breath of fresh air for typical cross-platform systems programs.
    - azth 5y ago
      GraalVM is not third party.
      - geodel 5y ago
twic 5y ago
The one significant thing i can think of is that Go makes pointers explicit, and allows variables and parameters which are by-value. So you can control whether some struct contains a pointer to some other struct, or just embeds the fields directly. This gives you influence over memory use patterns, access time, and garbage collection that you don't have in Java. Java is planned to gain an equivalent of this ability through primitive classes (JEP 401). As as i know, we expect to get a preview of this feature in Java 19, which should be released in September this year.
tptacek 5y ago
Two major things: 1. It compiles statically down to machine code; there's no JIT or bytecode interpretation execution path. 2. It offers straightforward control over the memory layout of your data structures (it doesn't offer straightforward control over the lifecycle of your memory, which is the next step towards the metal that Rust takes). The advantage is that casual Go code is generally going to be more efficient both in execution and memory usage than a casual program in a higher-level language. You can make Java do almost anything; the important thing is what languages make easy, not what they make possible.
- codeflo 5y ago
  When the actual machine code is generated is irrelevant to the level of abstraction. There have been JIT compilers for C, and ahead-of-time compilers for C# and Java, and that changes nothing about how close to the metal any of them are. Memory layout is a valid point though. C# with its value types gives you a lot more control than Java does, but is still often grouped with Java, and I think rightly so. Go's pointers go quite a bit further, but then on the other hand, it also has high-level data structures like map as language primitives, which makes it less close to the metal as far as I'm concerned. I'd personally group all GC'd languages in roughly the same class here, but I think it's reasonable to disagree or make finer distinctions.
  - tptacek 5y ago
    By that logic, every language is equivalently close to the metal when it comes to execution, since they can all be JIT'd one way or another. It's a colorable argument but not one most practitioners would agree with.
    - codeflo 5y ago
      No, I would agree that something with a smaller runtime might be considered closer to the metal, I was talking about level of abstraction, which I think is different. One example is that a typical C code that depends on a libc is farther from the machine than C code that runs without a libc. Both might use very similar styles. I'm also not saying JIT vs. AOT is an irrelevant distinction in practice -- like everyone else, I like my programs to start fast. But in the end, you have machine code in RAM either way; the level of abstraction is, all else being equal, the same. The precise details of how that machine code gets there change nothing about how the program is written. The emphasis people put on those details aren't always warranted. I don't think they matter at all for typical backend code, which is one of Go's main niches. Edit: The earlier version of this response was maybe unnecessarily pointed, I expanded and toned it down a bit.
fulafel 5y ago
It wasn't claimed to be an advantage I think. It's a tradeoff.
- azth 5y ago
  A tradeoff in what exactly?
  - fulafel 5y ago
    Shipping arch / OS / runtime vetsion neutral apps vs implementation simplicity and single file binaries, for one. Also, decoupling of the runtime from the language is huge, and lets us have nice languages like Clojure and Scala on the JVM.

Define "closer to the metal than Java". What exactly does that mean, and how exactly is that an advantage?

by azth 5y ago

Define "closer to the metal than Java". What exactly does that mean, and how exactly is that an advantage?

"Go performance is excellent since Go compiles to bare metal and there is no runtime between the metal and the language as is the case in other languages I used in this exercise (Java & Clojure: compile to JVM bytecode, and JVM runs the bytecode, Python & Javascript: interpreted languages and the runtime runs the code (though also Python compiles to bytecode)." Source: https://www.karimarttila.fi/languages/2018/11/13/go-good-productivity-with-bare-metal.html https://www.karimarttila.fi/languages/2018/11/13/go-good-pro...

azth 5y ago
That statement is misleading. You can also compile Java natively. Secondly, there is most definitely a runtime "between the metal and the language" in golang, the GC being the most obvious. This proves my thoughts that these claims are not valid.
- nemothekid 5y ago
  >You can also compile Java natively. This is also misleading. You are implying that GraalVM isn't relatively new and that Java native compilation isn't rare. I've yet to see anyone deploy service or CLI tools that are natively compiled in Java. That statement is about as true as saying you can compile Python natively. Just because its possible doesn't mean the language is actually suited for it.
  - azth 5y ago
    I never said it was rare or not. It is possible if you truly need fast startup times. The fact of the matter, the JVM is good enough for the vast majority of the use cases, and is faster than golang so no need to even go there.
    - anthk 5y ago
      >, and is faster than golang Nice joke. Go software runs much snappier and faster than any Java GUI or CLI tool.
      - azth 5y ago
        Not a joke. Large real world programs are proof (otherwise, my employer will not be spending millions of dollars on reinventing performance and other toolings already present in the JVM). What golang gui programs are you comparing against? Java CLI tools compiled with GraalVM start up just as fast.
  - Cupprum 5y ago
    >That statement is about as true as saying you can compile Python natively. Python is actually compiled. When you run a file, it firstly compiles the cod into a bytecode, which is saved in ‘.pyc’ files. These are afterwards interpreted by the interpreter.
    - anthk 5y ago
      So does TCL, and yet Go outperforms TCL/TK, even 8.6.
  - pjmlp 5y ago
    You weren't looking into the right plaaces, ExcelsiorJET, PTC, Aicas, Websphere Real Time, Android since version 5 (althought the story here is complicated).
- anthk 5y ago
  Call me when I can compile some static binary for Windows from OpenBSD such as GOOS=Windows GOARCH=arch32 go build foo.go.
cpuguy83 5y ago
There is a runtime between the metal and the language. The runtime is what makes it really nice for writing network services in. It's also what makes it really terrible for lower level things.

Thaxll 5y ago

Go does not have bytecode or a VM, it compiles directly to a binary with a runtime.

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.

mustache_kimono 5y ago

Golang can usually more than halve your memory usage? The economics may dictate something more like golang.

azth 5y ago
What does that have to do with being "closer to the metal"? Secondly, Java can be tuned, but its default mode of operation is to take up the most amount of memory it can in order to give you higher performance (thoughput and latency). `-Xmx` is a thing. Finally, now with GraalVM going mainstream, and frameworks like Quarkus[1] and Micronaut[2], you are able to compile Java programs to native binaries and also have lower memory usage if that's truly a restriction. [1] https://quarkus.io/ https://quarkus.io/ [2] https://micronaut.io/ https://micronaut.io/
- mustache_kimono 5y ago
  You also asked what the advantage of golang was and I told you what the advantage was. I'm was not saying "closer to the metal" is the right description, but, if we'd stop being pedantic, I think we know what she/he meant. Some people really don't want to tune VMs. No one is saying Java doesn't have a place too. Jeez, dude.
- unfocussed_mike 5y ago
  OK -- but you've listed a whole bunch of third party projects and technologies and tools to get Java closer to what Go does _really_ easily out of the box. I like Java (used to _love_ it about 26 years ago... been a decade since I've written any) but Go is actually a breath of fresh air for typical cross-platform systems programs.
  - azth 5y ago
    GraalVM is not third party.
    - geodel 5y ago

twic 5y ago

The one significant thing i can think of is that Go makes pointers explicit, and allows variables and parameters which are by-value. So you can control whether some struct contains a pointer to some other struct, or just embeds the fields directly. This gives you influence over memory use patterns, access time, and garbage collection that you don't have in Java. Java is planned to gain an equivalent of this ability through primitive classes (JEP 401). As as i know, we expect to get a preview of this feature in Java 19, which should be released in September this year.

tptacek 5y ago

Two major things: 1. It compiles statically down to machine code; there's no JIT or bytecode interpretation execution path. 2. It offers straightforward control over the memory layout of your data structures (it doesn't offer straightforward control over the lifecycle of your memory, which is the next step towards the metal that Rust takes). The advantage is that casual Go code is generally going to be more efficient both in execution and memory usage than a casual program in a higher-level language. You can make Java do almost anything; the important thing is what languages make easy, not what they make possible.

codeflo 5y ago
When the actual machine code is generated is irrelevant to the level of abstraction. There have been JIT compilers for C, and ahead-of-time compilers for C# and Java, and that changes nothing about how close to the metal any of them are. Memory layout is a valid point though. C# with its value types gives you a lot more control than Java does, but is still often grouped with Java, and I think rightly so. Go's pointers go quite a bit further, but then on the other hand, it also has high-level data structures like map as language primitives, which makes it less close to the metal as far as I'm concerned. I'd personally group all GC'd languages in roughly the same class here, but I think it's reasonable to disagree or make finer distinctions.
- tptacek 5y ago
  By that logic, every language is equivalently close to the metal when it comes to execution, since they can all be JIT'd one way or another. It's a colorable argument but not one most practitioners would agree with.
  - codeflo 5y ago
    No, I would agree that something with a smaller runtime might be considered closer to the metal, I was talking about level of abstraction, which I think is different. One example is that a typical C code that depends on a libc is farther from the machine than C code that runs without a libc. Both might use very similar styles. I'm also not saying JIT vs. AOT is an irrelevant distinction in practice -- like everyone else, I like my programs to start fast. But in the end, you have machine code in RAM either way; the level of abstraction is, all else being equal, the same. The precise details of how that machine code gets there change nothing about how the program is written. The emphasis people put on those details aren't always warranted. I don't think they matter at all for typical backend code, which is one of Go's main niches. Edit: The earlier version of this response was maybe unnecessarily pointed, I expanded and toned it down a bit.

fulafel 5y ago

It wasn't claimed to be an advantage I think. It's a tradeoff.

azth 5y ago
A tradeoff in what exactly?
- fulafel 5y ago
  Shipping arch / OS / runtime vetsion neutral apps vs implementation simplicity and single file binaries, for one. Also, decoupling of the runtime from the language is huge, and lets us have nice languages like Clojure and Scala on the JVM.