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

241–250 of 378 posts

Re: Generics enabled by default in Go tip

#241

Post by the_gipsy »

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.

In rust you have to swallow an error quite explicitly. In go it’s extremely easy to swallow one "err”, by assigning to some previous one which was already checked.

Re: Generics enabled by default in Go tip

#242

Post by erik_seaberg »

masklinn wrote: post #234
erik_seaberg wrote: post #225

Earlier quoted context omitted.

I was thinking of generic functions rather than (non-generic) methods on generic types. Unfortunately it looks like reflection can’t look up functions in a module at all , which is surprisingly broken.

> Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken. The more time passes the more I think ubiquitous reflection in statically typed languages is what's broken (and a reflection (heh) of deep limitations of the language). So while I could understand having issues with generics breaking existing reflection code (which doesn't seem to be the case), I'm not g…

What good are top-level functions if they’re unreachable from any script interpreter or management RPC server or other languages’ FFI?

Re: Generics enabled by default in Go tip

#243

Post by spion »

iainmerrick wrote: post #237
SideburnsOfDoom wrote: post #219

Earlier quoted context omitted.

> Go adds generics. HN thread: I don't want this If generics are a good idea for a language, then it's better to add them in version 0.01 of the language and build up from there with generics as an intrinsic part of the language and standard libraries. No, I don't want _tacked on_ generics. Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that t…

No, I don't want _tacked on_ generics. What languages in your opinion have good, non-tacked-on generics? Are they generally better than other languages? Here are some pretty successful languages that gained generics after maturity: C++, Java, C#, TypeScript (based on JavaScript), Objective-C, even Python.

The libraries are better because they're designed with generics in mind.

Most C# libraries in use today were built after generics were added, and there never was a large ecosystem already developed at the time

Java has had lots of libraries thrown away due to initial lack of generics and a lot of painful migration e.g. https://docs.oracle.com/javase/tutorial/extra/generics/conve...

A good parallel would be async-await in JS and nodejs. The entire core library and a huge percentage of the ecosystem ended up being really awkward to use after the introduction of async await. The whole ecosystem is now one big giant mess.

Re: Generics enabled by default in Go tip

#244

Post by dmitriid »

dmitriid wrote: post #135
jrockway wrote: post #109

Earlier quoted context omitted.

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) FetchN…

> Generics would let you enforce the type of `foo` at compile time, but it wouldn't save you many lines of code. You literally showed that "for each type of paged object, you write ". Where with generics you just have a single generic function. > We hand-wave over that in the above example with The problem is: there's no hand-waving in reality.

I'm traveling, so can't properly expand on what I said, but without generics the choice was:

- repeat unnecessary bolierplate code for every single return type

- skip types completely and use a function that accepts interface{} as a parameter and assigns whatever to that variable

Neither are really acceptable in my opinion. And both will be greatly simplified and improved by generics.

Re: Generics enabled by default in Go tip

#245

Post by SideburnsOfDoom »

iainmerrick wrote: post #237
SideburnsOfDoom wrote: post #219

Earlier quoted context omitted.

> Go adds generics. HN thread: I don't want this If generics are a good idea for a language, then it's better to add them in version 0.01 of the language and build up from there with generics as an intrinsic part of the language and standard libraries. No, I don't want _tacked on_ generics. Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that t…

No, I don't want _tacked on_ generics. What languages in your opinion have good, non-tacked-on generics? Are they generally better than other languages? Here are some pretty successful languages that gained generics after maturity: C++, Java, C#, TypeScript (based on JavaScript), Objective-C, even Python.

> What languages in your opinion have good, non-tacked-on generics?

It's cliche, but it's clear that generics like Result ( https://doc.rust-lang.org/std/result/ ) and Option ( https://doc.rust-lang.org/std/option/ ) are fundamental to Rust's design from the start.

> some pretty successful languages that gained generics after maturity

I'm very familiar with C#, of course it is a "pretty successful language", no kidding. I did not say otherwise, I said that there are "compromises" associated with adding generics in V2.

And there are: e.g. starting with collection types, interfaces and base types in pairs, such as List and List, IList and IList, IEnumerable and IEnumerable, etc ad nauseam. Then Delegates that precede Func and Action.

I suggest that you reread my comment above; the point is not just that adding generics later causes complication (historic record is clear that it does).

The point is that generics were _not_ proven in mainstream OO programming when c# 1.0 was released in 2002, but this has changed; now they are. Designs done in the last few years can avoid this complication: Ether your language wants them from the start, or it intends other ways to deal with the same kinds of problems.

Re: Generics enabled by default in Go tip

#247

Post by carnitine »

theshrike79 wrote: post #68
aptenoforst wrote: post #56

Earlier quoted context omitted.

How is a generic data structure a COMPLEX ABSTRACTION?

If people would stick to common generic data structures (like a map/list that can handle any datatype), i'd be fine with abstractions. But some people have a tendency to play code golf with their codebases. I have, for example, encountered a "generic data structure" that looked like a normal linked list on the surface. BUT, it actually sorted the largest three items in the first 3 cells and the average in the 4th. Th…

What does that have to do with generics? Surely they’d have written the same bad code monomorphised?

Re: Generics enabled by default in Go tip

#248

Post by 4ad »

erik_seaberg wrote: post #242
masklinn wrote: post #234

Earlier quoted context omitted.

> Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken. The more time passes the more I think ubiquitous reflection in statically typed languages is what's broken (and a reflection (heh) of deep limitations of the language). So while I could understand having issues with generics breaking existing reflection code (which doesn't seem to be the case), I'm not g…

What good are top-level functions if they’re unreachable from any script interpreter or management RPC server or other languages’ FFI?

Functions are useful because you can call them from your program.

Re: Generics enabled by default in Go tip

#249

Post by zimpenfish »

anothernewdude wrote: post #158
tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

The people who cared about Go not having generics (myself included) moved on. The time for a well designed language with Generics was five years ago. The only people who care about Go now are the ones who convinced themselves that casting from empty interfaces was okay.

Dunno about the rest of the world but London definitely seems to be embracing Go - many more jobs going now than even a year ago.

Re: Generics enabled by default in Go tip

#250

Post by _ph_ »

I like Go very much, a huge role plays its simplicity. In my career, I have been much more often bitten by having to deal with the complexity of a language then by not being able to do things, because a language feature is missing. That is, why I like Go so much. It strikes a great balance between important high-level features (GC, first class functions and closures) and still being a simple language (like Scheme is, in a sense they are very comparable in my eyes). The interface concept is great for covering a lot of cases. That is, why so far, I have not missed generics much and was rather reluctant to the constant wishes to add them to the language.

On the other side, there are cases, even if they are not very frequent, where generics do help a lot. Just the new slices package allone almost justifies the addition of generics. Furthermore, the proposal looks very much Go-like. As a consequence, I am quite looking forward to try them out and used responsibly[1], they can be a great addition to the Go universe.

1: I think the situation is somewhat similar to Lisp macros. Normally, a codebase rarely requires macros and readability is better, if you avoid creating too many macros. But occasionally there are situations, where using a macro tremendeously increases code quality. Both implementation and readability-wise. There macros should be used and it is great to have them available.

Post reply on HN