Go Enums Suck • Hacker News Board

Re: Go Enums Suck

#231

Post by thiht » Sat, Mar 02, 2024, 2:35 PM UTC

015a wrote: post #127

`iota` is maybe the only language feature of Go that I would actually support removing. Obviously, they never will because it would be a breaking change. Its just so vestigial. There's literally no reason to use it, and a very big reason why you shouldn't: The encoded value can change any time you re-compile your program, so you can't actually use it for anything where the value of the enum leaves the process that in…

Agree, iota is terrible. I think I encountered exactly one time where iota was a good fit for what I wanted to do (an internal representation of some kind, so whether the value changes in the future was irrelevant), but even then it was just needlessly opaque compared to just assigning values.

Real enumerations/discriminated unions is the one thing I consistently wish for in the Go annual surveys

Re: Go Enums Suck

#232

Post by randomdata » Sat, Mar 02, 2024, 2:54 PM UTC

cmrx64 wrote: post #230

randomdata wrote: post #229

Earlier quoted context omitted.

> 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.

> Not every language is unrepentantly unsound.

For sure. Coq does a decent job, but it's also a complete bear to use. Tradeoffs, as always.

> I continue to identify a confusion in this thread between a property of the languages, and a property of particular code

Go on. The original statement was that C and Go do not have type-safe enums. But there is no evidence of that being the case. The types are safe.

Indeed, the types are limited. An integer type, for example, cannot be further narrowed to only 1-10 in these languages. But the lack of a feature does not imply lack of type-safety. It only implies a lack of a feature.

Re: Go Enums Suck

#233

Post by cmrx64 » Sat, Mar 02, 2024, 3:05 PM UTC

randomdata wrote: post #232

cmrx64 wrote: post #230

Earlier quoted context omitted.

> 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.

> Not every language is unrepentantly unsound. For sure. Coq does a decent job, but it's also a complete bear to use. Tradeoffs, as always. > I continue to identify a confusion in this thread between a property of the languages, and a property of particular code Go on. The original statement was that C and Go do not have type-safe enums. But there is no evidence of that being the case. The types are safe. Indeed, the…

the disagreement is that the program is typesafe just because it was typechecked. BECAUSE the system is unsound (completeness is irrelevant), typechecking doesn’t imply type safety.

… where I am using type safety to mean “no runtime type errors/UB manifest”, ie, the property that a sound typesystem would guarantee _if we had one_. You seem to be saying that just because our type system is impoverished, does not make its resulting claim of “program is type safe” any less valid, whereas I am saying “type safety is a semantic property of programs, not of languages, and this value safety idea seems like it’s what PLTers think type safety means”.

It’s a violation of the C semantics to assign the wrong value to an enumeration, so I would say that fact the language doesn’t do anything at all to enforce or check this promotes this beyond “lack of a feature” and straight into “type unsafe”. However, I’d feel less strongly if at least initializers were checked.

As you say, different language design philosophies lead to this, and it’s not surprising. Most of these ideas came _after_ C anyway!

phone dying… no response soon.

Re: Go Enums Suck

#234

Post by yhavr » Sat, Mar 02, 2024, 3:35 PM UTC

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…

Btw, tried to implement Result[T] flatmaps etc, it looks uglier than err != nil

func myfunc(url string) Result[string] {

  tup := FromTuplePtr(http.Get(url))

  return FlatMap(tup, func(r http.Response) Result[string] {

    return Map(FromTuple(io.ReadAll(r.Body)), func(b []byte) string {

      return string(b)

    })

  })

}

Re: Go Enums Suck

#235

Post by gembeMx » Sat, Mar 02, 2024, 5:09 PM UTC

015a wrote: post #127

`iota` is maybe the only language feature of Go that I would actually support removing. Obviously, they never will because it would be a breaking change. Its just so vestigial. There's literally no reason to use it, and a very big reason why you shouldn't: The encoded value can change any time you re-compile your program, so you can't actually use it for anything where the value of the enum leaves the process that in…

Why iota show you a knuckle sandwich

Re: Go Enums Suck

#236

Post by ilove_banh_mi » Sat, Mar 02, 2024, 5:28 PM UTC

ithkuil wrote: post #194

ilove_banh_mi wrote: post #148

