Hacker News Reader

Comment by joshuaellinger | Hacker News Reader

Odd choice of examples...

1. The file I/O makes the case for including exceptions in the language. Specifically, adding one-off types to deal with exceptions is a bug, not a feature. There is a good case against exceptions but that ain't it.

2. On slide 5, it appears to show that you have to use a switch statement on a generic to get polymorphism because the language doesn't support overloading. Again, looks more like a bug than a feature.

Also, is the "break;" implicit in Go? At first glance, it looks like a coding error.

View on HN

Presumably these are tips for coders, not for language developers. As such, the language has neither generics nor exceptions and the programmer has to deal with that.

> is the "break;" implicit in Go?

Yes. http://golang.org/doc/effective_go.html#switch

W/r/t #2 - you're not familiar with Go but knew exactly what was going on. That's totally a feature. The language was designed around exactly that kind of reading.

"break;" is implicit in Go.

Sure, I spend a decade in C. It's not hard to read.

My only problem with using generics in this context is that you can't catch type-conversion errors at compile time.

Seems like a step backwards with only downside. I get why exceptions are a double-edge sword. I'm not clear on why undermining compile time type safety is an feature.

> I'm not clear on why undermining compile time type safety is an feature.

I think this is what people will ultimately focus on when considering Go. Many of the complaints are a product of type weaknesses in the language, voiced by people who had assumed that a modern static language wouldn't have that fault. Others tend not to mind because they lack that expectation, and regard the dynamic behaviour you can get as a feature. The argument about shared mutable state goes the same way, but for some concurrent but non-parallel code it might be convenient.

I can easily see people picking Go when moving from Python. But not when moving from a static language with a stronger, safer type system.

Also, as burntsushi points out, it does require more sophistication in the type system. I doubt they're trying to sell a naively simplistic type system (sophistication often makes it easier to use), but when Go was announced the feature they seemed to be selling the hardest was short compilation times. I think that feature is the seed of this behaviour.

> I'm not clear on why undermining compile time type safety is an feature.

More safety usually requires a more complex type system. Such a type system is usually more expressive and can make more guarantees about your program, which is a pro. But of course, it is also more complex, which is a con.

Totally agreed about #1 and exceptions. In that defintion of DumpBinary, each bit of error handling takes three extra lines. Speaking of "cognitive load". Whereas here's what it'd probably look like in Python, with exception handling (assuming binary.write() raised IOError on error, which they should).

   class Gopher:
       def dump_binary(self, writer):
           """Write this Gopher to given writer, raise IOError on error."""
           binary.write(writer, binary.LittleEndian, len(self.name))
           writer.write(self.name)
           binary.write(writer, binary.LittleEndian, self.age)
           binary.write(writer, binary.LittleEndian, self.fur_color)

I can see the argument for Go-style explicit error handling, but having this as the first best-practice example just doesn't sit right or sell it very well.

Edit: Okay, I guess I should have read the next slide before commenting. Still, the "one-off utility type" is longer and more complex than the original error handling (so I wouldn't do it unless you're using it elsewhere as well).

> 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.

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.

> 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.

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)

yes a switch will not fallthough unless you tell it manually http://golang.org/ref/spec#Fallthrough_statements

Reply on news.ycombinator.com