What Golang Is and Is Not

Poor old Tony Hoare (algol was mentioned earlier (rightly) as an exemplar of innovation) but Null in a safe memory managed context is a different beast to a true Null reference.

Null appears then as something between a known state and an not quite an exception, it carries different semantics from either, and whilst this could be seen as more complexity, I think the "I just don't know" case in practicality is useful, if harder to reason about.

Your point about the runtime is very true. Partly because of this - error checking is overrated! Yes I said it! We have go code that has been running in a reasonably high scale production environment for over two years and there are `if:...;err != nil` blocks that have never been touched in millions of calls per day, for 2 years. We have redundant services and trap panics in the rpc handlers, the nil becomes very clear and the rest of the system makes good progress. We save lines, save tests, and release a single binary fast. One example of where Go helps us deliver value faster, by being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie.

Most languages don't have abstract types (not to be confused with abstract classes!), so there's that. Abstract types protect invariants of modules from external tampering. This is a mathematical fact.

> However, that was your example. My argument is that's a really poor example. And now you are abandoning it.

I'm not abandoning anything. I'm only saying that the use cases of parametricity go far beyond parametric collections.

> I also like separating concerns.

Good! Then what do you gain from the existence of reflection (which is pretty much the opposite of type abstraction), or the possibility of sending wrong messages? This is as anti-separation-of-concerns as it gets.

Even more worrisome is what you have said in another post: “Decompilation in Smalltalk is trivially perfect, excluding local variable names, so closed source was fairly pointless.” (https://news.ycombinator.com/item?id=12340864) How can you pretend this is compatible with separating concerns? You're talking about inspecting the structure of arbitrary parts of a program!

> I'm also not a dynamic typing bigot, though you seem to be imagining you are arguing with one.

I've just made technical claims. I haven't personally attacked you. If you think I did, my apologies.

> How in the heck did you get here from parametric algorithms? This smacks of intellectual dishonesty.

I also request that you refrain from making personal attacks.

Anyway. Parametricity means more than you think. The inability to inspect the representation of an abstract type is an example of parametricity too.

> And earlier, you were claiming something about refactoring. Do you see a contradiction here?

Nope, I don't see it. Refactoring produces a different program with a different fixed structure. And the difference shows up when the old and new programs have different types. The reason why types are helpful is precisely because they guide the evolution from the old to the new program.

- Using an iterator more than once silently produces nothing. I notice this when I insert print statements to debug something, but then accidentally turn the following for-loop into a no-op. The Python 3 change that made more top-level functions return iterators made this problem more common, though I agree with the performance justification for doing it. It would be nice if iterating again after hitting the end raised an Exception, though I'm sure that would break all sorts of code that assumes it doesn't.

- Mutating function default arguments affects all subsequent calls. This is most common Python gotcha people seem to talk about.