(Even the concept of 'the value of nil' is tricky in Go; I believe the specification only talks about things being comparable to nil or allowing nil to be assigned to them. The specification really goes to a lot of work to not treat nil as a value, exactly. I suspect that the Go spec authors really did not want a rerun of the C idea that the NULL pointer is '0' and has an all-zero value and so on.)

(I'm the author of the linked-to entry.)

So it feels like you're trying to draw some distinction here that is like, "look, nil isn't really that special - there's groups A and B, and the core confusion is people think nil is in group A while the truth is in it's group B." And it's true, Go has both typed and untyped constants.

But as far as I know, nil is the only untyped constant without default type. So "group B" is still just nil, and nil remains a sui generis source of confusion in Go.

It seems the root problem is that interfaces and concrete values occupy the same semantic positions. But that's way too hard a problem to fix; if I had a magic wand to update all existing code I'd probably just have `== nil` on an interface check for both kinds and try to rescue transitivity.

The whole "confused about nil interface vs. interface containing nil pointer of some type", while I would contend has a root cause of improperly importing the idea from C++ that nil is automatically invalid when in fact it is perfectly valid in Go to call methods on nil and thus confusing "nil" with "invalid", is at least a cause of real bugs and real misunderstandings.

If you are looking for the perfect language may I suggest Forth on a Z80? Otherwise there's going to be a pile of shit hiding somewhere.

1) The language lacked hindsight in its domain because there wasn't a ton of prior art (C)

2) The language didn't have enough foresight put into it (JavaScript)

3) The language's modern usage has drifted significantly far from its original usage (Java)

Python is an example of a language people use that doesn't suffer from #1 (thanks to Perl and friends), doesn't really suffer from #2 (at least, Python 3) and doesn't (yet) suffer too badly from #3. It has plenty of flaws and limitations, but not in its foundation. The core language primitives are rock-solid.

#1 doesn't apply to Go, and it's not old enough for #3 to apply. So that seems to only leave #2.

(I should add that this doesn't make a language completely invalid or useless. I use (and even like!) JS despite its flaws; in fact I prefer it to Python overall, mostly due to the ecosystem. It's just disappointing to see issues of type #2, because they seem so avoidable.)

Your C example is also not convincing. Lisp and Algol were already strong contenders at the time. People chose C because they needed a fast and close to metal language to create their own operating system for mainframes. It was a hack just like your category 2. Still, it's a great language.

> It's pointless discussing this

I don't see how the first implies the second. This is a programming forum; it's good to discuss and debate the specifics of these things.

C may not have been the best example of the category, but I think the category stands. Rust for example, much as I love it, is exploring uncharted territory. I wouldn't be surprised if 10 years from now we have ownership-based languages that are much easier to use, simply because lessons will have been learned by that point. Arguably Java's OOP fundamentals are not as good as C#'s because Java had to explore that territory first (setting aside technicalities about what the term "OOP" really means). Etc.

I'll recommend Reddit's r/ProgrammingLanguages, as well as Scott's Programming Language Pragmatics as a reading instead. It's not fully up-to-date but I found the comparisons of features and their trade-offs in it fascinating.

   type T int

   const a = 0
   var b T = a
   var c interface{} = b
   fmt.Println(a == b, b == c, c == a) // true true false

In JS:

    false == undefined => false
    false == null => false
    undefined == null => true

    a = 1
    b = 2
    c = 1
    a == b => false
    b == c => false
    a == c => true

Second, if you have to reach for old javascript "features" (or got forbid PHP) to defend a language you're in a bad, bad place.

Third, the broken equality is not something that's usually praised about javascript. In fact the first rule of javascript equality is that there is only one situation in which `==` is the correct operator: checking that something is null (because that avoids having to differentiate between null and undefined, papering over one javascript wart using another). In every other situation you want "strict" (===) equality.

  A != B
  A != C
  B == C

  1 != 2
  1 != 2
  2 == 2

   A != B    1 != 2
   A != C    1 != 3
   B == C    2 == 3

JS loose equality is intransitive, though; the standard example being:

  '0' == 0; // true
  0 == ''; // true
  '0' == ''; // false

The first one he talks about is that [] + [] gives you "" (an empty string). I don't know what universe that makes sense in. [] + {} gives you {} back. Meanwhile {} + [] gives you 0. Yes, the order in which you add types that can't logically be added ends up giving you different incoherent answers. {} + {} gives you NaN.

One of the other sibling comments said that it was mostly implicit conversions, which I think is the underlying cause of most of these.

That's not to totally hate on Javascript, but the language could probably use fewer implicit conversions and more type errors. I struggle to think of a situation in which those outcomes are desirable, and it can cause extremely hard to follow stack traces. A JSON API returns a list of objects instead of a list of strings and now your types are screwed up in hard-to-follow ways.

{ }; +{}

If you put parentheses around it, or assign it to a value and then print that value then {}+{} isn't empty string.

Also see this minitalk (which actually gets some things wrong because of confusion on how the terminal interpreter behaves but is still amusing): https://www.destroyallsoftware.com/talks/wat

  > [] == []
  false
  > [] == ![]
  true

  This condition will always return 'false' since the types 'never[]' and 'boolean' have no overlap.

I wonder how much of weirdness is wiped out by linters/ts/etc.

In the same way a slice can contain one or more nil values without itself _being_ nil. A gift box containing nothing is not itself nothing.

> And the reason is hopefully apparent from the previous two lines: It depends on the type of "nil".It depends on the type of "nil".

Well, no. "r == nil" tests whether r itself is nil (i.e. the zero value of that interface type) which it is not. It contains b and is thus no longer nil. The type doesn't play a (large) role here. This misconception might be due to the fact that lots of types can be nil: slices, maps, channels, functions and (unfortunately) interfaces.

Nobody is astonished that a slice containing any sort of nils is not nil itself; that a buffered channel containing nils is not nil itself and that the constant function `func()*int { return nil }` is not nil itself either. Only for interfaces this poses a problem. If interfaces wouldn't be "nil" but lets say "zilch" than it would be evident that r != zilch.

Since nil does not have a default type, it's an error to write "x := nil".

But not an error to write "x := 0"?

I've found thinking about nil too much in Go hurts or creates weird loops in my brain, so I just tend to worry about it when I'm dealing with interfaces or pointers. Everything else I'm looking at zero-values.

Then determining if something is nil could be done without thinking about it at all. nil would be nil would be nil. (Also, it would be illegal to put methods on nilType, of course.)

(Yes, I make my living writing go, and this would make my life easier. And no, in that case, don't allow x := nil.)

[0] https://blog.golang.org/constants#TOC_5.