I assume with the duck typing you are talking about interfaces? How has that caused issues?

With huge projects that pull in packages i have seen the dependency management become a mess but most of the time its not that bad.

It was sloppy coding on the project I took over, but it still made me wish for explicit style interfaces. Cleaning up frequently broke the project in non-local ways, because someone would break an interface without meaning to.

Unless you are doing some (possibly unsafe) magic the interfaces are strongly typed, external dependencies are locked, so one cannot really break an interface without meaning to. Or I guess without realizing it immediately.

I ended up ripping out the unsafe magic, but it was a huge pain while it existed.

To be fair, most million plus LOC projects match “misfortune” and “nightmare”.

Go is verbose, a million plus LOC doesn't go as far as it would otherwise.

I don't know, my experience with mega SLOC projects were Java, so verbosity was also a thing.

Go's verbosity is usually found in multiples (if err), not in long forms (int[] arrayOfIntegersWithValuesOneToFive = new ArrayFactory().createArrayWithSize(5).populateWithValues(1, 2, 3, 4, 5); ).

I think you typed "python" wrong :) Duck typing is a python thing. And the dependency management is a nightmare, constantly breaking. To the article's point - you _must_ run it in a container and defer to the OS to have anything resembling a sane development story.

OP meant structured typing, which is the strong type version of duck typing.

As long as the type supports the same interface anything goes, even it actually supports another one, where the methods have the same name, with different semantics.

Ok that's totally fair. What's the Go name for it? In my mind Go interfaces are duck typed.

mostly joking - your complaints are big problems in python. Dependency management in Go has been contentious (historically) with "to vendor or not to vendor", glide and dep, GOPATH, etc. But that is all solved. Go mod for the win.

As far as "the nightmare of {using interfaces}" -- I have no clue to any controversy there. It is one of the most celebrated features of Go. Not sure where you were going with that. In Python, I do find duck typing to be a nightmare because you don't actually _know_ what you have. Can you change it? Try it and if it breaks you will know. Or you use it like a list but it is a string and that gives strange, unexpected behavior, so you end up doing things like `param=force_list(maybe_string_or_list)`.

The Python typing nightmares you refer to go away on large projects as soon as you start using mypy, which I tend to find most large projects do these days.

So yes, you can change that string and you do know.

It's still better that it's optional and gradual - it's unnecessary overhead on smaller projects, spikes, notebooks, etc. which are what most big projects grow out of.

Python typing nightmares definitely do not just go away with the use of mypy. There are so so many ways to break out of the guardrails it supplies that are not caught.

I can write stringly typed code in haskell too if it comes to that.

Don't you need stumps which are quite often not available?

What were they actually doing? Passing interface{} all the time and casting it?

Haha you're spot on. In the codebase I inherited that was everywhere.

You can do crazy things in any language if you try hard enough.

The trick to efficient Go is to not try hard, lol

Python is duck typed as it support dynamic type, whereas Go doesn't. Yet you can do polymorphism in Go and aside that difference I think Go interface are duck typed.

Probably structural typing?

I think you typed “JavaScript” wrong…

;)

I assume your only part of a larger larger team working on this 1M LOC project? If you are alone with no previous context/knowledge the language does no really matter, you would be in a world of hurt nonetheless.

I agree with you but that pretty much invalidates Go. The whole selling point is that it is lacking anything to make the language interesting to use but you can drop in and any two Go programmers write the same understandable code.