I mean, don’t program like this in any language:
cp newfil newfile2 # Deliberate typo
cp has a return value. Check it.
I believe that’s partly the point in the post. Using set -e effectively forces return code handling, at the least explicitly swallowing a bad return code with something like || true.
As an aside, this is why I’m not a fan of Go’s error handling. It’s optional because the “err := func()” can always be written as “func()” (afaik and can tell, anyway – happy to know if this can be forced.).
IIRC go vet will fail that particular idiom (failure to assign / check an error return).
So no better than shell scripts then, you need a separate tool to yell at your mistakes.
It’s good to have a linter like go vet, but I agree that compiler that defaults to throwing errors (or at least warnings) on clear anti-patterns is better. Go has an idiomatic escape already, too, in “_ := func()” to throw away the returned error, so I’m curious why go’s compiler allows any returned value to be implicitly and silently ignored.
_ := func()
I find it fascinating that this arrived at a similar set of conclusions to how Heroku’s buildpacks work. Namely, both use well-known scripts at well-known paths relative to the project root to capture the generic set of steps required to work with that project.
I also see these sorts of standards as an entrypoint for a new developer to dive into how a project is supposed to work. It serves as a kind of introductory documentation-as-code for how general tasks are specifically implemented for the particular project, since it details the specific commands the project relies on for the given task (e.g., using make vs. cmake vs. rake vs…). I find it more developer-friendly than the common README pattern, since it’s actually functional and provides a simplified interface to the project’s life-cycle, regardless of the complexity of the project.
Yes great example! I haven’t worked with them, but now that I think about it they are using very much the same pattern.
I think this would have been better than the .travis.yml and .github/workflow.yml stuff … i.e. you push and make stuff happen through a language, not a weird YAML config. I’ll have to think about it