Hacker News Reader

Comment by dilap | Hacker News Reader

Confusing post; as I see it, it doesn't really have much to do with duck-typing.

It's more an illustration that with Go you can, if you choose, take "any" as your argument type and then later cast to the actual type you need, risking, of course, run-time exceptions if the type is not fulfilled.

Basically, you can opt-in to dynamic typing (the same as e.g. C#).

If the method quack were

    quack(ducks ...Duck)

then you'd get a compile-time error.

View on HN

> It's more an illustration that with Go you can, if you choose, take "any" as your argument type and then later cast to the actual type you need, risking, of course, run-time exceptions if the type is not fulfilled.

Not cast to just a concrete type, but to an interface. Literally duck typing.

> then you'd get a compile-time error.

Which is emblematic of structural typing, and the only real difference between structural typing and duck typing is that one is dealt with at compile time and the other at runtime. The article tells that Go supports both.

How is that any different from doing

    public interface ISwim { void Swim(); }

    public interface IQuack { void Quack(); }

    public interface IDuck extends ISwim, IQuack { }

    public class Mallard implements IDuck {
        public void Swim() { System.out.println("mallard swimming"); }
        public void Quack() { System.out.println("mallard quacking"); }
    }

    public class Dog implements ISwim {
        public void Swim() { System.out.println("dog swimming"); }
        public void Bark() { System.out.println("dog barking"); }
    }

    public static void quack(Object... ducks) {
        for (Object duck: ducks) {
            ((ISwim)duck).Swim();
            ((IQuack)duck).Quack();
        }
    }

    public static void main() {
        quack(new Mallard(), new Dog());
    }

in Java? You can do this in Java, you know, casting down to an interface; the same goes for C#. Do those languages now have duck typing, just because in them you can up-cast anything to Object, and then try to down-cast to any other type, be it an interface or a class?

> Do those languages now have duck typing

Maybe. I don't have a language reference handy. Does runtime type checking take place with that code?

My impression, based on the way you said it (and my vague memories of using Java once upon a time), is no. On that assumption, where would you find the duck type? The significance of both structural typing and duck typing is that type checking occurs. As before, the difference is when the check takes place – be it at compile time or at runtime.

Perhaps you could update that code to demonstrate how you would bypass calling objects which, when type checked, show to not quack like a duck like as is shown in the Go examples?

I think the closest equivalent in Java or C# would be to use reflection to pull out the Swim and Quack methods.

In C# you would simply use the 'dynamic' keyword.

And get yelled at by your colleagues ;D

In practice, the use of dynamic is highly discouraged as well as anything that could lead to type confusion i.e. currently discussed Go's duck typing it calls structural (runtime vs static is impl. detail).

Instead, you are expected to simply do 'lessSpecific is IMoreSpecific ms`, works particularly well with pattern matching on switches for functional style.

ha totally forgot about that! what a crazy feature. i wonder if anyone uses it in the wild?

Yes, the runtime type check does happen, see [0]. The output is pretty much the same as with the Go example, only the exact wording of the exception/panic is different.

And no, the structural/duck typing is not about when the type checking happens. It's about not having to write "implements IDuck" right in the class declaration for the down-cast to succeed.

[0] https://godbolt.org/z/vndns4619

> It's about not having to write "implements IDuck" right in the class declaration for the down-cast to succeed.

That doesn't make sense. Not having to write "implements IDuck" is true of both structural typing and duck typing. That logically cannot be what makes them different.

Sorry, apparently we literally can't understand each other. I write "the structural/duck typing is not about [X], it's about not having to write "implements IDuck", and you reply with "that doesn't make sense. Not having to write "implements IDuck" is true of both structural typing and duck typing".

My original point was that TFA doesn't really feature duck/structural typing; the example program just shows dynamic upcasting/downcasting, which has been a staple of OOP since forever, and has no relation to duck/structural typing.

> I write "the structural/duck typing is not about [X]

The structural/duck typing thing is exactly about when the type check happens. That is the thing that makes them different. We aren't just throwing out random words. We would not be talking about them in the first place if not for that fact. To say it is not about the only reason we have for talking about them is... strange.

> My original point was that TFA doesn't really feature duck/structural typing

It does, indeed. It demonstrates both, in fact. Go uses nominal typing for everything but interfaces. Is that the source your confusion?

> the example program just shows dynamic upcasting/downcasting

I know we threw casting around loosely to not confuse the contextual parent, but if you look closely, Go doesn't even support casting at all. And this isn't type conversion either. Go uses the syntax `type(variable)` for that. This really has nothing to do with what was seen in the article; it was doing something quite different.

To be fair, I'm not sure you have demonstrated that Java has casting either. What you wrote appears to be much more like type conversion, except type conversion is checked statically, while yours was checked at runtime. Frankly, I have never heard of a term for what you have shown, so I don't know what to call it. I suppose casting, overloaded with new meaning, really is that term[1]? Go doesn't support casting in that sense either, though.

[1] Which, if that is the case, would make the rest of this thread quite hilarious with your attempt to be the language police for "duck type", yet being accepting of any arbitrary use of "cast".

> yours was checked at runtime. Frankly, I have never heard of a term for what you have shown, so I don't know what to call it.

Surely that's not the first time you've heard of run-time type casts? Well, in any case, they are colloquially called "type casts" and/or "type conversions".

To be more pedantic, Java calls it "casting conversion" [0] which, in this specific case, allows one of the "narrowing reference conversion" [1] to happen.

Go calls their version "type assertion" [2] but if you read what it actually does ("If T is an interface type, x.(T) asserts that the dynamic type of x implements the interface T") and compare with what Java does ("Such conversions require a test at run time to find out whether the actual reference value is a legitimate value of the new type"), I hope you would agree they are essentially the same.

We can also take a look at C# [3]: it has "cast expressions" which work like this: "A cast-expression of the form (T)E, where T is a type and E is a unary-expression, performs an explicit conversion (§13.2) of the value of E to type T". And in this example, the exact kind of conversion to be performed would be 13.2.3, "Explicit reference conversions" for which the following is stated: "The explicit reference conversions are those conversions between reference-types that require run-time checks to ensure they are correct".

So TFA could be written in any of those languages (or even in C++ with its dynamic_cast<T>) and look almost exactly the same because all TFA does it takes some objects, converts them up to Object type that subsumes all other types (in Golang's case, this type is called "any"), then tries to convert them down to some interface types which those objects may or may not implement, and blows up. But neither Java, C#, nor C++ have neither structural nor duck typing so TFA's claim that somehow this example shows that Go has duck or structural typing is simply baseless.

[0] https://docs.oracle.com/javase/specs/jls/se6/html/conversion...

[1] https://docs.oracle.com/javase/specs/jls/se6/html/conversion...

[2] https://go.dev/ref/spec#Type_assertions

[3] https://www.itu.dk/people/sestoft/ecma/Ecma-334.pdf

> Surely that's not the first time you've heard of run-time type casts?

Indeed – and for good reason, I'm sure. Pedantically, a cast is where the programmer says in a language "just trust me on what type this is, don't bother to check my claim". A runtime type cast doesn't make any sense.

I mean, I'm fine with words evolving and whatnot. I'm not here actually trying to play language police myself. But, as it seems you want to squabble over "duck type", which is then quite humorous when you accept any random definition someone can dream up for "cast": Why not call what Java is doing duck typing?

> I hope you would agree they are essentially the same.

I do agree, just as I said before, that Go's type conversions are essentially the same, except checked at compile time rather than run time. There is no conversion with type assertions, however. It is merely a runtime type check. The type you have is the type you keep.

Now, what is important to remember is that Go's interface is a structural type. And what is a "structural type" checked at run time? That's right: A duck type!

> So TFA could be written in any of those languages

It's all just 1s and 0s at the end of the day. Of course you can write something that achieves the same result in just about any language. There is more nuance at play here, though. In the case of Go, it is not "here is another way to achieve the same thing". It literally employs duck typing, as duck typing is normally understood.

Ah, ok, thanks, now I see the point the article was trying to make.

Yes -- supporting structural typing + also runtime casts means you support duck typing.

> Not cast to just a concrete type, but to an interface. Literally duck typing.

That's not duck typing, though. It's similar but not the same.

With duck typing there isn't an interface to cast to, but the runtime object has a method matching the one being called. If you're casting, then it's not real duck typing.

People often imagine a "metaclass" or "meta-interface" for each method to help understand how duck typing works, but it's just a mental model to understand the concept. In reality there is no interface tying the methods together, and the whole thing is done at runtime, along with a runtime error if the method doesn't exist.

> If you're casting, then it's not real duck typing.

'If' being the operative word. You're not actually casting. That was merely to not try and confuse the commenter further. In fact, Go doesn't even support casting! It does support type conversion, which is oft confused with casting, but that uses the syntax `type(variable)`, which is not what is going on here either.

> In reality there is no interface tying the methods together, and the whole thing is done at runtime, along with a runtime error if the method doesn't exist.

Right, which is how it works.

I would point out that there is a special syntax / api when you deference “any” in Go. And you are explicitly prompted by the language to consider the case where you receive an unexpected type.

I think this is an important detail, because it’s way safer than in C, where you can just re-interpret memory accidentally and the compiler won’t stop you. Go will panic the thread. Ok, but we already knew that.

The subtle bit is that it’s even a bit safer than most dynamic languages like Python. Because the programmer has to explicitly handle the “unexpected type” case. And because of how verbose Go’s error handling is, every caller up the stack has to consider the error, enforced by the type system. This is different than in Python, where every variable is type any at compiler time, so every line can throw a time error and the callers probably don’t handle it. Even when using “any”, Go’s type system enforces that both the caller and callee consider the “unexpected variable type case”. Overall, it’s still way more of a controlled failure compared to dynamic languages.

It’s great that Go has generics now, to do away with some any hacks. And in general you should avoid any in Go. But when you need it, I think Go actually has a really great reflection API (especially with how it composes with other features like error handling). It’s a bit looked over I think because the difference is subtle at first glance.

Reply on news.ycombinator.com