News for hackers. Stuff that matters.
Re:The Simplicity of Single-File Golang Deployments by synergy20 on Wednesday March 22, 2023 @11:09AM (#35262211)
very true, for Go though if you need CGO it's hard to make a single executable, otherwise it is great.

I run a few Go apps, all are single executables, upgrading to new releases has never been easier.

if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.

Re:The Simplicity of Single-File Golang Deployments by dilyevsky on Wednesday March 22, 2023 @05:07PM (#35267095)
> CGO_ENABLED=1 CC=musl-gcc go build --ldflags '-linkmode external -extldflags=-static'

Unless you cant use musl for some reason, but that’s a glibc problem, not Go

Re:The Simplicity of Single-File Golang Deployments by aatd86 on Wednesday March 22, 2023 @06:34PM (#35267962)
Some people are writing alternative via WebAssembly.

For instance wazero which I'm really excited about.

https://tetrate.io/blog/introducing-wazero-from-tetrate/?utm...

Re:The Simplicity of Single-File Golang Deployments by cookiengineer on Thursday March 23, 2023 @12:48AM (#35270656)
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) because it is independent of dlopen.

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

Re:The Simplicity of Single-File Golang Deployments by synergy20 on Thursday March 23, 2023 @01:08AM (#35270733)
very useful,thanks