Having nullability has its own set of issues. I prefer explicit error handling to null checks. That being said, I don’t think there is really that much of a dif

Having nullability has its own set of issues. I prefer explicit error handling to null checks. That being said, I don’t think there is really that much of a difference in that you might use Interface as a JS Any sort of thing in Go (it’s obviously difference), and where you would deal with nil pointers is often where you would perform a null check anyway. I prefer the go style of doing a check every time rather than some of the time with the risk of missing a time. Or on the flip-side simply defining your own default. I know that a lot of people like how C# is becoming more and more reliant on the compiler to handle type checks, but it also opens up the risk of more developer mistakes. It’s mostly down to opinion and preference. So I don’t think you can really call it a “problem” as such. Having nullability will be a feature to some, and not having it will be a feature to others. I think both decisions were right for their respective languages. C# needs it for its close integration with mssql and its exception handling. Go doesn’t want it because it favours simplicity in types and direct error handling.