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

61–70 of 112 posts

Re: Leveraging the Go Type System

#61

Post by saagarjha »

shadowgovt wrote: post #57
gher-shyu3i wrote: post #52

Earlier quoted context omitted.

Go has many shortcomings that make it difficult and extremely annoying to do refactorings. Things like no constructors where types are declared as follows A { Field1: field1, Field2, field2, } Now adding a new field to A would require ensuring that all code paths initialize Field3, otherwise you're going to have silent errors at runtime. This has been solved ages ago in Java and C# and similar languages by means of c…

A constructor is just a function though... If I add a new field to a Java class and fail to add its initialization to the constructor, I have the exact same problem because Java initializes the field to its default value when the constructor is called. You are correct that every situation where the struct in Go is initialized "bare" would need to be addressed if a field is added, but Go considers this a feature, not…

Usually you would create a constructor without that parameter which sets the field to something backwards-compatible.

Re: Leveraging the Go Type System

#63

Post by morelisp »

IMO this article really does language learners a disservice by stopping before at least mentioning stringer, which is even more critical to cleaning this up than iota (which does get a mention). It doesn't only generate most of the boilerplate code but does so in a safer and more efficient manner.

On the other hand, the efficiency concern it presents is real, and just repeating "sum types" is not, alone, enough to address it. Many languages with sum types would still store, and even more still serialize, a string.

Re: Leveraging the Go Type System

#64

Post by morelisp »

nonameiguess wrote: post #53

"Make Genre an int instead of string to save space, but then bake the same strings into the String method of Genre anyway." I don't understand why you would ever want to possibly save space in a database at the cost of consuming it in your binaries instead. You're almost certain to deploy more copies of your binaries than you are of your database.

Are you going to deploy more copies of your binary than rows in your database? Or points in an event stream?

Plenty of problem spaces still wish to repeat the same value many times and give it a more human readable name when necessary and not coordinate a shared DB connection or even a dynamic string pool.

Re: Leveraging the Go Type System

#65

Post by mssundaram »

throwaway894345 wrote: post #47
denysvitali wrote: post #20

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 don't mind that the compiler doesn't provide a default string implementation by default. I'm happy to use string values in my enums (in most cases const string vs int doesn't matter much for performance) for convenience; what I do wish for is full-blown ADTs. I want to be able to express `'Hello' | 'World' | 42 | struct{Name string, Age int} | []int` and know that the compiler will enforce. You can sort of get ther…

Do you have any examples of how you would implement a makeshift sum type like your example?

Re: Leveraging the Go Type System

#66

Post by mssundaram »

musingsole wrote: post #62

I am once again underwhelmed by the amazing might of a type system.

I hope you mean Golang's type system. It is indeed underwhelming. However it is arguably the poorest type system in popular usage. Therr exists much better, which I encourage you to explore - Typescript, Haskell, Rust

Re: Leveraging the Go Type System

#67

Post by jerf »

cdelsolar wrote: post #2

You can also use `go generate` to generate the code that translates constants into strings.

That's kind of misleading, like there's some sort of built-in support in some sort of go command that does that already.

"go generate" is really a red herring. It's completely meaningless. It allows you to define some commands that get run when you type "go generate", but... if I define a shell script called "blah", I can get some commands to run every time I type "blah". go generate doesn't do anything useful.

Re: Leveraging the Go Type System

#68

Post by morelisp »

gher-shyu3i wrote: post #54
lhorie wrote: post #51

Personally, I think the only part that makes sense is making a type to hide the implementation. That String() method is kinda nasty: It's O(n), and you need to edit it every time a category gets added/removed/changed. I think it'd make more sense to just make a idiomatic struct: type Genre struct { id int name string } func New(id int, name string) Genre { return Genre {id, name} } Then, you can define your categorie…

> Then, you can define your categories normally: > var ( > Adventure = genre.New(1, "Adventure") > Comic = genre.New(2, "Comic") > // etc > ) Yet there is nothing preventing anyone from reassigning Adventure to genre.New(2, "Comic") or some other arbitrary value. The fact that golang doesn't have the equivalent of Java's `final` is just poor design.

> The fact that golang doesn't have the equivalent of Java's `final` is just poor design.

That Java dropped C++-style `const` is also poor design.

We're just all really bad at this.

Re: Leveraging the Go Type System

#69

Post by Groxx »

beatbrot wrote: post #3

So what you are describing is enums but way more complicated?

And unsafe, since you can trivially make a `Genre(1138)` and that's correct, compile-able code.

The same is true for a `Genre(0)`, which is easy to make by accident with just a `var genre Genre` declaration (that's a `Genre(0)` already). Or by ignoring an error return, like in `json.Unmarshal(data, &genre)` (that func returns an error, but that fact is invisible in text, and you are not required to assign or handle it. fun for code reviews!).

You can also have a Genre-arg func like `func GenreToString(g Genre) string` and call it with `GenreToString(12345)` and that'll also compile.

---

Go does not have anything even remotely like enums. It has a short-hand for auto-incrementing constants, nothing more. As if that were somehow the most valuable part of constants / enums.

Re: Leveraging the Go Type System

#70

Post by shadowgovt »

mhh__ wrote: post #23
shadowgovt wrote: post #14

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…

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.

What languages do you tend to use?
Post reply on HN