31–40 of 112 posts
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.
It needs sum types and pattern matching. Once you have used them, not having them is a huge gray void. Const expr, interfaces, sum types and pattern matching get you 85% of the way there.
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.
type Book = {
id: number;
name: string;
genre: Genre;
};
type Genre =
| "Adventure"
| "Comic"
| "Crime"
| "Fiction"
| "Fantasy"
| "Historical"
| "Horror"
| "Magic"
| "Mystery"
| "Philosophical"
| "Political"
| "Romance"
| "Science"
| "Superhero"
| "Thriller"
| "Western";Earlier quoted context omitted.
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 s…
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.
Some people love reinventing the past.
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.
Although we did survive with them and delivered code into production, it doesn't mean we keep using them 20-30 years later.
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 :(
I love Go for many decisions that have been made during its development, but the handling of enumerations is certainly not part of it.