4 ms·

I recently saw a go generic data structures library in the wild: https://github.com/zyedidia/generic https://github.com/zyedidia/generic. Anyone have any more?

I recently saw a go generic data structures library in the wild: https://github.com/zyedidia/generic https://github.com/zyedidia/generic. Anyone have any more? I'm curious what people come up with for goroutines/channels.

kodablah 5y ago
Undocumented early impl/design of futures: https://github.com/cretz/fut https://github.com/cretz/fut. Examples: https://github.com/cretz/fut/blob/main/ops_test.go https://github.com/cretz/fut/blob/main/ops_test.go.
nkcmr 5y ago
I made this: https://github.com/nkcmr/async https://github.com/nkcmr/async so I can experiment with the idea of Promises in Go. Keep in mind it's experimental and I've only lightly played around with the pattern.
- Zababa 5y ago
  That's interesting, I always found Go's handling of asynchronous stuff way better than other languages, especially the ones that relies on async.
  - cube2222 5y ago
    For those interested to learn more about Go's handling of async, I wrote a comment a while ago where I describe why I too think the Go model is superior: https://news.ycombinator.com/item?id=27545031 https://news.ycombinator.com/item?id=27545031 EDIT: Superior for most non-performance sensitive use cases, that is.
    - Zababa 5y ago
      I personally prefer Go's handling of async too. I'm not sure if I would call it superior, because from what I understand monadic async has its uses, especially when you don't have a runtime. But for the kind of programming that I do, which doesn't need every last bit of performance, monadic async is a pain. For people not familiar with "monadic async", it's the formal way to refer to the function coloring problem [1]. Monads offer you ways to "lift" your functions/values in the monadic world (paint the blue values red), but you can't do the opposite (paint the red functions/values blue). [1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
      - deleted 5y ago
        [deleted]
- jerf 5y ago
  Go doesn't have much use for promises, and generics won't change that, because channel covers the problem space that promises cover. It is obvious that a channel is not the same thing as a promise. They are quite different in many ways. But the problems that you solve with promises in some languages are solved with channels in Go. There's pros and cons to each, but the cons of channels aren't all that significant in the specific context of Go and there are some compelling pros to the channels in the specific context of Go, so there isn't a very fertile space left over for a promise library. I've already seen half-a-dozen go by (non-generic, but missing generics aren't the problem) and those are just the ones that get posted to reddit. I advise writing Go in Go, and not Javascript in Go. But it's your codebase. (Promises are basically an inner platform [1] for functionality not provided by the base language. Go provides the requisite functionality in the base language. I think I'm more hostile to inner platforms every year, but at least when you're adding capabilities to the base language you can't get any other way there's a debate to be had. Adding an inner platform to get functionality that already exists is just a bad plan.) [1]: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
  - xiaq 5y ago
    Promises aren't inherently an "inner platform". You can certainly make them part of the "base language", like Rust. JavaScript didn't have async functions and promises in the beginning, but it integrates with the rest of the language and runtime well enough to not feel like something tacked on (well, at least by the standard of JavaScript language design :). Whether async function + promises is a better model than goroutine + channels is another issue. What you said is accurate in the context of Go though. Having promises in Go will create an "inner platform". If one wants to nitpick, there may be certain workloads that would perform better with async functions and promises, but the design philosophy of Go would happily trade a small amount of performance for simplicity.
    - jerf 5y ago
      "Promises aren't inherently an "inner platform". You can certainly make them part of the "base language", like Rust." That's fair, and I will try to update my internal mental model and stop unconditionally referring to them as such. Thank you. (My primary objection to them is the way they throw away the stack and throw away structured programming as a result, but they're at least less bad if they aren't also an inner platform. :) )
kubb 5y ago
This is actually a pretty neat collection of data structures! Goes to show what people can do given the opportunity.
mappu 5y ago
You'll notice the functional iterators under iter/ don't include benchmarks. Go will not inline a function that exceeds complexity metrics, and one of those metrics is whether the function contains a range statement. You will get a real heap-allocated closure invocation on each loop. Go's function calls are not that cheap, and these will be measurably slower than the for-loop equivalent. I see functional idioms as being a huge risk factor for Go.
- felixge 5y ago
  > Go will not inline a function that exceeds complexity metrics True, but: > and one of those metrics is whether the function contains a range statement. You will get a real heap-allocated closure invocation on each loop. I think this is no longer true in Go 1.18, see https://github.com/golang/go/issues/14768#issuecomment-981759381 https://github.com/golang/go/issues/14768#issuecomment-98175... .
- zyedidia 5y ago
  Author here. I think there is definitely room for improvement in the iterator API. I intend to experiment with more implementations in the coming weeks with the goal of settling on something better by the time Go 1.18 is released. The main alternative I have in mind is a cursor-style iterator (for example, with `Next`, `Done`, and `Value` methods). If you have something else in mind too, let me know and I might be able to try it out.
  - lucian1900 5y ago
    I think the cursor alternative works best with Go's syntax. it := GetAnIterator() for it.Next() { it.Value() } This still allows composition of different iterators, for building up lazy/incremental processing.
- lazyjones 5y ago
  It should not be hard to automatically convert code using such generics libraries to use specialized type-specific code instead for better performance.
- deleted 5y ago
ghughes 5y ago
This has been useful: https://github.com/rakeeb-hossain/functools https://github.com/rakeeb-hossain/functools It contains generic implementations of Any All Count Filter ForEach Map Reduce ReduceRight Sum Chunk
feffe 5y ago
I've just finished porting my gods module (Go Data Structures) to make use of generics. https://github.com/johan-bolmsjo/gods/tree/v2 https://github.com/johan-bolmsjo/gods/tree/v2 It's not much, only a simple list and an AVL tree that I've carried with me for many years. Binary search trees are useful to solve some problems because they are ordered. I was impressed with how polished the tools where. The go-lsp plugin just worked with the new generic types. I solved all compiler errors in the editor without actually compiling anything. Did not expect that level of polish. The modules introduction broke the editor integration for many release cycles. This seems much smoother.

kodablah 5y ago

Undocumented early impl/design of futures: https://github.com/cretz/fut https://github.com/cretz/fut. Examples: https://github.com/cretz/fut/blob/main/ops_test.go https://github.com/cretz/fut/blob/main/ops_test.go.

nkcmr 5y ago

I made this: https://github.com/nkcmr/async https://github.com/nkcmr/async so I can experiment with the idea of Promises in Go. Keep in mind it's experimental and I've only lightly played around with the pattern.

Zababa 5y ago
That's interesting, I always found Go's handling of asynchronous stuff way better than other languages, especially the ones that relies on async.
- cube2222 5y ago
  For those interested to learn more about Go's handling of async, I wrote a comment a while ago where I describe why I too think the Go model is superior: https://news.ycombinator.com/item?id=27545031 https://news.ycombinator.com/item?id=27545031 EDIT: Superior for most non-performance sensitive use cases, that is.
  - Zababa 5y ago
    I personally prefer Go's handling of async too. I'm not sure if I would call it superior, because from what I understand monadic async has its uses, especially when you don't have a runtime. But for the kind of programming that I do, which doesn't need every last bit of performance, monadic async is a pain. For people not familiar with "monadic async", it's the formal way to refer to the function coloring problem [1]. Monads offer you ways to "lift" your functions/values in the monadic world (paint the blue values red), but you can't do the opposite (paint the red functions/values blue). [1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
    - deleted 5y ago
      [deleted]
jerf 5y ago
Go doesn't have much use for promises, and generics won't change that, because channel covers the problem space that promises cover. It is obvious that a channel is not the same thing as a promise. They are quite different in many ways. But the problems that you solve with promises in some languages are solved with channels in Go. There's pros and cons to each, but the cons of channels aren't all that significant in the specific context of Go and there are some compelling pros to the channels in the specific context of Go, so there isn't a very fertile space left over for a promise library. I've already seen half-a-dozen go by (non-generic, but missing generics aren't the problem) and those are just the ones that get posted to reddit. I advise writing Go in Go, and not Javascript in Go. But it's your codebase. (Promises are basically an inner platform [1] for functionality not provided by the base language. Go provides the requisite functionality in the base language. I think I'm more hostile to inner platforms every year, but at least when you're adding capabilities to the base language you can't get any other way there's a debate to be had. Adding an inner platform to get functionality that already exists is just a bad plan.) [1]: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
- xiaq 5y ago
  Promises aren't inherently an "inner platform". You can certainly make them part of the "base language", like Rust. JavaScript didn't have async functions and promises in the beginning, but it integrates with the rest of the language and runtime well enough to not feel like something tacked on (well, at least by the standard of JavaScript language design :). Whether async function + promises is a better model than goroutine + channels is another issue. What you said is accurate in the context of Go though. Having promises in Go will create an "inner platform". If one wants to nitpick, there may be certain workloads that would perform better with async functions and promises, but the design philosophy of Go would happily trade a small amount of performance for simplicity.
  - jerf 5y ago
    "Promises aren't inherently an "inner platform". You can certainly make them part of the "base language", like Rust." That's fair, and I will try to update my internal mental model and stop unconditionally referring to them as such. Thank you. (My primary objection to them is the way they throw away the stack and throw away structured programming as a result, but they're at least less bad if they aren't also an inner platform. :) )

kubb 5y ago

This is actually a pretty neat collection of data structures! Goes to show what people can do given the opportunity.

mappu 5y ago

You'll notice the functional iterators under iter/ don't include benchmarks. Go will not inline a function that exceeds complexity metrics, and one of those metrics is whether the function contains a range statement. You will get a real heap-allocated closure invocation on each loop. Go's function calls are not that cheap, and these will be measurably slower than the for-loop equivalent. I see functional idioms as being a huge risk factor for Go.

felixge 5y ago
> Go will not inline a function that exceeds complexity metrics True, but: > and one of those metrics is whether the function contains a range statement. You will get a real heap-allocated closure invocation on each loop. I think this is no longer true in Go 1.18, see https://github.com/golang/go/issues/14768#issuecomment-981759381 https://github.com/golang/go/issues/14768#issuecomment-98175... .
zyedidia 5y ago
Author here. I think there is definitely room for improvement in the iterator API. I intend to experiment with more implementations in the coming weeks with the goal of settling on something better by the time Go 1.18 is released. The main alternative I have in mind is a cursor-style iterator (for example, with `Next`, `Done`, and `Value` methods). If you have something else in mind too, let me know and I might be able to try it out.
- lucian1900 5y ago
  I think the cursor alternative works best with Go's syntax. it := GetAnIterator() for it.Next() { it.Value() } This still allows composition of different iterators, for building up lazy/incremental processing.
lazyjones 5y ago
It should not be hard to automatically convert code using such generics libraries to use specialized type-specific code instead for better performance.
deleted 5y ago

ghughes 5y ago

This has been useful: https://github.com/rakeeb-hossain/functools https://github.com/rakeeb-hossain/functools It contains generic implementations of Any All Count Filter ForEach Map Reduce ReduceRight Sum Chunk

feffe 5y ago

I've just finished porting my gods module (Go Data Structures) to make use of generics. https://github.com/johan-bolmsjo/gods/tree/v2 https://github.com/johan-bolmsjo/gods/tree/v2 It's not much, only a simple list and an AVL tree that I've carried with me for many years. Binary search trees are useful to solve some problems because they are ordered. I was impressed with how polished the tools where. The go-lsp plugin just worked with the new generic types. I solved all compiler errors in the editor without actually compiling anything. Did not expect that level of polish. The modules introduction broke the editor integration for many release cycles. This seems much smoother.