7 ms·

Having learned some Rust in the last few years (coming from python) I now want sum types everywhere. Anything less is a disappointment.

alkonaut 4y ago
The C# of my day job often feels like banging rocks together with its c-style enums and lack of sum types. But there is always an article about go that makes you appreciate what you do have.
- throwaway858 4y ago
  C# has sum types
  - masklinn 4y ago
    C# does not have sum types. It has "enumeration types" but their behaviour is exactly that of C's, with various additional conveniences but critically (and unlike Java for instance) no more type-safety.
  - alkonaut 4y ago
    Not without squinting really hard and making some OO monstrosity with internal impls of an outer abstract type it doesn’t. And that’s not really language support it’s banging your rocks together really hard trying to bend it into being ML.
- munchler 4y ago
  > The C# of my day job often feels like banging rocks together with its c-style enums and lack of sum types. Hah, I agree. I switched over to F# and never looked back. It plays nicely enough with C# that my colleagues couldn't stop me (but didn't join me either). > But there is always an article about go that makes you appreciate what you do have. Yes. Go seems like a time machine back to about 1985.
  - OliverGilan 4y ago
    Starting a new project and trying to decide between Go and F# of all things. Go seems fast and very widely used which means resources and help is widely available and it’ll be easier to find contributors. Meanwhile coming from the C# world at my job I really like the syntax of F# from what I’ve seen so far. The type system seems incredibly expressive in a way Go’s isn’t, access to C# libraries means I can do pretty much anything I’ll need to, and I enjoy FP paradigms even though I’m not looking for full FP (I generally like loops and escape hatches from FP if I need to do something specific). What’s your experience with F#? I’m worried about support and finding other people familiar with the language, not a huge fan of nuget, and I prefer to use VSCode but C# has been impossible to program in VSCode imo.
    - munchler 4y ago
      I’ve had a great experience with F#. It’s now my preferred language in almost all cases, and it’s plenty fast enough for the vast majority of applications. I use Visual Studio and the UX is excellent. (A lot of F# developers use Paket instead of Nuget.) MS seems committed to F# as at least a source of future C# language enhancement ideas (although C# will never fully catch up). There’s also a vibrant F# community on Stack Overflow, Reddit, etc. I never have trouble getting help if I need it.
  - pjmlp 4y ago
    Unfortunely switching to F# also means throwing away what actually makes .NET relevant in terms of end to end developer experience, and the Redmond overloads don't seem to care that much to change that, as the C in CLR seems to refer to C# and no longer to Common, in the ways VS and VS4Mac are designed.
- mastax 4y ago
  I do like the way they added type-switch and switch expressions to get some of the sum-type ergonomics out of the existing object oriented type system.
