5 ms·

Agree with you on all points, but especially on enums. The most surprising thing to me, is that typed enums look super orthogonal to all the other features of t

by bsaul 4y ago

Agree with you on all points, but especially on enums. The most surprising thing to me, is that typed enums look super orthogonal to all the other features of the language, look quite « easy » to add and certainly won’t make the language more confusing (like generics for example) Yet having a compiler be able to tell you « this code isn’t handling all the cases » is really really valuable.. Edit: about the error interface nil casting, i had this problem just 2 days ago, fortunately the linter detected the problem (not the compiler) with a weird « this code is never reached » error. I would have never guessed this behavior otherwise.

015a 4y ago
Its EXTREMELY weird behavior. Like, in that example I linked in [4] above; just parsing over the code what you should expect to happen is nothing all that interesting; it should just run. Instead, what happens is, the error conditional on line 33 is triggered, which triggers the panic on line 43, but that's not even the end of the insanity, because due to the underlying value being nil even though it clears an if != nil check the PANIC itself PANICS while it tries to render the error. This isn't okay! Like, the other stuff I complain about or ask for improvements is whatever, but this is something that if any Go devs are reading, legitimately needs to be fixed, even if it means a language breaking change. There's no logical or reasonable explanation as to why that conditional on line 33 passes. There's definitely a reason; I don't care what it is, its a bad one. Its a surprisingly common situation to run into once you start hitting medium-sized codebases and custom errors; where you have some module returning a custom error, some other module returning its own custom error or just an error, and you need to coalesce them back into just a plain-old-error. The SOP at my 1000 engineer big-tech 90%-go-shop is to literally never specify custom error types in a function's return signature. Its too unsafe; you know, that thing that's supposed to make your code more safe, providing more information to the type system, yup it makes your code less safe. Return the custom error (concretely), specify 'error' in the signature, and put in a comment that it can return that error type for eventual type coercion. How embarrassing is that for the language? Reminder, team: its 2023.

by bsaul 4y ago

015a 4y ago

Its EXTREMELY weird behavior. Like, in that example I linked in [4] above; just parsing over the code what you should expect to happen is nothing all that interesting; it should just run. Instead, what happens is, the error conditional on line 33 is triggered, which triggers the panic on line 43, but that's not even the end of the insanity, because due to the underlying value being nil even though it clears an if != nil check the PANIC itself PANICS while it tries to render the error. This isn't okay! Like, the other stuff I complain about or ask for improvements is whatever, but this is something that if any Go devs are reading, legitimately needs to be fixed, even if it means a language breaking change. There's no logical or reasonable explanation as to why that conditional on line 33 passes. There's definitely a reason; I don't care what it is, its a bad one. Its a surprisingly common situation to run into once you start hitting medium-sized codebases and custom errors; where you have some module returning a custom error, some other module returning its own custom error or just an error, and you need to coalesce them back into just a plain-old-error. The SOP at my 1000 engineer big-tech 90%-go-shop is to literally never specify custom error types in a function's return signature. Its too unsafe; you know, that thing that's supposed to make your code more safe, providing more information to the type system, yup it makes your code less safe. Return the custom error (concretely), specify 'error' in the signature, and put in a comment that it can return that error type for eventual type coercion. How embarrassing is that for the language? Reminder, team: its 2023.