Hacker News new | past | comments | ask | show | jobs | submit login

`unsafe.Pointer` isn't really a pointer, it's more like a uintptr; Go actually flat-out has safe pointers to begin with. They can do most things you'd care to do with pointers, including being passed around, dereferenced and storing addresses to non-Go memory. The only reason to use `unsafe.Pointer` is to do unsafe things with the addresses stored in pointers, like passing pointers across programming language boundaries, performing pointer arithmetic, reinterpreting memory, or serializing/deserializing pointers.

The real fear you should have is wasting your time by using unsafe mechanisms when you could use much more robust safe mechanisms instead, by reframing your problems. Pointers themselves, obviously, are nothing more than memory addresses with possibly a type attached to them.




>The real fear you should have is wasting your time by using unsafe mechanisms

I had a long career already, I have nothing to fear left, I have depleted all the megafauna. You're telling a hunter-gatherer that you know better because your .22 has a safety, and you only eat blueberries wrapped in cellophane.

>The only reason to use `unsafe.Pointer` is to do unsafe things with the addresses stored in pointers, like passing pointers across programming language boundaries

you're explaining how to use pointers to a C veteran? 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. (I quoted the text unsafe.Pointer from somebody else, that was the exact amount of understanding I needed and wished to convey, not a call for help to an LLM)


> 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!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: