(I usually avoid ranting, but just couldn't resist it this time around. Go on, bring on your downvotes, you still know deep inside this is the truth.)
Oblig. generic laughter [1]
Are Go's problems over, then? I have read the error handling draft so far, and girl, was I in for a big surprise. Imagine a few nested try-catch blocks, where all the try{} and catch{} are written... imperatively, one after the other, with both try{} bodies and catch{} blocks interspersed in the same scope. E.g., line 1: "catch" block, lines 2-10: "call IO" statements, line 11: another "catch" block, etc. The errors are always passed to the previous "catch" block, then the one before that, etc, until the error has been handled.
Haven't we seen something like this before? Ah yes, the goto statements!
This was designed by a person with a severe case of scope-o-phobia. If that person has designed the rest of Go (and I think she has), the language might be unsalvageable. Just start from scratch, and do it right this time around. Oh wait, no need - we already have Kotlin.
Oblig. generic laughter [1]
Are Go's problems over, then? I have read the error handling draft so far, and girl, was I in for a big surprise. Imagine a few nested try-catch blocks, where all the try{} and catch{} are written... imperatively, one after the other, with both try{} bodies and catch{} blocks interspersed in the same scope. E.g., line 1: "catch" block, lines 2-10: "call IO" statements, line 11: another "catch" block, etc. The errors are always passed to the previous "catch" block, then the one before that, etc, until the error has been handled.
Haven't we seen something like this before? Ah yes, the goto statements!
This was designed by a person with a severe case of scope-o-phobia. If that person has designed the rest of Go (and I think she has), the language might be unsalvageable. Just start from scratch, and do it right this time around. Oh wait, no need - we already have Kotlin.
/rant
[1] https://www.youtube.com/watch?v=iYVO5bUFww0