I've had the misfortune of working on a C# code base that uses this pattern for many years.

I've also used it with F#, where it feels natural - because the language supports discriminated unions and has operators for binding, mapping etc. Without that, it feels like swimming against the tide.

Code has a greater cognitive overhead when reading it for the first time. And there is always a big over head for new starters needing to understand the code.

It feels idiomatic in F#. It feels crow-barred in with C#

▲

DimmieMan 2 days ago | parent | next [-]

F# also has substantially better type inference so you don't need to write the types out everywhere, type aliases are first class too so you can easily write out some helper types for readability.

You can pipe a monadic type through various functions writing little to no type declarations, doing it nicely is F#'s bread and butter.

In C# version n+1 when the language is supposedly getting discriminated unions for real this time I still don't see them being used for monadic patterns like F# because they're going to remain a menace to compose.

▲

douglasisshiny 2 days ago | parent | prev | next [-]

I felt the same way with fp-ts then effect in typescript. Pretty cool libraries and I learned a lot about FP while trying them out for a couple of years, but a lot of ceremony and noise due to them (especially effect) almost being a new language on top of typescript.

Recently got the opportunity to try out elixir at my job and I'm liking it thus far, although it is an adjustment. That static typing and type inference are being added to the language right now is helpful.

	▲	gr4vityWall 2 days ago \| parent [-]
		I had a similar impression with using those constructs on TypeScript. IMO it's hard to justify creating Option<T>/Result<T,E> wrappers when T\|null and T\|E will work well enough for the majority of use cases. effect specifically feels like a different programming language altogether. And maybe going that path and compiling down to TS/JS could've been a better path for them. I'm not on the ecosystem though, so it's an uninformed thought.

▲

bonesss 2 days ago | parent | prev [-]

Monadic binding and other functional mainstays in C# mostly fall into the same uncanny valley. Like non-exhaustive pattern matching, we get some nice sugar, but it’s not the same, and not a proper substitute for what we’re trying to do.

F# ~~ripped off~~ is deeply inspired by OCaml, with a very practical impact on its standard library: there are facilities available for all the functional programming jazz one hasn’t though about or bumped into. In active patterns, pattern matching, recursive list comprehensions, applicatives, or computation expressions when you bump into the corners of the language you find a deep, mature, OCaml core that nerds much smarter and more talented have refined for decades. The language was built around those facilities.

Bumping into the edges of the partial features in C# is a pretty common experience for me, resulting in choices about kludges to support a superficial syntax, raising concerns about goldbricking.

It feels crowbarred because it was.

“Railway oriented programming” passes over well as a concept, but it’s an easier sale when you see its use resulting in smaller, simpler, easier functions