4 ms·
> Each format must be built on the platform it runs on, there is no cross-platform support. So now you're back to platform-specific packages, except you don't
by pdpi 4y ago
> Each format must be built on the platform it runs on, there is no cross-platform support.
So now you're back to platform-specific packages, except you don't have Go's support for cross-compilation. Hardly much of an advantage.
- mike_hearn 4y agoYou can make self-updating packages of JVM apps for Windows, macOS and Linux from your local OS ("cross compiled") using Conveyor: https://conveyor.hydraulic.dev/ https://conveyor.hydraulic.dev/ It's not JVM specific but it does understand how to bundle the JVM, use jlink to shrink it, read your classpath from Gradle etc.
- marginalia_nu 4y agoWell yeah. You've still got jars though if you want architecture independence. Java's not really aiming at the desktop market though. It's a server language first and foremost. You're most likely setting up a machine (or VM or container) to cater to the Java code you're running. But to be realistic, most Java code either runs in application servers (as WARs) or in containers, and in the latter case, even though your java jars are architecture independent, docker just isn't.
- pjmlp 4y agoGo only does cross-compilation when using the standard library and pure Go libraries, hardly any different. Plus the target OS needs to exist on the toolchain anyway.