<p>By script I mean:</p>
<p> </p>
<ol>
<li><p>Write a <code>script.go</code></p></li>
<li><p>Send it to the server</p></li>
<li><p>Run the script on the server <code>go run script.go</code></p></li>
<li><p>Edit if needed.</p></li>
<li><p>Run again.</p></li>
</ol>
<p> </p>
<p>Are there any drawbacks to doing it this way?</p>
<p>I like the idea of having a source file that you can edit at any time instead of sending binaries back and forth.</p>
<p>Plus, the Go runtime doesn't seem to be any more hefty than the Python runtime.</p>
<p>Would I gain anything if I used Python or Perl instead?
The only thing I can think of is less boilerplate but If I'm writing a longer script the boilerplate doesn't matter anyway and for short scripts I use Bash.</p>
<p> </p>
<p>Also, there is the option of writing scripts in this format:</p>
<p> </p>
<pre><code>//usr/bin/env go run $0 "$@"; exit
package main
import "fmt"
func main() {
fmt.Println("Hello, world!")
}
</code></pre>
<p> </p>
<p>And then just running it like any other script <code>./script.go</code></p>
<p> </p>
<p><strong>Edit:</strong></p>
<p>I also found this quote supposedly from Rob Pike, commenting on why there is no support for the use of a shebang<code>!#</code> in Golang programs:</p>
<p> </p>
<blockquote>
<p>“Useful” is not an argument for a feature. All features are useful; otherwise they would not be features. The issue is whether the feature justifies its cost. That is a judgement call, and my judgement is, no. Running compilers and linkers, doing megabytes of I/O, and creating temporary binary files is not a justifiable expense for running a small program. For large programs, the amortization is even more in favor of not doing this.</p>
<p>I am firmly against adding a feature to Go that encourages abuse of resources.</p>
<p>If you want the feature, use gorun or an equivalent wrapper program. That’s what it’s for. I think believe [sic] gorun is a mistake, but I’m not stopping you from installing it and using it as you see fit.</p>
</blockquote>
<p> </p>
<p><code>gorun</code> being the Ubuntu utility that allows you to use <code>!#</code> at the top of the Go program, otherwise you have to fake it with <code>//</code>.</p>
<p>Not sure if I completely agree. I'm sure my computer doesn't mind if I abuse its resources, unless I want to conserve electricity.</p>
<hr/>**评论：**<br/><br/>ExceptionallyAdmiral: <pre><p>Why not just use something like <a href="https://www.ansible.com/" rel="nofollow">Ansible</a>? That would let you run anything you need on remote systems, including your Go programs, and all that needs to be installed are Python for the Ansible runtime and Golang in your case.</p></pre>jrkkrj1: <pre><p>This. Right to for the job. Just depends on a single python install on your master. Everything else is just ssh. </p>
<p>Give a man a hammer, everything looks like a nail.</p></pre>cwchentw: <pre><p>It is fine if running Go programs this way. However, Perl or Python will be easier. One of the advantages of Golang comes with binary deployment. If running Go programs as scripts only, why not Python?</p></pre>DanChm: <pre><p>Primarily because I know Go better than Python. So I wasn't sure if learning Python was worth the time.</p></pre>lampshadish2: <pre><p>It is worth your time.</p></pre>JackOhBlades: <pre><p>Not necessarily.</p></pre>ryeguy: <pre><p>For scripting and small tasks it absolutely is. This is one of its primary uses which leads to a better package ecosystem for that type of thing.</p></pre>n1ghtm4n: <pre><p>Good idea! The alternative is a bash, Python, or Ruby script. Python and Ruby add tons of dependency baggage to the runtime environment. You've got to make sure you've got the right version of the interpreter, all the gems/modules installed, and potentially <code>pip</code>, <code>gem</code>, <code>bundler</code>, <code>rvm</code>, <code>venv</code>, and much more. bash will cause you different headaches, e.g. <code>apt-get</code>ting all the UNIX utilities. bash code quality is usually terrible.</p>
<p>If you script in Go, your only runtime dependency is the <code>go</code> tool and <code>$GOPATH</code>, which you probably have set up already. You get all the goodness of Go (easy async, highly readable code). Odds are your devs write better Go than bash. The only real downside is that scripting in Go is verbose. Who cares?</p></pre>JackOhBlades: <pre><p>They would still need to manage third party dependencies since OP is sending source files, not binaries. </p></pre>jdeville: <pre><p>The dependency issue is just as true for go if you have any imports that aren't stdlib. Especially if the library has significantly changed since you installed it since go get doesn't make it easy to pin versions. I suppose vendoring helps, but then you have to send a file tree. </p>
<p>That said, I still think this is an overall good idea and our build tool at work uses a go run based script. The biggest issue to me is that go isn't really designed as a scripting language and your scripts do end up more verbose if u want things like shelling out to another tool or file is. Not a deal breaker but something to be aware of</p></pre>Shammyhealz: <pre><p>Depends on what you mean by admin scripts. If it's something that's not going to be god awful, bash is a good choice.</p>
<p>If it's something that's not well suited for bash, Go is an okay choice. Python may be a better choice, since Go isn't quite as popular as Python is, but Go is a serviceable choice.</p>
<p>It's also really not that difficult to send Go programs. Set up a CI/CD pipeline that uploads the latest version of the binary to a web server and you can just wget the latest version of the binary. That prevents you from having to install the Go runtime on every system, and frees you up to use non-standard libraries without having to distribute them everywhere.</p></pre>ericzhill: <pre><p>I have started writing utilities in go and just sitting the binary next to the go source. Running the tool directly via the binary as needed, and if I need to change it, just update the source and go build source.go. it feels a lot like the old school turbo Pascal days or BCC days where the code and exe just lived in the same directory for small apps. </p></pre>: <pre><p>[deleted]</p></pre>JackOhBlades: <pre><p>OP specifically mentions sending Go source files (not binaries); so your point is moot. </p></pre>: <pre><p>[deleted]</p></pre>natefinch: <pre><p>OP asked about using go run. There's no binary (I mean, obviously, go run compiles a temporary one, then throws it away).</p></pre>nstratos: <pre><p>I've been using "<a href="https://github.com/nstratos/make.go" rel="nofollow">go scripts</a>" to build projects instead of makefiles for a while now and I am quite satisfied with the results. I usually run them with <code>go run</code>.</p>
<p>I imagine the same procedure would work just fine for admin scripts the way you are describing it as long as the Go toolchain is installed on the server.</p>
<p>I wasn't aware that <code>gorun</code> existed but I am a little surprised by Mr. Pike's quote. I wonder if he considers <code>go run</code> also a mistake. I always viewed go scripts that run with <code>go run</code> as part of the toolchain, similar to <code>go generate</code>.</p></pre>carsncode: <pre><p>I guess it comes down to: why is step 4 there? In what situation are you writing most of your code somewhere else, uploading it to a server, modifying it some more (in a way that couldn't be replaced with runtime configuration), then running it on the server with no build/test in between? Regardless of the language used, if someone was doing this in my environment, I'd revoke their access. Even bash scripts can and should be tested before pushing them.</p></pre>
