undefined | Better HN

0 pointssnovv_crash4y ago0 comments

Interfaces would work fine here as well.

0 comments

As someone who is greatly in favor of composition over inheritance, I don't agree - or at least my experiences don't point that way.

Both Rust and Go have had medium sized warts and/or boilerplate around errors, especially if you need control flow to depend on the error. In Python I've never felt that way.

Not sure I can put my finger on it, because any trivial example would be fine in either paradigm. I think it has to do with the forced/unnatural upfront decision "is this error a type or an interface" that may change later on, as a type might need to be refactored to an interface. There's probably one or two other reasons I can't think of right now.

Zababa4y ago

Standard ML and OCaml have both sum types (like in Rust) and exceptions. I feel like both have their value, and both are important. A nice thing is that you can match on exceptions:

    match number_of_lines_of_a_file() with
    | x -> x
    [ exception File_not_found -> 0

This makes it really easy to create alternative versions of functions, using exceptions or option types:

    match number_of_lines_of_a_file_opt() with
    | Some x -> x
    | None -> raise File_not_found

    match number_of_lines_of_a_file_exc() with
    | x -> Some x
    | exception File_not_found -> None

jatone4y ago

flow control is always impacted by errors. rust and go just don't hide that on you with a giant 'go to random location in the stack' capability.

j / k navigate · click thread line to collapse