зато масштабируй как хочешь

Это как? Код на плюсах магическим образом сразу может работать и асинхронно, и тредами, и между серверами? Может вы хотели сказать "как напишешь"?

Это как? Код на плюсах магическим образом сразу может работать и асинхронно, и тредами, и между серверами? Может вы хотели сказать "как напишешь"?

Код на акке может

Короче выбирая между Go и Scala для изучения, я выбрал Scala потому что JVM это безопасно, это масштабируется в любую сторону, легче интегрировать свои поделия с Hadoop, и являет нормальное человеческое ООП и нормальную человеческую функциональщину

Тогда как Go это утконос

Милый но странный

А безопасность докера в кубернетесе оставляет желать лучшего

Потому что гринлетам по удобству и адекватности далеко до goшных сопрограмм, а с скалашной akka ситуация под капотом кардинально меняется

Хм, а может наоборот? Там только две проблемы: старый синхронный код и gil

Код на акке может

Ну, это если вы его так написали. А если у вас там распределенные локи работают через файлы, то на нескольких серверах уже не развернешь

Это как? Код на плюсах магическим образом сразу может работать и асинхронно, и тредами, и между серверами? Может вы хотели сказать "как напишешь"?

На ерланге может

На ерланге может

И там есть защита от программистов, которые не мыслят распределенными системами?

И там есть защита от программистов, которые не мыслят распределенными системами?

Такие программисты пишут фронтенд

Такие программисты пишут фронтенд

а как с распределенными системами на .NET? =)

неплохо наверн

И там есть защита от программистов, которые не мыслят распределенными системами?

Да.

Такие программисты пишут фронтенд

Круто вам

Да.

Классно им)

я откровенно не шарю этот вопрос, но подозреваю что .NET программисты не особо сталкиваются с распределенными системами

Классно им)

Поэтому их почти нет

я откровенно не шарю этот вопрос, но подозреваю что .NET программисты не особо сталкиваются с распределенными системами

Веб-сервер вроде же распределенная система, нет? Если правильно писать

многопоточная - да, распределенная - не факт

На питоне от зомби потоков так или иначе никуда не деться

А можешь пояснить, каким образом наличие зомби зависит от языка, а конкретно от Петона?

А можешь пояснить, каким образом наличие зомби зависит от языка, а конкретно от Петона?

на сколько я понимаю, зависит прежде всего от наличия семафора и необходимости управлять блокировками

как быстренько посчитать кол-во пикселей опредленного цвета RGBи альфа каналом

в функциональных языках это не нужно

а в го это работает искаропки довольно таки хорошо, тогда как на питоне приходится делать много ручной работы

В PILLOW можно пнг файл по пикселю разобрать?

А в го потоки сами себя синхронизируют?

на сколько я понимаю, зависит прежде всего от наличия семафора и необходимости управлять блокировками

Аргумент пока так себе, бо весь функционал по управлению в петоне есть, а ентот функционал по сути апи к лоу левелу тех же юникс

в функциональных языках это не нужно

В функциональных языках не нужны блокировки при многопоточности?

В функциональных языках не нужны блокировки при многопоточности?

да, потому что там нет переменных в понимании нефункциональных языков

или как минимум можно их не использовать

Зомби потоки - это же когда операционная система их уже убила, но результат еще никто не получил

атомарные переменные это другое

Или вы о чем-то другом

Зомби потоки - это же когда операционная система их уже убила, но результат еще никто не получил

потому что они скорее всего заблокированы)

нет, зомби не заблокированы

потому что они скорее всего заблокированы)

Почему?

просто их никто не собрал

да, потому что там нет переменных в понимании нефункциональных языков

Ну мутабельное состояние то у вас все равно есть, пусть и не в приложении

В PILLOW можно пнг файл по пикселю разобрать?

Да

Да

я не нашел

нашел крч

открыть изображение

и что-то в нем нарисовать

а как про анализировать я чот не нашел функции

Ну мутабельное состояние то у вас все равно есть, пусть и не в приложении

А еще есть зависимые операции

а как про анализировать я чот не нашел функции

get_pixel или что-то такое

И всякие группы операций

А еще есть зависимые операции

Это норм работает само

теперь выложу карты на стол и отмечу что имел довольно ограниченный опыт работы с потоками на питоне, а в остальном ориентируюсь по информации изложенной в книжке Роберта Мартина "Чистая архитектура" и теории описанной в книге Мартина Одерски про Scala

