Live data from Hacker News

Leveraging the Go Type System

gopherguides.com

41–50 of 112 posts

Re: Leveraging the Go Type System

#41

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.

Without Algebraic Data Types, Go is just awkward. This example could be so simple typed as the sum of string literals.

[deleted]

Re: Leveraging the Go Type System

#43

It doesn't take much "leveraging" to do this in a language with ADTs. E.g. Typescript 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";

The benefit to having a type is mainly IDE experience and catching it at compile time. It's easiest to say `Genre.WESTERN` than using the string `western` and hoping you didn't accidentally type `westrn` and get a runtime error.

Re: Leveraging the Go Type System

#44

It doesn't take much "leveraging" to do this in a language with ADTs. E.g. Typescript 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";

The benefit to having a type is mainly IDE experience and catching it at compile time. It's easiest to say `Genre.WESTERN` than using the string `western` and hoping you didn't accidentally type `westrn` and get a runtime error.

Compile time checks on the strings are exactly what you get with that TypeScript definition above.

Re: Leveraging the Go Type System

#45

It doesn't take much "leveraging" to do this in a language with ADTs. E.g. Typescript 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";

The benefit to having a type is mainly IDE experience and catching it at compile time. It's easiest to say `Genre.WESTERN` than using the string `western` and hoping you didn't accidentally type `westrn` and get a runtime error.

    const someBook: Book = {
      id: 1,
      name: "Title",
      genre: "wstern"
     // Compile error: [tsserver 2322] [E] Type '"westrn"' is not assignable to type 'Genre'.
    };
That's not how string literals work in Typescript. If you mis-type the string you'll get a compile error. It won't make it to runtime.

Re: Leveraging the Go Type System

#46
post #19

I had heard that the Go type system was just annoying and too simple to be useful, and this blog post has convinced me that that is 100% true.

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.

Re: Leveraging the Go Type System

#47

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 there with Go through various workarounds and with enough boilerplate (and no, I'm not one to complain about error handling or for loop boilerplate, but the boilerplate to workaround ADTs is much more tedious and much less discernible.

Re: Leveraging the Go Type System

#48

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.

Without Algebraic Data Types, Go is just awkward. This example could be so simple typed as the sum of string literals.

[deleted]

Re: Leveraging the Go Type System

#49

It doesn't take much "leveraging" to do this in a language with ADTs. E.g. Typescript 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";

As a JavaScript developer I once abhorred TypeScript, until I realized TypeScript's type system is really powerful, it can do something like > and >.

Mind. Blown.

Re: Leveraging the Go Type System

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

This is true, but I'll take these shortcomings over deficiencies in tooling, ecosystem, performance, learning curve, etc any day. In other words, I can ship software pretty easily with a suboptimal type system, but much less easily if I have to select for candidates with a decade of experience in a particular VM runtime or if the performant runtimes are incompatible with important parts of the ecosystem or if there is no sane package management tooling or if the ecosystem itself is lacking important high quality packages. I'm of the opinion that in-language features are overrated.
Post reply on HN