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

21–30 of 89 posts

Re: Is Go Duck-Typed?

#21

Post by masklinn »

mrkeen wrote: post #11
mjr00 wrote: post #9

Earlier quoted context omitted.

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?

If the interfaces have only id/value with matching parameters and return types then yes the interfaces would be functionally identical and all objects satisfying one of the interfaces would satisfy the others.

Re: Is Go Duck-Typed?

#23

Post by didibus »

I think duck typing is different from structural typing, and go is not duck typed, but structurally typed.

I think the difference is that in duck typing, there is no real type. A thing is a duck if I can use it as one, and that same thing can be a chair if I can also use it as one.

So on duck typing, we say, does it have the properties I need, if so I can happily use it, don't care what it is. And that can only be done at runtime, since you can't fully predict the runtime properties the thing will have.

In structural typing, we say that the type of a thing is defined by its structure. This thing is a Duck because it is of the expected structure of a duck, which might be to define a quack string -> string method. At this point, you say the thing is a Duck. You can do this at compile time, because you have defined statically a set of named things and their structure, and then you can track the things passed to you and match their structure to the list of structures you have to find the one that fits and consider it of that type.

Re: Is Go Duck-Typed?

#24

Post by masklinn »

bjz_ wrote: post #17
the_unproven wrote: post #8

Earlier quoted context omitted.

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 G…

> languages like Standard ML and Typescript that tend to be more structural.

AFAIK SML is nominal. OCaml has a structural subsystem in that its object system is structural. The vast majority of the language is nominally typed.

> It's probably more that most mainstream typed languages, like C, C++, Java, C#, etc. have mainly gone down the nominal route

It's not just mainstream typed languages. Almost all statically typed languages use nominative typing. Tt doesn't have any real drawback and it's just simpler to understand and work with.

A language like typescript would go with a structural system because it's a much easier bridge and sell from an object-oriented dynamically typed world.

Re: Is Go Duck-Typed?

#25

Post by _y5hn »

seertaak wrote: post #18
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,…

For golang, single method interfaces are recommended as preferable. The problem with huge interfaces or classes is they can always become larger! While if you compartmentalize single responsibility into separate components (may be several methods if applicable to the domain and design), each reason to change may be restricted to that bounded context only. If not, it's a signal design might need revisit.

The problem with "Drawable" is that it is property/data, and not messaging-based, thus breaking encapsulation, even if it was behaviour-based.

Re: Is Go Duck-Typed?

#26

Post by seertaak »

_y5hn wrote: post #25
seertaak wrote: post #18

Earlier quoted context omitted.

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,…

For golang, single method interfaces are recommended as preferable. The problem with huge interfaces or classes is they can always become larger! While if you compartmentalize single responsibility into separate components (may be several methods if applicable to the domain and design), each reason to change may be restricted to that bounded context only. If not, it's a signal design might need revisit. The problem w…

> The problem with huge interfaces or classes is they can always become larger!

That's definitely a good reason to prefer small interfaces; I hadn't thought of that but it certainly makes sense.

That said, I think we may be referring to different things when we use the word "property". Stroustroup is talking about properties in the mathematical sense, i.e. he's talking about the properties of the operation "draw()" in the concept Drawable.

Am I misunderstanding you? To my mind that's an operation and closer to "message" (emphasis on the verb aspect) rather than data or property.

Re: Is Go Duck-Typed?

#27

Post by tedunangst »

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

There was also a fork of java called white oak that added structural typing.

Re: Is Go Duck-Typed?

#28

Post by [deleted] »

lkitching wrote: post #20
_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…

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.

[deleted]

Re: Is Go Duck-Typed?

#29

Post by bjz_ »

masklinn wrote: post #24
bjz_ wrote: post #17

Earlier quoted context omitted.

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 G…

> languages like Standard ML and Typescript that tend to be more structural. AFAIK SML is nominal. OCaml has a structural subsystem in that its object system is structural. The vast majority of the language is nominally typed. > It's probably more that most mainstream typed languages, like C, C++, Java, C#, etc. have mainly gone down the nominal route It's not just mainstream typed languages. Almost all statically ty…

> AFAIK SML is nominal

I guess I was referring to how records are structural. Although granted tagged unions are nominal, and you can get nominal typing through modules. I was probably wrong in posing it as 'one or the other' - seeing as many languages have a mix of both. I'm definitely not saying that nominal typing is bad, it's just that it's nice to have the option to go structural if you want, and many have not known that this option exists.

Re: Is Go Duck-Typed?

#30

Post by throwaway894345 »

jerf wrote: post #13
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…

My experience is the same.

It's interesting to me that people are very concerned about Go's structural subtyping, but they generally have no qualms about passing functions around. Given that the contract for a function is the function signature, and the contract for an interface is [all function signatures and their associated names], surely the latter is less error prone?

Post reply on HN