W4w4rh4wk5·Dec 17, 2021
I'd say, take a look at error handling. In Haskell you can accomplish a lot by just using `Maybe` and `Either` along with the functions related to them, provided by the standard library. Haskell's pattern matching feature makes it even more straight forward to handle these types.
A lot of this translates to Rust, as Haskell influenced the language design of Rust. In Rust you have `std::option::Option` and `std::result::Result` which relate closely to `Maybe` and `Either`, respectively. Also pattern matching is available in Rust.
When you then look at other (imperative) languages like Go, C, and C++, error handling becomes a bit more cumbersome IMHO. I am not talking about explicit or implicit error handling. It's more about urging the programming to check for and handle errors, and also giving them the necessary tools to do that efficient
Read the rest
ly.
In Go, you have lots of `if err != nil { return err }`, which is cumbersome to write (luckily we have snippets) and _clutters_ the code. Yes, it is explicit and easy to read, but I don't think error handling should make up 4/5 of the lines of your algorithm.
The same applies to C, more or less, as functions typically tell you about success or failure via their return value. Like `err` in Go.
In C++ we have `std::optional` which is handy, but C++ lacks a lot of functional features and convenient syntax to take full advantage of it. No straight forward pattern matching here. There is `std::variant` to create sum types, but I've only seen that in use occasionally. There is also `std::expected` on the horizon, which is similar to `Either` / `std::result::Result`, but adoption will take ages.
C++, being a complicated language, makes it very difficult to just come up with your own wrapper classes that _just work_. See https://github.com/oktal/result/blob/master/result.h for example.