Can other models of concurrency be added to Go 2 or is that put of the question?

xuanbao · · 382 次点击

这是一个分享于的资源，其中的信息可能已经有所发展或是发生改变。

Having Actor Model/Virtual Actor Model would be interesting to see. I know it goes against "don't add what's not necessary" but debate is still in the air over CSP vs Actor Model. Pipe dream wish, I know. <hr/>**评论：** earthboundkid: <pre>Am I the only one who feels like they are taking crazy pills when they read about async in C#/Python/JavaScript? It's so much less convenient than Go, but people act like it's great even though it's really just cooperative multitasking with a language keyword. It makes no sense to me. </pre>lhxtx: <pre>Yeah. I tried multiple times to grok asyncio on Py3 and just gave up. Either the documentation is that terrible or the library is that poorly engineered. </pre>Kraigius: <pre>I thought it was great with C# but then I stumbled across cases where it would deadlock because of the context of where you used it. So basically it's doing a lot of magic behind the scene and you actually need to be aware of what's going on and where to use the async syntax. You can't just read the code and understand it anymore.</pre>EZYCYKA: <pre>JS promises are quite interesting and make a lot of sense for front-end code where you are waiting for some data to come in from the back-end.</pre>TheMerovius: <pre>Honestly? I 100% prefer go's "write synchronous code and let the runtime handle asynchronicity for you" philosophy. I'd much rather write (fake javascript using go's concurrency model): <pre><code>function getData() { showSpinner(); try { data = get("/data"); otherData = doSomethingElsePossiblyInvolvingTheNetwork(data); return doMoreStuff(data, otherData); } catch (e) { showErrorMessage(e); } finally { hideSpinner(); } } </code></pre> than write (with promises): <pre><code>function getData() { var data; showSpinner() return get("/data").then(function(d) { // Wait, how are you supposed to even do this idiomatically? This can't be it… data = d; return doSomethingElsePossiblyInvolvingTheNetwork(data); }).then(function(otherData) { doMoreStuff(data, otherData); hideSpinner(); }).catch(e) { showErrorMessage(e); hideSpinner(); // Am I understanding correctly, that promises have no finally? } } </code></pre> (as you can tell, not great with javascript…). Go's concurrency model allows you, to write sequential code, without needing to care whether something you write will block or not. To make that work with javascript, it would need to a) spawn callbacks in a new user-land thread, b) would need to yield when doing (asynchronous) IO and schedule threads and… that's it, pretty much. You could also add some locking to browser-APIs that mutate state (like DOM-manipulations), but you could also just continue to let js run single-threaded. With that kind of concurrency support in the runtime, probably upwards of 90% of user-code could just be synchronous. The power of go's concurrenly model isn't so much channels and goroutines, it's the fact that all go code and all IO integrates nicely with it. I rarely actually use channels or goroutines and instead rely on things like <code>errgroup</code>. I still profit immensely from the go concurrency model, because the runtime will make sure that long-running IO will be interleaved efficiently - and in the end, that's the real goal. PS: Serious question though, how are you supposed to pass on some data in the continuation-style? I mean, I have <code>data</code> and a promise, returned by <code>doSomethingElsePossibly…</code> -- how do I pass both on?</pre>EZYCYKA: <pre>You can do <code>finally</code> by slapping a <code>.then</code> at the end (after <code>.catch</code>). It seems many share your sentiment though, as the new async/await looks very much like your first example.</pre>TheMerovius: <pre>async/await, AFAIK, still requires you to actually know about concurrency and whether a function blocks or not (and make that part of the API). I don't want to care.</pre>SSoreil: <pre>Other models of concurrency are normally designed to be implemented via a library. The model Go uses is already quite an exception to the rule in that it relies on language features. Why would a different model need to rely on language changes?</pre>corvuscrypto: <pre>This being said I would like it if you could specify priorities that the scheduler could recognize. A la boost's fiber scheduler</pre>shovelpost: <pre><a href="https://media.giphy.com/media/1M9fmo1WAFVK0/giphy.gif">But why?</a></pre>srbufi: <pre><a href="https://www.quora.com/How-are-Akka-actors-different-from-Go-channels" rel="nofollow">https://www.quora.com/How-are-Akka-actors-different-from-Go-channels</a></pre>shovelpost: <pre>When you originally posted this question, it had zero explanation. Anyways, the language is done. They wouldn't add other models of concurrency at this point. BUT they are discussing Go 2 at the moment. If you are really serious about this then you should create a concrete proposal and describe if you want a language change or if it could be added as a library, what problems it solves etc.</pre>srbufi: <pre>Re-read my post title. TL;DR "could we add new concurrency models to Go 2"</pre>shovelpost: <pre>TL;DR If you are really serious about this then you should create a concrete proposal that describes why, what problems it solves, how it is going to be implemented (language change, library, tooling), the impact on existing codebases etc.</pre>TheMerovius: <pre>Hm, but you can already have unbounded, asynchronous queues in go: <pre><code>func asyncQ(ch <-chan int) <-chan int { out := make(chan int) go func() { var ( q []int send chan int next int } for send != nil && ch != nil { select { case v, ok := <-ch if !ok { ch = nil continue } q = append(q, v) next, send = q[0], out case send <- next: q = q[1:] if len(q) == 0 { send = nil } else { next = q[0] } } } close(out) }() return out } </code></pre> So, this seems to be perfectly expressible with the current concurrency primitives (though I'd consider it a bad idea). It might be a bit unwieldy, but can be abstracted once in a library. There doesn't seem to be a particular need for adding this as a language feature.</pre>srbufi: <pre>Other models of concurrency: <a href="https://youtu.be/7AByMX76c_4?t=7m11s" rel="nofollow">https://youtu.be/7AByMX76c_4?t=7m11s</a></pre>youtubefactsbot: <pre><blockquote> <a href="http://youtu.be/7AByMX76c_4" rel="nofollow">Groovy and Concurrency with GPars [60:50]</a> <blockquote> This session looks at using Groovy for writing multithreaded, concurrent, and parallel programs. It briefly discusses leveraging legacy Java techniques such as multiple processes, multiple threads, the java.util.concurrent APIs, and shared-state atomicity. Then it considers some useful AST transforms in core Groovy (Lazy, Synchronized, Immutable, WithReadLock, and WithWriteLock) before diving headlong into GPars, a comprehensive library for parallel execution that provides a menu of options to the developer. </blockquote> <a href="https://www.youtube.com/channel/UCdDhYMT2USoLdh4SZIsu_1g" rel="nofollow">JavaOne</a> in People & Blogs 539 views since Jun 2015 </blockquote> <a href="/r/youtubefactsbot/wiki/index" rel="nofollow">bot info</a></pre>_youtubot_: <pre>Video linked by <a href="/u/srbufi" rel="nofollow">/u/srbufi</a>: <table><thead> <tr> <th align="center">Title</th> <th align="center">Channel</th> <th align="center">Published</th> <th align="center">Duration</th> <th align="center">Likes</th> <th align="center">Total Views</th> </tr> </thead><tbody> <tr> <td align="center"><a href="https://youtu.be/7AByMX76c_4?t=7m11s" rel="nofollow">Groovy and Concurrency with GPars</a></td> <td align="center">JavaOne</td> <td align="center">2015-06-08</td> <td align="center">1:00:50</td> <td align="center">4+ (100%)</td> <td align="center">539</td> </tr> </tbody></table> <blockquote> This session looks at using Groovy for writing... </blockquote> <hr/> <a href="https://np.reddit.com/r/youtubot/wiki/index" rel="nofollow">Info</a> | <a href="https://np.reddit.com/message/compose/?to=_youtubot_&subject=delete%20comment&message=dkx0rak%0A%0AReason%3A%20%2A%2Aplease+help+us+improve%2A%2A" rel="nofollow">/u/srbufi can delete</a> | v1.1.3b</pre>