Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Go Duck-Typed?

bionic.fullstory.com

Post reply on HN
Print view View original

11–20 of 89 posts

Re: Is Go Duck-Typed?

#11

Post by mrkeen »

mjr00 wrote: post #9
zwieback wrote: post #7

I like the histogram showing how much more frequent interfaces with just one or two methods are. How frequent are problems where classes unintentionally use an interface due to identical signatures? Seems likely to happen in theory if so many interfaces have few functions.

In theory, yeah... in practice, as someone who uses Go and Python with mypy (which supports structural type-checking using the Protocol interface) professionally, I haven't seen it happen. It's easy to think of contrived examples like the one in the post, where Cat/Dog/Table all implement GetLegCount(), but in practice your interface methods usually aren't that simple, and interface signatures like func InsertFoo(*sq…

I tend to use nominal types a lot in other languages, so I have a lot of types with id() or value().

Would those be mixed up?

Re: Is Go Duck-Typed?

#12

Post by Nullabillity »

mjr00 wrote: post #9
zwieback wrote: post #7

I like the histogram showing how much more frequent interfaces with just one or two methods are. How frequent are problems where classes unintentionally use an interface due to identical signatures? Seems likely to happen in theory if so many interfaces have few functions.

In theory, yeah... in practice, as someone who uses Go and Python with mypy (which supports structural type-checking using the Protocol interface) professionally, I haven't seen it happen. It's easy to think of contrived examples like the one in the post, where Cat/Dog/Table all implement GetLegCount(), but in practice your interface methods usually aren't that simple, and interface signatures like func InsertFoo(*sq…

And at that point, you have.. nominal types with less documentation?

Re: Is Go Duck-Typed?

#13

Post by jerf »

zwieback wrote: post #7

I like the histogram showing how much more frequent interfaces with just one or two methods are. How frequent are problems where classes unintentionally use an interface due to identical signatures? Seems likely to happen in theory if so many interfaces have few functions.

I've been programming for over 20 years primarily in languages in which this can nominally happen, and I think I've literally never seen it happen. I've been in situations where I expected a method and it was missing (e.g., Python code expecting a vaguely-file-like object to have seek, receives a socket), but that's the closest to this sort of thing I think I can say I've come. I've never had a case where I called a method that I expected to be one sort of thing, and got a method that was actually a completely different thing.

I used to worry about this sort of thing, but now I think that any language designer making a new language should just consider it a non-issue. If you happen to make it impossible for some other reason, sure, cool, I guess, but don't put even a little bit of effort into worrying about this case.

(Note I'm not saying it can't happen, or even be bad if it did. I'm sure it's happened to some people, and of that set, I'm sure there must be at least one person with a story of how it went really badly wrong somehow. I'm just saying that compared to the sorts of issues that affect every programmer in your language every day, worrying about this edge case is not productive. If this is your biggest problem in your language, or even fits into the top 100, please let me know about your surprisingly perfect language as I am very interested in using it.)

Re: Is Go Duck-Typed?

#14

Post by _y5hn »

mbell wrote: post #2

This is called Structural Typing[0] and is in contrast to Nominal Typing[1] (e.g. Java). 0: https://en.wikipedia.org/wiki/Structural_type_system 1: https://en.wikipedia.org/wiki/Nominal_type_system

Duck typing is according to Wikipedia: https://en.wikipedia.org/wiki/Duck_typing

Duck typing as a concept was re(?)-popularized around the advent of ruby, so might make sense to talk from a ruby perspective: http://rubylearning.com/satishtalim/duck_typing.html

With ruby, most everything you interact with is a true object, ie. you can modify behaviour of almost all classes/objects by adding/removing methods, mixin, etc. It's not unheard of monkey patching Integer or Array classes, core parts of standard library and language. Thus, you could dynamically invoke any object with any methods, without regards to compile-time constraints or "types". Errorhandling thus delegated almost entirely to runtime beyond basic syntax parsing.

Golang furthers the notion of capabilities as shared method signatures, by loosely binding this into interfaces, and enforcing many errors by static type checks at compile time. It's interesting as a development away from inheritance and towards composition and loose coupling of static program components.

Re: Is Go Duck-Typed?

#15

Post by tgv »

_y5hn wrote: post #14
mbell wrote: post #2

This is called Structural Typing[0] and is in contrast to Nominal Typing[1] (e.g. Java). 0: https://en.wikipedia.org/wiki/Structural_type_system 1: https://en.wikipedia.org/wiki/Nominal_type_system

Duck typing is according to Wikipedia: https://en.wikipedia.org/wiki/Duck_typing Duck typing as a concept was re(?)-popularized around the advent of ruby, so might make sense to talk from a ruby perspective: http://rubylearning.com/satishtalim/duck_typing.html With ruby, most everything you interact with is a true object, ie. you can modify behaviour of almost all classes/objects by adding/removing methods, mixin, et…

