> the only reason to use a pointer unsafely is, you don't know what you are doing and are sloppy. otherwise, use pointers safely and you won't need to worry.
Yes of course, just simply never make mistakes! The secret to writing good software was in front of us the whole time. If only someone had told me sooner that all I had to do was be literally perfect!
OK, I apologize for the sarcasm, but at this point, it's hard to take this line of thinking very seriously. I'm sure you do not make (m)any mistakes, but most of the humans around you make mistakes often enough, and we need more than one programmer on Earth. I think you will have to cope with the fact that many of us are interested in improving the programming experience for the plebians who are not ~100% perfect.
And while I'm at it, the whole appeal-to-experience line of argument just doesn't have the same impact on me as it did when I was younger. Now, really, I'd prefer an honest intellectual discussion over trying to see who has the most "credentials", but if we're going to talk about credentials, you may as well go for quality over quantity. I'm sure you know people who have a very successful and long programming career and yet write pretty awful code. That's no surprise; programming jobs have surprisingly little to do with programming.
Either way, "safety" in programming language design is not just about people making mistakes, but also about consistency. Two changes that are safe can occur concurrently and, when combined, create a bug. Humans can't really do much to catch that, but software checks sometimes can. When the cost of a bug or worse, vulnerability, is relatively high, it's not hard to see why there's a lot of hoopla over "safety".
> you're explaining how to use pointers to a C veteran?
I didn't explain how to use pointers, I was explaining that Go has pointers, and counter-intuitively, `unsafe.Pointer` isn't actually a pointer. You said that people are "deathly afraid of pointers", when quoting "Don’t use unsafe.Pointer". That's very different from telling people to not use pointers!
Yes of course, just simply never make mistakes! The secret to writing good software was in front of us the whole time. If only someone had told me sooner that all I had to do was be literally perfect!
OK, I apologize for the sarcasm, but at this point, it's hard to take this line of thinking very seriously. I'm sure you do not make (m)any mistakes, but most of the humans around you make mistakes often enough, and we need more than one programmer on Earth. I think you will have to cope with the fact that many of us are interested in improving the programming experience for the plebians who are not ~100% perfect.
And while I'm at it, the whole appeal-to-experience line of argument just doesn't have the same impact on me as it did when I was younger. Now, really, I'd prefer an honest intellectual discussion over trying to see who has the most "credentials", but if we're going to talk about credentials, you may as well go for quality over quantity. I'm sure you know people who have a very successful and long programming career and yet write pretty awful code. That's no surprise; programming jobs have surprisingly little to do with programming.
Either way, "safety" in programming language design is not just about people making mistakes, but also about consistency. Two changes that are safe can occur concurrently and, when combined, create a bug. Humans can't really do much to catch that, but software checks sometimes can. When the cost of a bug or worse, vulnerability, is relatively high, it's not hard to see why there's a lot of hoopla over "safety".
> you're explaining how to use pointers to a C veteran?
I didn't explain how to use pointers, I was explaining that Go has pointers, and counter-intuitively, `unsafe.Pointer` isn't actually a pointer. You said that people are "deathly afraid of pointers", when quoting "Don’t use unsafe.Pointer". That's very different from telling people to not use pointers!