3 ms·

Is this article from 2016? You can do all this with Java nowadays. I have observed a lot of folks on HN whose last knowledge about Java was from a decade plus a

Is this article from 2016? You can do all this with Java nowadays. I have observed a lot of folks on HN whose last knowledge about Java was from a decade plus ago pontificating about Java deficiencies that no longer exist today. Use the GraalVM native build tools https://graalvm.github.io/native-build-tools/latest/index.html https://graalvm.github.io/native-build-tools/latest/index.ht.... "Use Maven to Build a Native Executable from a Java Application" https://www.graalvm.org/22.2/reference-manual/native-image/guides/use-native-image-maven-plugin/ https://www.graalvm.org/22.2/reference-manual/native-image/g...

Rapzid 4y ago
.Net too, also same prob with decade old worldview about .Net One thing that hasn't changed is that C# > Java ;P
cxr 4y ago
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.
- lenkite 4y ago
  "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.
  - cxr 4y ago
    > 5-6 minutes extra. 3 more steps. 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.
    - lenkite 4y ago
      > 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.
      - cxr 4y ago
        So have you measured it or not? > 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.

Rapzid 4y ago

.Net too, also same prob with decade old worldview about .Net One thing that hasn't changed is that C# > Java ;P

cxr 4y ago

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.

lenkite 4y ago
"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.
- cxr 4y ago
  > 5-6 minutes extra. 3 more steps. 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.
  - lenkite 4y ago
    > 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.
    - cxr 4y ago
      So have you measured it or not? > 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.