[dragonwriter]

> The file I/O makes the case for including exceptions in the language.

Exceptions are included in the language, they are called panics, and the go convention is that libraries don't expose them in the public interface, but can use them internally (and, of course, application code can use them.)

> Specifically, adding one-off types to deal with exceptions is a bug, not a feature.

One-off types aren't used for error handling in the example, they are used for abstracting a writing pattern that works like binary.Write for writing non-string values and like io.Writer#write for string values. Sure, the special type's write method also swallows errors, but, except that the mechanism by which it swallows errors would look different, the use of the one-off type and its write method would be pretty much the same with exceptions/panics as with error returns from the underlying library functions.

[joshuaellinger]

My point is that an example of a 'best practice' shouldn't make the reader think: Oh, that's a kludge to get around a design decision in the language.

In his example, he uses a one-off type to isolate the caller from having to explicitly check if each individual write failed. I got no problem with that.

But it seems like it a work-a-round.

It's just an odd choice for an example. The take-a-way seems to be that the basic class libraries need a wrapper that makes them easier to work with and that, you the developer, should build these wrappers so you know exactly what the policy is.

[dragonwriter]

> My point is that an example of a 'best practice' shouldn't make the reader think: Oh, that's a kludge to get around a design decision in the language.

I would think that some of the most important best practices would relate to the best means of dealing with situations where the approach users coming from other languages might naturally seek to apply are not the most appropriate, either because the other-language feature they are likely to have used does not exists (or works differently) or because of features in the target language that allow a better approach than in other languages.

> In his example, he uses a one-off type to isolate the caller from having to explicitly check if each individual write failed. I got no problem with that.

You'd do that if the library function threw exceptions, too. Eliminating repeated try/catch blocks (or calls to inline functions with deferred recover calls in go) and eliminating repeated if/then blocks are pretty much the same thing.

[joshuaellinger]

Yeah, fair enough.

I want to like that language but I just keep going seeing things that make me pause.

Really I'd like a C-dull or a C-- (keep a small subset and get close to the metal as C)