Proposal: add "future" internal type (similar to channel)

[funny-falcon]

"Future" is commonly used synchronization primitive used in many languages and environments.
It allows several "receivers" to wait "computaion" of a single value, and single "receiver" to wait for several values to be computed using same convenient construction.
Although Golang already has channels, it is more like "stream/queue of values" instead of "single value to be computed". To make several "receivers" to wait on single value, one ought to use relatively complex wrappers around channel (usually, waiting for channel to be closed). And usually it lacks of type information of value cause uses interface{} for value.

Proposal

Add future primitive derived and equal rights to channels. Obviously, it will share representation and a lot of code with channels.

• it is created with make sentence:

    f := make(future string)

• it could be then split to receive and send subtypes:

    var rf <-future string = f
    var sf future<- string = f

• future has same internal representation to buffered channel with capacity == 1, and uses similar receive and send operations.

    f <- "hello"
    s := <- f

• there is no "close" of future.

• 'receive" operation is almost equal to receiving from channel with excepts:

  • receiver doesn't pop value from a buffer, every receiver receives same values sent to a future

    s1 := <- f
    // it is possible to fetch same value several values
    s2 := <- f
    if (s1 != s2 || &s1[0] != &s2[0]) { panic("not the same") }

  • there is no "receive with check" operation (cause "future" could not be closed):

    s, ok := <- f // this is syntax error
  

• "send" has properties of both sending to channel and closing channel:

  • like send to channel it fills value, stored in a future's buffer,
  • like close of channel it awakes all receivers blocked on a future,
  • also, like close of channel second send to future leads to panic,
  • to conditionally send value to a future, non-blocking send should be used (using select with default)

    select {
    case f <- "world":
       // do something, if we are first who sent value to a future
    default:
       // do something, if someone already filled future
    }

  • to avoid semantic complexity, this is only allowed use of send to future inside of select. It is better to force it on a syntax level.
  • as alternative, "send with check" could be introduced, (then "send to future" is completely forbidden inside of select) (it could be useful for sending to closed channels too, but it looks like it were rejected in the past).:

    if ok := f <- "world"; !ok {
      // do something, if someone already filled future
    }

Note: some names construction similar to future as 'I-var' - "immutable variable". Looks like, it will introduce less name collisions with existing code, so type could be named as ivar:

    f := make(ivar string)
    var rf <-ivar string = f
    var sf ivar<- string = f

[cznic]

What this proposal buys wrt to proper use of sync.Once?

[Merovius]

Futures are a step back for go. They are added to other languages, which are lacking proper concurrency support, to make code look more sequential, so they replace callbacks and event loops. In go, the propper way to make your code look sequential, is to write it sequentially in the first place.

So, I don't think this is a good addition. I believe there are very view proper use cases for them (like, "to do a thing, I first need to kick of thing A, then do lots of other stuff and then wait for A to finish to use the result" is relatively rare).

For the rare cases where futures are useful, I'd rather suggest something like this:

func ThingA() func() string {
    ch := make(chan string)
    go func() {
        ch <- doThing()
        close(ch)
    }
    return func() { return <-ch }
}

which seems wordy; but that's fine as it shouldn't be necessary that often anyway. And ThingA can then be used like returning a proper future, with very little syntactic overhead.

[Merovius]

Also, the fact that you mention yourself how much functionality, code and syntax they'd share with channels, shows, that they are not at all orthogonal to them (they are pretty much colinear) and as such, the addition would violate one of the core design principles of go.

[funny-falcon]

@cznic futures are selectable, so you may combine them with timeouts, other futures and channels
@Merovius channels are not the same as a future, cause many receivers may wait for a same value from a future, but is is hard to wait same value from a channel.

Example:

