[CharlieDigital]

You can write very functional C#. Our codebase is a mix with some aspects being functional (`ErrorOr`[0] being a big part of it as well as `OneOf`[1]) and OOP. Our core, common services all return `ErrorOr` to allow fluent call chaining at the top of the stack (controllers).

Modern C# features like `switch` expressions[2] (not `switch-case`) and pattern matching mean that it is possible to write very terse, expressive code. Extension members and methods[3] go a long way as well by making the builder pattern easier to implement.

Overall, it's up to the team to make use of the tools provided by the C# team. You can write C# in a very OOP heavy way (as is possible with TS in the case of Nest.js); you can also write in in a very functional way given many of the functional features adopted from F# over the years. It's up to the team.

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

[1] https://github.com/mcintyre321/OneOf

[2] https://timdeschryver.dev/blog/pattern-matching-examples-in-...

[3] https://typescript-is-like-csharp.chrlschn.dev/pages/interme...

[rafaelmn]

That's a perfect example of making it overcomplicated, just in the FP direction.

C# uses exceptions for error handling. It has it's own control flow primitives. C# developers know how to work with it, everything else uses it. Why would I want to pull in a randos GH DSL and types to pretend I'm writing F# when I can just use F# that has first class support for this ?

[CharlieDigital]

C# is already very functional when it comes to Linq. In real world use, this just feels like extending in the same directionality while still preserving familiarity. Whereas F# does feel like an entirely different language.

Learning C# when you know TS is like learning Portuguese when you know Spanish.