executable-dist-plugin
debug
| executable-dist-plugin | debug | |
|---|---|---|
| 1 | 1 | |
| 3 | 115 | |
| - | 0.0% | |
| 10.0 | 0.6 | |
| about 9 years ago | about 1 month ago | |
| Java | Go | |
| BSD 2-clause "Simplified" License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
executable-dist-plugin
-
The Simplicity of Single-File Golang Deployments
I feel like i'm taking crazy pills (at a low dose) when i read this stuff.
I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1].
That is one step more than deploying a single binary, but it's a trivial step, and both steps are done by a release script, so there is a single user-visible step.
The additional pain associated with deploying a tarball rather than a single binary is negligible. It simply is not worth worrying about [2].
But Go enjoyers make such a big deal of this single binary! What am i missing?
Now, this post does talk about Docker. If you use Docker to deploy, then yes, that is more of a headache. But Docker is not the only alternative to a single binary! You can just deploy a tarball!
[1] We do deploy the JDK separately. We have a script which takes a local path to a JDK tarball and a hostname, and installs the JDK in the right place on the target machine. This is a bit caveman, and it might be better to use something like Ansible, or make custom OS packages for specific JDKs, or even use something like asdf. But we don't need to deploy JDKs very often, so the script works for us.
[2] Although if you insist, it's pretty easy to make a self-expanding-and-running zip, so you could have a single file if you really want: https://github.com/vmware-archive/executable-dist-plugin
debug
-
The Simplicity of Single-File Golang Deployments
In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace).
And there's also "purego" as an implementation that directly generates shellcode.
Maybe those will help you, too?
I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.
[1] https://github.com/Binject/debug
[2] https://github.com/ebitengine/purego
What are some alternatives?
bearclaw - tiny static site generator w/ rss
go-reuseport - reuse tcp/udp ports in golang
Quarkus - Quarkus: Supersonic Subatomic Java.
release.sh - 🚀 A simple bash script for building Go projects for multiple platforms 💻💾
tableflip - Graceful process restarts in Go
httpx - Provides an extended, production-ready HTTP server.
go - The Go programming language