Hacker News Reader

Comment by arianvanp | Hacker News Reader

This is also why I like interfaces in Golang (as a Haskell developer). You simply define a slice of the world you want to see and anything that fits the box can be passed.

It's just unfortunate golang interfaces dont support fields. Only methods. Typescript fares better with its interface type

View on HN

> It's just unfortunate golang interfaces dont support fields. Only methods.

Why is that unfortunate? Usually when defining interfaces you care about the API surface without wanting to care about the internals of what will eventually implement that API. If you suddenly also spec fields with the interface, wouldn't be too easy to couple the internals to the API?

I can't say I've programmed in Go too much, so maybe I'm missing something very obvious.

The API surface of some struct is determined by visibility, not by whether a member of the struct is a method or a field.

I can't remember the specifics for why fields cannot be used within a Go interface but I do remember missing it a few times while writing Go code.

I think the reasoning is that interfaces are implemented by a dynamic lookup. Part of Go's philosophy is that things that could be expensive (function calls) should be visually distinct from cheap things.

Struct field access is cheap, hopping through a dynamic dispatch table is less cheap.

Took me a second to grok why the field access would require dynamic dispatch and it's because you have to deal with differing layout between structs.

Reply on news.ycombinator.com