I guess I should've worded that differently. No, it doesn't force you to handle errors, but it makes the possibility of errors much more obvious. With exception handling, you never know what functions may raise an exception; Go is much more explicit in that sense, so if you don't handle the error, it's your own damn fault.

In what ways is testing an error code with an if statement more manual than catching an exception with a try/catch?

There is a better way. Check out how Erlang embraces failure with its "let it crash" philosophy, and considers trying to handle every error condition manually ("defensive programming") an anti-pattern. Read the "Error handling philosophy" section of Joe Armstrong's thesis[1] if you want to learn more.

[1]: http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

I wonder if embrace the unix stdin/stdout is the solution.

I'm toying about a new languagte where each function have IN/OUT/ERR channels.

So, is possible to do:

result | err = open('file)

This consume the ERR channel, however, if is not:

result = open('file')

it "trow". Inside the open, any raise is like a return for the ERR channel.

This combined with RAII & scope like in D: http://dlang.org/exception-safe.html