> I'm responding to your claim. The onus is on you to substantiate it.
Snort. I believe the original claim has been substantiated enough already - that Go holds no advantage over Java wrt single file deployment as you can achieve "single binary" in Java too if you wish.
Measurement of a one-time setup cost was a claim made by you, not by me. You gave a description and I gave a description. Demanding precise time measurement of a ballpark is where the "double standard" lies - since you never provided any to "substantiate" yours, yet demand one from me by statements like: "So have you measured it or not?" for a CLI compiler install.
But, hey, in the spirit of goodness:
time bash <(curl -sL https://get.graalvm.org/jdk)
8.62s user 3.90s system 29% cpu 42.876 total
export JAVA_HOME="graalvm-ce-java17-22.3.1/Contents/Home"
export PATH="$JAVA_HOME/bin:$PATH"
javac HelloWorld.java && native-image HelloWorld
<....compiler output removed, except for last line>
Finished generating 'helloworld' in 16.8s.
./helloworld
Hello, World!
Huh, so it was actually FASTER than I thought for an end to end setup. You don't even need the open JDK since graalvm already comes with it. (I mistakenly thought needing open jdk was a pre-requisite).
So, its literally just: install tool, set path and invoke compilation commands. 1-2 min end to end.
> write a hello-world service, and run "go build" [...] you'll have your single-file binary ready for deployment
You seem to have written a much simpler hello-world toy program (one that literally just prints those words and exits), instead of a "hello-world service [...] ready for deployment". (Am I mistaken? 16 seconds—on what I'm assuming is not a modestly specced workstation—is a crazy-long compile time for a simple hello-world program, but it would be pretty crazy even for a deployable service.) What happens if you attempt to satisfy the actual criteria laid out?
> I believe the original claim has been substantiated enough already
Uh, no. It's not substantiated until someone substantiates it. To "substantiate" something is not synonymous with merely claiming that it is true.
> Demanding precise time measurement of a ballpark is where the "double standard"
It's not a double standard; I didn't even ask for "precise time measurement". I asked you to substantiate what you're saying. Seeking substantiation does not comprise a separate claim in and of itself (but nice try, I guess?).
"I love the promise of Graal native binaries. At the moment I'm unable to get it to work with my codebase." [2]
"Building is a resource hog. I set up a VM with 2 CPUs, 100GB of disk space, and 8GB of memory, and even a relatively small project took over 10 minutes to build." [3]
"the power of the Java ecosystem is libraries, but you cannot use 99% of them because they just use too much reflection and I am afraid they will never be prepared for Spring AOT" [3]
"DI does not work inside a native binary at runtime, you need some tool which does the whole DI at compile time (Spring Native and Quarkus do that)" [1]
"I do not even think we are in the alpha stage. For example, for 2 days I am fighting with a simple microservice using JPA, MySQL, some transactions and without success. Fixed at least 4 bugs, and now I gave up. I cannot imagine what problems can arise in mid-size projects." [3]
"GraalVM [not] supporting Swing and JavaFX "out of the box"." [4]
"Even assuming your app run as intended (which is already complicated enough, you will have to run their java agent to register all reflections), there is no telling how it will perform. For example record methods are currently implemented using reflection which completely obliterate performance: https://github.com/oracle/graal/issues/4348" [1]
This is my pet peeve. Presumably you're very familiar with the single binary Java deployment story you're describing. And yet, somehow everything you say is false. It's incredibly vexing to have to go out and verify such claims about subject matters that I'm not that familiar with because the supposed experts are basically lying through their teeth :/
Snort. I believe the original claim has been substantiated enough already - that Go holds no advantage over Java wrt single file deployment as you can achieve "single binary" in Java too if you wish.
Measurement of a one-time setup cost was a claim made by you, not by me. You gave a description and I gave a description. Demanding precise time measurement of a ballpark is where the "double standard" lies - since you never provided any to "substantiate" yours, yet demand one from me by statements like: "So have you measured it or not?" for a CLI compiler install.
But, hey, in the spirit of goodness:
Huh, so it was actually FASTER than I thought for an end to end setup. You don't even need the open JDK since graalvm already comes with it. (I mistakenly thought needing open jdk was a pre-requisite).So, its literally just: install tool, set path and invoke compilation commands. 1-2 min end to end.