4 ms·

And enums.

fullstackchris 2y ago
package main import "fmt" // Define an enumeration for status type Status int const ( Pending Status = iota InProgress Completed Failed ) func (s Status) String() string { return [...]string{"Pending", "InProgress", "Completed", "Failed"}[s] } func main() { var s Status = InProgress fmt.Println(s) // Output: InProgress }
- Svip 2y ago
  OK, but I can set s to 1000, and it still compiles.
- alkonaut 2y ago
  Next day I have this (added one entry). I forgot to update the string list elsewhere however. const ( Pending Status = iota InProgress Completed Cancelled Failed ) func (s Status) String() string { return [...]string{"Pending", "InProgress", "Completed", "Failed"}[s] } func main() { var s Status = Cancelled fmt.Println(s) // Output: ?? If the compiler - not some linter - protests that the list of names is different from the number of items in the enum, then I think this is at least a half-decent design of an enum type. Not a great one (because the author still had to repeat the names), but at least something that isn't a fundamentally broken design of an enum type. But if the compiler is silent, and the output of the Println(Cancelled) is "Failed" then I'm not angry, I'm disappointed. Edit: https://go.dev/play/p/MMPMh7_U81- https://go.dev/play/p/MMPMh7_U81-
- physicsguy 2y ago
  I see this suggested all the time as though it’s supposed to be a replacement. It isn’t sufficient, it’s a poor emulation of what enums can be used for and doesn’t offer the same protections, since Status can be set to any integer value without casting or any knowledge that it’s broken. In your suggested method it doesn’t even catch that case and provide an error if the value isn’t in the range.
  - powerhugs 2y ago
    It seems like none of the other comments here use or are even aware of `go generate`. Go has excellent code generation features [1]. I think parent should be using `stringer` [2] instead. 1: https://go.dev/blog/generate https://go.dev/blog/generate 2: https://pkg.go.dev/golang.org/x/tools/cmd/stringer https://pkg.go.dev/golang.org/x/tools/cmd/stringer
    - physicsguy 2y ago
      I'm well aware of Stringer but I don't again think it's a good replacement of having enums built in!
      - powerhugs 2y ago
        > I don't again think it's a good replacement of having enums built in! I didn't say anything along those lines, in fact I was commenting generally about this issue that you guys and the other commenters mentioned. I was just suggesting a solution to the the problem stated.
        fullstackchris 2y ago
        "We don't want a solution! We want to complain about what we are used to and dont have!"
- pjmlp 2y ago
  Also known as design hack, workaround for what other languages support natively since 1970's. Only one step better than Assembly or Fortran.
theoryofx 2y ago
You can point out flaws so it's not well designed? By this logic nothing is. And pointing out missing features in a programming language is just about the weakest criticism possible. Piling on lots of features is easy and fun. That's why almost all language designers do it. Most popular languages destroy themselves with features. Rust is in the process of gaining every single feature anyone can imagine. Following C++ right off the complexity cliff. Go is one of the very few languages to show incredible restraint in adding features because its designers understood the combinatorial complexity problem, among other things. Not having unnecessary features is one of the best features of Go.
- powerhugs 2y ago
  I very much agree. The fewer ways a programmer can become creative, the easier it is to fully understand their code. In a business environment, this is a obvious win.
  - pjmlp 2y ago
    Especially when programmers are seen as cogs in the business machine.
- physicsguy 2y ago
  The issue with Enums is that the "unnecessary" feature means that people have to encode the behaviour with things that aren't suitable. E.g. creating a new type that's a thin wrapper over string or integer means it can be set as some non-valid value, even without some sort of explicit cast that says "I know I'm doing something that might fail". I don't see that that is an improvement over any other language. It's not simpler because, as people have shown by the examples trying to prove that you don't need it, they don't have all the (necessary) behaviour that enums do to prevent this sort of problem.
  - theoryofx 2y ago
    There are some useful features that Go really should add, and enums might be one of them, but lacking a useful feature doesn't mean its not well designed. The results are in for Go. It's already one of the most successful programming languages in history any way you measure it. Of course Go should continue to improve and add features where the value outweighs the increased complexity. That's how it eventually got generic functions and other features.
roncesvalles 2y ago
The appeal of Go is that it has just the bare minimum feature set to be useful for modern backend engineering. It's a language that you can completely fit within your head within a few months of using it, as opposed to certain languages like C++ (or say C# to a lesser but increasing extent) that most will never know completely even after decades of working with it. It's basically the RISC of programming languages. And if I had to guess, it doesn't have enums so that it can remain flexible when serializing/deserializing enum-like types over the wire. Imagine you can't parse an incoming payload containing an enum field because your service is one version older than the one that extended the enum type (or the enum type is defined in a package dep... you get the idea). Enums are actually a terrible idea now that I think about it.
- theThree 2y ago
  The appeal of Go is goroutine.
  - za3faran 2y ago
    Java has virtual threads with better and safer ergonomics.
- anal_reactor 2y ago
  > The appeal of Go is that it has just the bare minimum feature set to be useful for modern backend engineering. It's a language that you can completely fit within your head within a few months of To me, golang symbolizes the shift of philosophy of Google as a company. It changed from "it's a smart nerd company for smart nerd people" to "golang will allow us to hire cheaper devs because golang will prevent them from making mistakes". I mean, this makes sense from business perspective, I won't deny this fact, but it's the programming equivalent of Ferrari making a SUV: tremendously profitable, but sad to see. BTW > golang doesn't support overloading because overloading is bad. Having said that, it's 'go', not 'golang', like the verb 'go', which already has a thousand meanings depending on the context I find that hilarious
  - AnimalMuppet 2y ago

And enums.

package main import "fmt" // Define an enumeration for status type Status int const ( Pending Status = iota InProgress Completed Failed ) func (s Status) String() string { return [...]string{"Pending", "InProgress", "Completed", "Failed"}[s] } func main() { var s Status = InProgress fmt.Println(s) // Output: InProgress }

Svip 2y ago
OK, but I can set s to 1000, and it still compiles.
alkonaut 2y ago
Next day I have this (added one entry). I forgot to update the string list elsewhere however. const ( Pending Status = iota InProgress Completed Cancelled Failed ) func (s Status) String() string { return [...]string{"Pending", "InProgress", "Completed", "Failed"}[s] } func main() { var s Status = Cancelled fmt.Println(s) // Output: ?? If the compiler - not some linter - protests that the list of names is different from the number of items in the enum, then I think this is at least a half-decent design of an enum type. Not a great one (because the author still had to repeat the names), but at least something that isn't a fundamentally broken design of an enum type. But if the compiler is silent, and the output of the Println(Cancelled) is "Failed" then I'm not angry, I'm disappointed. Edit: https://go.dev/play/p/MMPMh7_U81- https://go.dev/play/p/MMPMh7_U81-
physicsguy 2y ago
I see this suggested all the time as though it’s supposed to be a replacement. It isn’t sufficient, it’s a poor emulation of what enums can be used for and doesn’t offer the same protections, since Status can be set to any integer value without casting or any knowledge that it’s broken. In your suggested method it doesn’t even catch that case and provide an error if the value isn’t in the range.
- powerhugs 2y ago
  It seems like none of the other comments here use or are even aware of `go generate`. Go has excellent code generation features [1]. I think parent should be using `stringer` [2] instead. 1: https://go.dev/blog/generate https://go.dev/blog/generate 2: https://pkg.go.dev/golang.org/x/tools/cmd/stringer https://pkg.go.dev/golang.org/x/tools/cmd/stringer
  - physicsguy 2y ago
    I'm well aware of Stringer but I don't again think it's a good replacement of having enums built in!
    - powerhugs 2y ago
      > I don't again think it's a good replacement of having enums built in! I didn't say anything along those lines, in fact I was commenting generally about this issue that you guys and the other commenters mentioned. I was just suggesting a solution to the the problem stated.
      - fullstackchris 2y ago
        "We don't want a solution! We want to complain about what we are used to and dont have!"
pjmlp 2y ago
Also known as design hack, workaround for what other languages support natively since 1970's. Only one step better than Assembly or Fortran.

theoryofx 2y ago

You can point out flaws so it's not well designed? By this logic nothing is. And pointing out missing features in a programming language is just about the weakest criticism possible. Piling on lots of features is easy and fun. That's why almost all language designers do it. Most popular languages destroy themselves with features. Rust is in the process of gaining every single feature anyone can imagine. Following C++ right off the complexity cliff. Go is one of the very few languages to show incredible restraint in adding features because its designers understood the combinatorial complexity problem, among other things. Not having unnecessary features is one of the best features of Go.

powerhugs 2y ago
I very much agree. The fewer ways a programmer can become creative, the easier it is to fully understand their code. In a business environment, this is a obvious win.
- pjmlp 2y ago
  Especially when programmers are seen as cogs in the business machine.
physicsguy 2y ago
The issue with Enums is that the "unnecessary" feature means that people have to encode the behaviour with things that aren't suitable. E.g. creating a new type that's a thin wrapper over string or integer means it can be set as some non-valid value, even without some sort of explicit cast that says "I know I'm doing something that might fail". I don't see that that is an improvement over any other language. It's not simpler because, as people have shown by the examples trying to prove that you don't need it, they don't have all the (necessary) behaviour that enums do to prevent this sort of problem.
- theoryofx 2y ago
  There are some useful features that Go really should add, and enums might be one of them, but lacking a useful feature doesn't mean its not well designed. The results are in for Go. It's already one of the most successful programming languages in history any way you measure it. Of course Go should continue to improve and add features where the value outweighs the increased complexity. That's how it eventually got generic functions and other features.

roncesvalles 2y ago

The appeal of Go is that it has just the bare minimum feature set to be useful for modern backend engineering. It's a language that you can completely fit within your head within a few months of using it, as opposed to certain languages like C++ (or say C# to a lesser but increasing extent) that most will never know completely even after decades of working with it. It's basically the RISC of programming languages. And if I had to guess, it doesn't have enums so that it can remain flexible when serializing/deserializing enum-like types over the wire. Imagine you can't parse an incoming payload containing an enum field because your service is one version older than the one that extended the enum type (or the enum type is defined in a package dep... you get the idea). Enums are actually a terrible idea now that I think about it.

theThree 2y ago
The appeal of Go is goroutine.
- za3faran 2y ago
  Java has virtual threads with better and safer ergonomics.
anal_reactor 2y ago
> The appeal of Go is that it has just the bare minimum feature set to be useful for modern backend engineering. It's a language that you can completely fit within your head within a few months of To me, golang symbolizes the shift of philosophy of Google as a company. It changed from "it's a smart nerd company for smart nerd people" to "golang will allow us to hire cheaper devs because golang will prevent them from making mistakes". I mean, this makes sense from business perspective, I won't deny this fact, but it's the programming equivalent of Ferrari making a SUV: tremendously profitable, but sad to see. BTW > golang doesn't support overloading because overloading is bad. Having said that, it's 'go', not 'golang', like the verb 'go', which already has a thousand meanings depending on the context I find that hilarious
- AnimalMuppet 2y ago