[Kamq]

> instead of ever being able to know through the type system that you have a meaningful value.

That's... not what I'm looking for out of my type system. I'm mostly looking for autocomplete and possibly better perf because the compiler has size information. I really hate having to be a type astronaut when I work in scala.

So, I mean, valid point. And I do cede that point. But it's kind of like telling me that my car doesn't have a bowling alley.

[stouset]

Making an analogy between a car with a bowling alley being as useful as having the ability to know you have a valid selection from a list of choices does not exactly reflect well on your priorities.

[Kamq]

I take it you use enums fairly regularly?

I don't really use them that much, so they're superfluous for the most part. Sort of like a car having a bowling alley. I mean, I'll take them if it doesn't complicate the language or impact compile time, but if they're doing to do either of those, I'd rather just leave them.

Adding default branches into the couple of switch statements and a couple spots for custom json parsing that return errors for values outside the set doesn't seem like a bad tradeoff.

[aatd86]

It's not optimal but one can still implement enums in userland using struct and methods returning a comparable unexported type.

[the_gipsy]

More like a car without ABS and no TC. It's cheaper and you can drive just more carefully, but you're more likely to crash.

[Kamq]

I think that's a bad analogy because I actually use ABS and TC. I don't really use an enum heavy style of programming. Maybe twice per project or so. Putting a default branch in a couple switch statements also seems to get me back the same safety (although I'd rather detect the error early and return it in a custom UnmarshalJSON method for the type).

I also imagine I'd use a bowling alley in my car ~2 times per year, tops. So that seems like a better analogy to me.

edit: I guess I should bring up that I don't use go's switch statement much either, and when I do, 99% of the time I'm using the naked switch as more of an analog to lisp's cond clause.

[ParetoOptimal]

> I think that's a bad analogy because I actually use ABS and TC. I don't really use an enum heavy style of programming.

The point the others are making is you are using a less safe type of programming equivalent to driving without ABS and TC.

From your point of view, "TC and ABS is useful so I use it unlike enums".

From their point of view though, you are the person not using ABS and TC insisting that they offer nothing useful.

[Kamq]

To continue the analogy, since I don't use enums, I'm also the person who isn't driving the car.

Can you explain how owning a car without ABS and not driving it is less safe?

Edit: Wait, or am I not using breaks? I think the analogy changed slightly during this whole process.

[ParetoOptimal]

> Can you explain how owning a car without ABS and not driving it is less safe?

I don't know that it is, I'm speaking based on the implication in this thread that no-enum and no-ABS people are overconfident to a fault.

I do believe that those who claim they don't need enums, static typing, etc are probably overconfident and have a strong desire or need to feel more control.

I'm not sure though, at least for GC'd languages, how enums sacrifice control.

[the_gipsy]

There are still people that swear that they can brake better than ABS. Until they do a side-by-side test.

Re: custom UnmarshalJson implementation - you still have to remember, and do it for every serialized format (e.g. sql).

A default case in a switch only solves, well, switching. If a rogue value comes in, it will go out somewhere. E.g. json to sql or whatever things are moving.

[Kamq]

> A default case in a switch only solves, well, switching. If a rogue value comes in, it will go out somewhere. E.g. json to sql or whatever things are moving.

I mean, yeah, but eventually you have to do something with it. And the only useful thing you can really do with an enum is switch on it...