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

201–210 of 244 posts

Re: Go Enums Suck

#201

Post by xigoi »

mseepgood wrote: post #78
coldtea wrote: post #10

Go's iota is probably one of the worst ideas in all programming languages. Not a full typesafe enum type, the same clunky "enums" (assigned constants) available in C, but they bother to implement an auto-incremented counter. So you can't depend on the enum for exhaustiveness warnings e.g. on switch statements, type checking, or correctness, but you do get a useless numeric association autogenerated with iota - so tha…

> Go's iota is probably one of the worst ideas in all programming languages. iota is a great idea, especially if you have to define bit mask constants, e.g. 1 << iota. I wish other languages (yes, also those with enums) had it as well.

Having an actual set type is much better than having to manually fiddle with bitwise operations.

Re: Go Enums Suck

#202

Post by coffeebeqn »

gregors wrote: post #187
LispSporks22 wrote: post #163

Earlier quoted context omitted.

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

I still can't understand how anyone designing a language can defend self-rolled stack traces as a good thing.

You can in theory unwrap them but that seems to rarely be something people use in the real world

Re: Go Enums Suck

#203

Post by coffeebeqn »

mojuba wrote: post #169
nzach wrote: post #130

Earlier quoted context omitted.

This is in line with 'guard clauses' and this is why it is accepted as idiomatic code. For this example we only have a single condition but as soon as you add more conditions it start to get out of hand. I prefer the original code because it makes the codebase as a whole easier to read. But I don't think there are any 'hard facts' to support using either of these styles over the other in these simple cases.

There is one simple hard fact: shorter code is faster to read and understand, period. If someone doesn't understand what the result of `o != Unknown` is then they should probably go back and read more about programming. Sorry to sound a bit condescending.

I would’ve written a shorter letter if I had more time. I’ve also noticed people don’t want to think through Boolean logic enough to write things legibly. Or the other extreme is way too many Boolean operators on a line where it gets very hard to parse. Even worse when there are multiple cases like that in one function

Re: Go Enums Suck

#204

Post by randomdata »

xigoi wrote: post #200
randomdata wrote: post #126

Earlier quoted context omitted.

> C does have enums. Then again, so does Go. Go doesn't have an enum keyword like C, but that isn't what defines enums.

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.

Re: Go Enums Suck

#205

Post by neonsunset »

Pet_Ant wrote: post #41
neonsunset wrote: post #17

Earlier quoted context omitted.

Java generics aren't even proper generics. For that better look at Rust and C#.

Everything in Java is a compromise. The leaders of Java will often admit that. Josh Bloch openly talks about Java being a working man's language, a blue collar one. Every idea has to be tampered down to make it fit for Java's purpose (Bloch has said that they blew Java's complexity budget on closures and wildcards). BGGA was the real proposal for adding closures to Java, but instead it went with CICE. Java works, and…

This sounds like a strange way to excuse deficiencies of a language in verbosity or otherwise.

Re: Go Enums Suck

#206

Post by neonsunset »

Thaxll wrote: post #197
pkulak wrote: post #167

Earlier quoted context omitted.

> Golang is an absolutely ideal language for writing REST API microservices Those are strong words for a language with all the flaws I just mentioned. :D Yes, green threads are great for network programming, but it's not the only language with them, and one feature does not make it "ideal". If I had to pick the best networking language... I'd probably say Elixir. But even if we agree that it's ideal, it doesn't chang…

Elixir performance is pretty average and it's not a statically typed language, things will blow up at runtime.

The better language at this to both Java, Go and, god forbid, Elixir is C#. It properly implements generics, pattern matching and task-based asynchronous model which allows to trivially interleave or dispatch all kinds of method calls in ways which require extremely verbose and bulky code in Go.

Re: Go Enums Suck

#207

Post by neonsunset »

mathiasgredal wrote: post #21

If you are already using gRPC in your codebase, then you can define your enums with Protobuf, which does much of the same as the tool shown in this article.

Ah yes, gRPC, something using which requires more ceremony and worse UX in Go than in …C# of all the languages.

Re: Go Enums Suck

#208

Post by neonsunset »

bedobi wrote: post #181
uticus wrote: post #173

Earlier quoted context omitted.

What language typically returns the `Either ` you refer to here? I get (and love) the idea but have never seen it in official documentation (sure I could go off the beaten path and implement in my language of choice). Also, did you come up with this on your own, or were you exposed to it?

not as many languages as you'd hope unfortunately, but plenty do (see eg other reply you got, there are more still including F# etc etc) + other languages get close, eg Kotlin has nullable types (which is a poor substitute) and Result (which is also poor because it's not a true Either) that said lots of languages these days have libraries that do it (Arrow, Vavr and countless others) IMO the killer simple language th…

C# gets pretty close with NRTs, pattern matching, terse record declaration and task-based async syntax, lambdas and Result libraries if you like those. Also nicely builds to self-contained binaries, both JIT and AOT.

Re: Go Enums Suck

#209

Post by neonsunset »

Jtsummers wrote: post #165
scosman wrote: post #160

Earlier quoted context omitted.

Faiiir. Nothing was net new concept. But the package they made was quite unique. Garbage collected but always native. No thread access, native channels and coroutines instead. Defer is pretty much net new in language design terms. No while loop?!? “If err != nil”!!? Lots of bold ideas, in a good package, and it worked so well. Calling the evolution boneheaded dismisses how hard it is to make so many opinionated bets…

Just pointing out that it was not really as novel as you seem to believe it was at the time it came out. > Garbage collected but always native. Ok, sure. There were no other native garbage collected languages. Ignoring history, this is true. > No thread access, native channels and coroutines instead. If we ignore history again, also new with Go. > Defer is pretty much net new in language design terms. I can't think o…

defer is a poor man’s C# IDisposable (or even IAsyncDisposable)

    // The file handle will be freed at OS level when exiting current scope
    using var file = File.OpenHandle("somefile");

Re: Go Enums Suck

#210

Post by Jtsummers »

neonsunset wrote: post #209
Jtsummers wrote: post #165

Earlier quoted context omitted.

Just pointing out that it was not really as novel as you seem to believe it was at the time it came out. > Garbage collected but always native. Ok, sure. There were no other native garbage collected languages. Ignoring history, this is true. > No thread access, native channels and coroutines instead. If we ignore history again, also new with Go. > Defer is pretty much net new in language design terms. I can't think o…

defer is a poor man’s C# IDisposable (or even IAsyncDisposable) // The file handle will be freed at OS level when exiting current scope using var file = File.OpenHandle("somefile");

defer is best compared to try/finally or unwind-protect and friends. You can defer any action, not just whatever the IDisposable happens to cleanup. It also gets access to the lexical scope for its deferred actions.

You could imitate that with IDisposable, but it would be overkill compared to just using finally (in C#).

Post reply on HN