3 ms·

This was the main reason I started writing my random tools and scripts in Go. I can just write, cross-compile and deploy. Trying to get a "simple" Python tool

This was the main reason I started writing my random tools and scripts in Go. I can just write, cross-compile and deploy. Trying to get a "simple" Python tool with library dependencies working on a random server is a huge pain in the keister I'd rather not deal with if I have the option. This became even easier now that I can "simply" feed my old Python stuff to GPT4 and have it transform it to mostly-working Go code =)

eurekin 3y ago
Interesting. Where are those tools deployed to? Is there any runtime needed on the client? How can I grab a go tool on a pristine machine?
- jbarrs 3y ago
  Not the original commenter, but Go programs are all statically-compiled, with everything needed at run time bundled into the executable. Go does use a runtime, but that's incorporated into the exe, so no external libraries required. As such, you can get a program written in Go running on a new machine just by downloading it :) For machines where you may actually have a Go installation already, the majority of programs now can also be installed from source via Go's built-in package manager, which installs it to your home directory. A lot of dev utils, like go-imports, the language server, etc. are typically installed this way. It's usually just a single command (though the exact command can vary between projects, but is usually signposted fairly clearly).
- theshrike79 3y ago
  For 99% of stuff I need to move either one statically compiled Go binary and maybe a configuration yaml. That's it. With Python I need to have Python installed in there, and it has to be the correct version because of <reasons>. Then I need to figure out how I can install the dependencies for the program, with the correct version(s). This usually would require me to figure out what's the current virtual env du jour and how do I get it working on a random *nix distro on the target computer. Then I can install what's in requirements.txt or whatever the venv tool is using. And now I can maybe run it if all went well. And when I need to update said program, with Go I can just scp/rsync a new binary on top of the old one at it'll Just Work. With Python I need to move the Python source file(s) there, check for possible updates to libraries, update them using the venv tool and re-check that I have the correct Python version installed once more. Now picture a situation where I need to do the process above for, let's say 12 different servers on different clients after every fortnight. All servers are Intel-based, but run a variety of Linux distros. I can use the exact same Go binary for every single one, the Python solution is a complete clusterf... I do need to spend a bit more time when developing a Go solution compared to Python, but the ease of deployment is definitely worth it.
- fragmede 3y ago
  It seems too easy coming from python land where dependencies are handled so poorly, but for a lot of go programs (depends on how you're holding it), a simple scp program server: is enough.
jeroenhd 3y ago
My problem is the exact opposite. Every distribution under the sun comes with some form of Python but getting Go running can be a hassle (sometimes even impossible). For scripts, Python works great in my experience. Every time I need to load some Go related project into my workflow I somehow end up at some open Github issue that says "we can't do X I go yet but we plan on implementing it in 2021 when <some compiler feature> is done". It's not just Go, but its opinionated nature (solving difficult problems by picking one solution making it the default you can't change, and then assume nobody ever has a problem with it) and the fact it compiles to binaries makes it susceptible to "it always works except if your system does <something my system happens to do>". Things like "paths are always UTF-8" are great assumptions Go tools utterly fails to deal with.
- theshrike79 3y ago
  > For scripts, Python works great in my experience For scripts _with no external dependencies_ I do agree with you. But as soon as you do something non-trivial then you have requests and boto in there and maybe a few smaller utility ones. And now you've got issues. You can't just install them globally, because that'll change it for ALL Python programs on the machine. And now we're in venv hell again.

eurekin 3y ago

Interesting. Where are those tools deployed to? Is there any runtime needed on the client? How can I grab a go tool on a pristine machine?

jbarrs 3y ago
Not the original commenter, but Go programs are all statically-compiled, with everything needed at run time bundled into the executable. Go does use a runtime, but that's incorporated into the exe, so no external libraries required. As such, you can get a program written in Go running on a new machine just by downloading it :) For machines where you may actually have a Go installation already, the majority of programs now can also be installed from source via Go's built-in package manager, which installs it to your home directory. A lot of dev utils, like go-imports, the language server, etc. are typically installed this way. It's usually just a single command (though the exact command can vary between projects, but is usually signposted fairly clearly).
theshrike79 3y ago
For 99% of stuff I need to move either one statically compiled Go binary and maybe a configuration yaml. That's it. With Python I need to have Python installed in there, and it has to be the correct version because of <reasons>. Then I need to figure out how I can install the dependencies for the program, with the correct version(s). This usually would require me to figure out what's the current virtual env du jour and how do I get it working on a random *nix distro on the target computer. Then I can install what's in requirements.txt or whatever the venv tool is using. And now I can maybe run it if all went well. And when I need to update said program, with Go I can just scp/rsync a new binary on top of the old one at it'll Just Work. With Python I need to move the Python source file(s) there, check for possible updates to libraries, update them using the venv tool and re-check that I have the correct Python version installed once more. Now picture a situation where I need to do the process above for, let's say 12 different servers on different clients after every fortnight. All servers are Intel-based, but run a variety of Linux distros. I can use the exact same Go binary for every single one, the Python solution is a complete clusterf... I do need to spend a bit more time when developing a Go solution compared to Python, but the ease of deployment is definitely worth it.
fragmede 3y ago
It seems too easy coming from python land where dependencies are handled so poorly, but for a lot of go programs (depends on how you're holding it), a simple scp program server: is enough.

jeroenhd 3y ago

My problem is the exact opposite. Every distribution under the sun comes with some form of Python but getting Go running can be a hassle (sometimes even impossible). For scripts, Python works great in my experience. Every time I need to load some Go related project into my workflow I somehow end up at some open Github issue that says "we can't do X I go yet but we plan on implementing it in 2021 when <some compiler feature> is done". It's not just Go, but its opinionated nature (solving difficult problems by picking one solution making it the default you can't change, and then assume nobody ever has a problem with it) and the fact it compiles to binaries makes it susceptible to "it always works except if your system does <something my system happens to do>". Things like "paths are always UTF-8" are great assumptions Go tools utterly fails to deal with.

theshrike79 3y ago
> For scripts, Python works great in my experience For scripts _with no external dependencies_ I do agree with you. But as soon as you do something non-trivial then you have requests and boto in there and maybe a few smaller utility ones. And now you've got issues. You can't just install them globally, because that'll change it for ALL Python programs on the machine. And now we're in venv hell again.