Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Jesper Louis Andersen]

On Mon, Oct 17, 2016 at 5:08 PM adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>
> Go does not take a strong Erlang-like stance against concurrency with
> shared variables, so mutexes really are critical to Go's concurrency.
>
>
>
Even Erlang took a more loose stance towards concurrency with shared
variables. You have ETS tables, which acts as tables of M-Vars (in the
setting of how such vars work in Id or Haskell). In turn, they act as a way
to share data between processes without resorting to message passing.

The primary reason is efficiency. An ETS table has sub-microsecond lookup
time (because you still need at least two locks in the runtime to grab a
value, and then you have to copy it into your own memory space). But it
avoids a context switch when you look up. They are used as an in-memory
backing store for the mnesia database, among other things, but finds broad
use in most Erlang applications.

As for the concept of future, I feel it is a crutch. If you have channels,
mailboxes or some other concurrency pattern, I've often preferred tailoring
a solution to the problem space, rather than trying to get things to work
with futures. I'm also skeptic towards its need to be efficient. A
long-running computation in the background is often measured in
milli-seconds and a channel operates under the 1ms barrier in practice. I'd
much rather see some uses of a future primitive where it is applicable and
not solvable with a bit of simple channel code, while also being necessary
for efficiency reasons.

Also note that most broadcast-like patterns are more efficient if the
subscribers pull their data. See, for instance, the Disruptor pattern in
Java, which would be a nice construction to implement rather than
implementing something such as futures (which I feel is a special case of a
one-slotted disruptor).

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Rob Pike]

What Ian said, plus select is awkward to implement as a library, but works
quite well when its syntax is analogous to switch.

-rob


On Tue, Oct 18, 2016 at 11:41 AM, Ian Lance Taylor  wrote:

> On Tue, Oct 18, 2016 at 8:52 AM,   wrote:
> > so why are channels and goroutines built into the language proper?
>
> Channels and goroutines are widely used.  Go does not follow a strict
> principle of putting everything in a library.  That said, ultimately
> these things boil down to matters of taste, in this case the taste of
> the original language designers.
>
> Ian
>
> > On Monday, October 17, 2016 at 9:42:17 AM UTC-4, adon...@google.com
> wrote:
> >>
> >> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
> >>>
> >>> "future" is commonly used synchronization abstraction.
> >>>
> >>> It could be implemented in a library, using mutex, channel and
> interface.
> >>> Example:
> >>> https://github.com/Workiva/go-datastructures/blob/master/
> futures/selectable.go
> >>
> >>
> >> If it can be implemented as a library, why build it in to the language?
> >> You don't need futures very often---far less than, say, Mutex, and
> mutexes
> >> aren't built into the language either.
> >>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to golang-nuts+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Ian Lance Taylor]

On Tue, Oct 18, 2016 at 8:52 AM,   wrote:
> so why are channels and goroutines built into the language proper?

Channels and goroutines are widely used.  Go does not follow a strict
principle of putting everything in a library.  That said, ultimately
these things boil down to matters of taste, in this case the taste of
the original language designers.

Ian

> On Monday, October 17, 2016 at 9:42:17 AM UTC-4, adon...@google.com wrote:
>>
>> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>>>
>>> "future" is commonly used synchronization abstraction.
>>>
>>> It could be implemented in a library, using mutex, channel and interface.
>>> Example:
>>> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>>
>>
>> If it can be implemented as a library, why build it in to the language?
>> You don't need futures very often---far less than, say, Mutex, and mutexes
>> aren't built into the language either.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[andrey mirtchovski]

> so why are channels and goroutines built into the language proper?

Channels and goroutines are not just language constructs in Go. They
are part of the formal language of Communicating Sequential Processes
and as such are being actively researched. CSP is under active
research. For example, CSPs can be used to specify and verify the
concurrent aspect of a system. More info here:

 https://en.wikipedia.org/wiki/Communicating_sequential_processes#Primitives

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[gopher]

so why are channels and goroutines built into the language proper?

On Monday, October 17, 2016 at 9:42:17 AM UTC-4, adon...@google.com wrote:
>
> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>>
>> "future" is commonly used synchronization abstraction.
>>
>> It could be implemented in a library, using mutex, channel and interface.
>> Example: 
>> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>>  
>> 
>>
>
> If it can be implemented as a library, why build it in to the language? 
>  You don't need futures very often---far less than, say, Mutex, and mutexes 
> aren't built into the language either.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Ian Lance Taylor]

