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

Generics enabled by default in Go tip

go-review.googlesource.com

Post reply on HN
Print view View original

101–110 of 378 posts

Re: Generics enabled by default in Go tip

#101

Post by jolux »

tptacek wrote: post #98
jolux wrote: post #96

Earlier quoted context omitted.

There are certain things that just can’t be done without generics, though. Type safe higher order functions, type safe custom collections, etc. Of course, perhaps these are all just subjective to you, because you can still write any program you need without them. But not having this feature does constrain the set of type-safe programs you can write quite a bit.

I feel like it pretty much always turns out that the things you can't do without generics are, like, second-order things. Higher order functions, type safe custom collections, those are tools. What we care about mostly is what we actually build , and people build pretty much everything in every language, generics or not.

It depends what you’re building. If you’re writing a library to do those things, they may well be first order. Certain extremely useful patterns like parser combinators rely on them. And of course, the current answer is just “do something else instead.” But I don’t really see why this has to be the answer. Surely the decision to leave them out is just as subjective as a decision to add them.

Re: Generics enabled by default in Go tip

#102

Post by leshow »

jshen wrote: post #85
leshow wrote: post #76

Earlier quoted context omitted.

I'm well aware when they are useful, I've been using them in languages for the past 10 years. By the same token though, leaving type parameters out of the language has had far reaching implications outside of this "narrow" situation (I'll put forth that implementing a data structure isn't a narrow situation). Error handling and the lack of sum types also seem particularly egregious and are heavily influenced by the l…

I’ve been using them for the past 30 years and have come to a different conclusion. You have plenty of languages that do what you want. I hope go doesn’t lose what made it different

Oh sorry, you were saying lack of generics were the reason you could make sense of code easily, implying that if a language has generics you can't make sense of it. That seems juxtaposed to having used them for decades. In any case I can tell you're passionate about this so I think we can just agree to disagree.

That said I don't think there's much "hope", from the looks of things it is coming to Go.

Re: Generics enabled by default in Go tip

#104

Post by tapirl »

peter_l_downs wrote: post #4

Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX

Each Unwrap() call needs two OK() calls? Letting Unwrap return OK would be better?

BTW, the readability is really not good as Go 1.

Re: Generics enabled by default in Go tip

#105

Post by tannhaeuser »

Not entirely getting the hate/hype towards generics. What about run-time reflection and annotations, arguably an addition with more drastic consequences, and all things considered, not for the better IMO. Has anyone an opinion on using GraalVM/Java vs Golang?

Re: Generics enabled by default in Go tip

#106

Post by mseepgood »

pm90 wrote: post #90
buu700 wrote: post #18

Earlier quoted context omitted.

I personally think this will be a great thing for the quality of the language (no typed higher-order functions is a massive pain point as-is), but at the same time one could argue that this is an equally massive bait-and-switch for all the developers who prefer Go's original take on "simplicity".

Go is still pretty “simple”. They didn’t introduce a while loop. Adding generics would arguably “simplify” the language even further since you would presumably throw away a lot of duplicated code.

They can simplify code, but they don't simplify the language.

Re: Generics enabled by default in Go tip

#107

Post by takeda »

theshrike79 wrote: post #61
reissbaker wrote: post #52

Earlier quoted context omitted.

While it's true that some find it liberating, a large number don't — personally, I've written a fair amount of production Go code and found it unnecessarily verbose and repetitive in ways that generics would've helped. I imagine some of this is based on problem domain; if you're writing a web application for example, maybe you don't really need generics much. After all, how often do you need a function that logs in a…

You say "verbose and repetitive", I say "easy to read without any surprises". The verbose patterns (if err!= nil for example) make the code predictable to read, you notice the code smell of missing error handling really fast.

I think readability has multiple dimensions, and it really depends what you are looking for.

