Someone sent me a language on twitter that has a similar concept. They had both "traits" and "interfaces", where traits had to be explicitly implemented and interfaces would be more like Go.
While structural typing is safer, the post pretty clearly explains the problems with it. The safety brought by structural typing isn't worth the benefits that it restricts.
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).
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.
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
This is really cool. Would be awesome to see in more languages to be honest
Someone sent me a language on twitter that has a similar concept. They had both "traits" and "interfaces", where traits had to be explicitly implemented and interfaces would be more like Go.
That sounds like Scala. It has a type safe concept of structural typing (a lot safer than Go)
While structural typing is safer, the post pretty clearly explains the problems with it. The safety brought by structural typing isn't worth the benefits that it restricts.
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).
Go is statically typed. If you were to pass a
Dog
struct (which can'tQuack()
) into a function that takes aDuck
interface, you will hit a compile-time error.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
The only time it would result in a runtime error is when casting, as per every staticly typed language.
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