On Tue, Oct 18, 2016 at 5:44 AM, Sokolov Yura  wrote:
>
> Then why should I watch ego of a man who didn't read this discussion,
> and posts another almost exact copy of sample code?
> Why that man do not respect other people in this chat, and I should respect
> him?
>
> I know, I will be banned after this.
> Nevertheless, why should I endure it?

I encourage you to read the code of conduct that applies to this
mailing list (https://golang.org/conduct):

People are complicated. You should expect to be misunderstood and
to misunderstand others; when this inevitably occurs, resist the urge
to be defensive or assign blame. Try not to take offense where no
offense was intended. Give people the benefit of the doubt. Even if
the intent was to provoke, do not rise to it. It is the responsibility
of all parties to de-escalate conflict when it arises.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Respect is not only "use of right words and polite phrases".
Respect is being attentive.

And that is why I ask you to excuse me for misspelling your name, 
Konstantin.

вторник, 18 октября 2016 г., 14:37:44 UTC+3 пользователь Konstantin 
Khomoutov написал:
>
> On Tue, 18 Oct 2016 01:10:36 -0700 (PDT) 
> Sokolov Yura  wrote: 
>
> > > If you want to make it possible, it's pretty easy: 
> > https://play.golang.org/p/YWYFSL2QTe 
> > 
> > Thank you for fifth copy of almost same code. I clearly have no 
> > enough experience to use close of channel and `sync.Once`. Do you 
> > really think so? 
>
> Do you really think we here have any desire to watch you playing smart 
> ass?  Your stream of ego pushing has been already cut in [1]; please 
> get easier on it here as well. 
>
> 1. https://github.com/golang/go/issues/17466 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Konstantive,

Then why should I watch ego of a man who didn't read this discussion,
and posts another almost exact copy of sample code?
Why that man do not respect other people in this chat, and I should respect 
him?

I know, I will be banned after this.
Nevertheless, why should I endure it?

вторник, 18 октября 2016 г., 14:37:44 UTC+3 пользователь Konstantin 
Khomoutov написал:
>
> On Tue, 18 Oct 2016 01:10:36 -0700 (PDT) 
> Sokolov Yura  wrote: 
>
> > > If you want to make it possible, it's pretty easy: 
> > https://play.golang.org/p/YWYFSL2QTe 
> > 
> > Thank you for fifth copy of almost same code. I clearly have no 
> > enough experience to use close of channel and `sync.Once`. Do you 
> > really think so? 
>
> Do you really think we here have any desire to watch you playing smart 
> ass?  Your stream of ego pushing has been already cut in [1]; please 
> get easier on it here as well. 
>
> 1. https://github.com/golang/go/issues/17466 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Konstantin Khomoutov]

On Tue, 18 Oct 2016 01:10:36 -0700 (PDT)
Sokolov Yura  wrote:

> > If you want to make it possible, it's pretty easy: 
> https://play.golang.org/p/YWYFSL2QTe 
> 
> Thank you for fifth copy of almost same code. I clearly have no
> enough experience to use close of channel and `sync.Once`. Do you
> really think so?

Do you really think we here have any desire to watch you playing smart
ass?  Your stream of ego pushing has been already cut in [1]; please
get easier on it here as well.

1. https://github.com/golang/go/issues/17466

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Axel, thank you. Big heartfelt thanks. You really understand me.
My respect to you.

вторник, 18 октября 2016 г., 11:55:40 UTC+3 пользователь Axel Wagner 
написал:
>
> Not all of them are wrong (in fact, almost none of them are). They just 
> don't do everything and anything you could ever choose to want from an 
> implementation so they appear unsatisfactory.
>
> Which, in the long list of issues that have been presented and remain 
> unaddressed in regards to this proposal, adds another one: Writing one 
> implementation that covers every use case you could ever have for them 
> efficiently is, indeed, hard and error-prone. Whereas covering any specific 
> use case with channels takes only a small handful of lines of trivial code.
>
> On Tue, Oct 18, 2016 at 10:17 AM, andrey mirtchovski  > wrote:
>
>> as a person happy to remain willingly ignorant of promises and futures
>> i notice from the sidelines that the concepts seem to lack clarity and
>> vision. if five different implementations got them wrong there will be
>> five different people wondering why the stdlib one isn't working
>> right. that's five too many.
>>
>> On Tue, Oct 18, 2016 at 2:10 AM, Sokolov Yura > > wrote:
>> > Roger
>> >
>> >> If you want to make it possible, it's pretty easy:
>> > https://play.golang.org/p/YWYFSL2QTe
>> >
>> > Thank you for fifth copy of almost same code. I clearly have no enough 
>> experience to use close of channel and `sync.Once`.
>> > Do you really think so?
>> >
>> >> There's another idiom I quite like for futures (when there's only one
>> > possible source of the value) putting the value back after
>> > taking it out: https://play.golang.org/p/_7p69KE_RZ
>> >
>> > And that is really broken idiom. It has race condition: concurrent 
>> goroutine may put dufferent value in the channel between those two lines of 
>> code. More over, if you use blocking send here, then you will end in 
>> blocked goroutine in this case.
>> > Another mistake in this idiom: if other concurrent goroutine checks 
>> this channel within select, and that check happens between those two lines 
>> (between receive and following send), then it see empty "future".
>> > And even ir when does not lead to mistake, it serialize "broadcast": 
>> goroutines are awoken one after other, instead of being awoken in parallel.
>> >
>> > That is why I want language (or standard library) to have reliable 
>> implementation:  people should not invent bicycles with square wheels.
>> >
>> > --
>> > You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to golang-nuts...@googlegroups.com .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

