Ask HN: Experience with Go Lang Interfaces

https://news.ycombinator.com/item?id=32375341

by yonisto • 4 years ago

2 5 4 years ago

news.ycombinator.com

I wonder how well go interfaces are working for you in regards to the fact that a type doesn't declare the interface it implements (like in many other languages).

8 years a ago I worked on a 50kloc project and it doesn't seem to matter this way or the other. I didn't find it useful nor did I find it harmful (since then I moved to work in other languages). Then I had the feeling that if the project needed a massive refactor it would really introduce bugs that wouldn't happen elsewhere. But that assumption never got to be tested.

Do you have a battle story regarding go's interfaces? did it save you? did it introduce bugs?

Thanks,

_benj2• 4 years ago

I got to use interfaces twice in big-ish projects and the biggest advantage I found was decoupling, separation of concerns and code organization.

Go compiler throws an error for circular dependencies and I found that interfaces provided a way to arrange the source code to avoid that error.

It also made testing easier in certain cases because I was able to implement mock interfaces to perform unit tests.

What I found caused quite a few runtime bugs was writing go with a sort of OOP flavor, that is, having most functionality in methods instead of functions. This then forces you to have to pass pointer all over the place and since a null pointer is not something checked during compile time I came across a few panics in go when following that pattern.

Keeping data alone, returning empty structs on errors and having behavior in actions in my case made for a pretty sturdy program that most of the bugs where catch during compile time, and the kind of bugs I came across where mostly external one, i.e. network timeout or dns issues which make for some weird behaviors I hadn’t accounted for

drakonka2• 4 years ago

I use Go interfaces fairly often, not least for easy mocking for testing scenarios. Not having to explicitly declare what interface a struct is to implement has never been an issue for me. Modern IDEs provide this information (I prefer JetBrains Goland), so I never feel like I'm working "blind". And if I really feel the need to enforce a certain interface implementation at compile time I can do so:

`var _ InterfaceName = &StructName{}`

Having refactored applications that use interfaces, I've never found the interface usage to make it any more difficult or bug-prone personally. I tend to stick to the "accept interfaces, return structs" guideline, and that's worked pretty well for my use cases.

_benj2• 4 years ago

+1 for goland, allows me to be very productive and with interfaces in particular it makes it very easy to jump from the interface to the implementation(s)

yonisto• 4 years ago

how does it work? there can be endless implementations and the IDE/Compiler doesn't know beforehand what satisfies the interface as oppose to other languages ?

Ask HN: Experience with Go Lang Interfaces

Related Stories