Hacker News Reader

Comment by throwaway6497 | Hacker News Reader

Glad I am not the only one who feel this way. Some benchmarks between load ptr/store ptr and the read-write lock would be helpful. Also simplified code-blocks for each of the approaches and more details into pro/cons of each approach could have helped for better understanding.

View on HN

Agreed. CSP is one of the selling points of Go, in my view. I expect some overhead to be the price of a simple and easy concurrency model. Some conservative use of locking etc is okay in some cases, and as a non-Gopher those are the cases I'm most interested in.

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

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