Wouldn't that make any language with reflection Duck-typed? That would suggest Wikipedia's definition is not very useful.

Re: Is Go Duck-Typed?

#16

Post by _y5hn »

tgv wrote: post #15
_y5hn wrote: post #14

Earlier quoted context omitted.

Duck typing is according to Wikipedia: https://en.wikipedia.org/wiki/Duck_typing Duck typing as a concept was re(?)-popularized around the advent of ruby, so might make sense to talk from a ruby perspective: http://rubylearning.com/satishtalim/duck_typing.html With ruby, most everything you interact with is a true object, ie. you can modify behaviour of almost all classes/objects by adding/removing methods, mixin, et…

Wouldn't that make any language with reflection Duck-typed? That would suggest Wikipedia's definition is not very useful.

Fair question!

"Duck typing" can be implicit, if you can call quack() on this() without error, you (the programmer) assume it's a Duck. The language may make it explicit (loosely structural typed like in golang, or other variations), or implicit (like in ruby). There are varying degrees, but you should be able to have a collection of the "Ducks" and be able to invoke quack() on them all.

Can't really say I see the connection with reflection. If quack() fails, you can get an error, either at runtime or compile-time. So no reflection required, though using reflection you may avoid errors dynamically.

Structural Typing as a concept is much better defined though.

Re: Is Go Duck-Typed?

#17

Post by bjz_ »

the_unproven wrote: post #8
mbell wrote: post #2

This is called Structural Typing[0] and is in contrast to Nominal Typing[1] (e.g. Java). 0: https://en.wikipedia.org/wiki/Structural_type_system 1: https://en.wikipedia.org/wiki/Nominal_type_system

I just recently found out about these two types of system. It's strange how people (like shown in the article) don't emphasize(know) it when talking about types in languages. Interestingly, python has included structural subtyping in 3.8[1] as part of the typing module. [1] https://www.python.org/dev/peps/pep-0544/

It's probably more that most mainstream typed languages, like C, C++, Java, C#, etc. have mainly gone down the nominal route, as opposed to languages like Standard ML and Typescript that tend to be more structural.

Structural vs. nominal typing is pretty well known in programming language design circles, but circulating that knowledge is a constant uphill challenge. One of the reasons many of us are frustrated with Go's designers were how quickly they threw this work under the bus as part of their initial marketing strategy, which kind of knocks away the ladder for anyone else who is curious to learn about this stuff.

Re: Is Go Duck-Typed?

#18

Post by seertaak »

zwieback wrote: post #7

I like the histogram showing how much more frequent interfaces with just one or two methods are. How frequent are problems where classes unintentionally use an interface due to identical signatures? Seems likely to happen in theory if so many interfaces have few functions.

I think it's really interesting to contrast this with Stroustroup's advice on concepts: "My rule of thumb is to avoid “single property concepts.”".

He gives an excellent example leading to this dictum: single property interface "Drawable". Let Shape implement drawable with widely expected results. But: let Cowboy implement Drawable -- now with disastrous consequences. The solution to this dilemma is as stated above, not to allow concepts/interfaces/{wave hands} to refer to a single object -- for example, a number is a concept which refers to multiple operations (i.e. methods).

To my mind, this feels right, albeit initially surprising. It makes me think that e.g. the "Neg" interface in Rust is wrong.

See: http://www.stroustrup.com/good_concepts.pdf

Re: Is Go Duck-Typed?

#19

Post by IshKebab »

nemith wrote: post #4

I like to call it Quack typing as interfaces are based on behavior and not attributes.

No they aren't, they're matched based on method names.

Go isn't duck typed, except for interfaces which are. Pretty simple.

Re: Is Go Duck-Typed?

#20

Post by lkitching »

_y5hn wrote: post #14
mbell wrote: post #2

This is called Structural Typing[0] and is in contrast to Nominal Typing[1] (e.g. Java). 0: https://en.wikipedia.org/wiki/Structural_type_system 1: https://en.wikipedia.org/wiki/Nominal_type_system

Duck typing is according to Wikipedia: https://en.wikipedia.org/wiki/Duck_typing Duck typing as a concept was re(?)-popularized around the advent of ruby, so might make sense to talk from a ruby perspective: http://rubylearning.com/satishtalim/duck_typing.html With ruby, most everything you interact with is a true object, ie. you can modify behaviour of almost all classes/objects by adding/removing methods, mixin, et…

I'm not sure what you mean by 'not exact' since the article you posted explictly contrasts duck typing with structural type systems of which Go is given as an example.
Post reply on HN