News for hackers. Stuff that matters.
Re:Constraints in Go by indulona on Sunday November 17, 2024 @01:34PM (#42165914)
> I see even experienced Go programmers constantly wasting time writing unreadable boilerplate

if it is unreadable, in Go, probably the most readable language used today, i would question the aforementioned experience.

Re:Constraints in Go by DangitBobby on Sunday November 17, 2024 @02:47PM (#42166542)
What you're doing right now is called "coping".
Re:Constraints in Go by LinXitoW on Sunday November 17, 2024 @04:51PM (#42167645)
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.

Re:Constraints in Go by kweingar on Sunday November 17, 2024 @06:00PM (#42168136)
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.

Re:Constraints in Go by the_gipsy on Sunday November 17, 2024 @07:58PM (#42168746)
Exceptions have been a mistake, the alternative are Result types, a concept which predates go.
Re:Constraints in Go by int_19h on Tuesday November 19, 2024 @08:29PM (#42189956)
Go doesn't force you to either handle or propagate the error.

And the alternatives are not exceptions, of course, but ADTs.