3 ms·

I’ve never seen a real bug from the interface nil != concrete nil thing. When does it come up?

lenkite 3y ago
People have raised dozens of issues on the Go tracker because they got stumped by this. You don't really need to look hard on a search engine to see thousands of questions/issues. If you don't believe me, take a project like k8s and starting from its inception, you can see dozens of issues where people have to explain function returns a nil interface and not a nil value. This is explained a stupendous number of times. Now repeat this for thousands of Go projects. Of-course you can claim this is not an issue in the same way that anyone can claim that buffer overflows are not an issue in C/C++ for "real" programmers.
- earthboundkid 3y ago
  I see people say that they're confused by it a lot, sure. But do the bugs get to production? That was my question. Buffer overflows get to production all the time! But do the concrete vs interface nils get to production or are they caught in dev and then someone opens an issue to ask why it doesn't work? I suspect it's more the later. Obviously, it would be better if Go didn't have this problem. If I made Go 2, it would have blank interface be "none" and blank pointer be "null". Even better, I would add a reference type that can't be null and sum types or something like that. But these things are all relative. In Python, people using "is" for numbers is a problem. But in practice only very junior developers do that and it mostly gets caught in dev. There was the Digg outage caused by a default argument being [] instead of None https://lethain.com/digg-v4/ https://lethain.com/digg-v4/ and that I see as a slightly more serious bug that can slip by without good code review. Every language has pitfalls and the question is whether they outweigh the other benefits.
  - bb88 3y ago
    > But do the bugs get to production? That was my question. Yes, in my case anyway. That code didn't have any unit tests around it. Goland didn't flag it. It's a pattern that was "surprising" to me at least. Particularly since it breaks with tradition. I consider Goland to be invaluable when coding go. But still, it's not perfect. > There was the Digg outage caused by a default argument being [] instead of None FWIW Pycharm flags this now, and can fix this automatically. Not sure about VSCode. I guess the point I'm making is IDE's should find the novice mistakes, and then a lot of my complaints about languages go away.

People have raised dozens of issues on the Go tracker because they got stumped by this. You don't really need to look hard on a search engine to see thousands of questions/issues. If you don't believe me, take a project like k8s and starting from its inception, you can see dozens of issues where people have to explain function returns a nil interface and not a nil value. This is explained a stupendous number of times. Now repeat this for thousands of Go projects. Of-course you can claim this is not an issue in the same way that anyone can claim that buffer overflows are not an issue in C/C++ for "real" programmers.

earthboundkid 3y ago
I see people say that they're confused by it a lot, sure. But do the bugs get to production? That was my question. Buffer overflows get to production all the time! But do the concrete vs interface nils get to production or are they caught in dev and then someone opens an issue to ask why it doesn't work? I suspect it's more the later. Obviously, it would be better if Go didn't have this problem. If I made Go 2, it would have blank interface be "none" and blank pointer be "null". Even better, I would add a reference type that can't be null and sum types or something like that. But these things are all relative. In Python, people using "is" for numbers is a problem. But in practice only very junior developers do that and it mostly gets caught in dev. There was the Digg outage caused by a default argument being [] instead of None https://lethain.com/digg-v4/ https://lethain.com/digg-v4/ and that I see as a slightly more serious bug that can slip by without good code review. Every language has pitfalls and the question is whether they outweigh the other benefits.
- bb88 3y ago
  > But do the bugs get to production? That was my question. Yes, in my case anyway. That code didn't have any unit tests around it. Goland didn't flag it. It's a pattern that was "surprising" to me at least. Particularly since it breaks with tradition. I consider Goland to be invaluable when coding go. But still, it's not perfect. > There was the Digg outage caused by a default argument being [] instead of None FWIW Pycharm flags this now, and can fix this automatically. Not sure about VSCode. I guess the point I'm making is IDE's should find the novice mistakes, and then a lot of my complaints about languages go away.