[TheDong]

> A for loop is more readable than the lambda soup.

Let's assume you have a slice of strings you want to uppercase. Which of the following is more readable?

    uppercased := slices.Map(inputSlice, strings.ToUpper)
    // or
    uppercased := make([]string, 0, len(inputSlice))
    for _, s := range inputSlice {
      uppercased = append(uppercased, strings.ToUpper(s))
    }

Let's say you want to parse a bunch of user-given inputs into durations, surely the following is more readable?

    parsed, err := slices.MapErr(inputstrings, time.ParseDuration)

I think map functions lead to cleaner code when used like the above, and a lot of for loops end up falling into those patterns.

[wlamartin]

I think in a language designed around FP ergonomics and expectations there's a lot to like about it.

In your second example, as a retrofit, I find myself asking "when does MapErr stop consuming the input list?", "which error gets returned if multiple errors could be returned?", "is it a errors.Joim situation", "if there are multiple errors how do I map them to the failed elements in parsed", "if I did want each parse to have either success or fail (think Result type) how would I represent this generically in a language that favours multiple return types"

There's a lot going on with that example that a for loop makes explicit and flexible for other choices.