Hacker News Reader

Comment by the_other_guy | Hacker News Reader

It's hard to argue with someone who sees these 2 examples are the SAME thing, if you really see the 2nd example is equivalent in _SAFETY_ and readability as the first one, you probably haven't written much code or used many languages

In every other language, people keep arguing about advanced features, moving forward and such, only in Go people defend the undefendable and reject any kind of the simplest obvious improvements, I say so and I am sad because I use Golang very heavily, it's sad to see a modern language so popular and its core designers are still stubborn about doing anything in the right direction even if it is as simple as adding enums

View on HN

I don't say it's equivalent in safety, I say (and defend it with my example) it is even safer. Feel free to provide me with an example where C-style enums are more type-safe than the equivalent go constructs.

Readability-wise, this is disputable, the go version is a bit more verbose, but I can't imagine a developer not understanding what happens there at first sight.

Instead of an ad hominem, please clearly explain the main way that the example Go code is less safe than the C example code.

I didn't mean the C example to be applied in C compilers, I meant having the first example in Golang itself, enums are not just constants, they are type safe constants, you can't just use any other constants in some switch-case and get away with it, that's the raison d'etre of enums in the first place

I didn't know that enums are so controversial, unnecessary and equivalent to just constants, but maybe a look of how it's done in any other language can give you a clear difference between enums and constants

https://doc.rust-lang.org/1.30.0/book/2018-edition/ch06-01-d...

https://doc.rust-lang.org/rust-by-example/custom_types/enum....

You first asked for C-style enums, which are not type safe constants (but nothing more than integer constants), then asked for type-safe constants, and then, you say they are not enough either and you want full-blown rust-style enums, which are not enumeration types but true sum types.

Thing is, as soon as you provide users with one more feature, some of these users want even more features: "yeah, enums are great, but I would like to have type safety with them; oh, type safety is important, but why not have sum types, after all? Oh, now that we have sum types, why not add pattern-matching?"

All of these features are great, but they make the language harder to master, and tooling harder to write. This is a tradeoff, there are many languages that implement all the features its users want (I can think of C++, Rust, probably C# too), why not let other language designers try another way?

I have to admit I wouldn't dislike an enum construct in Go, just syntactic sugar that would be equivalent to the type foo int + const block, but I certainly won't push for it.

Reply on news.ycombinator.com