Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leveraging the Go Type System

gopherguides.com

Post reply on HN
Print view View original

11–20 of 112 posts

Re: Leveraging the Go Type System

#11

Post by benbjohnson »

corylanou1 wrote: post #7
torben-friis wrote: post #5

Semi related question: what resources do you recommend for go's state of the art regarding best practices, idiomatic project structure, tooling and the like? Preferably books, but I'll take anything. I searched recently and most of what I saw were either in depth books about the language itself, outdated blog posts, or non-relevant books that just happened to use go to explore an unrelated topic.

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/

Thanks for the mention, Cory. Great article, btw!

To the parent post, there are several articles on Go Beyond[1] that walk through development of an open-source, real-world application called WTF Dial[2]. The source is available on GitHub and you can ask Go application design questions on the Discussions board[3].

[1] https://www.gobeyond.dev/

[2] https://wtfdial.com/

[3] https://github.com/benbjohnson/wtf/discussions

Re: Leveraging the Go Type System

#12

Post by phyrex »

Frankly, this article has the opposite effect of convincing me. The author starts with a perfectly reasonable data model and munges it for some questionable space savings (that only apply in the dumbest of databases that don't do any sort of compression), for the price of a lot of boilerplate, and significantly less insight into the data if you look at it in serialized format (either directly in the database or on the wire). Maybe someone can explain to me how this is supposed to be better?

Re: Leveraging the Go Type System

#13

Post by corylanou1 »

phyrex wrote: post #12

Frankly, this article has the opposite effect of convincing me. The author starts with a perfectly reasonable data model and munges it for some questionable space savings (that only apply in the dumbest of databases that don't do any sort of compression), for the price of a lot of boilerplate, and significantly less insight into the data if you look at it in serialized format (either directly in the database or on th…

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.

Re: Leveraging the Go Type System

#14

Post by shadowgovt »

phyrex wrote: post #12

Frankly, this article has the opposite effect of convincing me. The author starts with a perfectly reasonable data model and munges it for some questionable space savings (that only apply in the dumbest of databases that don't do any sort of compression), for the price of a lot of boilerplate, and significantly less insight into the data if you look at it in serialized format (either directly in the database or on th…

One of Go's strengths is that it should make it easier to swing between the optimized abstraction and the less-optimized abstraction. If you start with that data represented as strings and then find yourself backed into a performance corner and need to change the representation, Go types and type-based compile-time method selection can make it a bit easier to make that change.

Even in this era of fast computers and preposterously large storage, one sometimes hits a situation where the way to get the improvements you need is to start number-representing your strings.

Re: Leveraging the Go Type System

#15

Post by jerluc »

marcus_holmes wrote: post #8

The points about iota are interesting. I always define the first constant as "unknown" when defining a set of iota-driven constants. That way the zero value is "unknown" so if I create a new struct with no initialiser it doesn't accidentally inherit a value I didn't mean it to have, and instead gets the "unknown" value. It also doesn't touch on the other useful "system" funcs to include on a type (Scan, Value, Marsha…

I feel like there are times when zero values can make things awkward (e.g. boolean flags often need to be expressed in the "negative" form because the zero value is false), but this is a great idea for iota!

Re: Leveraging the Go Type System

#16

Post by corylanou1 »

shadowgovt wrote: post #14
phyrex wrote: post #12

Frankly, this article has the opposite effect of convincing me. The author starts with a perfectly reasonable data model and munges it for some questionable space savings (that only apply in the dumbest of databases that don't do any sort of compression), for the price of a lot of boilerplate, and significantly less insight into the data if you look at it in serialized format (either directly in the database or on th…

One of Go's strengths is that it should make it easier to swing between the optimized abstraction and the less-optimized abstraction. If you start with that data represented as strings and then find yourself backed into a performance corner and need to change the representation, Go types and type-based compile-time method selection can make it a bit easier to make that change. Even in this era of fast computers and p…

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.

Re: Leveraging the Go Type System

#18

Post by newlisper »

phyrex wrote: post #12

Frankly, this article has the opposite effect of convincing me. The author starts with a perfectly reasonable data model and munges it for some questionable space savings (that only apply in the dumbest of databases that don't do any sort of compression), for the price of a lot of boilerplate, and significantly less insight into the data if you look at it in serialized format (either directly in the database or on th…

Bringing Java's premature over-engineered over-abstracted practices to Go.

Re: Leveraging the Go Type System

#20

Post by denysvitali »

I'm a Go fan and I love the language, but what I can't really stand is the fact that enums do not really exist, and it's representation (stringification, for example) is not implemented by default.

So far I still haven't found a clean way to have proper enums, and this article shows us that unfortunately neither the author has :(

Post reply on HN