3 ms·

> Go enums are the same as in every single other language. After all, all an enum does is count. There isn't anything more you can do with it. You may want to

> Go enums are the same as in every single other language. After all, all an enum does is count. There isn't anything more you can do with it. You may want to meet a modern language one day. Or hell not even a modern language, even a shit one like Java. As it turns out there are languages where you can define an enum foo { bar, baz } and when you type a parameter as a `foo` you're not at risk of getting 69 or 4328.

9rx 2y ago
> You may want to meet a modern language one day. Like what? CrabLang? Its enums are identical to Go, unsurprisingly. Above the enum rests a discriminated union that ends up hiding the details of the enum. That is where things begin to differ greatly. You have to do some real trickery to actually get at the underlying enum result in that language. But, when you do, you see that it is exactly the same. > and when you type a parameter as a `foo` you're not at risk of getting 69 or 4328. That's thanks to the type system, though, not enums. Enums are not a type. Enums are a number generator. Hence the name.
- tialaramex 2y ago
  > That's thanks to the type system, though, not enums. Enums are not a type. Enums are a number generator. Hence the name. What's happened here is that you've mistaken "Things I believe" for "What everybody else believes" but you're talking to other people, not yourself, so, this makes you seem like a blithering idiot. The particular version of this trap you've fallen into is a variation of the "It's all just the machine integers" mental model from C. It's just a model and the problem arises when you mistake that model for reality. Now, technically this model isn't even correct for C's abstract machine, but it's close enough for many programmers and it tends to match how they think the hardware works, which is even more confusing for the hardware people who know how it actually works but that's another conversation. This model is completely useless for languages which don't have the same type system, and so it's no surprise that it immediately led you astray.
  - 9rx 2y ago
    > but you're talking to other people No, I am clearly talking to a computer program. It is possible that the program is forwarding the discussion on to people. Perhaps that is what you are trying to allude to? The details of how the software works behind the scenes is beyond my concern. There is no intention to talk to other people, even if the software has somehow created that situation incidentally. If I wanted to talk to people, I would go out and talk to people, not type away at my computer into a box given to me by the software. > The particular version of this trap you've fallen into is a variation of the "It's all just the machine integers" mental model from C. As much as I enjoy your pet definition that you've arbitrarily made up on the spot here, the particular trap I have fallen into is the dictionary. It literally states what an enumeration is according to the prevailing usage. It does not describe it as a type, it describes it as the action of mentioning a number of things one by one. Which is exactly what an enum does. The previous comment is talking about type constraints. You can definitely constrain a type such that it is invalid to use it outside of the numbers generated by the enum, just as you can constrain a type to only accept certain strings. e.g. from Typescript: `type Email = "{string}@{string}"` This idea is not limited to enums. That's definitely a thing, and definitely a thing that could be used in conjunction with an enum, but is not an enum itself. Not as enum is normally used. Of course you can arbitrarily define it however you please. But, if you are accepting of each holding their own pet definition, your comment doesn't work. You can't have it both ways.
noapologies 2y ago
> ... even a shit one like Java. I agree with your point about Go enums. But in defense of Java, modern Java is actually pretty pleasant. Virtual threads, records and sealed classes, pattern matching, state-of-the-art garbage collectors, a great standard library etc. (and obviously well-behaved enums). Not to mention the other languages you get for free with the JVM ecosystem. It might not be as expressive as Rust, but certainly Java/JVM > Go.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- pjmlp 2y ago
  It is so funny how Go folks praise its standard library, when it is a fraction of Python, Java and .NET standard libraries.
  - deleted 2y ago
    [deleted]
  - kbolino 2y ago
    Things that were in the Go standard library from the first public release (2012): encoding/json vs Python: 2008, json package added in version 2.6 .NET: 2019, System.Text.Json came with .NET Core 3.0 JVM: still nothing net/http client vs Python: gave up, "just use requests" .NET: also 2012, HttpClient came with .NET Framework 4.5 JVM: 2018, HttpClient came with Java 11 The time library definitely sucks though. There's really no excuse for it, joda-time came out a long time ago.
    - pjmlp 2y ago
      Cherry picking examples are we? What about actually counting the set of features across a full stack application? I can pick countless of examples of features in Java and .NET standard library that Go 1.24 still doesn't have any answer for.

