Hacker News Reader

Comment by pedrocr | Hacker News Reader

The second one just looks like a hack. You've defined a useless function to make an interface not implementable. It would look cleaner with a keyword in the interface definition.

View on HN

First of all: I agree. There are many things in Go that feel like a hack. For example, it is common (and idiomatic) to use a map with empty values when you want to use a set (unordered and unique values), because the map's keys are a set. I personally dislike this, and some aspects of Go are like this.

However this blog post is about how good core language design leads to unplanned patterns that are useful, like HandlerFunc and the private interface hack.

One person's "unplanned patterns that are useful" is another's "this is a potentially dangerous hack that could lead to all manner of headaches in any non-trivial program with even just a few hundred lines of code, let alone thousands or millions."

The sweet spot for Go is in the hundreds to a couple of thousand lines of code. Unix philosophy and all that. Leave the monolithic MLOC monstrosities to Java.

People write MLOC monstrosities in Java because they can. You get some boring financial topic and some sub-par programmers and they'll write as much garbage as the language can possibly sustain.

These things are a testament to how safe and simple Java is as a language.

Not having massive crappy code bases is a negative sign in terms of how reliable and easy to understand a language is.

Yes, it's best to use the smallest tool (orthogonal language and libraries) for the job because it's less to test and maintain, and more likely to be correct.

None of the things you mentioned are "potentially dangerous hacks." Using maps as sets is common in many languages and there's nothing wrong with it. Adding a guard method to an interface is pretty clear and it works well, as well.

That's funny, that's how sets in early versions of CPython were implemented.

The function doesn't have to be useless. He uses a small and simple example to illustrate it. However the more common example of this is an interface with public piece your consumers can interact with and a private piece that only you can interact with.

> However the more common example of this is an interface with public piece your consumers can interact with and a private piece that only you can interact with.

Also known as...a class. Honestly, this is why classes exist: they are able to support both public and private interfaces, while interfaces and type classes are only able to support public interfaces. The closest we get to this essential aspect of OO programming in the H & M world is via existential types.

Reply on news.ycombinator.com