['Axel Wagner' via golang-nuts]

Not all of them are wrong (in fact, almost none of them are). They just
don't do everything and anything you could ever choose to want from an
implementation so they appear unsatisfactory.

Which, in the long list of issues that have been presented and remain
unaddressed in regards to this proposal, adds another one: Writing one
implementation that covers every use case you could ever have for them
efficiently is, indeed, hard and error-prone. Whereas covering any specific
use case with channels takes only a small handful of lines of trivial code.

On Tue, Oct 18, 2016 at 10:17 AM, andrey mirtchovski 
wrote:

> as a person happy to remain willingly ignorant of promises and futures
> i notice from the sidelines that the concepts seem to lack clarity and
> vision. if five different implementations got them wrong there will be
> five different people wondering why the stdlib one isn't working
> right. that's five too many.
>
> On Tue, Oct 18, 2016 at 2:10 AM, Sokolov Yura 
> wrote:
> > Roger
> >
> >> If you want to make it possible, it's pretty easy:
> > https://play.golang.org/p/YWYFSL2QTe
> >
> > Thank you for fifth copy of almost same code. I clearly have no enough
> experience to use close of channel and `sync.Once`.
> > Do you really think so?
> >
> >> There's another idiom I quite like for futures (when there's only one
> > possible source of the value) putting the value back after
> > taking it out: https://play.golang.org/p/_7p69KE_RZ
> >
> > And that is really broken idiom. It has race condition: concurrent
> goroutine may put dufferent value in the channel between those two lines of
> code. More over, if you use blocking send here, then you will end in
> blocked goroutine in this case.
> > Another mistake in this idiom: if other concurrent goroutine checks this
> channel within select, and that check happens between those two lines
> (between receive and following send), then it see empty "future".
> > And even ir when does not lead to mistake, it serialize "broadcast":
> goroutines are awoken one after other, instead of being awoken in parallel.
> >
> > That is why I want language (or standard library) to have reliable
> implementation:  people should not invent bicycles with square wheels.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[andrey mirtchovski]

as a person happy to remain willingly ignorant of promises and futures
i notice from the sidelines that the concepts seem to lack clarity and
vision. if five different implementations got them wrong there will be
five different people wondering why the stdlib one isn't working
right. that's five too many.

