anyBlue := false
for _, c in range col {
ready, err := c.IsReady()
if err != nil {
return nil, fmt.Errorf("isReady failed: %v", err)
}
if !ready {
continue
}
x, err := ConvertToX(c)
if err != nil {
return nil, fmt.Errorf("convertToX failed: %v", err)
}
color, err := x.GetColor()
if err != nil {
return nil, fmt.Errorf("getColor failed: %v", err)
}
if color == BLUE {
anyBlue = true
break
}
}
which badly obscures what’s going on but demands no cleverness at all (except that some might forget the “break” and still get the right answer). col.filter(c => Try(c.isReady).getOrElse(false))
.map(convertToX).any(_.color == BLUE)Rust is a good example of functional lang without exceptions (panics aside).
In Rust there are many cases where I could use FP but opt not to because it can make error handling more awkward. For example to collect the result of a map operation to a vector, and if there is an error along the way you want to abort the entire operation. In functional this means collecting to a Result<Vec<T>>. Not sure if I'm just tired today but I can think of how to do it in 5 seconds with a loop. I suspect functional solution would be uglier.
https://doc.rust-lang.org/stable/rust-by-example/error/iter_...
This is easy to miss if you are mainly reading reference docs. I probably read the getting started guide at a time before there was a section on it.
My other comment in this thread comes to mind https://news.ycombinator.com/item?id=24300057
I don’t personally really agree with what you’ve said, but that’s fine. Different people perceive things differently.
Robustness. Speed. Simplicity. Easiness. Conciseness. Writability. Readability.
Hard to tell which are independent vs correlated, let alone how they factor into productivity. And productivity is also a function of the kind of problem you work on.