scripting in Go

[eko...@gmail.com]

sc is a convenience package to support writing short automation scripts that simply panic on errors. It is similar to shell scripting with "set -e" option.

https://pkg.go.dev/github.com/egonk/sc

I wrote the package to stop copy pasting trivial helpers in throwaway and build automation scripts. Obviously panics instead of errors are not recommended for Go code, but I saw no big benefits by writing elaborate error messages in such scripts.

M (generic Must) does not show on pkg.go.dev, probably because generics are not yet enabled. P (Printf) and PE (Fprintf os.Stderr) are currently not detected by go vet as printf funcs, is there a way to mark them in the package as printf?

[Christoph Berger]

Thanks for sharing your package.

To me it seems that the functions are rather shallow wrappers around other single functions from the standard library (e.g., sc.P() maps 1:1 to fmt.Printf()). You certainly save a couple of keystrokes while writing a script this way, but on the other hand, reading the resulting code adds cognitive overhead, as you need to go one extra step from recognizing stdlib functions (fmt.Printf) to recognizing custom lib functions and their mapping to the underlying stdlib functions ("ok, there is a sc.P() in this script, this maps to fmt.Prinft()...").

This is super ok if you write throwaway scripts for your own purpose, but once you pass the scripts around, the receivers would have to learn a new pacakge API and read through an extra API layer to see what the script is doing. Remember that code is much more often read than written.

If the main purpose is to eliminate explicit error handling (which is perfectly fine for simple scripts IMHO), then I would at least prefer longer names, like sc.Printf(), which would make the purpose of this function obvious.

Just my $0.02. Otherwise, I generally like the idea of providing a simplified API for supporting quick&dirty throwaway scripting in Go. Remember what Kelsey Hightower said: "Bash is the reason people leave IT"! :-)

[eko...@gmail.com]

Thanks for the feedback! I can't say I disagree and I half expected the points you mentioned. Out of all the wrappers, P and PE admittedly give the least value.

I placed more weight on these factors:
- compared to the deployed production code that I'm working with (basically carved in stone and passed from programmer to programmer), supporting scripts are read less often and are usually thrown away or rewritten when the pipeline changes
- out of the box Go makes it easy to ignore errors from functions like os.Chdir which are critical in scripts, so I wanted to make it extremely convenient to write error checks even when used without IDEs and linters
- I'm a vi fan and there was a time when ex/vi was new and people learned the cryptic keystrokes anyway :)

[Corin Lawson]

For my money, as a newcomer to the API, having both the long named function and the shorthand would be useful.  I can see myself using M immediately, but some like W I'm not likely to remember as readily and longer names would help in adopting the library.  (Also, what is the mnemonic for W?)  Afterall, commands in vi have a long form and short forms.

[eko...@gmail.com]

Good ideas, I added explanations for the shorthands: https://github.com/egonk/sc/commit/257d48f5ba187082ffb6a9b8b9d326eca26cb787

W or Wrap comes from the classic errors.Wrap (https://github.com/pkg/errors)

Long forms might be added in a different package in the future (like github.com/egonk/sc/long/sc) because short form is specifically designed to work with dot imports. I am not sure if having two different names for everything is a good idea though, it could be even more confusing? I don't plan to add any extra functions to the package so learning these 9 should be enough for the foreseeable future. Unless some extremely useful func comes up of course :)

[eko...@gmail.com]

I made a second variant in a separate repo/module: https://pkg.go.dev/github.com/egonk/scr

The function names are more descriptive, Printf wrappers were removed and it is not meant to be used as a dot import anymore.

On Monday, January 24, 2022 at 12:32:48 PM UTC+1 eko...@gmail.com wrote:

[Christoph Berger]

Thanks for adding a long-name variant! Indeed I feel the code is much more self-documenting this way. But in the end it is only a matter of getting used to an API. Power users of "sc" will certainly be able to read the original short-name variant without problems.