Hacker News Reader

Comment by jurschreuder | Hacker News Reader

I've never needed either.

Try/catch is super confusing because the catch is often far away from the try. And in Python I just put try/catch around big chunks of code just in case for production.

I think Go is more stable and readable because they force you not to use the lazy unreadable way of error handling.

Enums I honestly never used in Go also not the not-type-safe ones.

But I'm also someone who used interfaces in Go maybe I think 4 times only in years and years of development.

I just never really need all those fancy things.

View on HN

I think what this comment is missing is any sort of analysis of how your experience maps to the general go user, and an opinion on while you've never needed either whether you think it could have provided any benefit when used appropriately.

For example, and option type with enums combined can ensure return values are checked by providing a compile time error if a case is missing (as expressed in the first few examples of the readme).

I know it can, the compiler can do one more "automatic" unit test based on the type checking system.

But they decided not to add enums because it conflicted and overlapped too much with interfaces.

I just want to add "my" experience that personally, yes maybe you can argue enums are nice, but I never missed them in Go.

I personally agree with the Go team on how they argue and for me it would be a step back if they listened to the herd that does not take all sides of the story into consideration but just keeps pushing enums.

Try/catch is just a really bad thing all "hacky solution" alarm bells go off for me if you want to change error handling to giant try/catch blocks.

> But they decided not to add enums because it conflicted and overlapped too much with interfaces.

I'm very curious now about how it might conflict and/or overlap with interfaces.

To reach the goal of an enumeration type (and all the strong type-checking that that brings with it), enums could look as simple as:

    type DayNames enum {
       Sunday
       Monday
       Tuesday
       Wednesday
       Thursday
       Friday
       Saturday
    }
    ...
    func isFunDay (dow DayNames) {
       // This must fail to compile, because there is an unhandled enumeration
       switch {
          case Sunday: ...
          case Monday: ...
          case Tuesday: ...
          case Thursday: ...
          case Friday: ...
          case Saturday: ...
       }
       ...
    }
    ...
    isFunDay (0)   // Compile failure
    var x int
    isFunDay (x)   // Compile failure

And I don't see how that conflicts or overlaps with interfaces.

I think something like when a variable type in an enum was an interface it would destroy the galaxy or something, not 100% sure, would have to look it up... 1 sec.

Here you Go: https://go.dev/doc/faq#variant_types

> I think something like when a variable type in an enum was an interface it would destroy the galaxy or something,

Hah :-)

> Here you Go: https://go.dev/doc/faq#variant_types

Not quite the same: Variants are a constrained list of types. Enums are a constrained list of values.

Let's assume that I agree with the reasoning for not having a constrained list of types.

It still doesn't tell me why we can't have a constrained list of values.

I largely agree with your sentiment. Go’s simplicity is what makes it such a useful tool for me. It’s worth protecting, and that means setting a very high bar for proposals that add new things to the language.

However, 2 things I would be enthusiastic about if it got included in the language: - having ‘?’ As syntactic sugar for ‘if(err != nil) …’. Would make code more easily readable, and I think that is a benefit for programmers trying to keep things simple. - Sum Types. I’ve had a few cases where this would’ve been very useful. I consider the ‘var state customtype = iota’ a bit too easy to make mistakes with (eg exhaustive checking of options).

Like generics, I hope that when that happens, they take a very deliberate approach on doing it.

Your comment could have been a nice opinion that proves to a drive-by reader that needs can differ drastically between programmers.

But you ruined it with "fancy things" which shows offhand disregard and disrespect.

A question like "what do you need these features for?" would have been a better contribution to the forum.

I actually really have a disrespect for them. I'm in a constant fight against developers that want to translate code in almost the same code but "only using language features from the Advanced book".

I also wanted to add that I used inheritance only ONCE in all my years of writing Python in all other millions of lines of code inheritance was not the best solution.

This is my daily struggle as a CTO. People using waaayy too many "fancy" features of languages making it totally unreadable and unmaintainable.

It's their ego they want to show off how many complex language features they know. And it's ruining my codebases.

    > This is my daily struggle as a CTO

This is a nice humblebrag. Why does it matter that you are a CTO for this comment? It doesn't. It would better written as: "This is my daily struggle with my team."

Haha I actually thought about that maybe 8 times haha I just wrote it and pressed send but exactly that I wanted to edit later XD.

It's one thing to want your devs to produce readable code -- as a former CTO I also spent significant effort in teaching people that -- but it's completely another to be a curmudgeon and directly disregard valuable programming tools like the sum types.

Not sure why you are conflating both. Also inheritance was known to be the wrong tool for the job at least 15 years ago, maybe even 20. Back then people wrote Java books that said "prefer composition over inheritance" so your analogy didn't really land.

Everyone who uses sum types in production code agrees they reduce bugs.

Maybe it's time for you to retire.

Reply on news.ycombinator.com