On Tue, Oct 18, 2016 at 2:10 AM, Sokolov Yura  wrote:
> Roger
>
>> If you want to make it possible, it's pretty easy:
> https://play.golang.org/p/YWYFSL2QTe
>
> Thank you for fifth copy of almost same code. I clearly have no enough 
> experience to use close of channel and `sync.Once`.
> Do you really think so?
>
>> There's another idiom I quite like for futures (when there's only one
> possible source of the value) putting the value back after
> taking it out: https://play.golang.org/p/_7p69KE_RZ
>
> And that is really broken idiom. It has race condition: concurrent goroutine 
> may put dufferent value in the channel between those two lines of code. More 
> over, if you use blocking send here, then you will end in blocked goroutine 
> in this case.
> Another mistake in this idiom: if other concurrent goroutine checks this 
> channel within select, and that check happens between those two lines 
> (between receive and following send), then it see empty "future".
> And even ir when does not lead to mistake, it serialize "broadcast": 
> goroutines are awoken one after other, instead of being awoken in parallel.
>
> That is why I want language (or standard library) to have reliable 
> implementation:  people should not invent bicycles with square wheels.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Roger

> If you want to make it possible, it's pretty easy: 
https://play.golang.org/p/YWYFSL2QTe 

Thank you for fifth copy of almost same code. I clearly have no enough 
experience to use close of channel and `sync.Once`.
Do you really think so?

> There's another idiom I quite like for futures (when there's only one 
possible source of the value) putting the value back after 
taking it out: https://play.golang.org/p/_7p69KE_RZ 

And that is really broken idiom. It has race condition: concurrent goroutine 
may put dufferent value in the channel between those two lines of code. More 
over, if you use blocking send here, then you will end in blocked goroutine in 
this case.
Another mistake in this idiom: if other concurrent goroutine checks this 
channel within select, and that check happens between those two lines (between 
receive and following send), then it see empty "future".
And even ir when does not lead to mistake, it serialize "broadcast": goroutines 
are awoken one after other, instead of being awoken in parallel.

That is why I want language (or standard library) to have reliable 
implementation:  people should not invent bicycles with square wheels.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[roger peppe]

On 17 October 2016 at 17:18, Sokolov Yura  wrote:
>
> понедельник, 17 октября 2016 г., 18:12:59 UTC+3 пользователь Roberto Zanotto
> написал:
>>
>> I missed the chance to comment on github...
>>
>> This also works for implementing futures and it's simple, type-safe and
>> can be used with select:
>> https://play.golang.org/p/VDT36rC5A-
>> Of course the syntax is not as nice as built-in futures.
>
>
> Roberto, no it doesn't work.
> You miss possibility of filling future from several (usually, two)
> concurrently running goroutines.

I'd suggest that this requirement is fairly unusual. For example,
I just glanced at the C++ future implementation which suggests
using std::promise::set_value to set the associated value, and that
raises an exception if you try to set the value twice.

If you want to make it possible, it's pretty easy:
https://play.golang.org/p/YWYFSL2QTe

There's another idiom I quite like for futures (when there's only one
possible source of the value) putting the value back after
taking it out: https://play.golang.org/p/_7p69KE_RZ
Quite a while ago I wrote a blog post that leveraged that idiom to
make a kind of broadcast channel: https://rogpeppe.wordpress.com/2009/12/

That technique is also applicable to having multiple values in a channel
to implement a pool of available tokens.

BTW here's an example of a Go package that uses the future idiom
quite a bit: https://godoc.org/github.com/hashicorp/raft#ApplyFuture
It doesn't seem so onerous to do something like this without
needing direct support in the language (it would be easy
to add a wait channel too).

  cheers,
rog.

>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Proposal: add "future" internal type (similar to channel)

['Alan Donovan' via golang-nuts]

On 17 October 2016 at 12:31, Sokolov Yura  wrote:
>
> понедельник, 17 октября 2016 г., 18:08:43 UTC+3 пользователь
> adon...@google.com написал:
>>
>> Go does not take a strong Erlang-like stance against concurrency with
>> shared variables, so mutexes really are critical to Go's concurrency.
>>
>
> Am I mistaken? Golang authors said mutexes are second class citizens.
> They'd prefer not to expose them, but unfortunately, channels are not fast
> enough for some use-cases.
>

Well, it's true that mutexes can be implemented in terms of channels,
albeit with some loss of efficiency in practice, so in that sense I suppose
you could describe them as second class.  But it doesn't change the
fundamentals: unlike Erlang, Go has always supported mutable variables
concurrently accessible by multiple goroutines, and I've never heard anyone
in the Go community wish it were otherwise.

Your code also misses the case when concurrently running goroutines wish to
> fill same future.
>

