10 ms·
Bad data isn't unique to Go; let's assume bad data is an external constant. If Go is a superior programming language -- error handling or not -- it should be e
by CharlieDigital 2y ago
Bad data isn't unique to Go; let's assume bad data is an external constant.
If Go is a superior programming language -- error handling or not -- it should be easy to find the statistical evidence. Otherwise, you just prefer green crayons; please, by all means, go enjoy your green crayons.
Go's error handling isn't any better or worse; it's just objectively way more verbose. With what benefit? If you wish to claim one beyond your subjective vibes, please by all means prove it with evidence.
- MattPalmer1086 2y agoThe topic was not determining which language has fewer defects. It was specifically about whether the error handling aspect is better. I'm not claiming any benefit by the way of Go's error handling. I've never even used Go. Just pointing out that measuring defects is not a good way to determine whether it is or isn't.
- CharlieDigital 2y ago> It was specifically about whether the error handling aspect is better. If it's better, how? Can you prove it? Does it lead to lower defect rates? Lower time to debug? Less runtime errors? How is it better other than your preference of green crayons?
- MattPalmer1086 2y agoAs I said before, I've never used Go. I have no opinions about its error handling, or green crayons for that matter. Measuring defect rates against another language will not tell you whether the error handling is better or worse than the other language either.