[Seb-C]

I have been thinking about this problem for a long time as well.

But I think that focusing on nils is a wrong analysis. The problem is the default zero-values dogma, and that is not going to change anytime soon.

Sometimes you also need a legitimate empty string or 0 integer, but the language cannot distinguish it from the absence of value.

In my codebase, I was able to improve the readability of those cases a lot by using mo.Option, but that has a readability cost and does not offer the same guarantees than a compiler would. The positive side is that I get a panic and clear stack trace whenever I try to read an absent value, which is better than nothing, but still not as good as having those cases at compile time.

No amount of lint checkers (however smart) will workaround the fact that the language cannot currently express those constraints. And I don't see it evolving past it's current dogmas unfortunately, unless someone forks it or create something like typescript for go.

[xyzzy_plugh]

It's not a dogma it's a breaking change to the language. Removing default zero-values is effectively a different language. Literally none of my code over the past several years (which otherwise all still works perfectly as-is) would work.

The Go team is very careful to avoid breaking changes (cue all the usual Well Actually comments regarding breaking changes that affected exactly zero code bases) and rightfully so. Their reputation as a stable foundation to build large projects upon has been key to the success and growth of the language and its ecosystem.

I have about a million and one other issues I'd like to see resolved first that don't involve breaking changes. It's a known pain point, the core maintainers acknowledge it, but suggestions to fundamentally derail the entire project are ludicrous.

Focusing on nils is fine. NilAway is fine. It's a perfectly reasonable approach and adds a lot of value. This solves a real problem in real code bases today. There is no universe wherein forking to create a new language creates remotely equivalent value.

[Seb-C]

I didn't said that we should remove default values, that is a wrong interpretation of my message.

For example we could have a new non-nilable pointer type (that would not have any default value), or an optional monad natively in the language (or any other thing in-between, there are many possibilities). That would allow the compiler to statically report about missing checks, without breaking backward compatibility.

But we all know that it's not going to happen soon because while not breaking any existing code, it goes against the "everything has a zero-value" dogma. That was the meaning of my message.

[xyzzy_plugh]

You are wrong regardless: there is no such dogma. There are numerous ongoing proposals discussing how to accomplish this. You're welcome to contribute. It took me a minute to find these proposals, as examples:

https://github.com/golang/go/issues/57644

https://github.com/golang/go/issues/19412

I interpret your comments as propagating FUD in bad faith.

[Seb-C]

Sum types are a different issue (even if somewhat related) than what I am talking about.

Even if sum types were introduced, it would not help with nil values because - as you said - backward compatibility won't be broken.

If I had the luxury of spare time to contribute, I would probably spend it switching away to another richer language instead, because it would be cheaper, solve more of my problems and with a higher degree of certainty. And that's not even mentioning the attitude and toxicity of the community compared to most of other languages facing critics and ideas.

[xyzzy_plugh]

What toxicity? This doesn't track for me.

> backward compatibility won't be broken.

I'm not sure what your point is anymore. You are clearly divested. Your assessment is totally unfounded. What are you trying to accomplish here?

[Seb-C]

Personal attacks are not welcome and against HN guidelines.

You can disagree with me and criticize my points, but I do not feel like it's done in a good faith or is leading to anything constructive.

So I'm going to stop the discussion here and let the readers judge by themselves what I meant, and what to conclude about it.