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
>>
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FWorkiva%2Fgo-datastructures%2Fblob%2Fmaster%2Ffutures%2Fselectable.go&sa=D&sntz=1&usg=AFQjCNErWyxHIbetA_9_Su3al1T2kxM9tQ>
>>
>
> 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.
