corylanou1

Intro video here as well to explain what/why I wrote this: https://www.youtube.com/watch?v=SE_Noc3T_DY

It might be a little premature to judge an entire language on an introduction article for beginners. This article isn't intended to show every possible way Go can solve a problem, but intended to show people new to Go different ways to think about types. In a production scenario, it's unlikely I would use this solution. This is really an "academic" exercise in types for Go, not a practical application.

That's a great point. Anyone who has spent significant time with Go knows how easy it is to do a large refactor (or even a minor one) due to it being a types language.

And yes, you may not start with ints, but you could easily add code for the marshal/unmarshal later on to convert those strings to ints for serialization purposes. And it wouldn't require a change to any of your other code, not to mention that if you stored these values in a database already you don't need to perform a migration either.

You aren't wrong. I think it depends on what your needs are. As well as what the scenarios are.

If you are serializing this data a lot, then having ints vs strings is a significant advantage.

Again, it depends on your use case. If you don't care about serialization size, then I agree, it's extra effort that you may not need.

Agreed. There are a couple of clever ways to handle iota, but as my next article suggests, in general, I steer away from them if you really just need constants.

I didn't go into any of the Scan/Value/Marshal etc as it was a little beyond the scope of this article. I can certainly do a follow up article on it though

Thanks for the feedback!

Well, we obviously have paid courses that cover all this, but if you want my personal opinion on package layout, Ben Johnson really has a great article on it here: https://www.gobeyond.dev/packages-as-layers/

In a way, yes. Go doesn't have the concept of enums, so this is as close as it gets.