9rx 2y ago

> You may want to meet a modern language one day. Like what? CrabLang? Its enums are identical to Go, unsurprisingly. Above the enum rests a discriminated union that ends up hiding the details of the enum. That is where things begin to differ greatly. You have to do some real trickery to actually get at the underlying enum result in that language. But, when you do, you see that it is exactly the same. > and when you type a parameter as a `foo` you're not at risk of getting 69 or 4328. That's thanks to the type system, though, not enums. Enums are not a type. Enums are a number generator. Hence the name.

tialaramex 2y ago
> That's thanks to the type system, though, not enums. Enums are not a type. Enums are a number generator. Hence the name. What's happened here is that you've mistaken "Things I believe" for "What everybody else believes" but you're talking to other people, not yourself, so, this makes you seem like a blithering idiot. The particular version of this trap you've fallen into is a variation of the "It's all just the machine integers" mental model from C. It's just a model and the problem arises when you mistake that model for reality. Now, technically this model isn't even correct for C's abstract machine, but it's close enough for many programmers and it tends to match how they think the hardware works, which is even more confusing for the hardware people who know how it actually works but that's another conversation. This model is completely useless for languages which don't have the same type system, and so it's no surprise that it immediately led you astray.
- 9rx 2y ago
  > but you're talking to other people No, I am clearly talking to a computer program. It is possible that the program is forwarding the discussion on to people. Perhaps that is what you are trying to allude to? The details of how the software works behind the scenes is beyond my concern. There is no intention to talk to other people, even if the software has somehow created that situation incidentally. If I wanted to talk to people, I would go out and talk to people, not type away at my computer into a box given to me by the software. > The particular version of this trap you've fallen into is a variation of the "It's all just the machine integers" mental model from C. As much as I enjoy your pet definition that you've arbitrarily made up on the spot here, the particular trap I have fallen into is the dictionary. It literally states what an enumeration is according to the prevailing usage. It does not describe it as a type, it describes it as the action of mentioning a number of things one by one. Which is exactly what an enum does. The previous comment is talking about type constraints. You can definitely constrain a type such that it is invalid to use it outside of the numbers generated by the enum, just as you can constrain a type to only accept certain strings. e.g. from Typescript: `type Email = "{string}@{string}"` This idea is not limited to enums. That's definitely a thing, and definitely a thing that could be used in conjunction with an enum, but is not an enum itself. Not as enum is normally used. Of course you can arbitrarily define it however you please. But, if you are accepting of each holding their own pet definition, your comment doesn't work. You can't have it both ways.

noapologies 2y ago

> ... even a shit one like Java. I agree with your point about Go enums. But in defense of Java, modern Java is actually pretty pleasant. Virtual threads, records and sealed classes, pattern matching, state-of-the-art garbage collectors, a great standard library etc. (and obviously well-behaved enums). Not to mention the other languages you get for free with the JVM ecosystem. It might not be as expressive as Rust, but certainly Java/JVM > Go.

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
pjmlp 2y ago
It is so funny how Go folks praise its standard library, when it is a fraction of Python, Java and .NET standard libraries.
- deleted 2y ago
  [deleted]
- kbolino 2y ago
  Things that were in the Go standard library from the first public release (2012): encoding/json vs Python: 2008, json package added in version 2.6 .NET: 2019, System.Text.Json came with .NET Core 3.0 JVM: still nothing net/http client vs Python: gave up, "just use requests" .NET: also 2012, HttpClient came with .NET Framework 4.5 JVM: 2018, HttpClient came with Java 11 The time library definitely sucks though. There's really no excuse for it, joda-time came out a long time ago.
  - pjmlp 2y ago
    Cherry picking examples are we? What about actually counting the set of features across a full stack application? I can pick countless of examples of features in Java and .NET standard library that Go 1.24 still doesn't have any answer for.