Hacker News Reader

Comment by aabalkan | Hacker News Reader

This explains why there is "goto" keyword in Go spec. Nobody uses it, except state machines and reducers for compilers. They probably thought they'll rewrite compiler in Go and didn't drop that keyword?

View on HN

That's not why goto is there. Goto is there because sometimes you want to go somewhere and goto is the best way to get there.

I wonder why this is not a more wideread notion. Goto is useful, in all languages where it is defined. Can be misused? Sure, just like you can write switches with ifs or use while in all loops (talking of C here, not Go... I'm kind of glad I only write for or ranges now.) It's just that goto has bad fame, and ifs and whiles don't

It's because "goto considered harmful" is a catchy meme, and also many older programmers have had understandably bad experiences with code that abuses goto.

I suspect the percentage of programmers who actually had bad experience with goto is now vanishingly small. I'm not downplaying the harm that goto can cause - but to have experienced it, you have had to experience old basic, fortran 77 or COBOL before learning C or Java. That probably describes 0.1% of people doing programming. Maybe less.

The averse reaction to goto is conditioned response, not learned experience.

I learnt programming with a book named "Basic para niños" (Basic for kids when I was ~7-8, around 23 years ago) and with the programmers manual for GW-Basic. So goto was an inherent part of it, but as soon as I learnt other languages goto lost a big part of its significance. I read a lot of code full of gotos (back in my Basic days) but afterwards only the occasional goto would pop up. When I learnt C at my university for numerical stuff, we weren't taught goto existed (I found it out when reading K&R 2-3 years later, when I wanted to get a better understanding of it.) Goto is awesome in a lot of cases (where something alike to break label; is not available), but as you say, the conditioned response is "goto is bad." And it's pity, because nothing is inherently bad, most often it's just the user at fault.

Where was that? In 1990 in the US and UK and France (possibly other places - that's where I'm aware of), Basic was already on the way out - and that was the "good" basics like BBC Basic (with procedures, local variables, WHILE/WEND, REPEAT/UNTIL, named labels, proper error control with ON ERROR - I think of these, GW Basic only had "on error").

It was already Pascal in academia and "regular" insdustry, C in low-level stuff and FORTRAN 77 in science stuff. Of course, there was still legacy Basic and legacy COBOL, and you were much more likely to run into a historical mess of GOTOs. But still, it was already past the Acceptable Spaghetti era.

I once had a book, in coffee table, landscape format that was titled "Linux Core Kernel Commentary Vol 2".

In the annotator's introduction it stated something like "I haven't seen this many goto statements since I was writing BASIC as a teenager!" but then went on to explain why sometimes they're the right tool for the job.

I'll have to order another copy. It was an amazingly varied source of knowledge!

[1] http://www.amazon.com/Linux-Core-Kernel-Commentary-Edition/d...

Am I misunderstanding this comment? Golang has a "goto" like many other languages. There's a goto in my source tree (in a lexer, to handle the newline terminating a line comment); there are also plenty of gotos in the go standard library. "goto" can be useful.

I have also used goto a few times in Go. There are occasions where it makes the code more obvious than the alternatives.

A lot of people cargo-cult Dijkstra's hate on goto. It does have its uses as long as you're very selective about when to apply it.

I've used it. It's uncommon, but occasionally useful.

https://groups.google.com/forum/#!topic/golang-nuts/LT94Oc6m...

Reply on news.ycombinator.com