My team just recently made the switch from a TS backend to a C# backend for net new work. When we made this switch, we also introduced `ErrorOr`[0] which is a monadic result type.

I would not have imagined this to be controversial nor difficult, but it turns out that developers really prefer and understand exceptions. That's because for a backend CRUD API, it's really easy to just throw and catch at a global HTTP pipeline exception filter and for 95% of cases, this is OK and good enough; you're not really going to be able to handle it nor is it worth it to to handle it.

We'll stick with ErrorOr, but developers aren't using it as monad and simply unwrapping the value and the error because, as it turns out, most devs just have a preference/greater familiarity with imperative try-catch handling of errors and practically, in an HTTP backend, there's nothing wrong in most cases with just having a global exception filter do the heavy lifting unless the code path has a clear recovery path.

    > I don't think you should never use OOP or abstractions. I don't think there is a golden rule for when you should use either.

I do think there is a "silver rule": OOP when you need structural scaffolding, functional when you have "small contracts" over big ones. An interface or abstract class is a "big contract" that means to understand how to use it, you often have to understand a larger surface area. A function signature is still a contract, but a micro-contract.

Depending on what you're building, having structural scaffolding and "big contracts" makes more sense than having lots of micro-contracts (functions). Case in point: REST web APIs make a lot more sense with structural scaffolding. If you write it without structural scaffolding of OOP, it ends up with a lot of repetition and even worse opaqueness with functions wrapping other functions.

The silver rule for OOP vs FP for me: OOP for structural templating for otherwise repetitive code and "big contracts"; FP for "small contracts" and algorithmically complex code. I encourage devs on the team to write both styles depending on what they are building and the nature of complexity in their code. I think this is also why TS and C# are a sweet spot, IMO, because they straddle both OOP and have just enough FP when needed.

[0] https://github.com/amantinband/error-or

    > Usually you combine this with pattern matching and other functional features and the whole thing makes it convenient in the end. That part is missing in C#

    string foo = result.MatchFirst(
        value => value,
        firstError => firstError.Description);

    ErrorOr<string> foo = result
        .Then(val => val * 2)
        .Then(val => $"The result is {val}");

    ErrorOr<string> foo = await result
        .ThenDoAsync(val => Task.Delay(val))
        .ThenDo(val => Console.WriteLine($"Finsihed waiting {val} seconds."))
        .ThenDoAsync(val => Task.FromResult(val * 2))
        .ThenDo(val => $"The result is {val}");

    var holidays = new DateTime[] {...};
    var output = new Appointment(
        DayOfWeek.Friday, 
        new DateTime(2021, 09, 10, 22, 15, 0), 
        false
    ) switch
    {
        { SocialRate: true } => 5,
        { Day: DayOfWeek.Sunday } => 25,
        Appointment a when holidays.Contains(a.Time) => 25,
        { Day: DayOfWeek.Saturday } => 20,
        { Day: DayOfWeek.Friday, Time.Hour: > 12 } => 20,
        { Time.Hour: < 8 or >= 18 } => 15,
        _ => 10,
    };

    #!/usr/local/share/dotnet/dotnet run
    #:package ErrorOr@2.0.1
    using ErrorOr;

    var computeRiskFactor = ErrorOr<decimal> ()
        => 0.5m; // Just an example

    var applyAdjustments = ErrorOr<decimal> (decimal baseRiskFactor)
        => baseRiskFactor + 0.1m; // Just an example

    var approvalDecision = computeRiskFactor()
        .Then(applyAdjustments)
        .Match(
            riskFactor => riskFactor switch {
                < 0.5m => "Approved",
                < 0.75m and >= 0.5m => "Approved with Conditions",
                >= 0.75m and < 0.9m => "Manual Review",
                _ => "Declined"
            },
            errors => "Error computing risk factor"
        );

    Console.WriteLine($"Loan application: {approvalDecision}");

    let compute_risk_factor () = 0.5

    let apply_adjustments base_risk_factor = base_risk_factor +. 0.1

    let approval_decision =
      let risk_factor = compute_risk_factor () |> apply_adjustments in
      match risk_factor with
      | r when r < 0.5 -> "Approved"
      | r when r < 0.75 -> "Approved with Conditions"
      | r when r < 0.9 -> "Manual Review"
      | _ -> "Declined"

    let () =
      print_endline approval_decision