[go-nil-why]

The issue isn’t the services that stay up forever, it’s the ones subject to a huge amount of churn where maintainers lose context on what is or isn’t possibly nil, and get loose with their checks.

Edit, responded to pointer vs reference down thread.

[hnlmorg]

The issue I’m addressing is your exaggerated verbiage which sounds like it’s a reasoned argument but is actually just biased nonsense.

I’m not disagreeing that nil pointers are an ugly sore for Go. What I’m arguing against is your claim that Go services are constantly failing in production because of that sore point.

The reason I make that argument is because:

- sore points are a problem for every programming language. designing a programming language is a constant trade off of concerns. so there will always be stuff that doesnt work well. And I know this as an author of a programming language myself.

- however if sore points prevent a language from being usable in a production context (assuming that’s its intended role), then that becomes an insurmountable problem.

Nil pointers aren’t an insurmountable problem for Go. They’re ugly and arguably a terrible design choice, but not an insurmountable problem. Which is why Go succeeds despite this sore spot.

Typescript has its own WTF moments too. Every language does.

[go-nil-why]

Clearly, we don’t work at the same company.

What I claimed applied to my company, exactly as I said.

If it doesn’t apply to yours… ok? Congrats?

Looking back, maybe you didn’t understand the shell variable syntax?

[hnlmorg]

You’re right, I didn’t understand that syntax. Sorry.