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

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

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

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

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

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

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

> 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,

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

понедельник, 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

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

понедельник, 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

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

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

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

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

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

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

[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

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