Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Enums Suck

zarl.dev

Post reply on HN
Print view View original

221–230 of 244 posts

Re: Go Enums Suck

#221

Post by mariusor »

zarldev wrote: post #153
llmblockchain wrote: post #151

Earlier quoted context omitted.

Yes. Your DSL is JSON in this case, { "enums": [ { "package": "cmd", "type": "operation", "values": [ "Escalated", "Archived", "Deleted", "Completed" ] } ] } My point was the "Go" way to do this isn't parsing a custom format (like your JSON), but it's to use go generate.

But all go generate does is run a binary like stringer? This can be used in go generate.

I'm not sure I understand exactly what you mean, but you can combine go:generate with go run so you can execute code from the current module/project that does what you want.

//go:generate go run ./internal/enumhelper -flag1 -flag2

Re: Go Enums Suck

#222

Post by pwdisswordfishc »

randomdata wrote: post #6
the__alchemist wrote: post #3

Go and Python have OK enums. I will use them, but they could be simpler/more expressive. This begs the question: Is there an obstacle to releasing better enums in the next Python and Go versions? If the concern is about breaking backwards compatibility, I would be OK with a new type. Is it a culture issue, ie that Python and Go programmers don't use enums much? (Chick + egg here) Rust's enums are great. No "auto" boi…

> Rust's enums are great. Rust doesn't have enums. It has sum types – that for some reason it arbitrarily decided to call enums. Sum types are great. There is a good case to be made that Go would benefit from the addition of sum types. But until that day there isn't much more you can do with enums. That's all enums are – a set of named constants.

That's because what you insist is the only thing deserving of the name "enum" is just a sum type of unit types.

Re: Go Enums Suck

#223

Post by cmrx64 »

randomdata wrote: post #204
xigoi wrote: post #200

Earlier quoted context omitted.

But neither C nor Go have type-safe enums.

They are type safe. They are not value safe, but neither language supports value constraints, so that isn't unexpected.

