You, and any other non-Golang programmer, could visit the golang.org site, download the latest release, untar it, write a hello-world service, and run "go build". It will take about that many steps and about 5 minutes, and you'll have your single-file binary ready for deployment.
Can you compare doing the same thing with Java? How many more steps does it take, assuming that you don't already have a standard Java dev setup that's configured and ready-to-go on your machine? Now, let's let you put your thumb on the scale and assume that you do already the standard setup, but you want to pursue what this posts lays out and that you insist can be done with Java. How much more effort does it take just to go from "typical Java setup" to "setup that actually lets you do what this article describes"? If the answer is not zero but your position is still that there's nothing special here because "You can do all this with Java nowadays", then it's because you're not understanding what "here" and "this" actually are.
"How much more effort does it take just to go from "typical Java setup" to "setup that actually lets you do what this article describes"? "
5-6 minutes extra. 3 more steps. You are making a mountain out of a mole-hill. Sorry to burst your bias-bubble, but Java deployment is damn easy nowadays.
If you are leveraging a cloud build-pack, single file
native exe deployments like Go's are un-optimal since they are slower - no intelligence to perform differential updates like the way you get for a Java fat-jar or tar-ball.
That's greater than zero. So you're already failing—and that's on top of the handicap already afforded to you for the initial setup.
(Even ignoring that, I'm suspicious of your numbers. Have you actually measured it? Do you have something to show that your off-the-cuff figures match what people will actually experience?)
> Sorry to burst your bias-bubble
Major irony—assuming bias on my part (where there is, in fact, none) without realizing that doing so broadcasts evidence of yours.
> Even ignoring that, I'm suspicious of your numbers. Have you actually measured it? Do you have something to show that your off-the-cuff figures match what people will actually experience?
What ? This is the time required to download GraalVM and then configure your project. This is a ONE-TIME setup. Strictly speaking, if you omit a build tool like maven - you don't really need it for a native binary - then it is simply one additional install - get Graal native image and compile your code to a binary using the CLI. Why would I even bother measuring this ?
The fact that you are even asking for "measurements" without providing corresponding "measurements" for the Golang setup - something the article never even bothered to mention is ludicrous. Why would one even consider the one-time cost of installing one additional tool ?
That way lies silliness - I should then consider Java superior because Go requires additional command to install godoc for example while Javadoc comes with the base JDK.
> Major irony—assuming bias on my part (where there is, in fact, none) without realizing that doing so broadcasts evidence of yours.
There is nothing ironic in pointing out your double-standards. I develop in both Go and Java. Both languages come with their advantages. The strict advantages Go has over Java is goroutines, more feature-packed stdlib and reduced memory footprint at runtime. (The goroutine advantage has also gone away now with virtual threads in Java).
But single file deployment is NOT an advantage Go holds over Java - since several years now.
> The fact that you are even asking for "measurements" without providing corresponding "measurements" for the Golang setup
I'm responding to your claim. The onus is on you to substantiate it.
> Why would one even consider the one-time cost of installing one additional tool ?
Aside from the low-hassle relative simplicity being the fundamental subject of the submitted article, there's no reason I suppose.
> There is nothing ironic in pointing out your double-standards.
There is no double-standard aside from the aforementioned handicap that benefits you, and you're moving the goalposts, besides. You specifically accused me of being in a "bias-bubble". There is no purer form of irony.
> 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 :/
Can you compare doing the same thing with Java? How many more steps does it take, assuming that you don't already have a standard Java dev setup that's configured and ready-to-go on your machine? Now, let's let you put your thumb on the scale and assume that you do already the standard setup, but you want to pursue what this posts lays out and that you insist can be done with Java. How much more effort does it take just to go from "typical Java setup" to "setup that actually lets you do what this article describes"? If the answer is not zero but your position is still that there's nothing special here because "You can do all this with Java nowadays", then it's because you're not understanding what "here" and "this" actually are.