You can dock a couple of points for pointers being allowed to be nil. You may want to give half-a-point back for the fact that a nil pointer can actually be a valid implementation of an object, and I actually use this quite a bit. But nil maps can be accidentally unpleasant.
You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.
This paralyzing fear of goto is really out of date. I work on a Perl code base with dozens of other programmers of varying levels of skill across man-centuries of programming the vast bulk of which has basically had no code review. I've seen enormous quantities of bad code and had a hand in cleaning up a lot of it. I've seen confusing object hierarchies, bunches of confusing functions calling each other with essentially untyped parameters, all of them "fixing up" each other's parameters (mostly "correctly"...), functions a mile long with nothing but the occasional incorrect comment, reams of dead code kept around "just in case", and a huge variety of other bad code practices. And you know what I have literally not seen once? An abuse of goto. Nor do I see it in the open source I crack open, nor anything else I read.
Even if someone pops up and claims they see goto abuse "all the time", I'd challenge them to go find the source for them, and I bet they find it was just one person doing all of them in their code base. People do not abuse goto anymore, because if anything, they've been beaten so thoroughly into compliance with "goto is bad!" that the problem they have with it is not using it when they should. I don't fear that putting goto into a language will suddenly produce tons of code where entire programs are just one big function with tons of gotos in it, because I observe that it doesn't happen, and observation of facts trumps any theory about how the facts "could" be something else, because the facts are the facts.
As for passing pointers, yes, it can be dangerous. So far I've had no trouble with it because I'm always also passing ownership, but you do have to know what you are doing. I used to pine for Rust's feature set, but then, I observe that it turns Go into a completely different language, so now I prefer a world in which they are both available.
https://github.com/guzzle/guzzle/pull/965 https://github.com/igorw/retry/issues/3
Goto's are seldom used by bad programmers anyway - most of them wouldn't even be aware of them. They generally exist in languages as a niche feature used be experienced developers for those rare situations where a goto results in cleaner code. You definitely don't see Go developers sprawling goto's everywhere just because it exists.
> You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.
Erm, sorry. You've lost me now. I'll grant you that pointers require a little extra mental overhead, but they're most definitely necessary when you're writing code that either needs to be sensitive to memory usage, or performance.
As for pointers "encouraging bad code", I'm not even going to dignify that remark with a proper response.
.....yeah.
I've seen too many internal codebases where "goto" was used so horrifically I want that feature to die in a fire just to prevent such malignancy in the future.
Golang only hasn't reached that stage because its young enough there isn't heavy maintenance work over a 10+ year period yet.
Anything can create unreadable code, but mostly it's bad programmers writing unreadable code, not the syntax they use.
That's the old wives tale about gotos. Mostly repeated by freshment that heard gotos are bad, don't understand fully when and why they are bad, and repeat it as cargo cult gospel.