type usersMap struct {
  m sync.Mutex
  u map[int] future User
}
var users = usersMap{ u: make(map[int] future User }
func userFuture(uid int) (f future User) {
    users.m.Lock()
    if f, ok := users.u[uid]; !ok {
        f = make(future User)
        go func() {
            f <- findUser(uid)
        }()
        users.u[uid] = f
    }
    user.m.Unlock()
    return f
}
func getWithTimeout(uid int, timeout time.Duration) (u User, err error) {
    f := userFuture(uid)
    to := time.NewTimer(timeout)
    select {
    case u = <- f: // that is how it differs from sync.Once()
        return u, nil
    case <-to.C:
        err = TimeoutError
        return
    }
}
// that is why channel is not suitable (several receivers of same value)
go func() {
   if user, err := getWithTimeout(1, time.Second); err != nil {
     sendToParis(user)
   }
}()
go func {
   if user, err := getWithTimeout(1, time.Millisecond); err != nil {
      giveAPresent(user)
   }
}()

It could be implemented with more wrapper code, as example: https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
But if it were internal type, then it will be more elegant and type-safe.

[andlabs]

I have a blog post pending on why JavaScript's futures (the Promise object) do not actually solve any problems (or at least any of the problems they aim to solve). Let's not ruin Go, please.

As for the case with "many receivers may wait for a same value from a future", use a RWMutex and release the W lock when the value is ready. Or cancel a context and store the result in a Value. Or maybe something in one of the many concurrency talks the Go team have made; I'm sure there's something somewhere.

[funny-falcon]

@andlabs I already know how to build future with code (as wrapper around mutex and channel) (and I've already posted a link above to such code).
But every such code is inelegant and not type-safe.

I'm not propose bringing Javascript's futures/promises to Go. No "then+catch" callbacks.

This proposal is about bringing "Future" abstraction to language in a way suitable for Go language.
And this abstraction is really useful.

[Merovius]

You can also do

func ThingA() (func() string, <-chan bool) {
    ch := make(chan bool)
    var s string
    go func() {
        s = doExpensiveThing()
        close(ch)
    }()
    return func() string {
        <-ch
        return s
    }, ch
}

and get selectability and an arbitrary number of receivers (and yes, I am aware that this is used syntactically different from what you propose).

However, that's not even the larger point. The larger point is, that they are a) not necessary, because the problem they usually are added for doesn't really exist in go and b) they are not orthogonal to channels. That c) you can already emulate them, which means they don't actually add more power to the language is, at least to me, more of a side-note.

Another issue I have with futures are, that they are poisonous; when your function returns a future, I suddenly need to care about concurrency when I use your stuff, whether I want to or not (and even if that only means adding an arrow). Whereas, if you just, like recommended in idiomatic go code, write your function to be synchronous and return a value, I can choose myself whether I want to call it asynchronously or keep my life simple by just treating it as a normal function call.

Thus, in a world with futures, soon all go code will be riddled with futures, because people decide they need to return a future whenever they do anything involving files or the network (and they are only really useful if returned by the function) and then all go code gets riddled with arrows, because in practice, people need the result of a function call immediately most of the time anyway.

Just write your code as taking a context.Context for cancellation and returning a regular value. And in the 1% of cases where futures are useful, people can add the two lines of code necessary for most of those use cases themselves. Or the twelve lines of code for the 1% of the 1% where you actually need selectability or multiple receivers.

[funny-falcon]

@Merovius your code looks like a simplest wrapper code for making future :-) But still you not convince me.

Converting "synchronous code" to "asynchronous" usually means running goroutine for every "synchronous->asynchronous conversion". It is really expensive and scales bad.

Practice shows that "asynchronous first" API is more scalable.
Providing useful primitive for will lead to more scalable api, and it is good, IMHO.

For example, one kv storage has asynchronous network protocol and allows to send asynchronous requests.
If one need to send bunch of independent queries (for example, batch insert, or batch fetch for meany ids), then he should send asynchronous requests to maximize throughput and reduce total time of computation.

But if library provides only synchronous API, then one should wrap every request with goroutine.
Other option is "batch api", which will be very different from "regular api", and will duplicate functionality.

But if library provides "asynchronous first" api with futures, then it is only api every user need to use.

[funny-falcon]

proposal for select on conditional variables from @bradfitz looks similar in spirit:
#16620

[bradfitz]

I've wanted something this (auto-pumped, single value 1:many channels) a number of times in the past too.

It might be nicer if it could be done without a language change, though. Maybe the runtime or reflect packages could just be extended a bit to provide a way to let this "future" behavior be provided by a normal package.

[funny-falcon]

@bradfitz, but giving Go has no generics, single way to make it type-safe is to change language a bit.
I've tried to make this change as small as possible, reusing most of syntax and semantic from channels.

[bradfitz]

@funny-falcon, it's not the "single way". There are plenty of other ways one might imagine. Here's one example, which I'm not saying is good, but I'm giving as proof that a language change is not the "single way":

package runtime

// RegisterOnEmpty registers that the runtime should call fn when the channel
// given in ch transitions from 1 buffered element to 0. It panics if ch is
// not a channel or ch is not a buffered channel.
func RegisterOnEmpty(ch interface{}, fn func()) {
   // ....
}

Then you make a future in a regular package, and do:

package github_foo_future

// Set sets the value of the futureChan to value.
// It sends value and continues to send the value as it is received.
// Set panics if futureChan is not a buffered channel.
func Set(futureChan, value interface{}) {
     cv := reflect.ValueOf(futureChan)
     vv := reflect.ValueOf(value)
     send := func() { cv.Send(vv) }
     runtime.RegisterOnEmpty(futureChan, send)
     send()
}

Again, I'm not saying that's a good solution, but it's a solution that doesn't require a language change. (only a runtime/API change)