Which is why Go has goto's and pointers. Got it. No, Go's adherents are just sloppy in a different way. I have many bad things to say about Haskell, but I admire Haskellers lack of sloppiness. I cannot say the same about Gophers.
Go's goto is the standard structured-programming-limited goto which is not allowed to violate blocks, which means it is not the goto that is "considered harmful". Go's "pointers" are not allowed to do pointer arithmetic, which basically means that they are references. As they are also backed by a garbage collector, this means you can't do any of the nasty C things you can do with them, not even "fail to deallocate" them. All you've got left is "unexpected liveness" (a.k.a. "memory leak") and that can happen to anybody, even Haskell.
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.
Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code.
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.
No, gotos are present to allow you to use programming paradigms other than structured programming, isolated within the confines of a structure-programming function. The most popular such alternative paradigm that can be written by a human being a finite-state machine, which can be quite clearly and efficiently expressed via goto. Generated code can also get a lot of mileage out of goto, and this is usually code you're not going to be touching anyhow if you've gone so far as to generate it.
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.
I do see a bit of goto use in the PHP community, but it tends to be used by well-known and respected programmers, sometimes just to make the point that goto isn't evil in and of itself.
> Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code.
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.
> Goto's are seldom used by bad programmers anyway - most of them wouldn't even be aware of them.
.....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.
Goto's are used extensively in the Linux kernel for clean exits from functions (typically system calls) that must validate parameters, allocating resources as they go, but then abort if there are any errors in the parameters. For example: http://lxr.free-electrons.com/source/kernel/fork.c?v=3.3#L42...
>Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code.
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.
In my organization Goto's have to get past code review, which is rare and when they do make sense they are probably good option. Your organization can have its own style guidelines.... Just say no gotos- done.
