re: Well, before you score, how would the Go counterpart for the same problem look like and would it give you the same guarantees? Can you declare a ...
 

I agree with some points of the article (e.g. The map declaration syntax is just WTF and inconsistent), but what I said is that I don't understand in which way the Elixir example is more readable. I can understand it's safer, but personally I don't care.
And who needs a function that can take an int or a string or a map or a chicken 🐔?

Boris, let us discuss the example from three different angles: soundness of the type system, understandability and relevance for real-world problems.

With regard to the type system I think the main point is that it is relatively easy to lose the guarantees that static typing can provide. The example might be contrived and the Elixir counterpart illuminates that while static typing doesn't necessarily equal strong compile time guarantees, and at the same time that there are constructs that allow strong compile time guarantees in a dynamic languange. And to further elaborate on the example, the use of pattern matching has another beneficial aspect: exhaustiveness checking. If the runtime guards are written with if statements, you would need to ensure that you have all edge cases covered, with this idiom you can let the compiler help you on your way there.

With regard to readability: I personally would consider it equally comprehensible, but I have been exposed to Prolog and Haskell, where pattern matching is a very common idiom. I have to grant, that transitioning from imperative to declarative/functional style initially puts more cognitive load on the person, but the underlying principle can be explained in a few sentences. I'd argue that the pattern matching style lends itself favorably to some problems, although using it in lieu of an if/else cascade as in the examples might not be the most convincing show case.

As for the real world: consider an HTTP endpoint which had to be evolved over time and, for reasons outside of your sphere of influence (assume for example design by committee), it was decided that it needs at all costs be backwards compatible and at the same time be able to deal with different payload formats. We can argue all day long that someone has made a design error at some point in time, but long-lived systems which are connected to other long-lived systems tend to be that way. In RFC 793, which specified the TCP protocol, John Postel proposed for the its implementation, something that is good advice for system design in general:

[A] general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

Since the debate in the thread was a bit heated, let me conclude with this: The designers of Go made decisions and trade-offs. To reflect on those doesn't invalidate the language, nor does it diminsh the efforts that went into any program written in Go. But it might expand someones perspective, which is something I personally consider to be worth striving for.

code of conduct - report abuse