10 ms·
All I want is typesafe efficient higher order list operations like map, filter, reduce, flatmap, zip, takeUntil, etc. I don't care if Go puts them into the stdl
by jadbox 8y ago
All I want is typesafe efficient higher order list operations like map, filter, reduce, flatmap, zip, takeUntil, etc. I don't care if Go puts them into the stdlib and only allows these operators to use special internal generics to operate. If Go had a robust higher order std library like this, I would stop asking for generics.
Again, must be typesafe and zero overhead.
- bradfitz 8y agoOne of the main motivations for adding generics is that we could then put typesafe algorithms and data structures in the standard library.
- quotemstr 8y agoAnd make the standard library unmagical? One of the things I've always disliked about Go is how stdlib provides magic facilities unavailable to user code.
- icholy 8y agoWhat's magical about the stdlib?
- grey-area 8y agoMaybe they meant the language, which has some generic functions like append or delete - instead of those functions being attached to a data type or accepting any type, they only act on built-in types. I doubt any of that would change though given the stated goal of remaining compatible in most cases.
- SamWhited 8y agoThere are a handful of packages (time and some stuff in os for example) that are tied into the runtime and can't be rewritten outside the standard library. It's not a huge amount, and some of it can probably be fixed in the future.
- bradfitz 8y agoI agree, but there's not much, and it's usually for decent reasons: * the "time" package hooks into the Go scheduler. * the "reflect" package needs type information out of the runtime. * the "net" package hooks into the Go scheduler a bit. But way less than it used to. I think you might even be able to do this all yourself outside of std nowadays. What else? Our rough plan going forward is to actually move a bunch of the stdlib elsewhere but ship copies/caches of tagged versions with Go releases. So maybe "encoding/json" is really an alias for "golang.org/std/encoding/json" and Go 1.13.0 ships with version 1.13.0 of golang.org/std/encoding/json. But if you need a fix, feature, or optimization sooner than 6 months when 1.14.0 comes out, you can update earlier.
- aleksi 8y agoMy guess that quotemstr meant builtins: append, copy, range "protocol", etc.
- TheDong 8y agoThere are many examples of things builtins can do which user-code can't: 1. The constructs like "x <- chan" and "x, ok <- chan" (and map indexing and so on) are only available to builtin types. It's impossible to write a thing like "x, ok <- chan" where it either panics or doesn't depending on if the caller wanted two or one return values. 2. generic types, like 'map' and 'chan'. 3. 'len' can't be implemented for a user type, e.g. "len(myCustomWorkQueue)" doesn't work. 4. range working without going through weird hoops (like returning a channel and keeping a goroutine around to feed it) 5. Reserving large blocks of memory up front (e.g. as 'make' can do for slices and maps) in an efficient manner (e.g. make(myCustomWorkQueue, 0, 20) doesn't work)
- deleted 8y ago[deleted]
- sdegutis 8y agoWhat changed? Why is the Go team finally considering this now, when it has been requested for these exact reasons by many credible developers since Go's beginning? EDIT: Yes, something has changed. They always said "no, but maybe later" and now it's "ok how about now". That is a big change and I am just asking what's the reason for it.
- m_sahaf 8y agoNothing changed. It wasn't off the table to begin with. See: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
- coldtea 8y agoThe question of the parent boils down to "what put it on the menu". So, yeah, it was always "on the table" in some hazy, we'll see later, way, but not like that.
- BurningCycles 8y agoLikely because they have now figured out implementations of these features which they feel work well with the rest of the language design.
- sagichmal 8y agoI think a good faith reading of the circumstance would lead one to conclude that the passage of time, and other, higher-priority and lower-cost-of-implementation issues being addressed, have put these issues on the menu.
- cridenour 8y agoBecause now is later than when they said later?
- ianlancetaylor 8y agoA year ago we said it was time to move toward Go 2: https://blog.golang.org/toward-go2 https://blog.golang.org/toward-go2 . This is another step in that direction.
- tejasmanohar 8y agoWhat if generics were just implemented internally in Go? IMO, there are good use cases, like generic numbers (int32, int64, etc.), list processing, etc. There's already precedence for this with map[A]B, make(), etc.
- ori_b 8y agoThose are the things that I don't want to see in Go, honestly.
- pwm 8y agoI'm curious: why not?
- ori_b 8y agoGenerally, chaining things in the style that encourages that makes it harder to debug the code, harder to step through it in my head or on paper, and harder to compile to performant code. I'd rather see loops.
- bschwindHN 8y agoOn the other hand, you're less likely to need to debug those things because they've been implemented once, correctly. A manually-written filter, map, etc. will pretty much always have a higher probability of containing a bug. And in languages that have these features, I've never found it difficult to debug. What issues have you had in the past?
- ori_b 8y agoI've almost never had issues with manually written filters/maps -- at least, not with the iteration itself. On the other hand, having to untangle stack traces of closures of closures that have been passed through closures does slow me down when the function that's being mapped is buggy.
- bschwindHN 8y agoI guess I've never run into issues where a map or filter slowed me down for debugging, most languages will pretty easily show you where the error occurred. And if you're `map`ping and `filter`ing with pure functions, debugging is pretty simple because you just need the input that went into the buggy function. A good compiler will also optimize the closures into something you'd write by hand in Go. Overall I'm glad to see Go get these nice tools for more easily working with collections.
- gekkonier 8y agoSo you want a Lisp with other syntax, right?
- coldtea 8y agoYou say it like it's a bad thing.
- gekkonier 8y agoI was just curious, because those functionionality wished is in nearly every list processor, no mather what syntax used. And if not you macro that away, right?
- codr4 8y agoThat's about right. And gradual types, multi methods, generics and tight integration with C++: [0]. Dylan was too long winded for my taste, as are most modern attempts. [0] https://github.com/codr4life/snabl https://github.com/codr4life/snabl
- platinumrad 8y agoAt that point why not just add generics...
- nine_k 8y agoLisp tends to build abstractions, too, and it also does that via macros, which are even harder to mentally parse unless you have a habit. I'd say that to attain simplicity and clarity, you have to limit the use of abstraction. OTOH there's no way to avoid abstraction at all; programming is all about abstraction. If the means of abstraction are not powerful enough, copy-paste programming and boilerplate proliferate, making code less maintainable and harder to understand.
- platinumrad 8y agoIn my opinion, implementing these higher order functions with the help of one powerful abstraction (generics) is much simpler than having to deal with a bunch of special cased weaker abstractions (magic map, magic filter, magic reduce, magic...).
- krylon 8y agoI basically agree. I still think, while we're at it, making Generics a general feature of the language would probably be easier than adding all kinds of special cases. But yeah, if Go just added a generic map/filter mechanism (Python's list comprehensions (in turn inherited from Haskell) look very nice), that would cover about %75 of the use cases I want Generics for. Add a generic mechanism to use the range operator with user-defined types, and we're at about 95%.
- thiht 8y ago> Python's list comprehensions (in turn inherited from Haskell) look very nice Do they? I find them hard to read and hard to chain. I tend to prefer basic map, filter, reduce methods
- krylon 8y agoMmmh, that is a good point. I never used nested list comprehensions, to be honest, and I have not used Python in a couple of years. For non-nested cases, they are very nice, though. OTOH, I never used nested map/remove-if constructs in Lisp, because that, too, can get rather annoying to read.
- AndyMcConachie 8y agoI agree with this sentiment completely. Of course, if the only way to get these wonderful list operations is generics, then I guess I want generics, too.
- nemo1618 8y agoYou might be interested in my project: https://github.com/lukechampine/ply https://github.com/lukechampine/ply The idea is that when people say "generics", they usually just mean map/filter/reduce. So ply just bakes those into the language directly instead of adding new generic programming facilities.