What is value safety? Why should value constraints be pertinent here? near I can tell this is a neologism (introduced here? https://itnext.io/we-need-to-talk-about-the-bad-sides-of-go-...) that just happens to be near the top of search results in this area.

The introduction rule for enum values in C is _not_ type safe. You know how you can tell? Well typed programs go wrong. a language absolutely does not need value constraints of any kind to get this right.

Re: Go Enums Suck

#224

Post by kamaal »

klysm wrote: post #15
sgift wrote: post #5

I love Go. Especially how the devs stubbornly refuse to learn anything from Java, but stumble boneheaded into everything that Java solved over the years. Generics? We don't need that .. (time goes on) .. okay, damn it. Here! Generics! Enums? We don't need that, just do iota/integers! How long will it be this time until the Go devs accept that Java Enums are a safer and better abstraction over integers for the cases w…

I think boneheaded is a good way to describe the evolution of go. It seems like the original authors were convinced most of the complexity of modern languages was unjustified and have slowly proven themselves incorrect over the years

>>It seems like the original authors were convinced most of the complexity of modern languages was unjustified and have slowly proven themselves incorrect over the years

Python was the same way a few years back. People would give elaborate lectures on why Perl's features were so bad, only that they agreed to add many such features to Python within a decade, even at the extreme act of breaking backwards compatibility.

This is seems to be a common arc to so many things. When you start you are all about principles and as you age, you realise practicalities of every day life demand making lots of tradeoffs and deviations from founding principles.

Re: Go Enums Suck

#225

Post by yhavr »

bedobi wrote: post #155
yhavr wrote: post #138

Earlier quoted context omitted.

> sane error handling? Golang _has_ sane error handling. It just considers errors a normal and expected situation. When you perform a http request, and the result is successful you expect the result to be assigned a variable, right? Then why would you expect non-successful outcome to be returned in a different way? Why is it different? Why do you unwind the stack? Something terrible happened? Definitely not, it's as…

100% agree, and Go gets oh so close But the correct and only sane way to do this is Either that you can then pass on, map over both or either of the two, flatMap to chain with other Eithers, fold into a single thing etc etc. Not endless sprinkling of if err != nil { log.Fatal(err) } everywhere (and no, those operations are not obscure, esoteric or difficult to learn or understand - they're the same for other types li…

I agree that the type system should be better. And for some reasons, golang didn't even implement proper tuple types. However, now with generics, you can actually do Result[T] with all functions you described.

> in itself as well is inexcusable for a modern language

In Go, you can assign nils only to pointers

Re: Go Enums Suck

#226

Post by yhavr »

LispSporks22 wrote: post #163
yhavr wrote: post #138

Earlier quoted context omitted.

> sane error handling? Golang _has_ sane error handling. It just considers errors a normal and expected situation. When you perform a http request, and the result is successful you expect the result to be assigned a variable, right? Then why would you expect non-successful outcome to be returned in a different way? Why is it different? Why do you unwind the stack? Something terrible happened? Definitely not, it's as…

> Why do you unwind the stack? Something terrible happened? Definitely not, Definitely do. In Go we just have to emulate it, badly, by manually writing code to forward the error up the stack so you can finally top-level print “error bad thing happen” or maybe some unholy stringification of wrapped errors possibly collected along the way.

Please explain how errors are fundamentally different so they require drastically different way of returning.

Re: Go Enums Suck

#227

Post by randomdata »

cmrx64 wrote: post #223
randomdata wrote: post #204

Earlier quoted context omitted.

They are type safe. They are not value safe, but neither language supports value constraints, so that isn't unexpected.

What is value safety? Why should value constraints be pertinent here? near I can tell this is a neologism (introduced here? https://itnext.io/we-need-to-talk-about-the-bad-sides-of-go-... ) that just happens to be near the top of search results in this area. The introduction rule for enum values in C is _not_ type safe. You know how you can tell? Well typed programs go wrong. a language absolutely does not need value…

> Why should value constraints be pertinent here?

Because that's where it is unsafe: You can introduce a value of the same type that is outside of the enumerable range. You cannot introduce a value of a different type, though. It is type safe.

Yeah, any language with a type system worth its salt has value constraints, but if you choose to forego them as C and Go have, you're not going to bother adding them just for enums. It would be kind of silly to leave developers with a noose to hang themselves with everywhere else, but then think you need to tightly hold their hand just for enums.

In fact, I'd argue that if you are short on time and need to make compromises to reach a completion state, enums are the last place you would want to take the time to add value constraints. The types more often used would find much greater benefit from having value constraints.

Case in point: Typescript. When was the last time you cared that its enums behave just like C and Go? Never, I'm sure, because it having value constraints everywhere else more than makes up for it. Giving up value constraints for safer enums is a trade you would never consider.

Re: Go Enums Suck

#228

Post by cmrx64 »

randomdata wrote: post #227
cmrx64 wrote: post #223

Earlier quoted context omitted.

What is value safety? Why should value constraints be pertinent here? near I can tell this is a neologism (introduced here? https://itnext.io/we-need-to-talk-about-the-bad-sides-of-go-... ) that just happens to be near the top of search results in this area. The introduction rule for enum values in C is _not_ type safe. You know how you can tell? Well typed programs go wrong. a language absolutely does not need value…

> Why should value constraints be pertinent here? Because that's where it is unsafe: You can introduce a value of the same type that is outside of the enumerable range. You cannot introduce a value of a different type, though. It is type safe. Yeah, any language with a type system worth its salt has value constraints, but if you choose to forego them as C and Go have, you're not going to bother adding them just for e…

> Because that's where it is unsafe: You can introduce a value of the same type that is outside of the enumerable range. You cannot introduce a value of a different type, though. It is type safe

C’s type system is unsound, and not all compileable programs respect its dynamic requirements. We cope with this by referring to some code as “not type safe”.

foo bar = NOT_FOO;

You say this “typedef enum {…} foo” is not a type, naming a set of values, but just a convenient alias for whatever the representation is, thus all “enum” (regardless of actual decl) name the same set, and every constructor expression shares the same “type”. Consistent with the language specification, and passes the type checker, so you could say this code is “type safe”? but it’s one hell of a foible and not consistent with any lay (non PLT) understanding of type safety, where typesafety means the type written in the code and the runtime representation won’t desync (no runtime type errors).

If you simply forbid UB and refer to only strictly conforming programs, I will accept this modified meaning of “type safe”, but grumble that this meaning is not very good

edit to encompass parent edit: as a typescript nonprogrammer, I have nothing to add :) I am confused why you are putting the features in opposition. gradual + value-sensitive typing is a good feature, but doesn’t conflict with sums. in ocaml, we support both, real sum types as well as variant [`A | `B] etc that are structural in the way you’d want C to be

Re: Go Enums Suck

#229

Post by randomdata »

cmrx64 wrote: post #228
randomdata wrote: post #227

Earlier quoted context omitted.

> Why should value constraints be pertinent here? Because that's where it is unsafe: You can introduce a value of the same type that is outside of the enumerable range. You cannot introduce a value of a different type, though. It is type safe. Yeah, any language with a type system worth its salt has value constraints, but if you choose to forego them as C and Go have, you're not going to bother adding them just for e…

> Because that's where it is unsafe: You can introduce a value of the same type that is outside of the enumerable range. You cannot introduce a value of a different type, though. It is type safe C’s type system is unsound, and not all compileable programs respect its dynamic requirements. We cope with this by referring to some code as “not type safe”. foo bar = NOT_FOO; You say this “typedef enum {…} foo” is not a ty…

> C’s type system is unsound

Along with every other programming language under the sun. A complete type system is not exactly an easy feat – especially if you want it to be usable by people.

> We cope with this by referring to some code as “not type safe”.

Value constraints are an application of types, so yes, if C/Go had value constraints then violation of those constraints would leave it to not be type safe. But they don't have value constraints. Insofar as what the types can constrain, the safety is preserved.

It seems all you are saying is that C (and Go) do not have very advanced type systems. But that shocks nobody. Especially in the case of Go, that was an explicit design decision sung by its creators. You'd have to be living under a rock to not know that.

Was there something useful you were trying to add?

Re: Go Enums Suck

#230

Post by cmrx64 »

randomdata wrote: post #229
cmrx64 wrote: post #228

Earlier quoted context omitted.

> Because that's where it is unsafe: You can introduce a value of the same type that is outside of the enumerable range. You cannot introduce a value of a different type, though. It is type safe C’s type system is unsound, and not all compileable programs respect its dynamic requirements. We cope with this by referring to some code as “not type safe”. foo bar = NOT_FOO; You say this “typedef enum {…} foo” is not a ty…

> C’s type system is unsound Along with every other programming language under the sun. A complete type system is not exactly an easy feat – especially if you want it to be usable by people. > We cope with this by referring to some code as “not type safe”. Value constraints are an application of types, so yes, if C/Go had value constraints then violation of those constraints would leave it to not be type safe. But th…

> Was there something useful you were trying to add?

Yes, the clarification about value safety, which you’ve done quite well.

Not every language is unrepentantly unsound.

I continue to identify a confusion in this thread between a property of the languages, and a property of particular code, but I have clearly exhausted your patience. thank you.

Post reply on HN