top | item 23712988

(no title)

nmyk | 5 years ago

FWIW, there's a slightly more concise way of expressing this in Go:

    type state int
    
    const (
        on state = iota
        off
    )

discuss

josephcsible|5 years ago

I don't think the concern was verbosity so much as lack of type safety.

asdkhadsj|5 years ago

After using Go for ~5 years, so many little things in Rust blew me away. I thought I was okay with Go's "enums" but then I saw Rust's Enums. Most notably, the real enum type combined with pattern matching was an eye opener over what I've been missing.

Iterators were another one. The ability to express data transformation (mapps/filters/etc) in a very concise way blew me away. I had no idea what I had gotten used to in Go, though that's definitely not to say that I didn't feel the pain.

There's advanced features in Rust I could live without, but most of it just feels empowering. The beauty in it though, in my mind, is that you don't need to use all that advanced stuff. You can write Rust shockingly similar to Go.

The only thing Go truly nailed in my eyes is green threads. Those will always be better in Go than Rust (though futures are getting way better). Go nailed green threads.

But all the other "lack of features as a feature" left me frequently wanting for more tools to solve simple problems. And I was a Go nut. I have a Gopher plushie in my car for Petes sake.

coder543|5 years ago

It is type safe. Any integers with a defined type cannot be used as values of type "state" without an explicit conversion occurring.

Type safety does not guarantee exhaustive matching, unfortunately, because the underlying type is still an integer, but that's a separate issue.

https://play.golang.org/p/K0m4hfmw8C1

I wish Go had proper, exhaustive enums too (sum types preferably), but you're incorrect when you say that they don't have type safety.

nmyk|5 years ago

Fair enough. I would say if the way someone uses the Go "enum pattern" is causing them to have issues with type safety then their code could probably use a refactor, but the point does stand.

tsimionescu|5 years ago

`iota` is one of the strangest features in Go by far for me. So much complexity for such a simple feature with so few applications, instead of implementing even simple enums...