3 ms·
Now you can focus on if err return err instead. I wanted to like go for its crossplatformness, compile speed and relatively small memory usage while still bein
by tomjen3 5y ago
Now you can focus on if err return err instead.
I wanted to like go for its crossplatformness, compile speed and relatively small memory usage while still being more practical than C++.
But not having generics and having to constantly check for errors was the two big things that made me bail.
Just to clarify, I don't want exceptions, I just want some language mechanism that changes err, value to be errOr<value>, which if passed to any function while an error will just propagage that to the return value of the function.
Maybe for extra sugar something like errOr<value> | valueToUseIfError. This makes the code nice and thight, mean that I don't have to declare variables to give them one value to pass into the arguments of the next function and still perserve all the nice properties of Go.
Also a nice cross gui library would be nice, but that is a lot harder. Still 20 years on the best cross gui library that compiles once and runs anywhere is Java...
- kbd 5y ago> Now you can focus on if err return err instead. Yes that is indeed the next most-frustrating thing about Go! In the last Go language survey (https://go.dev/blog/survey2020-results https://go.dev/blog/survey2020-results), about 90% of people wanted generics and 60% of people want better error handling. So, one down, one to go. Modern languages like Zig and Rust show how you can do "errors as values" way better. Zig has error returns and stack traces built in, there's no reason Go has to be so impoverished here.