4 ms·

I agree. I find myself disengaged as soon as someone makes fun of the hard work of others. Intelligent people don't typically do this.

JonChesterfield 2y ago
The rationale for removing goto is: > Rationale: It is very difficult to make goto work well with defer and implicit unwrapping of optional results. It is not just making the compiler harder to write, but the code is harder to understand as well. That seems to fit your heuristic. Goto being difficult to implement in the compiler doesn't match expected reality.
- rob74 2y ago
  It's not difficult to implement goto as such, it's just a JMP instruction, but (I'm not a compiler developer, but I can imagine) implementing goto without introducing strange bugs or crashes is a bit more difficult.
  - JonChesterfield 2y ago
    Compilers really like canonical forms. There's a good chance that if, for, while, goto, break and so forth all turn into an edge between basic blocks (anything that doesn't have a branch or branch target in it). In a rather literal sense it's usually all sugar over goto, unless you're doing something niche like carefully preserving structure because your target language doesn't have branches. So seeing someone say that their compiler struggles to represent goto throws some doubt on how the thing is implemented. Goto should generally be the easiest possible control flow to translate into your IR.
- lerno 2y ago
  `goto` is trivial to implement. `goto` doing the right thing jumping over `defer` and implicitly unwrapping optionals (flow-typing) is less nice as you suddenly need to track much more things in the front end. And you might say "so what, the compiler can be complicated, just make the language easy to use". However, one design constraint is to not make the language hard to reimplement. And you might not agree with that constraint, but some people feel that this is indeed important. Important enough to not include `goto` as long as the use cases of `goto` are all covered.

JonChesterfield 2y ago

The rationale for removing goto is: > Rationale: It is very difficult to make goto work well with defer and implicit unwrapping of optional results. It is not just making the compiler harder to write, but the code is harder to understand as well. That seems to fit your heuristic. Goto being difficult to implement in the compiler doesn't match expected reality.

rob74 2y ago
It's not difficult to implement goto as such, it's just a JMP instruction, but (I'm not a compiler developer, but I can imagine) implementing goto without introducing strange bugs or crashes is a bit more difficult.
- JonChesterfield 2y ago
  Compilers really like canonical forms. There's a good chance that if, for, while, goto, break and so forth all turn into an edge between basic blocks (anything that doesn't have a branch or branch target in it). In a rather literal sense it's usually all sugar over goto, unless you're doing something niche like carefully preserving structure because your target language doesn't have branches. So seeing someone say that their compiler struggles to represent goto throws some doubt on how the thing is implemented. Goto should generally be the easiest possible control flow to translate into your IR.
lerno 2y ago
`goto` is trivial to implement. `goto` doing the right thing jumping over `defer` and implicitly unwrapping optionals (flow-typing) is less nice as you suddenly need to track much more things in the front end. And you might say "so what, the compiler can be complicated, just make the language easy to use". However, one design constraint is to not make the language hard to reimplement. And you might not agree with that constraint, but some people feel that this is indeed important. Important enough to not include `goto` as long as the use cases of `goto` are all covered.