Re:The Simplicity of Single-File Golang Deployments
by neverartful on Wednesday March 22, 2023 @09:33AM
(#35260748)
Probably referring to the fact that when you build a go executable there's just a single file to deploy (the executable).
[ Parent
| on HN ]
Re:The Simplicity of Single-File Golang Deployments
by jjtheblunt on Wednesday March 22, 2023 @09:39AM
(#35260822)
Go has a facility for embedding build time files within the resulting binary such that they can be read as if in a runtime file system, because the Go file access routines know about this file system type.
Re:The Simplicity of Single-File Golang Deployments
by PaulHoule on Wednesday March 22, 2023 @09:48AM
(#35260934)
You can definitely pack a Java application into a single JAR file and skip the Docker. Java's xenophobia (allergy to linking libraries) is the real root of "write once run everywhere" so often all you need is the Java runtime.
Re:The Simplicity of Single-File Golang Deployments
by thefounder on Wednesday March 22, 2023 @10:09AM
(#35261229)
You still need jre so it's not really a "single file" like on Go
Re:The Simplicity of Single-File Golang Deployments
by creshal on Wednesday March 22, 2023 @10:20AM
(#35261420)
Eh. From an ops perspective there isn't much difference between an executable file that Golang statically compiled all dependencies into and embedded a file system into, and a WAR archive that the Java compiler embedded a file system including dependencies into.
Both are self-contained single files you can give to a completely different organization and expect to run on the first attempt with no complications.
It's just that the latter needs Tomcat (not an issue, realistically) and has to be written as EnterpriseFactoryPatternFactorySingletonAbstractBaseFactorySingletonProvider that makes you feel dead inside just from looking at the documentation; while Golang (and similar newer languages) give you a lot more flexibility and better ergonomics on the developer side.
Re:The Simplicity of Single-File Golang Deployments
by PaulHoule on Wednesday March 22, 2023 @10:48AM
(#35261880)
Try Guava or Spring. In either case the framework supplies you with a
Factory, FactoryFactory, FactoryFactoryFactory, ...
that does the transitive closure so you can just get a "single" object injected into your app where you need it.
Re:The Simplicity of Single-File Golang Deployments
by jjtheblunt on Wednesday March 22, 2023 @11:37AM
(#35262729)
"lasciate ogne speranza, voi ch'intrate" (~ lose all hope, who enters) from Dante's Inferno is what comes to mind whenever someone mentions Spring.
Re:The Simplicity of Single-File Golang Deployments
by erichocean on Wednesday March 22, 2023 @10:22AM
(#35261452)
You still need a bespoke systemd configuration for TFA's Go deploys so it's not really a "single file" deploy their either.
And like the sibling comment noted, once you're allowed to set up the machine to support easy depolyment (e.g. JRE, Tomcat), a WAR becomes a single file deploy.
Re:The Simplicity of Single-File Golang Deployments
by logistark on Wednesday March 22, 2023 @11:00AM
(#35262094)
You can use JLink to embed only the needed modules and classes of the JRE for your application to run
Re:The Simplicity of Single-File Golang Deployments
by jjtheblunt on Wednesday March 22, 2023 @11:40AM
(#35262785)
class loaders in java are jvm's dynamic linker/loaders, wouldn't you say?