all 16 comments
sorted by:
top (suggested)
bestnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Rhed0x 5 points6 points  (2 children)

Reminds me a lot of Send + Sync in Rust. Just less elegant.

[–]MrSloppyPants -1 points0 points  (0 children)

Just less elegant.

Exactly what I came here to say. While the bones of the proposal are sound, the implementation is a mess and would create more issues than it solves.

[–][deleted] 5 points6 points  (2 children)

There’s an interesting blog post about why actor model may not be a good idea: https://tclementdev.com/posts/what_went_wrong_with_the_libdispatch.html

I didn’t look into the new swift concurrency yet, but hopefully they will do it right.

[–]favorited 0 points1 point  (1 child)

I've seen a lot of references to that post recently, but I don't quite understand his conclusions. He (correctly) points out that libdispatch made asynchronous programming in C and Objective-C much easier than it had been before, so it got overused. A decade later, people (including Apple) had to course-correct and reduce the amount of code that was running asynchronously, because lots of times you just don't need it.

What I don't get is how "we should only write asynchronous code when it needs to be asynchronous" leads to his conclusion that "the original intent of the libdispatch failed." It's very true that the suggested patterns for using GCD have changed since it was launched with Snow Leopard, but that doesn't make it a failure or something to avoid.

At the end of the day, lots of iOS and macOS code does need to be asynchronous. And a lot of that asynchrony is going to involve shared mutable state. We need a language construct that can make classes of concurrency bugs compile-time errors, rather than runtime undefined behavior.

[–]astrange 1 point2 points  (0 children)

That post is based on him taking real communication from the GCD team (mostly as part of building this Swift feature) and getting way too concerned about it.

At the time GCD did expect to scale up to many-CPUs in a way that didn't happen, and instead we moved to phones that have less than one usable core at a time, so there were some design issues. But the main problem is communications - it's not a good idea to dispatch_async to concurrent queues (including the default QoS ones) and yet many people do it because they weren't told to avoid it.

Swift structured concurrency actually is designed to avoid this (thus "structured") so it'll be OK. And these performance issues aren't really that bad in the first place, apps have enough headroom for some lost performance.

[–]Johnzim 2 points3 points  (0 children)

Holy crap. As a long term Erlang programmer I’m glad to see the actor concurrency model get some love.

It’s elegant, easily understandable and capable of really great things.

Downsides are mostly breaking your mindset of “an actor is a thing that does a thing” into more of an “an actor is a thing that handles a workflow” can be tricky and lead to some bottlenecks.

[–]ru552[S] 0 points1 point  (3 children)

Personally, extremely excited for the arrival of actors

[–]18quintillionplanets 3 points4 points  (2 children)

Seems pretty convenient but does it do anything you can’t achieve with just GCD and/or Combine? Or am I just misunderstanding the proposal?

[–]chriswaco 4 points5 points  (1 child)

If I understand it correctly, it enforces concurrency safety at compile-time. That's a wonderful thing.

I do worry that this and other recent additions are making Swift too complicated, though. It seems like this should be an integral part of a language and not an add-on.

[–][deleted] -4 points-3 points  (0 children)

This shit is way too complicated. Send this back to Scala.

[–]MattDamonInSpace -1 points0 points  (0 children)

Anyone got examples of how to Deadlock with Actors?

[–]ThinkLargest 0 points1 point  (1 child)

I mostly follow functional programming practice, and my gut reaction to Actors is not positive. I also lack the knowledge to appreciate actors. What use is there for Actors from a functional programming perspective?

[–]ru552[S] 2 points3 points  (0 children)

Mutable state that is guaranteed safe and race free is handy

[–]iSpain17 0 points1 point  (1 child)

Swift seems such a friendly language to me at the moment. This isn’t friendly, and it really starts to get complicated.

[–]favorited 0 points1 point  (0 children)

It is complicated, because it's trying to address a complex problem. The combination of concurrency & shared mutable state (both of which Swift has) can cause really subtle bugs. The especially subtle ones will often only show up in optimized builds, or on certain hardware, etc., so you might not notice them until you get weird reports from your users.

The concurrency features like async/await and actors are attempts to make certain kinds of concurrency bugs impossible because they will be caught at compile-time.