[ngruhn]

Same experience here. C# might have superior tooling, performance, whatever but the OOP baggage is too heavy. In theory you can write something else than a giant over-complicated, over-abstracted pile of OOP nonsense in C#, but every team I've seen has.

[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 ?

[overfeed]

> In theory you can write something else than a giant over-complicated, over-abstracted pile of OOP nonsense in C#, but every team I've seen has.

C# syntax is fine, but has a rotten[1] culture/conventions. I suppose it makes sense that Microsoft's "Java-killer" became enterprise-y, with the same over-engineered indirections.

1. IMO - I find it very unpleasant and never allowed myself to Internalize the IConventions out of spite. YMMV.

[hvb2]

Just to keep it relevant and off topic. Typescript is moving to go because you just cannot get performance out of javascript because of its design.

As he says in the video about perf "you cannot leave 10x on the table".

[cxr]

> Typescript is moving to go because you just cannot get performance out of javascript because of its design.

That's not an accurate summary. An accurate summary is that:

- They can't get the performance they want out of V8

- They're are moving to Go because its design is similar enough to JS that they can do a line-by-line port

These aren't similar claims (or mere quibbling) compared to what you wrote. They're very nearly exact opposites.