В общем, я пока не понял, каким боком петон имеет отношение к зомби. На моей скромной практике зомбарей чаще плюсы или си демоны плодят.

А мутабельное состояние у тебя ограничивается базой

на сколько я понимаю работа с акторами в принципе меняет проблематику в этом вопросе

Это норм работает само

Это очень зависит от того, как написать

Это очень зависит от того, как написать

Ну вот ты пишешь return sum(func1(), func2())

Что можно написать не так?

А мутабельное состояние у тебя ограничивается базой

И не все они умеют в транзакции, локи и блокировки

стоит ли переходить на poetry)

И не все они умеют в транзакции, локи и блокировки

Ну про базы в ерланге я не готов. Знаю что есть мнезия. Без подробностей

мне лично даже ограниченного опыта с gunicorn + monkey patching и greenlets хватило чтобы относиться к многопоточности на питоне как к нелюбимой жене

Что можно написать не так?

Внешний источник дергает две операции, второй нужны самые актуальные данные по первой

Это из-за патчинга вы такой злой

Внешний источник дергает две операции, второй нужны самые актуальные данные по первой

Ну окей, func2(func1())

стоит ли переходить на poetry)

Я пользовался, мне нравилось, правда в последнее время все-равно venv юзаю или докер

Ну окей, func2(func1())

он дергает их по апи же.

Сначала одну ручку, потом другую

он дергает их по апи же.

Ну что там func1 и функ2 это уже другой вопрос

И вообще не влияет как между ними данные передаются

Они не передаются между ними, вторая функция берет самые свежие результы первой из бд

Тогда они не связанны

мне лично даже ограниченного опыта с gunicorn + monkey patching и greenlets хватило чтобы относиться к многопоточности на питоне как к нелюбимой жене

Там же голые трединги и мультипроцессинги

И вторая не может гарантированно взять данные, которая положила перва,

Тогда они не связанны

Но вторая должна дождатся самые свежие расчеты по первой, следовательно, нужно немного блокировок

Но вторая должна дождатся самые свежие расчеты по первой, следовательно, нужно немного блокировок

Каких блокировок?

Каких блокировок?

если выполняется первая фунция, то дождатся выполнения и потом взять свежие данные

Во второй функции

Там же голые трединги и мультипроцессинги

грубо говоря сравнение питоно-потоков, го-сопрограмм (горутин) и скала-акторов это сравнение между механической коробкой передач, автоматом и роботом

если выполняется первая фунция, то дождатся выполнения и потом взять свежие данные

Не прокатит

Выполняй первую функцию, а потом бери ее результаты и клади в бд и одновременно передавай во вторую

Не прокатит

Технически или идеологически? Технически реализуемо

Технически ты делаешь прям очень сложный какой-то финт

Не забывай, это не процедурные языки. Возможно там вообще доков нет, я не знаю.

По крайней мере понятия "изменяема, переменная" обычно нет

грубо говоря сравнение питоно-потоков, го-сопрограмм (горутин) и скала-акторов это сравнение между механической коробкой передач, автоматом и роботом

А си тогда што?) Для полноты сравнения

Есть вход и выход

мне лично даже ограниченного опыта с gunicorn + monkey patching и greenlets хватило чтобы относиться к многопоточности на питоне как к нелюбимой жене

к тому же удобоваримые питонопотоки требуют наращивание лишних абстракций, тогда как прочие решения более лаконичны)

мне лично даже ограниченного опыта с gunicorn + monkey patching и greenlets хватило чтобы относиться к многопоточности на питоне как к нелюбимой жене

Да а вебе не нужны потоки

Как правило нужны процессы + любой способ параллельно послать пару запросов

Потому что внешний источник. Пример, внешний источник n раз в день присылает данные, которые нужно обработать. А другой внешний источник дергает апи для формирования _самого_ актуального отчета. Обе операции условно долгие (от нескольких минут). И если данные были у нас в системе, но не попали в отчет - проблемы.

Вот и приходится страдать с синхронизацией такой

Потому что внешний источник. Пример, внешний источник n раз в день присылает данные, которые нужно обработать. А другой внешний источник дергает апи для формирования _самого_ актуального отчета. Обе операции условно долгие (от нескольких минут). И если данные были у нас в системе, но не попали в отчет - проблемы.

Ну так поток данных какой?

Ну так поток данных какой?

Допустим, 5-10 таких оправок данных и один отчет в день

Николай конпеляет python3.7.3 на debian9

Надеюсь, не будет предложения сделать узкое горлышко