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

.NET (OK, C#) finally gets union types

andrewlock.net

Post reply on HN
Print view View original

101–110 of 300 posts

Re: .NET (OK, C#) finally gets union types

#101

Post by itishappy »

Quarrelsome wrote: post #45
adjejmxbdjdn wrote: post #39

Earlier quoted context omitted.

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,…

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.

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-gui...

Re: .NET (OK, C#) finally gets union types

#102

Post by skybrian »

fwip wrote: post #93
skybrian wrote: post #54

Earlier quoted context omitted.

Being first isn't necessarily good if you get it wrong, though. Laziness by default and Hindley-Milner type inference seem like mistakes that simply aren't going to get cleaned up. Other languages make their own mistakes too.

What's wrong with Hindley-Milner?

Leaving out types in public API's makes type errors hard to understand. Types should be declared in the API and bidirectional type inference used in the implementation.

https://jimmyhmiller.com/easiest-way-to-build-type-checker

Re: .NET (OK, C#) finally gets union types

#104

Post by zamalek »

bartwe wrote: post #97

As a big user and fan of c# but this is a miss, as it always boxes value types.

When I cared about C# (which is no longer the case), I was lightly involved in the discussion for this and sibling features - mostly theorycrafting exactly your ask: the JIT team very succinctly expressed extreme disinterest in adding support of any kind.

The C# compiler could do it to a degree, but there would be too many caveats to make it actually useful. Unless the JIT team has a change of heart, you're probably never going to see this.

Re: .NET (OK, C#) finally gets union types

#105

Post by frutiger »

caioricciuti wrote: post #103

About time. TypeScript and Rust proved how much cleaner code gets when you can model "this OR that" at the type level. The real test will be whether library authors start using them in public APIs or if they stay a curiosity.

Standard ML proved this 50 years ago.

Re: .NET (OK, C#) finally gets union types

#106

Post by hirvi74 »

glimshe wrote: post #31

I love C# and in every iteration we're getting more and more features to get C-like performance in a lot of scenarios. C# does it really well because if your problem isn't performance/memory-constrained, you can ignore these features and fallback on the language's natural ease of use.

I daylight as a .NET dev professionally. I completely agree with what you have wrote, but I do not think C# is particularly unique in that regard. I would say many common compiled languages are on the same path, e.g., Swift, Java, Kotlin, etc.. As time progresses, I am finding it harder to justify using C# for a greenfield project.

Re: .NET (OK, C#) finally gets union types

#107

Post by jen20 »

correct_horse wrote: post #29
munchler wrote: post #2

F# leads the way and C# slowly catches up, as always. Yet for some reason, C# still gets all the mindshare.

Haskell, OCaml, Erlang lead the way and Rust, Zig and Go get all the mindshare. I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.

The idea that Erlang is experimental is pretty amusing- it’s one of the most stable platforms there is.

Re: .NET (OK, C#) finally gets union types

#108

Post by kensai »

glimshe wrote: post #31

I love C# and in every iteration we're getting more and more features to get C-like performance in a lot of scenarios. C# does it really well because if your problem isn't performance/memory-constrained, you can ignore these features and fallback on the language's natural ease of use.

Do you think by now C# has left Java behind in features and performance?

Re: .NET (OK, C#) finally gets union types

#109

Post by za3faran »

hirvi74 wrote: post #106
glimshe wrote: post #31

I love C# and in every iteration we're getting more and more features to get C-like performance in a lot of scenarios. C# does it really well because if your problem isn't performance/memory-constrained, you can ignore these features and fallback on the language's natural ease of use.

I daylight as a .NET dev professionally. I completely agree with what you have wrote, but I do not think C# is particularly unique in that regard. I would say many common compiled languages are on the same path, e.g., Swift, Java, Kotlin, etc.. As time progresses, I am finding it harder to justify using C# for a greenfield project.

> As time progresses, I am finding it harder to justify using C# for a greenfield project.

Are you able to elaborate why? Just curious.

Re: .NET (OK, C#) finally gets union types

#110

Post by troad »

nesarkvechnep wrote: post #24
jzebedee wrote: post #14

Earlier quoted context omitted.

C# is strongly-typed, not stringly-typed. The point of the union is to list possible outcomes as defined through their respective types. The idiomatic way to do this would be to parse, don't validate [1] each string into a relevant type with a record or record struct. If you just wanted to return two results of the same type, you'd wrap them in a named tuple or a record that represented the actual meaning. [1] https:…

I guess C# is more strongly-typed than Haskell then... /s

String literal typing appears to be a common feature of type systems bolted onto dynamic languages:

    # Python
    MyStringBool = Literal("Yes") | Literal("No")

    // TypeScript
    type MyStringBool = "Yes" | "No"
I assume it exists to compensate for the previous lack of typing, and consequent likelihood of ersatz typing via strings.

It would seem pretty unnecessary in Haskell, where you can just define whatever types you want without involving strings at all:

    data MyBool = Yes | No
Of course you'd need a trivial parser, though this is probably a good idea for any string type:

    parseMyBool :: String -> MyBool 
    parseMyBool "Yes" = Yes
    parseMyBool "No" = No
    parseMyBool _ = error "..."
Interestingly, dynamic languages which make use of symbols (Ruby, Elixir, Common Lisp) probably fall closer to Haskell than Python or TS. Elixir example:

    @type my_bool() :: :yes | :no

    @spec parse_my_bool(String.t()) :: my_bool()
    def parse_my_bool("Yes"), do: :yes
    def parse_my_bool("No"), do: :no
    def parse_my_bool(_), do: throw("...")
Where :yes and :no are memory-efficient symbols, not strings.
Post reply on HN