Live data from Hacker News

Leveraging the Go Type System

gopherguides.com

21–30 of 112 posts

Re: Leveraging the Go Type System

#21
There are times this makes sense to do (mapping an enum to a db without enum support eg mssql) but this isn’t how I’d do it.

Personally I use stringer[1] to handle all the string generation and then implement the valuer and scanner interfaces on that type. Boom transparent mapping between useful values and their corresponding db representation without having to write so much boilerplate.

[1] https://pkg.go.dev/golang.org/x/tools/cmd/stringer

Re: Leveraging the Go Type System

#22
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…

That boiler plate usually can be generated for you. See Go's stringer which does all the magic for you. All you have to do is define the type and constants, and a go generate directive.

Re: Leveraging the Go Type System

#23
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…

Is this compared to a good language or (say) server-side JavaScript because the languages I tend to use allow me to do that and Go looks looks very Algol-68-y from that perspective as opposed to some hyper abstract wonder-language.

Re: Leveraging the Go Type System

#24
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…

I think this is mostly a toy example. In the real world the Genre would have it's own data, books can belong to multiple Genres, and you'd need the concept of SubGenres. So you'd have:

Book

Genre

BookToGenre

GenreToGenre

Re: Leveraging the Go Type System

#25
post #22
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…

That boiler plate usually can be generated for you. See Go's stringer which does all the magic for you. All you have to do is define the type and constants, and a go generate directive.

would you have a sample code? sounds interesting

Re: Leveraging the Go Type System

#26
post #4

For an example with Go generation and using iota see stringer[0] and Rob Pike's related blog post[1] [0] https://pkg.go.dev/golang.org/x/tools/cmd/stringer [1] https://blog.golang.org/generate

Go has so many `go generate` tools to overcome its shortcomings, it's ridiculous.

Re: Leveraging the Go Type System

#27
I'm going to be honest, after writing some programs in Go a few years ago, I was hoping for something nicer by now. I know writing Go is good because it's boring, but all this boilerplate just feels like reading Java in 2005.

Re: Leveraging the Go Type System

#28
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.

Java has Enums, so why would you bother with all of this?

Re: Leveraging the Go Type System

#29
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.

[deleted]

Re: Leveraging the Go Type System

#30
post #4

For an example with Go generation and using iota see stringer[0] and Rob Pike's related blog post[1] [0] https://pkg.go.dev/golang.org/x/tools/cmd/stringer [1] https://blog.golang.org/generate

This is cool and something about Go that I hadn’t researched much yet. It does make me wonder, however, why not just include some higher level structure for this? Or even some method built into the compiler? It feels odd to have to install a dependency like `stringer` just to build. Do I had it to my go.mod file? Also, the comment structure, while flexible, could be greatly simplified for common cases like this if there was, for instance, an enum type.

I really do enjoy Go, but there are several examples of things like enums that are left out because there is some way of doing it otherwise to only the theoretical advantage of “elegance” at the cost of developer productivity.

Post reply on HN