For example here's a code in Go to look for a Prime:

    func IsPrime(n int) bool {
        if n
It's readable as it is simple to understand what each line does.

Here for example is a code that does the same thing in Rust:

    fn is_prime(n: u64) -> bool {
        match n {
            0...1 => false,
            _ => !(2..n).any(|d| n % d == 0),
        }
    }
It's might seem more complex at first (what does match do, what 0...1 means, !(2..n) what is any() doing. But if you understand the language it actually this seem much simpler and you can quickly look at it and know exactly what it is doing. And because it is less verbose it is easier to grasp the bigger code.

I also noticed that while individual functions in Go are simple to understand and follow, you can still create complex, hard to follow and understand programs in Go.

Re: Generics enabled by default in Go tip

#108

Post by Santosh83 »

ramchip wrote: post #15
peter_l_downs wrote: post #4

Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX

> Viewing and/or sharing code snippets is not available in your country for legal reasons. This message might also appear if your country is misdetected. If you believe this is an error, please file an issue. Wow, interesting. I'm in Japan.

Shame as a species we can't even share information (literally bits on the wire) globally, even if tangible goods and movements are circumscribed by political borders.

Re: Generics enabled by default in Go tip

#109

Post by jrockway »

dmitriid wrote: post #77
reissbaker wrote: post #52

Earlier quoted context omitted.

While it's true that some find it liberating, a large number don't — personally, I've written a fair amount of production Go code and found it unnecessarily verbose and repetitive in ways that generics would've helped. I imagine some of this is based on problem domain; if you're writing a web application for example, maybe you don't really need generics much. After all, how often do you need a function that logs in a…

> if you're writing a web application for example, maybe you don't really need generics much All our microservices return a { result: ... } or a { result: ..., nextPageToken } We would definitely benefit from generic SingleResult and PagedResult . Instead, you copy-paste the same definitions over, and over, and over, and over again for every call.

I think I see what you're doing. Right now, each result type implements NextPager, which returns information about how to fetch the next page. You client can implement a utility like FetchNextPage:

    type NextPager interface {
        NextPage() PageSpec
    }
    func (c *Client) FetchNextPage(ctx context.Context, current NextPager) (interface{}, error) {
        ...
    }
Then for each type of paged object, you write:

   func (c *FooClient) FetchNextFoo(ctx context.Context, current Foo) (Foo, error) {
       next, err := c.client.FetchNextPage(ctx, current)
       ...
       if n, ok := next.(Foo); ok {
           return n, nil
       }
       return Foo{}, fmt.Errorf("unexpected type: got %T, want Foo", next)
   }
That's annoying. But, this problem has come up before with `sql`, which has rows.Next() and rows.Scan() to iterate over arbitrary row types, and you could use that as a model:

    pages := client.Query(...)
    defer pages.Close()
    for pages.Next() {
        var foo Foo
        if err := pages.Scan(&foo); err != nil { ... }
        // do something with the page
    }
Generics would let you enforce the type of `foo` at compile time, but it wouldn't save you many lines of code. I think you still have to write (or generate) a function like `func (c *Client) ListFoos(ctx context.Context, req ListFooRequest) (Paged[Foo], error) { ... }`. We hand-wave over that in the above example with a "..." passed to query (potentially possible if you retrive objects with a stringified query, like SQL or GraphQL), but that sounds like the hard and tedious part.

Let me conclude with a recommendation for gRPC and gRPC-gateway as a bridge to clients that don't want to speak gRPC. Then you can just return a "stream Foo", and the hard work is done for you. You call stream.Next() and get a Foo object ;)

Re: Generics enabled by default in Go tip

#110

Post by jshen »

leshow wrote: post #102
jshen wrote: post #85

Earlier quoted context omitted.

I’ve been using them for the past 30 years and have come to a different conclusion. You have plenty of languages that do what you want. I hope go doesn’t lose what made it different

Oh sorry, you were saying lack of generics were the reason you could make sense of code easily, implying that if a language has generics you can't make sense of it. That seems juxtaposed to having used them for decades. In any case I can tell you're passionate about this so I think we can just agree to disagree. That said I don't think there's much "hope", from the looks of things it is coming to Go.

I'm hoping that Go still keeps it's relative simplicity. It's lack of inheritance gives me hope that generics won't be as complicate as it is in other languages.

I understand generics well, I just find code bases that use a lot of abstractions harder to read than Go.

Post reply on HN