Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Just so you know, it’s already possible to use coroutines in Swift with Venice. https://github.com/VeniceX/Venice > On Aug 11, 2016, at 7:36 PM, Dan Stenmark via swift-evolution > wrote: > > Guys, as I have already mentioned a

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Guys, as I have already mentioned a couple of times in this thread, let’s please not turn this into a explicit discussion about how Swift could do concurrency. That discussion is at least a few more months out, especially with memory ownership ala Rust/Cyclone being explored for Swift 4. I

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

LLVM is getting actual coroutine support, do you think it is going to help Swift started in this direction? Sent from my iPhone > On 11 Aug 2016, at 22:17, Slava Pestov wrote: > > >> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution >>

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution > wrote: > > Thanks for the concise and clear review of green threads :). I can understand > the concerns of runtime implementation when the runtime of the language is > replacing the kernel

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Thanks for the concise and clear review of green threads :). I can understand the concerns of runtime implementation when the runtime of the language is replacing the kernel scheduler. Sent from my iPhone > On 11 Aug 2016, at 19:09, Kevin Ballard wrote: > > AIUI, fibers are

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

AIUI, fibers are basically coroutines. Even the Naughty Dog presentation says that fibers are run on threads, and you have to make an explicit call to switch between fibers. Looking at Ruby's Fiber type, that's also an explicit coroutine, where you actually yield up a value when you yield your

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

+Swift Evolution By the way, I was genuine when I said thank you because reading how Rust evolved in those two aspects is very insightful. On Thu, Aug 11, 2016 at 6:54 PM, Goffredo Marocchi wrote: > Hello Kevin, > > I may be wrong in my equating support for fibers to green

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

I'm confused by your email. Rust is all about performance, and embedded devices are one of the targets for Rust. And I can't think of any language that uses green threading that is appropriate for constrained devices (e.g. Go definitely isn't appropriate for that). One of the arguments for getting

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Thanks Kevin, I think they have accepted that they do not need to enter every segment of computing so the extra performance they could get on some devices is not worth the risk and the complexity it brings. Not everyone is trying to cram complex 3D experiences at 60-90+ FPS on a console like

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

For anyone interested in reading more about Rust's decisions, here's two links: The email about abandoning segmented stacks: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html The RFC to remove green threading, with motivation:

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 10, 2016, at 10:24 PM, Chris Lattner wrote: > > Hi Dan, > > There are many folks interested in concurrency topics related to this, but we > need to stay focused on finishing Swift 3 and then moving on to Swift 4 stage > 1 goals. As that work is cresting, we’ll

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 9, 2016, at 12:04 PM, Dan Stenmark via swift-evolution > wrote: > > I'd like to inquire as to what the Swift team thoughts on Go's concurrency > model are? I'm not referring to convenience of the 'go' keyword and nor am I > referring to how the language

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

On Wed, Aug 10, 2016 at 3:50 PM, David Sweeris via swift-evolution wrote: > For example, maybe you really do need to interpret a 64-bit chunk of data as > an Int64, even though the compiler is convinced it’s a Double. We can do that > in Swift through the various

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 10, 2016, at 5:36 PM, Slava Pestov wrote: > > >> On Aug 10, 2016, at 3:34 PM, Christopher Kornher wrote: >> >> Would this prevent an object from being “known" to multiple threads? >> …multiple queues? If so, it would be overly restrictive for a

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 10, 2016, at 3:34 PM, Christopher Kornher wrote: > > Would this prevent an object from being “known" to multiple threads? > …multiple queues? If so, it would be overly restrictive for a general-purpose > language. I assume that the plan includes a way to allow

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Would this prevent an object from being “known" to multiple threads? …multiple queues? If so, it would be overly restrictive for a general-purpose language. I assume that the plan includes a way to allow “unsafe” behavior to support other concurrency models. > On Aug 10, 2016, at 4:24 PM,

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 10, 2016, at 3:22 PM, David Sweeris wrote: > >> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution >> wrote: >> >> As I understand it, a big weakness of Go's model is that it does not >> actually prevent data races. There's

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution > wrote: > > As I understand it, a big weakness of Go's model is that it does not actually > prevent data races. There's nothing preventing you from sharing pointers to > mutable values between tasks,

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 9, 2016, at 1:59 PM, Joe Groff via swift-evolution > wrote: > >> >> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution >> wrote: >> >> The Rust language used to use a green thread model like Go (actually it >>

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

According to http://c9x.me/art/gthreads/intro.html I would guess so - pretty much userland threads - swapping context without kernel. > On Aug 9, 2016, at 11:07 PM, Goffredo Marocchi via swift-evolution > wrote: > > Talking

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Talking about green threads, are they similar to fibers? http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine Sent from my iPhone > On 9 Aug 2016, at 21:59, Joe Groff via swift-evolution > wrote: > > >> On Aug 9, 2016, at 1:28 PM, Kevin

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution > wrote: > > The Rust language used to use a green thread model like Go (actually it > exposed a configurable threading interface so you could choose green threads > or OS threads). It also used

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

The Rust language used to use a green thread model like Go (actually it exposed a configurable threading interface so you could choose green threads or OS threads). It also used segmented stacks like Go did. Over time, Rust ended up dropping the segmented stacks because it significantly

[swift-evolution] What're the Swift team's thoughts on Go's concurrency?

I'd like to inquire as to what the Swift team thoughts on Go's concurrency model are? I'm not referring to convenience of the 'go' keyword and nor am I referring to how the language handles Channels, both of which being what most folks associate with it. Rather, I'd like to ask about the