Hacker News Reader

Comment by parhamn | Hacker News Reader

I recently saw a go generic data structures library in the wild: https://github.com/zyedidia/generic.

Anyone have any more? I'm curious what people come up with for goroutines/channels.

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.

> 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-98175... .

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.

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.

It should not be hard to automatically convert code using such generics libraries to use specialized type-specific code instead for better performance.

I've just finished porting my gods module (Go Data Structures) to make use of generics.

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.

This has been useful: https://github.com/rakeeb-hossain/functools

It contains generic implementations of

    Any
    All
    Count
    Filter
    ForEach
    Map
    Reduce
    ReduceRight
    Sum
    Chunk

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

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

I made this: 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.

That's interesting, I always found Go's handling of asynchronous stuff way better than other languages, especially the ones that relies on async.

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

EDIT: Superior for most non-performance sensitive use cases, that is.

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-y...

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

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.

"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. :) )

> My primary objection to them is the way they throw away the stack and throw away structured programming as a result,

Structured concurrency is orthogonal to whether you're using a thread-based or monadic API. Goroutines, for example, are both thread-based and unstructured. On the other hand, you can have concurrency that is structured but still thread-based (like Trio), unstructured but monadic (like Scala's built-in Future type), or both structured and monadic (like Rust's Future type).

I think promises are a inner platform in Rust and JS, due to the function coloring problem. They are a different world that you can't escape from. In the async book from Rust [1]:

> Asynchronous and synchronous code cannot always be combined freely. For instance, you can't directly call an async function from a sync function.

Same with JavaScript from [2]:

> The await operator is used to wait for a Promise. It can only be used inside an async function within regular JavaScript code; however it can be used on its own with JavaScript modules.

In JS, the promise world is a different world. Exceptions won't work like they usually do for example.

[1]: https://rust-lang.github.io/async-book/01_getting_started/03...

[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Reply on news.ycombinator.com