3 ms·
One neat thing about Go that makes it superior to a shell script is that it compiles a statically-linked binary. One self-contained file! Or N if you support N
by bqmjjx0kac 2y ago
One neat thing about Go that makes it superior to a shell script is that it compiles a statically-linked binary. One self-contained file! Or N if you support N platforms. Did I mention that cross-compilation is trivial?
- c0balt 2y agoAs someone who once inherited a static binary (without debug symbols, gotta save those few bytes) that should have been a shellscript: Please don't. If your logic reasonably fits into a shell script, then put it there. Posix shell-compatible scripts will also likely work on all platforms where you go program would've been run.
- pstuart 2y agoOr just make sure the source is available.
- mst 2y agoIf a static binary's --help doesn't tell me where the repository lives then I hope the author steps on a lego.
- decasia 2y agoThis is a good idea, will add this to my cli tool :)
- solidsnack9000 2y agoIt is no help to you or your team if they step on the Lego, though.
- bqmjjx0kac 2y agoI mean this entirely depends on how things are done where you work. I wouldn't think the back-reference is necessary if all projects have their own repo in some central location (and it's trivial to match the binary's name to a repo).
- bqmjjx0kac 2y ago> Posix shell-compatible scripts will also likely work on all platforms where you go program would've been run. While I see your point, writing a Posix compatible shell script is not trivial. Little errors creep in that "work on my machine" because /bin/sh is a symlink to /bin/bash, but break the script when someone runs it on macOS. In my experience, you get a lot of cross-platform compatibility when writing Go for zero effort.