3 ms·

I love discriminated unions. The problem with C# is that it’s so overloaded with features. If you come from one codebase to another codebase by a different te

I love discriminated unions. The problem with C# is that it’s so overloaded with features. If you come from one codebase to another codebase by a different team it’s close to learning a completely new language, but worse, there is no documentation I can find that will teach me only about that language. Throw in all the versioning issues and the fact that .Net shops aren’t great about updating to the latest versions, especially because versions, although technologically separated from Visual Studio, are still culturally tied to it, and trying to break that coupling causes all kinds of weird challenges to solve. Then stuff like extensions means your private codebase or a 3rd party lib may have added native looking functionality that’s not part of the language but looks like it is. Finally, keywords and operators are terribly overloaded in C# at this point, where a keyword can have completely different meanings based on what it’s surrounded by. LLMs are a huge help here, since you can point to a line of code and ask them to figure it out, but it still makes the process of navigating a C# codebase extremely challenging. So I can see why someone may be unhappy to see yet another feature. It’s not just this one feature. It’s the 100s of other features that are hard to even identify.

paddim8 5mo ago
I am all for minimalism but "If you come from one codebase to another codebase by a different team it’s close to learning a completely new language" I really don't agree. It's not that big. Just sounds like a skill issue
- adjejmxbdjdn 5mo ago
  Sure. Maybe it was a skill Issue. I switched between dozens of similar codebases over a period of 3-4 years (pre AI) when I was consulting and did multiple projects in multiple languages (well, only 1 in rust). In my experience switching between the C# projects was always the worst. The codebase semantics diverged in ways I simply didn’t see in the Java/C++ codebases.
  - metaltyphoon 5mo ago
    > C++ codebases Now this one sounds almost unbelievable :). I’ve yet to see 3 or more C++ codebases using the same language feature set.
Quarrelsome 5mo ago
none of that applies to my position. I have an appreciation for almost all of C# and am comfortable in the framework. I just want to know what situations would be better suited to using them than traditional approaches. I get there's an .Either pattern when chaining function calls so you don't have to do weird typing to return errors, but I'm using exceptions for that anyway, so the return type isn't an issue.
- itishappy 5mo ago
  The Result pattern can be a lot more ergonomic than exceptions. Microsoft C# guidelines recommend try-parse (which is just the Result pattern, albeit somewhat cludgy with no unions) over exceptions. https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions-and-performance https://learn.microsoft.com/en-us/dotnet/standard/design-gui...
  - Quarrelsome 5mo ago
    the result pattern doesn't force you to handle the exception though. You can just discard the result.
    - itishappy 5mo ago
      A function that returns `Result<T,E>` is not a `T` and cannot be implicitly converted to one. If you want to use that `T`, the only way is writing code that drops or handles the `E`. If you don't, your program does not compile. Compare this to exceptions, where the type is just `T` and can be used without further ceremony. You can discard the error by forgetting a handler. Now you have a program that occasionally crashes. Follow-up: Are there async exceptions? A `Result` is just data that can be awaited. How would that work with exceptions?

paddim8 5mo ago

I am all for minimalism but "If you come from one codebase to another codebase by a different team it’s close to learning a completely new language" I really don't agree. It's not that big. Just sounds like a skill issue

adjejmxbdjdn 5mo ago
Sure. Maybe it was a skill Issue. I switched between dozens of similar codebases over a period of 3-4 years (pre AI) when I was consulting and did multiple projects in multiple languages (well, only 1 in rust). In my experience switching between the C# projects was always the worst. The codebase semantics diverged in ways I simply didn’t see in the Java/C++ codebases.
- metaltyphoon 5mo ago
  > C++ codebases Now this one sounds almost unbelievable :). I’ve yet to see 3 or more C++ codebases using the same language feature set.

Quarrelsome 5mo ago

none of that applies to my position. I have an appreciation for almost all of C# and am comfortable in the framework. I just want to know what situations would be better suited to using them than traditional approaches. I get there's an .Either pattern when chaining function calls so you don't have to do weird typing to return errors, but I'm using exceptions for that anyway, so the return type isn't an issue.

itishappy 5mo ago
The Result pattern can be a lot more ergonomic than exceptions. Microsoft C# guidelines recommend try-parse (which is just the Result pattern, albeit somewhat cludgy with no unions) over exceptions. https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions-and-performance https://learn.microsoft.com/en-us/dotnet/standard/design-gui...
- Quarrelsome 5mo ago
  the result pattern doesn't force you to handle the exception though. You can just discard the result.
  - itishappy 5mo ago
    A function that returns `Result<T,E>` is not a `T` and cannot be implicitly converted to one. If you want to use that `T`, the only way is writing code that drops or handles the `E`. If you don't, your program does not compile. Compare this to exceptions, where the type is just `T` and can be used without further ceremony. You can discard the error by forgetting a handler. Now you have a program that occasionally crashes. Follow-up: Are there async exceptions? A `Result` is just data that can be awaited. How would that work with exceptions?