That is true, but it's an advanced feature not needed by most users of
Futures.  You can of course add it at the cost of a few extra lines of
code.  Recall my stack analogy: for most users, it's not worth defining a
new Stack type; a slice will do. But some may want more advanced stack
features and then using a library package might be worth the cost (of
clumsy syntax).


> Most uses of reflect package doesn't bother with synchronization
> primitives. They only detects structs, strings, maps and slices, and
> ignores rest.
> Most of such code will not be broken.
>

A great many programs have a "switch v.Kind()" and a case for every
reflect.Kind.  All such programs would be broken by your change.  If for no
other reason, this means we cannot add Futures to the language because we
have guaranteed not to break any valid Go 1.x program.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

понедельник, 17 октября 2016 г., 18:08:43 UTC+3 пользователь 
adon...@google.com написал:
>
>
> Go does not take a strong Erlang-like stance against concurrency with 
> shared variables, so mutexes really are critical to Go's concurrency.
>

Am I mistaken? Golang authors said mutexes are second class citizens.
They'd prefer not to expose them, but unfortunately, channels are not fast 
enough for some use-cases.
 

> This is really a special case of the argument for generics in Go.
>
> Futures are to channels and stacks are to slices.  With generics, you 
> could provide first-class Future and Stack, but without generics it's 
> simply not worth the effort for most users to bother with the abstraction 
> since it can be written in little more than a dozen lines of code:  
> https://play.golang.org/p/Obqag2hgZe  It's just easier to implement the 
> underlying operations directly.
>

Your code also misses the case when concurrently running goroutines wish to 
fill same future.
That is why I think it should be at least in standard library, but better 
in a language: it should be reliable, and not error-prone.
 

> Adding a new data type is not a small change to the language.  It requires 
> changes to the spec, the compiler, the reflect package, every program that 
> uses the reflect package, every tool that manipulates Go source code, and 
> many other things too.  The only types that currently enjoy special status 
> in the type system are slice, map, channel and a small number of others, 
> all of which are very widely used.
>

Most uses of reflect package doesn't bother with synchronization 
primitives. They only detects structs, strings, maps and slices, and 
ignores rest.
Most of such code will not be broken.

But I agree with you (or better said: you caught me): I cheated a bit when 
were talking about amount of changes.
That is bonus point for you, cause you first who said about it.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

понедельник, 17 октября 2016 г., 18:12:59 UTC+3 пользователь Roberto 
Zanotto написал:
>
> I missed the chance to comment on github...
>
> This also works for implementing futures and it's simple, type-safe and 
> can be used with select:
> https://play.golang.org/p/VDT36rC5A-
> Of course the syntax is not as nice as built-in futures.
>

Roberto, no it doesn't work.
You miss possibility of filling future from several (usually, two) 
concurrently running goroutines.

>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Viktor Kojouharov]

A future is just a special case of an observable.  Honestly I'd prefer if 
an observable was built-in the language like a channel. You could use it 
like a channel in selects and the like, but with the possibility of 
receiver observables to be closable. When the list receiver observable is 
closed, the sender could stop producing new values.

On Sunday, October 16, 2016 at 3:40:32 PM UTC+3, Sokolov Yura wrote:
>
> "future" is commonly used synchronization abstraction.
>
> It could be implemented in a library, using mutex, channel and interface.
> Example: 
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>
> But obviously, semantically future is just a channel with buffer of 
> capacity 1, but receivers do not pop
> value from a buffer, but instead every receiver receive same value. And 
> "filling" future awakes all
> receivers simultaneously, similar to "closing of channel".
>
> So I propose to introduce "future" as a same internal type as a "channel".
> It will share representation and lot of code with buffered channel (of 
> capacity 1).
>
> https://github.com/golang/go/issues/17466
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Roberto Zanotto]

I missed the chance to comment on github...

This also works for implementing futures and it's simple, type-safe and can 
be used with select:
https://play.golang.org/p/VDT36rC5A-
Of course the syntax is not as nice as built-in futures.

On Sunday, October 16, 2016 at 2:40:32 PM UTC+2, Sokolov Yura wrote:
>
> "future" is commonly used synchronization abstraction.
>
> It could be implemented in a library, using mutex, channel and interface.
> Example: 
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>
> But obviously, semantically future is just a channel with buffer of 
> capacity 1, but receivers do not pop
> value from a buffer, but instead every receiver receive same value. And 
> "filling" future awakes all
> receivers simultaneously, similar to "closing of channel".
>
> So I propose to introduce "future" as a same internal type as a "channel".
> It will share representation and lot of code with buffered channel (of 
> capacity 1).
>
> https://github.com/golang/go/issues/17466
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[adonovan via golang-nuts]

