It defaults to not running the rest if a step fails, and the error result is accessible via usual mechanisms.

  _, err := script.Foo(...).Bar(...).Stdout();
  if err != nil {
    log.Fatal(err)
  }

is sufficient for a quick scripting hack designed to be run interactively.

I don't see it as a lot different to bash scripts with -e and pipefail set, which is generally preferable anyway.

Plenty of go code does

  if err != nil {
    return nil, err;
  }

for each step and there are plenty of cases where you only care -if- it failed plus a description of some sort of the failure - if you want to proceed on some errors you'd split the pipe up so that it pauses at moments where you can check that and compensate accordingly.

(and under -e plus pipefail, "error reported to stdout followed by aborting" is pretty much what you get in bash as well, so I'm unconvinced it's actually going to be harder to debug)

>The whole point of using Go is to explicitly handle errors as they happen

That's hardly the whole point of using Go.

The friendlier syntax (and in this case DSL) is an ever bigger point.

In any case, you can trivially get at the error at the point it occured:

n, err := script.File("test.txt").Match("Error").CountLines()

I believe error handling looks like this:

    package main

    import (
        "github.com/bitfield/script"
    )

    func main() {
         _, err := script.Stdin().Column(1).Freq().First(10).Stdout()
        if err != nil {
            log.Fatal(err)
        }
    }

Errors are "remembered" by the pipeline and can be processed when you get to a sink method.

From a technical point of view nothing prevents the scripting package to be just as informative with errors as bash and have a helper to log and clear the error. If it is not already the case, I call it a bug.