Some previous discussion: #17466

@daskol You don't need features.
If you want to recover panics from another goroutine you should resend them to current goroutine, by error channel, or something like result{value, error} object. Because in any case you will wait for result.

With future/promise you will increase complexity, without real profit.

@index0h Sure, it is not necessary to add new language expression. Here I implement future using standard lib. You presisely described my implementation. But what do you mean? In any case anyone will wait for result of execution a line of his or her code.

With feature/promise you will increase complexity, without real profit.

No, this is completely wrong. Look at definition of channels and futures. Future is read reduction of channel. Both channel and future are high level sync primitives. Channels are usefull in general case, however if it is needed only to get value people use futures(or channels avaliable for reading) to get result.

Channels provide a capability that is otherwise unavailable in the language. The version of futures that you are presenting is already available in the language. So I don't agree that they are both sync primitives; channels are a primitive and futures can be built on top of channels.

It seems to me that you are suggesting some syntactic sugar for a particular channel operation. That then leads to the question: why this sugar? Is this an operation so common that it merits extra support in the language? My guess is that it is not. For example, this syntactic sugar offers no way to cancel the operation if you decide later on that you don't need it.

@ianlancetaylor I think academia guys do not think so[1]. Moreover, notion of eventual consistency actually is defined with happened-before relation which is promise or future or channel. So, future and channel are located on the same level. Future and channel hardware implementation is based on CAS, TAS or LL/SC operations that are real primitives. In this sence you are right that future is not primitive.

In my point of view, such syntactic sugar is usefull at least in web application development. See issue #17466 where @funny-falcon gave examples in context requests to KV storage.

Well, the current golang version cancels only with context package. It is tricky and not very convenient. Is it appropriate if go statement made object that provides ways to cancel or identify a go-routine?

There is another one argument in order to "overload" go statement that is conceptual integrity. Why does the keyword apply only to functions which do not return anything but take arguments and even capture the execution context?

@daskol I agree that futures and channels are on approximately the same level of power, but my point is simply that when you already have channels, you don't also need futures. The paper you cite is describing a system that doesn't have channels, so that the fact they find futures to be useful doesn't tell us much one way or another.

Your other comments do not seem to me to be clearly related to this proposal. Perhaps they should be discussed on golang-nuts or some other forum.

@daskol

Sure, it is not necessary to add new language expression.

proposal: extend language or stdlib with future-like sync primitive

It sounds like a contradiction.

With feature/promise you will increase complexity, without real profit.

No, this is completely wrong. Look at definition of channels and futures.

My comment was abount language change.

Channels are usefull in general case, however if it is needed only to get value people use futures(or channels avaliable for reading) to get result.

If you want to use futures, it's ok. But channel is a "generic" type, where you can set type, which it'll process. In futures you can use only interface{} so you must always cast types, or use code generation.

Here I implement future using standard lib.

Your example is not working(( Use channels

func main() {
	result, ok := future.Go(func() future.RType {
		time.Sleep(time.Second * 2)
		return "test"
	}).Get()

	println(result.(string), ok)
}
// panic: interface conversion: future.RType is nil, not string

Look, I'm writing this because your proposal not solve any problems, but it creates new instrument to resolve same tasks as channels.
For example JS: at first time you had only callbacks, one function for error and result. Next you got promises, two functions for success and error results. Next you got async/await, cool! But in real life you also must use callbacks + promises + async/await. Hi backward capability.

In golang it'll be just the same.

Imho, my proposal (#17466) were much more in Go's way.

This one is more "lets use technique I learned from other language" than "lets implement useful primitive in a way useful in this language".

I could be mistaken.

The question to ask now is: what can futures do that Go cannot already do with channels and/or package sync?

@ianlancetaylor Next time I will refer to more sensible papers. However, the paper intoduces notion of future. Everyone should know definition of channel but not future. So now everyone can just compare definition and understand that future and channels for reading are the same.

Okay, except one point. You can think that I propose generalization of go statement to functions that return value. It seems to be natural continuation.

@index0h You improperly understand the appearance futures in JS. The fact is the simplest way to implement asynchronous behavior like coroutine, generators, channels, etc is to wrap some piece of code in future-promise pairs.

Your example is not working(( Use channels

You use my example in wrong way. This is not the right place to explain. (Hint: read from closed channel of type chan interface{} and cast to string).

I don't understand rest of your comments. They are quite messy.

@funny-falcon Futures, promises and channels is about 40 years old. Well, they are older than almost all modern language. I pull this idea from academia. I suppose that closed form of go statement is useful, consistent and clear. By the way there is a paper that propose the current generic type model in Java. So, may be Golang borrows a priori some concepts from other languages. I know nothing specific for Go.

@andlabs That is not right question. I can you ask similar questions too. What can channels do that Go cannot already do with package sync? What can channels do that Go cannot already do with channels? Every language has a bit of redundancy or excess. That things differ programming language from DSL.

Try repeate again. In general I propose the following code to be correct in some sence

    future := go func() int {
        return 42
    }()

The important thing is needed to discuss what properties does future have? The future could be a channel or new generic type or new not generic type and so on.

@dascol

Futures, promises and channels is about 40 years old.

Yes, I know. And I also proposed future/ivar. I just made it closer to Go's way, I think. And your way is more like C++.

I could be mistaken.

This is essentially the same as #17466, which was closed. Closing this one as well. See #17466 for discussion.