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<T> and Stack<T>, 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.
