DEV Community

loading...

Discussion on: The Problem with Interfaces, and how Go Fixed it

n3llyb0y profile image
Neil Chambers

That's a pretty broad statement. The best you can argue is a tradeoff for the language features that are right for the product/team/roadmap. I've work for years with static and dynamic languages. They both have strengths and weaknesses. That Go is duck typed is just not a selling point. Many languages do it. I would avoid comparing Go with statically typed, OOP, languages to be honest (unless you fancy a flame war). Go doesn't solve interface problems, it just has a different idea of what an interface is, and it's not that novel. Go should be considered when runtime performance is critical and a simple and effective concurrency paradigm is needed. Go is many things, but it will always have safety issues (maybe that is why the error handling seems to be, err, well).

Thread Thread
dean profile image
Dean Bassett Author

Go is statically typed. If you were to pass a Dog struct (which can't Quack()) into a function that takes a Duck interface, you will hit a compile-time error.

Thread Thread
danielw profile image
Daniel Waller (he/him)

If I understand correctly Go isn't even strictly duck typed.

The type inference doesn't happen at runtime but at compile time, giving very clear compiler errors.
So I don't really see how this kind of typing can lead to runtime errors in Go's case

Thread Thread
dean profile image
Dean Bassett Author

The only time it would result in a runtime error is when casting, as per every staticly typed language.

Thread Thread
danielw profile image
Daniel Waller (he/him)

That's what I thought! So I really don't get all this duck typing trash talk some people are throwing around in regards to Go