[xyzzy_plugh]

If you think developers at Google are bad and weren't taught fundamentals then we live in different universes.

Pike's point is that peak PLT is too lofty to be productive or even useful for folks who are actually technically competent and literate relative to the rest of the industry. No one will get anything done if they're spending all their time teasing an advanced type system into inferring the required program.

[eviks]

How does it apply to this specific issue? What is so lofty and unproductive in proper null handling?

[xyzzy_plugh]

I did not suggest it applies to this specific issue, I replied to a comment containing inflammatory remarks, but I'll bite: To answer that you need to first produce the minimum change to the language that provides this functionality.

A solution might be optionals, which might require sum types, which might require generics (which Go just learned), which most definitely requires a more complex type system, which almost certainly involves longer compiler times.

Is that all worth it? I don't know. The Go team certainly didn't think so.

Languages that I'm aware of that do solve this are Scala, Rust, Kotlin to some extent, Haskell... languages which do not have a reputation of being stable, easy to learn, easy to read and understand, compile quickly, etc.

[eviks]

Thanks, I understand it was more a general inflammatory conversation, that's why I didn't like it and was wondering whether it could be grounded to this specific topic. Although I had in mind what "teasing an advanced type system" would be needed in this case that would lead to a loss of productivity, slower compliation is also relevant.

Though the reputation for those other languages mainly stem from their embrace of way more advanced concepts rather than null handling via optionals, I think that this specific concept makes it easier to learn/read/understand (though not compile quicker)

[richbell]

> ...languages which do not have a reputation of being stable, easy to learn, easy to read and understand, compile quickly, etc.

Kotlin is definitely the odd man out in that list.

[usrbinbash]

Nothing, the question is whether it is important enough to be included in the language.

Just because person A thinks this is hugely important, doesn't mean person B has to agree, or that B is a bad developer.