3 ms·

I'll have to check this out properly later. 10 years ago go devs rejected the idea of introducing support hashbangs and now we're left with having to use gorun[

by mkdirp 5y ago

I'll have to check this out properly later. 10 years ago go devs rejected the idea of introducing support hashbangs and now we're left with having to use gorun[0], meaning, people are unlikely to use go for script. I hope the go devs will reconsider. I'd love to be able to use go for scripting. But as it stands, it's a sad state of affairs because you have to rely on hacks. [0] https://github.com/erning/gorun/ https://github.com/erning/gorun/

throwaway894345 5y ago
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.
moondev 5y ago
you can now directly "go run" any import path go run github.com/mikefarah/yq/v3@3.4.1 It also works fine in shebang that expects input of script filepath at $1. For example "test.yaml" #!/usr/bin/env -S go run github.com/mikefarah/yq/v3@3.4.1 r --- some: yaml: here chmod +x test.yaml then ./test.yaml some.yaml returns test

by mkdirp 5y ago

throwaway894345 5y ago

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.

moondev 5y ago

you can now directly "go run" any import path go run github.com/mikefarah/yq/v3@3.4.1 It also works fine in shebang that expects input of script filepath at $1. For example "test.yaml" #!/usr/bin/env -S go run github.com/mikefarah/yq/v3@3.4.1 r --- some: yaml: here chmod +x test.yaml then ./test.yaml some.yaml returns test