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.

Reply via email to