Ada has excellent enumeration types, and subtypes, and compile-time checking of case statement coverage for enum values, and an optional representation mechanism to control the binary value for each (symbolic) enum value. I'm not aware of any other language with that kind of enum type system. See e.g. https://adaic.org/resources/add_content/docs/craft/html/ch05...

Rust I think covers most if not all of Ada features you mentioned

Rust's "enum" mechanism is really an algebraic data type, and corresponds to Ada's enumeration types when applied as discriminants in variant record types. But Ada's enumeration types have a wider context of use, separate and independent from variant record types, including compile- and run-time features related directly to a) symbolic order and symbol names, b) binary representation mapped to these symbols, and c) subtyping/ranges.

I'm not aware of a good online presentation focused exclusively on Ada's enumeration types and their various uses. It's not even singled out in the Rationale documents for the design of the language and the (3?) design revisions since the 1980 launch; maybe the AARM (Annotated Ada Reference Manual) has more focused discussions? I'm not sure, I haven't looked at these since ~20y ago.

Re: Go Enums Suck

#237

Post by danenania » Sat, Mar 02, 2024, 7:09 PM UTC

coffeebeqn wrote: post #198

danenania wrote: post #88

Earlier quoted context omitted.

I'm working on an LLM project in Go and the term "context" is overloaded to the hilt--I use it to refer to the LLM context as well as Go's `context.Context` which I'm using all over the place. It's made worse since the most natural plural of context is... context. My solution is to use `ctx` for Go context, `contexts` for arrays of LLM context structs, and `contextPart` for individual context structs. "model" is anot…

Context is actually one of my least favorite parts of go. I wish they at least reimplemented it with generics so it’s not just a unlabeled box of maybe some stuff that can also cancel things

Yeah it's definitely a bit of a junk drawer. I'm using it for timeouts, cancelation, and cancelation trees and it's not so bad, but I know it can also be used to pass data around which doesn't strike me as a great idea.

Re: Go Enums Suck

#238

Post by Quekid5 » Sat, Mar 02, 2024, 8:19 PM UTC

ReleaseCandidat wrote: post #90

Quekid5 wrote: post #60

Earlier quoted context omitted.

I think it might be due to the O'Caml influence on early Rust. They call them enums there[0]. [0] https://www.ocamlwiki.com/index.php?title=Enums_in_OCaml

They are called variants in OCaml (and inductive data types in Roqc). But way more important: this OCaml wiki is an AI generated mess full of, well, bullshit. https://discuss.ocaml.org/t/whats-up-with-ocamlwiki/13605

Ah, I see. That's sad :(

... and now that you mention it, I do remember the variants terminology, esp. around the polymorphic variants feature. It's been 20+ years since I used OCaml, I'm afraid...

Re: Go Enums Suck

#239

Post by gleenn » Sat, Mar 02, 2024, 10:47 PM UTC

hardwaregeek wrote: post #185

gleenn wrote: post #184

Earlier quoted context omitted.

So the inventors and maintainers of V8 and C are very bad language designers? I don't like either of those languages but those are aome pretty strong words.

Did any V8 people work on Go? And V8 is an implementation of an existing language, so that fits under "very good software engineer, very bad language designer". As for C, well, it's not a fantastic language. Not to mention, it's been 50 years since C was created, ignoring those 50 years of progress to build essentially C with GC is pretty poor language design.

Robert Griesemer worked on V8 and Ken Thompson invented C. V8 is obviously not a language, but it is a massive project to make it as obscenely fast as it is and used in as many places, which should give Griesemer some credibility. I personally don't like C, but everything is obvious in hindsight and it's used everywhere, so you gotta give some credit to Thompson as well.

Re: Go Enums Suck

#240

Post by smw » Sun, Mar 03, 2024, 12:38 AM UTC

pkulak wrote: post #183

smw wrote: post #176

Earlier quoted context omitted.

I find go distasteful, but are there really many other languages with an m:n threading model? Only other popular one I can think of is Erlang/Elixir.

Java 21, and I assume like every scripting language (Ruby, Python, etc). Though I guess with scripting you can't use more than one OS thread (not totally sure). Rust started off with it, and C# tried it too, but there are huge downsides to the model, so it's not like it's perfection incarnate and every other language just can't pull it off.

Does 21 actually automatically schedule fibers? to open cores?