Say Goodbye to Magic Numbers: Using "Enums" in Golang!

[@FloWoelki]

This video was more like an ad-hoc video than a well-planned video (I didn't get much sleep that night). There were many errors in the code and in the explanation of the code (Go conventions and standard constants, which are no enums). I'm sorry for that, but that shouldn't be an excuse. The point of the channel is to have as much high-quality content about software engineering as possible, and I'll work on that! In the future, I'll focus more on planning the scripts and code beforehand! Nevertheless, I am grateful to have such a lovely community. Please read the other comments if you want to learn more!

[@tobyzieglerrr]

You having a bad day seems so much better than me having a good day haha... dont worry. As long as you are having fun doing these, i am happy and thankfu.

[@FloWoelki]

Thank you for the kind words! :D I have a lot of fun making these videos, but especially for programming, it's important to be factual and correct because beginners can always look at these videos and then might learn the wrong thing.

[@hirenpandit8499]

Last part where you mentioned Stringer interface was really fascinating for someone like me coming from Java background… great content

[@fluchschule]

When you've seen what other languages do with enums, and how nice it is to use them, you look at this with sad eyes.

[@soto5987]

yes, switch + enums is so valuable in rust, java and go refuses see the value of it :(

[@FloWoelki]

Yeah, I agree. But still, the primary purpose of the language is to be simple, and it fully fulfills that promise :D

[@orterves]

"Everything should be as simple as it can be, but not simpler" In this case, Go has made it simpler. Sum types are simple and powerful, to not have them isn't simple it's just ignorant. And the way go does it, the fields are in the package namespace, all mashed together with every other function, var or whatever - ugly and near useless, and prone to error I really like go, but this feature is particularly half-baked

[@cat-.-]

@@FloWoelkiusing tuples to express mutually exclusive constructs like is the convention in go is simple on the surface but deeply fucked in actuality

[@jaysistar2711]

​@@soto5987I think he was talking about Rust, Haxe, and OCAML. They all use enums to represent a full discriminated union, not just the discriminate (value used in switch or match).

[@vladimirlysenko384]

Thank you, i really love your content and your manner of explanation :)

[@crysiank]

I didn't like enums but now I know more and like them a bit more. Thanks for this

[@FloWoelki]

Good stuff that you've learned something from the video! :)

[@aritrachatterjee9496]

go's simplicity is why I love it so much,

[@FloWoelki]

Same here, but sometimes it can be too simple :D

[@tobyzieglerrr]

@@FloWoelki This is one (of the very few) points where i think go really could and should improve... Having a typed enum, instead of basically an alias to a string or int, i think most can agree that would be good to have. But i doubt it ever will arrive in go, due to some very basic decisions early on in the language design!?

[@Dom-zy1qy]

Would be a better language if the enums were just like they are in C.

[@SUN-mf5sk]

The main difference between enums and consts is that enums have names. Since all declarations within a package are visible in Go, we have a number of constants with general visibility. Personally, I find this confusing. And you can't do this either: func returnEnum() EnumType {}. I really like Go, but using iota constants as enums is an unpleasant crutch for me.

[@SUN-mf5sk]

And yes, there is the Odin language. For some reason, it remains very simple because of the presence of enums and unions.

[@C4CH3S]

@@SUN-mf5sk I agree. enums and unions should be added to the language. i've read somewhere that unions may not be possible due performance reasons, the compiler may slow down quite a bit. but I think string unions/enums should be fine, and would make the language feel much better to use.

[@mateusz5216]

I know what you want to present, but these are bad examples, unfortunately, and these may encourage writing a terrible code. First of first: if you compare enums from Rust (just for example) you have full compiler support - we can't have same in Go, unfortunately. Full compiler support means you will take 100% from this unless your app won't compile. Simple as that. Another problem, your second example: those are just constant strings, real enum you have different type. I can imagine in the code someone will mix "UDP" with "TCP" in a condition and that won't be caught by the compiler by any means even if it's wrong. It's just a prettier version of variable but nothing more. Of course, iota "official" workaround is not any better here. There are some enum libs in Go that are better than these examples but still: problematic. There is a 4rd approach: struct + methods to determine "correct enum variant" (citation because it's Go), but this is a lot of code and usually more code is more error-prone. In Rust you don't have to as this is fully supported by the lang. Language semantics should encourage you to write simpler and cleaner code, and this is the problem with the current version of Go. I hope for good enums someday in the future, but for now I would be careful with these propositions that make larger burden in a codebase.

[@FloWoelki]

Thank you for the detailed feedback. You raise valid points about the limitations of enum implementations in Go compared to languages like Rust! It's true about the constant string values, which was a bad example. I'll be more careful with the examples I'll actually present in the future! Thank you!

[@nicholasbicholas]

You're right that a constant value is not the same as an enum, but a constant will always be better than a string literal. It's not about "mixing up UDP with TCP", it's about magic values, removing the possibility of a typo, getting slightly better LSP support, etc.

[@nicholasbicholas]

I never knew you could use iota like that! My mind went immediately to bitwise flags using the bit shift operator, something like 1

[@FloWoelki]

Incredible that you've learned something! So glad to hear that :)

[@devopsislove]

Top! Thank you!

[@sloan00]

iota as a keyword looks really cursed... Does Go reject a variable or constant named with "iota"?

[@FloWoelki]

I agree! But yes it does reject a constant named "iota".

[@minma02262]

iota makes me uncomfortable. Someone changes the order indirectly, you get a subtle bug.

[@sighup124]

“Enums” in go… :/

[@botyironcastle]

I want to love go but it sucks :( , it doesnt have typesafe enums, readonly props, marker interfaces, explicit interface decl, discriminated unions, required fields, pattern matching, adhoc polymorphism...

[@botyironcastle]

no nameof(), no optional parameters

[@botyironcastle]

no default field values in structs

[@anon_y_mousse]

Not your fault, but the more I learn about Go, the more I hate this language. It's especially awful that this is how they implement enums. I can't say as though I like them too much in Rust either, because it basically implements tagged unions, but at least it makes a bit more sense there. I feel like all the issues that people have with them in C were a solved issue decades ago because of X macros, but it seems as though no one learns about X macros anymore, and some languages like to gank their macro systems by not having macros.