Re:Constraints in Go
by DangitBobby on Sunday November 17, 2024 @02:47PM
(#42166542)
What you're doing right now is called "coping".
I don't think a language where for every 1 line of functionality, you need 3 lines of error handling boilerplate gets to be called readable.
Heck, Go went out of it's way to "subvert expectations" more than the last season of Game of Thrones.
99% of decent C-ish languages either do "String thing" or "thing: String", but Go is so fancy and quirky, it does "thing String" for no freaking reason. Don't get me started on the nightmare that is map types.
I like Go's error handling. The reader knows exactly which lines of code can encounter an error, and exactly how the error is handled.
I find that exception-based code is much harder to read. The happy path is clearer, but exceptional code paths are often completely obscured. It's harder to reason about what state the program is in when the exception is handled.
Exceptions have been a mistake, the alternative are Result types, a concept which predates go.
if it is unreadable, in Go, probably the most readable language used today, i would question the aforementioned experience.