Yes, but giving nil a default type would be way more confusing.

Go already kind of does though, when you use it in a type switch nil has type nil. For binding purposes, `interface{}` also seems reasonable. (Or only half-joking, if I wanted maximum pragmatism for minimal clarity, nil's default type should be error.)

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.

At the risk of inviting a flame-war, it's distressing to me that a language this recent, with such a purported focus on simplicity, has design-problems this fundamental

I have a hard time classifying this as a "design problem" when it has zero practical implications. I've never encountered a problem that can be traced back to this, nor ever helped anyone else with a problem that can be tracked back to this. If it is a "design problem" it is of the weakest possible class. I can't imagine what would "fix" it that wouldn't be a larger design problem of its own.

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.

Sorry, you won't get much agreement from me on this. There's only two kinds of languages, the kind with fundamental design problems and the kind people don't use.

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.

I disagree. Issues like this on really core language primitives usually crop up when either:

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.)

I think Python suffers from #3, as they've been adding new (controversial) syntax like typing, the := operator, and pattern matching. These were intended to help write real-world code at the cost of simplicity and applicability as a teaching language.

It's starting to get there, yeah, though I think any sufficiently-popular language eventually gets there at a certain age

Eh, parsimony is nice to have, but at the end of the day, programming language design is just plain old engineering and engineers make tradeoffs to ship functional code that isn’t too terrible.

It's pointless discussing this. There is no perfect language and every programming language I've ever seen has design problems at one level or another. I know enough of CL, Pascal, Modula, Ada, Rust, Nim, etc., to know their weaknesses, too.

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.

> There is no perfect 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.

The problem is that decades of experience has shown that only few programmers can discuss the advantages and disadvantages of programming languages for certain purposes in a halfway objective manner, and since few of them implement their own languages even the good discussions often remain fruitless.

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.

Yes, that sounds like a flame war invitation. Issues with nil plays no role in practice.