3 ms·

I'm not sure what definition you have for "scripts", but I'm fine with running `go run main.go` or whatever. I don't need my Go files to be executable (half the

I'm not sure what definition you have for "scripts", but I'm fine with running `go run main.go` or whatever. I don't need my Go files to be executable (half the time I just run bash scripts via `bash script.sh` anyway because that always works). The biggest impediment is the ceremony for subprocessing out, but I'm sure that could be abstracted behind a library with a more pleasant veneer than os/exec, and even if not whatever you lose in subprocess ergonomics you make up for in static typing, not needing to Google/Stack Overflow everything, and general absence of weird quirks.

mkdirp 5y ago
I mostly use executable scripts so I can put it in a dir in my PATH. That way I can just run globally. No need to know where it is, or how to run it. > The biggest impediment is the ceremony for subprocessing out Not sure I fully understand what you mean with this, but if I'm understanding it right, gorun attempts to solve this by doing `syscall.Exec()` on the compiled binary. Combined with slight variation on the "comment" hack (see examples in gorun's readme), signals get fully directed your binary. // 2>/dev/null ; exec gorun "$0" "$@" package main // rest of the code
lenkite 5y ago
What about dependencies and libraries ? For tech that works very well for self-contained scripts, take a look at Deno. Supports she-bang. Also, you can have self-contained script with imports pointed to URL's or file system paths that are automatically resolved. This leads to easy management, maintenance and distribution.