Hacker News Reader

And I agree with the proposal committee for declining your request. For a language that prides in having great backward compatibility, what you were proposing wouldn't fly.

View on HN

The author did say "Back when we thought "Go 2" was going to have lots of breaking changes". It seems reasonable in that light.

Exactly; if we're going to "rip the bandaid off", just do it all at once. The idea seemed in line with other aspects of golang: for instance, you can't compare an int32 and an int64 directly -- the compiler will throw a warning if you don't cast the int32 to int64 before comparing. This is obviously because, as old-school C programmers, they recognized that automatic promotion is a trap that caused all kinds of issues. I'd argue that the "nil interface is not nil" trap is quite a bit worse.

As it turns out, a lot of the improvements they were thinking about could be done without breaking backwards compatibility; which of course has some huge advantages.

Reply on news.ycombinator.com