Hacker News Reader

Comment by chimeracoder | Hacker News Reader

> Agreed. CSP is one of the selling points of Go... and as a non-Gopher those are the cases I'm most interested in.

This makes sense, and when I first started writing Go, I felt the same way, but almost four years later, concurrency is one of the least important reasons I still write Go.

I wouldn't say all Gophers feel this way, but I know it's a very common experience for Gophers - "you come for the concurrency, but stay for the interfaces"[0].

[0] I've alternatively heard things like "readability", "tooling", and "robustness" used in the place of "interfaces" in this quote.

View on HN

Wait a minute, is this a troll post? Interfaces? I get the tooling, maybe, and CSP out of the box, I don't understand what's great about Go's interfaces (compared to plain old boring Java, for instance).

Have you had much experience with Go? Go interfaces and Java interfaces are different beasts... Go's interfaces are incredible...take a look at Reader and Writer from the io package as an example - they're two of the most powerful interfaces in the language, and extremely flexible.

> Go's interfaces are incredible...take a look at Reader and Writer from the io package as an example - they're two of the most powerful interfaces in the language, and extremely flexible.

Yup. I literally just gave a talk at two Go conferences in the last two weeks (GopherCon India and GopherCon Dubai) about the io.Reader/io.Writer interfaces specifically. They're deceptively simple on the surface, but they're insanely powerful once you 'get' them.

It would be interesting to know more about the power you seen in `io.Reader` and `io.Writer`. They seem to say, effectively, that every type implements serialization from bytes and serialization to bytes. Generic serialization is not so unusual but maybe in the context of Go can be so much more?

Interfaces in golang are error prone. It's easy to inadvertently implement an interface you didn't mean to. It's also difficult without the aid of some tooling, to determine which set (or whether at all) of interfaces a given structure implements.

There was a blog post a while ago about how golangs's interfaces caused issues in production because they're implicit.

Check out type classes for a superior way to solve this issue (e.g. what Scala or Rust do).

I can't think of a problem caused by inadvertently implementing an interface?

Client code relying on the fact that your class implements that interface when it wasn't intentional and might change perhaps?

Static ducktyping is a very interesting approach to interfaces that is very different from Java. I won't say how well it works as I've only dabbled in Go, but it struck me as very unique.

Reply on news.ycombinator.com