Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monads in C# (Part 2): Result

alexyorke.github.io

Post reply on HN
Print view View original

1–10 of 75 posts

Re: Monads in C# (Part 2): Result

#3

Post by polygot »

pimbrouwers wrote: post #2

I've been playing around with some of the "standard/common monads in C# for a while now, in OSS ( https://github.com/pimbrouwers/Danom ) and at work. It's awesome. I can't imagine working without them anymore.

Thanks for sharing! Appreciate the OSS work. Is it ok if I reference that repo in my article?

Re: Monads in C# (Part 2): Result

#4

Post by pimbrouwers »

polygot wrote: post #3
pimbrouwers wrote: post #2

I've been playing around with some of the "standard/common monads in C# for a while now, in OSS ( https://github.com/pimbrouwers/Danom ) and at work. It's awesome. I can't imagine working without them anymore.

Thanks for sharing! Appreciate the OSS work. Is it ok if I reference that repo in my article?

100%! I would be thrilled! Thank you very much.

Re: Monads in C# (Part 2): Result

#5

Post by galkk »

Idk, to me that constant

     Result
looks extremely ugly and unergonomic, even just to type.

I understand that this is complicated topic and there were a lot of strong opinions even inside of Google about it, but god, I miss absl::StatusOr and ASSIGN_OR_RETURN. Yes, it won’t work without preprocessor magic (and that’s why this article goes through heavy functional stuff, otherwise it just cannot work in language like C#), but it’s so easy and natural to use in base case, it feels like cheating.

Re: Monads in C# (Part 2): Result

#6

Post by simonask »

galkk wrote: post #5

Idk, to me that constant Result looks extremely ugly and unergonomic, even just to type. I understand that this is complicated topic and there were a lot of strong opinions even inside of Google about it, but god, I miss absl::StatusOr and ASSIGN_OR_RETURN. Yes, it won’t work without preprocessor magic (and that’s why this article goes through heavy functional stuff, otherwise it just cannot work in language like C#)…

I think in C# the way to solve this is to have two separate types, `Ok` and `Err`, and provide implicit conversions for both to `Result`.

The static method approach showcased in the article is really long-winded.

Re: Monads in C# (Part 2): Result

#7

Post by oaiey »

simonask wrote: post #6
galkk wrote: post #5

Idk, to me that constant Result looks extremely ugly and unergonomic, even just to type. I understand that this is complicated topic and there were a lot of strong opinions even inside of Google about it, but god, I miss absl::StatusOr and ASSIGN_OR_RETURN. Yes, it won’t work without preprocessor magic (and that’s why this article goes through heavy functional stuff, otherwise it just cannot work in language like C#)…

I think in C# the way to solve this is to have two separate types, `Ok ` and `Err `, and provide implicit conversions for both to `Result `. The static method approach showcased in the article is really long-winded.

Yes. Or even simpler, static imported functions. That is similar to how ASP.NET Core handles HTTP feedback. A very common and understood concept.

With implicit type parameters this boils down to Ok(4) or BadRequest()

Re: Monads in C# (Part 2): Result

#8

Post by 89netraM »

A friend and I wrote our master thesis on how to ergonomically fit monads into imperative programming languages [^1], taking inspiration from Haskells do-notation to get away from the method chaining. It's more on the theoretical side, but we did write a small implementation in C# [^2] (we use the exclamation mark as bind). We really could have used som better types though, this post seems have found a better direction.

[^1]: https://odr.chalmers.se/items/91bf8c4b-93dd-43ca-8ac2-8b0d2c...

[^2]: https://github.com/master-of-monads/monads-cs/blob/89netram/...

Re: Monads in C# (Part 2): Result

#9

Post by oaiey »

pimbrouwers wrote: post #2

I've been playing around with some of the "standard/common monads in C# for a while now, in OSS ( https://github.com/pimbrouwers/Danom ) and at work. It's awesome. I can't imagine working without them anymore.

Do you have a comparison to other libraries like https://github.com/louthy/language-ext

Yours looks a lot more idiomatic to C# (hence acceptable for a mixed code base) but the above linked more "systematic". Not that I have used any or have any competence.

Re: Monads in C# (Part 2): Result

#10

Post by xnorswap »

I really dislike this pattern:

    try
    {
        id = int.Parse(inputId);
    }
    catch (Exception ex) when (ex is FormatException or OverflowException)
    {
        throw new InvalidOperationException("DeactivateUser failed at: parse id", ex);
    }
Where all you're doing when you catch an exception is throwing it in a more generic way. You could just let the FormatException or OverflowException bubble up, so the parent can handle those differently if needed. If you want to hide that implementation detail, then you should still consider throwing more specific types of exception for different errors. Just throwing InvalidOperationException for everything feels lazy.

You've gone out your way to destroy the information being passed up when using exceptions, to demonstrate the value in having error types.

It would be far more conventional to also provide a `TryDeactivateUser` function that cannot throw an exception. The article does note this, but hand-waves it away.

I'm not against Result types, but I don't find this article entirely convincing.

Post reply on HN