ebingdom 4y ago
I'm pleasantly surprised by these comments. A few years ago people were so entrenched in their object-oriented upbringing that sum types were considered "weird functional stuff" and thus unsuitable for "real" work (what a shame to have that attitude). People are finally coming around to good ideas from other paradigms. Rust's popularity is certainly helping that, though I wish they hadn't repurposed the existing word "enum" to serve as a new synonym for a concept with an existing name ("algebraic data types").
- nicoburns 4y ago
  “algebraic data types” includes product types (aka structs, classes and tuples) as well as sum types (aka enums and probably other names)
  - ebingdom 4y ago
    Rust's "enums" also include products. Each case can have multiple arguments. That's a sum of products. "Algebraic data type" is the proper term for what Rust calls "enums", since they encompass both sums and products. (It is also true that structs are products. But that isn't relevant.)
    - kibwen 4y ago
      Rust's syntax makes plenty of concessions to familiarity, as a way of making up for the much more important and irreducible unfamiliarity that it brings to the table (e.g. ownership). Originally Rust used the keyword `tag` here (for "tagged unions"), then vacillated between `enum` and `union` for years and years prior to 1.0.
- morelisp 4y ago
  I also like sum types, but I have intense whiplash from "this language is AN ABSTRACT MESS that needs a PhD in type theory to use productively" five years ago, to today's "this language is COMPLETELY USELESS because it doesn't have them".
  - 4y ago
Splizard 4y ago
Since 1.18 was released it's now trivial to implement compile-time (safe) 'sum types' in Go. They're fully supported. It's about 300loc to implement and then sum types can be defined declaratively just like any other type (and without any boilerplate). There hasn't been any fanfare about this capability because it doesn't require any special syntax or new keywords. Just know that the suggestion that "Go 1.18+ doesn't support sum types and/or enums", is very wrong.
- Strum355 4y ago
  Not going to link it anywhere? I have some doubts given how widely it wouldve been shared if the claim is actually true, and your not linking of an example kinda just furthers that
  - Splizard 4y ago
    Sum types: https://go.dev/play/p/R7Bhy2LDmde https://go.dev/play/p/R7Bhy2LDmde Enums: https://go.dev/play/p/MnbmE0B3sSE https://go.dev/play/p/MnbmE0B3sSE Here you go.
    - esprehn 4y ago
      That code appears to be using reflection to build up runtime tables? https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba935765a4aefa514/sum/sum.go#L88 https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba... https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba935765a4aefa514/sum/sum.go#L177 https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba... That's a big difference from other languages where this is all handled at compile time.
    - suremarc 4y ago
      This is cool, but it doesn't seem like Switch is implemented for Int, and the use of runtime reflection limits the contexts in which this implementation can be used, compared to a language construct that gets compiled into efficient machine code. I wouldn't want this to be endemic in my codebase or my dependencies.
Tozen 4y ago
One of the "offshoot" or inspired by languages of Golang, is Vlang (https://vlang.io/ https://vlang.io/), and the other is Odin. Vlang has both sum types and real enums. It had those, including generics, for quite a while.
- tandr 4y ago
  From a first glance, Odin looks like a nice language to use! Looks like they have fixed ocd-causing idiosyncrasies of Go - "for value, index" and not the other way around, "defer" belongs to surrounding scope, and not the whole function. Thank you!
  - Tozen 4y ago
    Your welcome. I keep my eye on both Odin and Vlang. And if a person has experience with Go, they offer some different features and freedoms that might have been wanted, but couldn't get. Additionally, it's not too difficult to switch among the languages as well, if one is strongly familiar with one of them.
    - tandr 4y ago
      Problem is to switch people around you to use something else. Second company, second fight Java vs Go, and I am loosing again... Makes me wonder if all my efforts to learn something new are for nothing, for no real benefit.
vlunkr 4y ago
Everyone check off "immediately making a Golang conversation about Rust"'on your HN bingo.
- politician 4y ago
  The ‘safe’ keyword in the title is a Siren’s song to certain types of Rustaceans, so it’s not surprising.
  - tialaramex 4y ago
    I was reading this because hey, safer enums. But I agree, Sum types are a must have. Particularly, decryption should be Authenticated, and so the correct return type of a decrypt function is a Sum type, and if you don't have Sum types you can't do that.
- tempest_ 4y ago
  Aw come on there was a whole two hours that this post was about Go before I showed up. You gotta give the people what they want!
- stouset 4y ago
  Are you really surprised or upset to see those types of comments when the article itself is fundamentally about trying to adapt Go to become more Rust-like? Personally I think people can't help but notice the trend of Go users rediscovering bug-by-bug and frustration-by-frustration why Rust was designed the way it is.
  - vlunkr 4y ago
    No, I'm not surprised, that's why it's on the bingo card. They are very different languages, so endlessly comparing them is tiresome.
  - morelisp 4y ago
    > the article itself is about trying to adapt Go to become fundamentally more Rust-like? The article does not even mention Rust. Not every attempt to make something 'safer' is an attempt to make it 'fundamentally more Rust-like'. (And you're also misusing the word "fundamental" - even if we grant this is "Rust-like" this is adapting their code to make their Go programs practically more Rust-like.)

alkonaut 4y ago

The C# of my day job often feels like banging rocks together with its c-style enums and lack of sum types. But there is always an article about go that makes you appreciate what you do have.

throwaway858 4y ago
C# has sum types
- masklinn 4y ago
  C# does not have sum types. It has "enumeration types" but their behaviour is exactly that of C's, with various additional conveniences but critically (and unlike Java for instance) no more type-safety.
- alkonaut 4y ago
  Not without squinting really hard and making some OO monstrosity with internal impls of an outer abstract type it doesn’t. And that’s not really language support it’s banging your rocks together really hard trying to bend it into being ML.
munchler 4y ago
> The C# of my day job often feels like banging rocks together with its c-style enums and lack of sum types. Hah, I agree. I switched over to F# and never looked back. It plays nicely enough with C# that my colleagues couldn't stop me (but didn't join me either). > But there is always an article about go that makes you appreciate what you do have. Yes. Go seems like a time machine back to about 1985.
- OliverGilan 4y ago
  Starting a new project and trying to decide between Go and F# of all things. Go seems fast and very widely used which means resources and help is widely available and it’ll be easier to find contributors. Meanwhile coming from the C# world at my job I really like the syntax of F# from what I’ve seen so far. The type system seems incredibly expressive in a way Go’s isn’t, access to C# libraries means I can do pretty much anything I’ll need to, and I enjoy FP paradigms even though I’m not looking for full FP (I generally like loops and escape hatches from FP if I need to do something specific). What’s your experience with F#? I’m worried about support and finding other people familiar with the language, not a huge fan of nuget, and I prefer to use VSCode but C# has been impossible to program in VSCode imo.
  - munchler 4y ago
    I’ve had a great experience with F#. It’s now my preferred language in almost all cases, and it’s plenty fast enough for the vast majority of applications. I use Visual Studio and the UX is excellent. (A lot of F# developers use Paket instead of Nuget.) MS seems committed to F# as at least a source of future C# language enhancement ideas (although C# will never fully catch up). There’s also a vibrant F# community on Stack Overflow, Reddit, etc. I never have trouble getting help if I need it.
- pjmlp 4y ago
  Unfortunely switching to F# also means throwing away what actually makes .NET relevant in terms of end to end developer experience, and the Redmond overloads don't seem to care that much to change that, as the C in CLR seems to refer to C# and no longer to Common, in the ways VS and VS4Mac are designed.
mastax 4y ago
I do like the way they added type-switch and switch expressions to get some of the sum-type ergonomics out of the existing object oriented type system.

ebingdom 4y ago

I'm pleasantly surprised by these comments. A few years ago people were so entrenched in their object-oriented upbringing that sum types were considered "weird functional stuff" and thus unsuitable for "real" work (what a shame to have that attitude). People are finally coming around to good ideas from other paradigms. Rust's popularity is certainly helping that, though I wish they hadn't repurposed the existing word "enum" to serve as a new synonym for a concept with an existing name ("algebraic data types").

nicoburns 4y ago
“algebraic data types” includes product types (aka structs, classes and tuples) as well as sum types (aka enums and probably other names)
- ebingdom 4y ago
  Rust's "enums" also include products. Each case can have multiple arguments. That's a sum of products. "Algebraic data type" is the proper term for what Rust calls "enums", since they encompass both sums and products. (It is also true that structs are products. But that isn't relevant.)
  - kibwen 4y ago
    Rust's syntax makes plenty of concessions to familiarity, as a way of making up for the much more important and irreducible unfamiliarity that it brings to the table (e.g. ownership). Originally Rust used the keyword `tag` here (for "tagged unions"), then vacillated between `enum` and `union` for years and years prior to 1.0.
morelisp 4y ago
I also like sum types, but I have intense whiplash from "this language is AN ABSTRACT MESS that needs a PhD in type theory to use productively" five years ago, to today's "this language is COMPLETELY USELESS because it doesn't have them".
- 4y ago

Splizard 4y ago

Since 1.18 was released it's now trivial to implement compile-time (safe) 'sum types' in Go. They're fully supported. It's about 300loc to implement and then sum types can be defined declaratively just like any other type (and without any boilerplate). There hasn't been any fanfare about this capability because it doesn't require any special syntax or new keywords. Just know that the suggestion that "Go 1.18+ doesn't support sum types and/or enums", is very wrong.

Strum355 4y ago
Not going to link it anywhere? I have some doubts given how widely it wouldve been shared if the claim is actually true, and your not linking of an example kinda just furthers that
- Splizard 4y ago
  Sum types: https://go.dev/play/p/R7Bhy2LDmde https://go.dev/play/p/R7Bhy2LDmde Enums: https://go.dev/play/p/MnbmE0B3sSE https://go.dev/play/p/MnbmE0B3sSE Here you go.
  - esprehn 4y ago
    That code appears to be using reflection to build up runtime tables? https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba935765a4aefa514/sum/sum.go#L88 https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba... https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba935765a4aefa514/sum/sum.go#L177 https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba... That's a big difference from other languages where this is all handled at compile time.
  - suremarc 4y ago
    This is cool, but it doesn't seem like Switch is implemented for Int, and the use of runtime reflection limits the contexts in which this implementation can be used, compared to a language construct that gets compiled into efficient machine code. I wouldn't want this to be endemic in my codebase or my dependencies.

Tozen 4y ago

One of the "offshoot" or inspired by languages of Golang, is Vlang (https://vlang.io/ https://vlang.io/), and the other is Odin. Vlang has both sum types and real enums. It had those, including generics, for quite a while.

tandr 4y ago
From a first glance, Odin looks like a nice language to use! Looks like they have fixed ocd-causing idiosyncrasies of Go - "for value, index" and not the other way around, "defer" belongs to surrounding scope, and not the whole function. Thank you!
- Tozen 4y ago
  Your welcome. I keep my eye on both Odin and Vlang. And if a person has experience with Go, they offer some different features and freedoms that might have been wanted, but couldn't get. Additionally, it's not too difficult to switch among the languages as well, if one is strongly familiar with one of them.
  - tandr 4y ago
    Problem is to switch people around you to use something else. Second company, second fight Java vs Go, and I am loosing again... Makes me wonder if all my efforts to learn something new are for nothing, for no real benefit.

vlunkr 4y ago

Everyone check off "immediately making a Golang conversation about Rust"'on your HN bingo.

politician 4y ago
The ‘safe’ keyword in the title is a Siren’s song to certain types of Rustaceans, so it’s not surprising.
- tialaramex 4y ago
  I was reading this because hey, safer enums. But I agree, Sum types are a must have. Particularly, decryption should be Authenticated, and so the correct return type of a decrypt function is a Sum type, and if you don't have Sum types you can't do that.
tempest_ 4y ago
Aw come on there was a whole two hours that this post was about Go before I showed up. You gotta give the people what they want!
stouset 4y ago
Are you really surprised or upset to see those types of comments when the article itself is fundamentally about trying to adapt Go to become more Rust-like? Personally I think people can't help but notice the trend of Go users rediscovering bug-by-bug and frustration-by-frustration why Rust was designed the way it is.
- vlunkr 4y ago
  No, I'm not surprised, that's why it's on the bingo card. They are very different languages, so endlessly comparing them is tiresome.
- morelisp 4y ago
  > the article itself is about trying to adapt Go to become fundamentally more Rust-like? The article does not even mention Rust. Not every attempt to make something 'safer' is an attempt to make it 'fundamentally more Rust-like'. (And you're also misusing the word "fundamental" - even if we grant this is "Rust-like" this is adapting their code to make their Go programs practically more Rust-like.)