Swift Concurrency Manifesto | Chris Lattner and Lex Fridman

Lex Fridman Podcast full episode: • Chris Lattner: The Fut...
Please support this podcast by checking out our sponsors:
Blinkist: blinkist.com/lex and use code LEX to get a free week of premium
Neuro: www.getneuro.com and use code LEX to get 15% off
MasterClass: masterclass.co... to get 15% off annual sub
Cash App: cash.app/ and use code LexPodcast to get $10
PODCAST INFO:
Podcast website: lexfridman.com...
Apple Podcasts: apple.co/2lwqZIr
Spotify: spoti.fi/2nEwCF8
RSS: lexfridman.com...
Full episodes playlist: • Lex Fridman Podcast
Clips playlist: • Lex Fridman Podcast Clips
CONNECT:
Subscribe to this KZbin channel
Twitter: / lexfridman
LinkedIn: / lexfridman
Facebook: / lexfridmanpage
Instagram: / lexfridman
Medium: / lexfridman
Support on Patreon: / lexfridman

[@tomwright9904]

5:38 "You're kind of fu- stuck with a bad set of trade offs" :D

[@austinmw89]

One of my favorite guests

[@adelinaquijano1083]

I think my enternet before we apply before last 2018 I thought I finish my contract.

[@GoofyHistorians]

Lex, you are the best!

[@unoarecare5728]

please make distributed actor compatible with iOS, take in account battery, app lifetime, and bootstrap node by default in in apple

[@kevinayers7144]

wait, wait, wait........ are you saying you've solved race conditions :0

[@jj680l]

Rust language is known to have solved race conditions, even when using shared memory. Not sure about Swift.

[@Xaxxus]

@@jj680l yes, as of swift 5.5 race conditions are essentially solved at the compiler level now. Swift added actors. So if you put your race condition prone code into an actor, you will get compile errors when you try to do something that will cause a race condition.

[@ConernicusRex]

Not excited by async/await. DispatchQueue already has all of these features.

[@pawelpow]

Completion handlers? Actors? Synchronous syntax?

[@spaceowl5957]

I'm just learning about Swift concurrency, so forgive me if I'm wrong, but here's my assessment, having worked with DispatchQueues and locks: async / await is kinda just syntax sugar for completion handlers as far as I understand. But it's very nice syntax sugar that does really make the code easier to read and refactor in some cases. If you hide all accesses to a set of state behind a DispatchQueue, you basically have a more flexible version of an actor as far as I understand. So I think Actors are kinda syntax sugar for a specific pattern you can already implement with DispatchQueues. Task is kinda just a DispatchQueue that is compatible with the async / await keywords and the Swift error throwing syntax? It would've felt more elegant if they made async/await compatible with DispatchQueues instead of creating Task. I'm not sure why they didn't do that. Maybe technical reasons? Not sure what 'Synchronous syntax' means that @pawelpow mentioned. In conclusion: If I'm not misunderstanding, the whole Swift concurrency stuff is basically syntax sugar / a more restrictive and opinionated version of stuff you can already do with DispatchQueues and completion handlers. And of course that restrictiveness brings the dubious benefit of 'safety', which I generally dislike because the 'safe' version usually doesn't cover all the things I wanna do, makes some things more cumbersome or require workarounds, doesn't really make it that much easier to write code that is *acutally correct* and bug free, and - knowing Swift - the performance characteristics are probably not great either. So I think I'll use async await in some places instead of nested completion handlers, but I'll probably stay clear of the Actor stuff and just try to do things as single-threadedly as possible (like a sane person) and otherwise I'll use DispatchQueues or locks, which are flexible and performant. It's a shame, I think if Actors were more compatible with DispatchQueues, I think I'd use it as convient syntax sugar sometimes, but I really don't like that it forces you into using the async/await and Task stuff and restrictive Swift 'safety' rules everywhere that you interact with the Actor. I really don't like that. Especially since I'm not confident in this Swift stuff for performance-critical code.