On Monday, 17 October 2016 10:10:47 UTC-4, Sokolov Yura wrote:
>
> Mutex needs not to be type-safe.
> And Mutex is not part of concept of "language tailored towards 
> concurrency". 
>

Go does not take a strong Erlang-like stance against concurrency with 
shared variables, so mutexes really are critical to Go's concurrency.

But "future" is well known, widely adopted (though, in different ways)
> concurrency primitive.
> It definitely has right to be part of "language for concurrency".
>
I've already implemented Futures as library code several times, but
> they are redundant.
> To build Future as a library code, you need:
> - redundant interface{}
> - redundant Mutex
> - you still need 'chan'
> - you need to wrap it in a struct
> - and then provide "convenient" redundant api.
>

This is really a special case of the argument for generics in Go.

Futures are to channels and stacks are to slices.  With generics, you could 
provide first-class Future and Stack, but without generics it's 
simply not worth the effort for most users to bother with the abstraction 
since it can be written in little more than a dozen lines of code: 
 https://play.golang.org/p/Obqag2hgZe  It's just easier to implement the 
underlying operations directly.

 

> But 99% of functionality is already in 'chan' implementation.
> And ":= <-" with "<-" is a perfect api for future.
> There is a need only in a (relatively) small change to runtime and (a
> bit larger) to compiler.
>

Adding a new data type is not a small change to the language.  It requires 
changes to the spec, the compiler, the reflect package, every program that 
uses the reflect package, every tool that manipulates Go source code, and 
many other things too.  The only types that currently enjoy special status 
in the type system are slice, map, channel and a small number of others, 
all of which are very widely used.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Mutex needs not to be type-safe.
And Mutex is not part of concept of "language tailored towards concurrency".

But "future" is well known, widely adopted (though, in different ways)
concurrency primitive.
It definitely has right to be part of "language for concurrency".
(ohhh, three lines of text with "concurrency" in... sorry for that)

I've already implemented Futures as library code several times, but
they are redundant.
To build Future as a library code, you need:
- redundant interface{}
- redundant Mutex
- you still need 'chan'
- you need to wrap it in a struct
- and then provide "convenient" redundant api.

But 99% of functionality is already in 'chan' implementation.
And ":= <-" with "<-" is a perfect api for future.
There is a need only in a (relatively) small change to runtime and (a
bit larger) to compiler.


понедельник, 17 октября 2016 г., 16:42:17 UTC+3 пользователь 
adon...@google.com написал:
>
> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>>
>> "future" is commonly used synchronization abstraction.
>>
>> It could be implemented in a library, using mutex, channel and interface.
>> Example: 
>> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>>  
>> 
>>
>
> If it can be implemented as a library, why build it in to the language? 
>  You don't need futures very often---far less than, say, Mutex, and mutexes 
> aren't built into the language either.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Юрий Соколов]

Mutex needs not to be type-safe.
And Mutex is not part of concept of "language tailored towards concurrency".

But "future" is well known, widely adopted (though, in different ways)
concurrency primitive.
It definitely has right to be part of "language for concurrency".
(ohhh, three lines of text with "concurrency" in... sorry for that)

I've already implemented Futures as library code several times, but
they are redundant.
To build Future as a library code, you need:
- redundant interface{}
- redundant Mutex
- you still need 'chan'
- you need to wrap it in a struct
- and then provide "convenient" redundant api.

But 99% of functionality is already in 'chan' implementation.
And ":= <-" with "<-" is a perfect api for future.
There is a need only in a (relatively) small change to runtime and (a
bit larger) to compiler.

With regards,
Sokolov Yura aka funny_falcon


2016-10-17 16:42 GMT+03:00 adonovan via golang-nuts
:
> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>>
>> "future" is commonly used synchronization abstraction.
>>
>> It could be implemented in a library, using mutex, channel and interface.
>> Example:
>> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>
>
> If it can be implemented as a library, why build it in to the language?  You
> don't need futures very often---far less than, say, Mutex, and mutexes
> aren't built into the language either.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/yitP4iM4Y3k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.