Тут є два запитання:
- Чи є Scala хорошим вибором для порту
goroutines?
Це легке запитання, оскільки Scala - це мова загального призначення, яка не гірша чи краща за багато інших, які ви можете обрати для "перенесення горутин".
Звичайно, існує багато думок щодо того, чому Scala краща чи гірша як мова (наприклад, тут моя), але це лише думки, і не дозволяйте їм зупиняти вас. Оскільки Scala є загальним призначенням, це "в значній мірі" зводиться до: все, що ви можете робити на мові X, ви можете робити в Scala. Якщо це звучить занадто широко ... як щодо продовжень у Java :)
- Чи схожі актори Scala
goroutines?
Єдина схожість (крім нікчемності) полягає в тому, що вони обидва пов'язані з паралельністю та передачею повідомлень. Але на цьому подібність закінчується.
Оскільки відповідь Джеймі дала хороший огляд акторів Scala, я більше зупинюсь на Goroutines / core.async, але з деяким вступом акторської моделі.
Актори допомагають "безтурботному розподілу"
Там , де «вільний занепокоєння» частина, як правило , асоціюється з такими поняттями, як: fault tolerance, resiliency, availabilityі т.д ..
Не вдаючись у важкі подробиці того, як працюють актори, двома простими словами актори мають відношення до:
- Місцевість : кожен актор має адресу / посилання, за допомогою яких інші актори можуть надсилати повідомлення
- Поведінка : функція, яка застосовується / викликається, коли повідомлення надходить до актора
Подумайте про "розмовні процеси", де кожен процес має посилання та функцію, яка викликається, коли надходить повідомлення.
Звичайно, є набагато більше (наприклад, перевірте Erlang OTP або akka docs ), але наведені вище два є гарним початком.
Там, де стає цікаво з акторами, є .. реалізація. На даний момент двома великими є Erlang OTP та Scala AKKA. Хоча вони обидва прагнуть вирішити одне і те ж, є деякі відмінності. Давайте розглянемо пару:
Я навмисно не використовую жаргон, такий як "посилальна прозорість", "ідемпотентність" тощо. Вони не приносять жодної користі, окрім як викликають плутанину, тому давайте просто поговоримо про незмінність [ can't change thatпоняття]. Ерланг як мова є самовпевненим, і він схиляється до сильної незмінності, тоді як у Scala занадто легко змусити акторів, які змінюють / мутують свій стан при отриманні повідомлення. Це не рекомендується, але змінність у Scala знаходиться прямо перед вами, і люди цим користуються.
Ще одним цікавим моментом, про який говорить Джо Армстронг, є той факт, що Scala / AKKA обмежена JVM, яка насправді не була розроблена з урахуванням "розподілу", тоді як Ерланг В.М. Це пов’язано з багатьма речами, такими як: ізоляція процесу, для кожного процесу проти цілого збору сміття VM, завантаження класів, планування процесу та інші.
Сенс вищесказаного полягає не в тому, щоб сказати, що один кращий за інший, але в тому, щоб показати, що чистота акторської моделі як концепції залежить від її реалізації.
Тепер до горутин ..
Горутини допомагають міркувати про паралельність послідовно
Як і інші відповіді, про які вже згадувалося, горутини вкорінюються у передачі послідовних процесів , що є "формальною мовою для опису моделей взаємодії в паралельних системах", що за визначенням може означати майже все :)
Я збираюся навести приклади на основі core.async , оскільки я знаю його внутрішні елементи краще, ніж Goroutines. Але він core.asyncбув побудований за моделлю Goroutines / CSP, тому концептуально не повинно бути занадто багато відмінностей.
Основним примітивом паралельності в core.async / Goroutine є channel. Подумайте про це channelяк про "чергу на скелях". Цей канал використовується для "передачі" повідомлень. Будь-який процес, який хотів би "взяти участь у грі", створює або отримує посилання на a channelта передає / приймає (наприклад, надсилає / отримує) повідомлення в / з нього.
Безкоштовна цілодобова автостоянка
Більшість робіт, які виконуються на каналах, зазвичай відбуваються всередині " Goroutine " або " go block ", який " бере своє тіло і перевіряє його на будь-які операції каналу. Це перетворить тіло на автомат стану. Після досягнення будь-якої операції блокування, автомат стану буде «припаркований», і фактичний потік керування буде звільнений. Цей підхід схожий на той, що використовується в C # async. Коли операція блокування завершиться, код буде відновлений (для потоку пулу потоків або єдиний потік у JS VM) "( джерело ).
Набагато легше передати за допомогою візуального. Ось як виглядає блокування виконання вводу-виводу:
Ви бачите, що нитки в основному витрачають час на очікування роботи. Ось та ж робота, але виконана за допомогою підходу "Goroutine" / "go block":
Тут 2 потоки виконали всю роботу, що зробили 4 потоки під час блокування, забираючи стільки ж часу.
Кікер у наведеному вище описі: "потоки припарковані ", коли у них немає роботи, а це означає, що їх стан "розвантажується" до автомата стану, а фактичний поточний потік JVM може виконувати іншу роботу ( джерело для чудового візуального )
Примітка : у core.async канал можна використовувати поза "go block", який буде підтримуватися потоком JVM без можливості паркування: наприклад, якщо він блокує, він блокує реальний потік.
Потужність Go Channel
Ще одна величезна річ у "Goroutines" / "go blocks" - це операції, які можна виконувати на каналі. Наприклад, можна створити канал очікування , який закриється через X мілісекунд. Або виберіть / alt! функція, яка, використовуючись разом із багатьма каналами, працює як механізм опитування "ти готовий" для різних каналів. Подумайте про це як про селектор сокета в неблокуючому введенні. Ось приклад використання timeout channelта alt!разом:
(defn race [q]
(searching [:.yahoo :.google :.bing])
(let [t (timeout timeout-ms)
start (now)]
(go
(alt!
(GET (str "/yahoo?q=" q)) ([v] (winner :.yahoo v (took start)))
(GET (str "/bing?q=" q)) ([v] (winner :.bing v (took start)))
(GET (str "/google?q=" q)) ([v] (winner :.google v (took start)))
t ([v] (show-timeout timeout-ms))))))
Цей фрагмент коду береться з wracer , де він надсилає однаковий запит усім трьом: Yahoo, Bing та Google, і повертає результат з найшвидшого, або час очікування (повертає повідомлення про таймаут), якщо жоден не повернувся протягом заданого часу. Мова Clojure може бути не вашою рідною мовою, але ви не можете не погодитися з тим, наскільки послідовно виглядає та відчувається ця реалізація паралелізму.
Ви також можете об'єднати / роздути / розігнати дані з / у багато каналів, зіставити / зменшити / фільтрувати / ... дані каналів та багато іншого. Канали також є громадянами першого класу: ви можете передати канал на канал ..
Go UI Go!
Оскільки core.async "go blocks" має таку можливість "паркувати" стан виконання та мати дуже послідовний "вигляд і відчуття" при роботі з паралельністю, як щодо JavaScript? У JavaScript немає одночасності, оскільки існує лише одна нитка, так? І спосіб імітації одночасності - це 1024 зворотних викликів.
Але це не повинно бути так. Наведений вище приклад з wracer фактично написаний на ClojureScript, який компілюється до JavaScript. Так, це буде працювати на сервері з багатьма потоками та / або в браузері: код може залишатися незмінним.
Горутини проти core.async
Знову ж таки, кілька відмінностей у впровадженні [їх є більше], щоб підкреслити той факт, що теоретична концепція не є точно одна до одної на практиці:
- У програмі Go канал набирається, а в core.async це не так: наприклад, у core.async ви можете розміщувати повідомлення будь-якого типу на одному каналі.
- У Go ви можете розміщувати на каналі змінні речі. Це не рекомендується, але ви можете. У core.async, за проектом Clojure, всі структури даних є незмінними, отже, дані всередині каналів почуваються набагато безпечнішими для свого добробуту.
То який вирок?
Я сподіваюся, що вищесказане пролило світло на відмінності між акторською моделлю та CSP.
Не для того, щоб викликати полум’яну війну, а для того, щоб дати вам ще одну точку зору, скажімо, Річа Хікі:
" Я досі залишаюсь без ентузіазму щодо акторів. Вони все ще поєднують продюсера зі споживачем. Так, можна імітувати або впроваджувати певні види черг з акторами (і, зокрема, люди це часто роблять), але оскільки будь-який механізм актора вже включає чергу, це здається очевидним, що черги є більш примітивними. Слід зазначити, що механізми Clojure для одночасного використання держави залишаються життєздатними, а канали орієнтовані на потокові аспекти системи "( джерело )
Однак на практиці Whatsapp базується на Erlang OTP, і здавалося, він продається досить добре.
Ще одна цікава цитата з Роб Піке:
" Буферизовані надсилання не підтверджуються відправнику і можуть тривати довільно довго. Буферовані канали та програми дуже близькі до акторської моделі.
Справжня різниця між акторською моделлю та Го полягає в тому, що канали - це першокласні громадяни. Також важливо: вони є непрямими, як дескриптори файлів, а не імена файлів, дозволяючи стилі одночасності, які не так легко виразити в акторській моделі. Бувають також випадки, коли вірно і зворотне; Я не роблю ціннісного судження. Теоретично моделі еквівалентні. "( джерело )