مشکلات concurrency در اسکالا

scala
concurrency

#1

این ویدئو خیلی جالبه. به یه سری از مشکلات concurrency در اسکالا می پردازه که ما باهاش در حال دست و پنجه نرم کردن هستیم. اگر اونجا بودن اخرش بهش می گفتم “اگر clojure استفاده کنی هیچ کدوم از این مشکلات رو نخواهی داشت.” دقیفا همه مشکلاتی و راه حل هایی که می ده تو دنیای کلوژر خیلی وقت حل شده.


#2

اینا مشکلات سکالا نیست بلکه اگر بخواهی خالص فانکشنال کد بنویسی با تایپ سیستم قوی باید از IO Monad استفاده کنی ولی اگر قرار بود تایپ سیستم و بندازی دور خوب akka هست تو سکالا
Concurrency خیلی خوب هم جواب میده
Cats effect اینجا library کار کردن با تغییرات به صورت کاملا typesafe و فانکشنال scalaz 8 کلی future ها را بهتر کرده


#3

باید یه نگاهی بهش بندازم. اما مثلا استفاده از IO Monad یکی از دلایلش این هست که می خوان total order رو باهاش پیده سازی کنن که خوب CSP سالهاست این مسئله رو حل کرده. یا اینکه هنوز باید نگران این باشی که thread pool رو عوض کنی تو زمان مناسب و موارد اینچنینی به نظر من ضعف هایی هست که نباید باشن. یا مثلا این واقعیت که Scala تو expression problem دنبال رو جاوا هست و عدم وجود abstraction مناسب برای بیشتر امکانات concurrency اسکالا باعث می شه دست برنامه نویس تو انتخاب کتابخونه بسته باشه. در صورتی که تو Clojure با استفاده از protocol ها راحت می شه abstraction های که کتابخانه ای که داری استفاده می کنی رو تغییر بدی. با این حساب اگر مثلا کتابخونه X از یک پیاده سازی اشتباه برای یه protocol ی مثل Task استفاده کرده باشه از تو کد خودت می تونی این مشکل رو حل کنی.

از همه اینها گذشته concurrency تو اسکالا خیلی پیچیده تر از اونچیزی هست که باید باشه. ( البته در مقایسه با Clojure )
akka کتابخونه خوبیه اما خوب همونجور که گفتی اونم مسائل خودشو داره.


#4

سکالا در عمل اصلا مشکل concurrency نداره در تجربه من abstraction های زیادی برای fork actor task وجود داره و برنامه های بسیار زیادی مانند کافکا spark finagle که از ابتدا برای concurrency درست شدن جواب خودشونو پس دادن البته حرف شما صحیحه که سکالا تو خیلی قسمت ها الکی پیچیده هستش و هرکارو ۱۰۰ مدل میشه انجام داد من از akka دل خوشی ندارم و سعی میکنم pure fp کد کنم


#5

منم با فانکشنال کاملا موافقم و کلا بدم میاد oop رو با هاش قاطی کنم.
کاملا درسته که نرم افزار هایی مثل kafka و … امتحانشون رو پس دادن. ولی خوب نکته اینجاست که سازنده های اون کتابخونه ها کارشون رو بخوبی انجام دادن و نکاتی رو که سکالا داره رو هندل کردن.

اما مثلا تو کلوژر مدیریت thread pool ها با خود clojure هست و نیازی نیست که در گیرش بشی (‌البته اگر بخوای می تونی اما نیازی نیست ) به صورت پیشفرض و با یه abstraction خیلی ساده ای total order رو پیدا سازی کرده که source و sink رو هم جدا کرده و لزوما نیازی نست از هم خبر داشته باشن. و برنامه نویس واقعا رو چیزی تمرکز می کنه که بهش نیاز داره.


#6

در سکالا هم با future یا task نیاز به تغییر threadpool نیستfuture یک monad وباهاش sequnce و ordering ساده هست


#7

برای مثال اگر یه عالمه future بسازی و تو اون ها بلاک کنی ترد رو چه اتفاقی می افته ؟
تا اونجایی که من می دونم کلا یه ترد پول به صورت پیشفرض هستش تو اسکالا


#8

بله ولی بستگی به library future داره twitter future با گارانتی ordering میاد با کد یکم دیگه توضیح میدم


#9

#10

خوب چی می شه اگر تعداد زیادی future داشته باشی که همه بلاک کنن ترد رو ؟


#11

Twitter از همه ترد ها استفاده میکنه بعد اگه همه چی بلک بشه thread starvation به وجود میاد و deadlock میگیری


#12

#13

دقیقا این دلیلی هست که بخاطرش ترد پول ها جدا می شه. البته Future انتخاب مناسبی برای این کار نیست در کل.


#14

ولی شما نباید با thread pool حتما کار کنی و در اکثر کد اصلا بهش فکر نمیکنی یعنی مشکل اصلی اینکه بلاک میکنی نه اینکه abstraction غلطه


#15

یک دلیل بزرگ استفاده کردن monad ها جدا کردن جبر برنامه از مفسرشه
یک برنامه میتونه async یا sync اجرا بشه فقط با عوض کردن نوع monad

https://scalafiddle.io/sf/2H9nIZ3/2


#16

نه دیگه . نکته اینه که بلاک کردن یا همون side effect اجتناب ناپذیره. بالاخره مجبور می شیم که این کار رو بکنیم. برای همین هم هست که از چند ترد پول استفاده می شه. در مورد Abstraction غلط هم باید بگم که همه Abstraction ها غلط نیستن اما چیزی که سکلا و زبان های زیادی باهاش روبرو هستند عدم داشتن ابزار های مناسب برای ساخت abstraction هست. monad تا حدودی این رو جیران می کنه اما خودش پیچیدگی خاصی رو به نرم افزار اضافه می کنه.

در کل سکالا هم مثل خیلی از زبان های مدرن رو concurrency خیلی کار کرده اما خوب خیلی خوبه که نقاط ضعف و قوت ابزار هامون رو بشناسیم. که فکر می کنم نکته اصلی ویدئو هم همینه.


#17

IO monad دلیل وجودش اینکه effect هارو به صورت آشکار و‌typesafe انجام بده side effect وجود نداره side effect باگه
Effect ها کنترل شده هستند بله بالاخره شما همیشه محدود به resource هستی هر زبانی باشه در نهایت سیستم تا یک حدی میتونه کار انجام بده با IO monad میشه چند کارو به راحتی باهم compose کرد و هر قسمت و sync یا async در یک نقطه در آینده انجام داد.

https://scalafiddle.io/sf/Cb5bTEP/0


#18

ساید افکت باگ نیست و باید کنترلش کرد. در نهایت هدف هر نرم افزاری تغییر دنیاست. و درسته هر زبان و نرم افزاری مشخصا تا یه حدی میتونه ریسورس استفاده کنه. ولی خوب مثلا اینکه بتونی ترد پول جدا برای بلاک کننده ها داشته باشی و ترد پول جدا برای بقیه سیستم یه استراتژی برای مدیریت ریسورس هست که زبان با زبان فرق می کنه.
من با monad به جز پیچیدگیش مشکلی ندارم.


#19

Effect تغییر دنیا refrential transparent هست side effect
Referential transparency نداره


#20

اینجا این تفاوت توضیح داده شده