И что в ней сильного, если Erlang предлагает гораздо лучше,
На вкус и цвет, как говорится. Критерий лучшести приведёте? Какие у Вас конкретные претензии к go? Вот у меня есть к нему конкретные претензии- отсутствие перегрузки функций и странные дженерики.
Что именно приходит - пара и значение? Считаем порядок прихода естественным?
Желательно уточнить формат входящих сообщений.
если Δ больше 10% — отбросить, но сохранить в хранилище (любое)
Остальные надо сохранять? Нужна в сторадже отметка об отклонении?
а если меньше — посчитать на основе его и предыдущих четырех — новое «усредненное значение»
При скачке и фиксации более чем на 10% средний курс никогда не изменится
если курса нет больше, чем минуту — метрика должна покраснеть
В выдаче по http? Тогда нужен формат что отдавать по http. Может ограничиться JSON?
И ещё: если уж решили состязаться - параметр максимальной производительности входящих сообщений / сек кажется измеряемой метрикой
Оффтоп (просто резануло):
Применение сравнения среднего из 5 последних отсчётов - это фактически FIR с прямоугольным окном. Использование для этих целей IIR эквивалентно по ресурсам но даёт некоторые преимущества в предметной области.
просто пассаж про защиту от вайлтру — это явный признак теоретика.
Явный признак теоретика - это предложение завести 100`000 горутин. Странно, что Вами осталась незамеченной именно связка горутин и каналов, как сильная сторона go.
Сразу видно, что ничего действительно параллельного вы никогда в жизни не писали.
О! Экстрасенсы в треде!
Но ничего, наберётесь опыта - тяга к д`артаньянству пройдёт.
Если горутин (гринтредов, эрланговских процессов) не два с половиной, как в туториале, а тысяч десять, или сто, — кооперативная многозадачность не работает в принципе, и не из-за закукливания, а просто потому, что время отклика становится непредсказуемым: 10мс для одной горутины — уже непозволительная роскошь, стотысячная получит управление через сами посчитайте сколько часов.
А при вытесняющей ни одна из них за это же время так и не закончит своё выполнение. Все выполнятся ровно на 99% ... Что там с откликом, Ась?
И что, интересно, собираетесь делать в горутине более 10 мс между операциями ввода-вывода? (Про то, что в GO вытеснение происходит раз именно в 10 ms вообще молчу)
Грубо говоря, сообщения обрабатываются в одном главном цикле в огромном switch/case - так что один case ну никак не может ждать другого case.
А как у нас с многопоточностью этого огромного switch/case ? Вроде с этого требования начинали.
Есть фундаментальные ограничения на взаимные блокировки в параллельных средах исполнения. Сколько лет уже SQL базы пилят, но нет решения, как избежать дедлоков. Серебряной пули нет, к сожалению (((
Послушайте, ну перестаньте на секундочку держать собеседника за идиота,
Вас? Да упаси хосподи! Уж точно кем- кем, а идиотом Вас считать ну совсем нет никаких оснований! Манипулятором - возможно, но не идиотом.
Отправил и забыл.
Запросил значение и результат не интересен? А тут вдруг тот у кого запросили значение пришёл обратно (через длинную цепочку, с условиями, но так сложились звёзды...), и для ответа требуется запрошенное значение... Грусть-тоска. Так, конечно, в мире где каждая транзакция не менее 50М (Зибвамбвийских?) не бывает, но жизнь немного сложнее hello world, и по этому ответ на вопрос "обеспечивает ли акторная модель отсутствие дедлоков" однозначен - нет. Значит ли, что акторная модель не применима? Конечно не значит. Более того, она является пожалуй наилучшей (из универсальных) при реализации взаимодействия между процессами, идущими на разных ядрах, но как указывал уважаемый @rsashka, замечание которого про то, что сколько гринтредов ни крутятся в рамках одного треда ОС - подход к примитивам взаимной синхронизации совершенно иной, при этом в большинстве случаев примитивы синхронизации вообще не требуются, к сожалению, остался без должного внимания, хотя это лучший вариант с точки зрения обеспечения производительности.
Понятно, что по существу у Вас аргументов не имеется. (((
Ну, когда люди начинают в дискуссии юродствовать, всем всё становится понятно.
Парадигма или даёт гарантии или нет. Нельзя быть немного беременной. Напомню, что изначально разговор шёл об ужасных дедлоках в ООП при применении мьютексов.
P.S. Но всё равно большое спасибо за Ваши статьи, они заставляют вернуться к обдумыванию важных вопросов и вне зависимости от выводов, которые мы сделаем, периодически размышлять на эти темы крайне полезно.
Посылать синхронное сообщение самому себе из обработчика другого сообщения — это настолько редкий и безумный случай, что люди отучаются так делать на втором часу знакомства.
Связи могут быть длинные A ждёт B, B - C, C - ...., ... - Z, Z-A. И усё.
В акторной модели все сообщения асинхронны, поэтому создать дедлок можно только дожидаясь сообщения от самого себя изнутри обработчика предыдущего сообщения
Так можно и про мьютексы сказать - "словить дедлок можно только ожидая уже захваченный мьютекс". Однако такое определение счастья не приносит.
что банально отлавливается простейшим тулингом.
Подождите, мы вроде про парадигмы говорим, а не про некоторый тулинг, который чёто там может отловить (или не отловить).
Кроме того, зависимости бывают сложные, например, наличие зависимости по некоторому условию, и тулингу будет мешать теорема об останове исключить ложно положительные срабатывания.
Однако утверждать, что вся объектная модель обречена в многопоточном мире, неверно.
Реальный параллелизм всегда сложен и, по своей природе, потенциальные дедлоки ему всегда сопутствуют при появлении взаимного влияния частей системы. Даже в пропагандируемой автором акторной модели дедлоки возможны: A ждёт ответа от B а B - от A.
Подход с иммутабельными объектами безусловно решает ряд проблем, таких как внутренняя консистентность объекта, но тянет за собой местами излишние копирование на каждый чих и при этом не является единственно возможным подходом. Это спор скорее религиозный. (Во многих реальных случаях изменение объекта на spinlock для сохранения консистентности не оставит конкурентам ни малейшего шанса в вопросах производительности)
Китай мог их ввезти контрабандой только в том случае, если они запрещены Китаем ко ввозу. А так он их контрабандой вывез.
На вкус и цвет, как говорится. Критерий лучшести приведёте?
Какие у Вас конкретные претензии к go? Вот у меня есть к нему конкретные претензии- отсутствие перегрузки функций и странные дженерики.
"Задолго" - весьма сомнительный аргумент.
Очень клёво, когда кто-то что-то делает.
Респект и уважуха!
Противоречие никого не напрягает?
Горите в аду, проклятые манипуляторы! (Это я так, для привлечения внимания)
Батл, круть!
Только надо бы уточнить условия.
Что именно приходит - пара и значение? Считаем порядок прихода естественным?
Желательно уточнить формат входящих сообщений.
Остальные надо сохранять? Нужна в сторадже отметка об отклонении?
При скачке и фиксации более чем на 10% средний курс никогда не изменится
В выдаче по http? Тогда нужен формат что отдавать по http. Может ограничиться JSON?
И ещё: если уж решили состязаться - параметр максимальной производительности входящих сообщений / сек кажется измеряемой метрикой
Оффтоп (просто резануло):
Применение сравнения среднего из 5 последних отсчётов - это фактически FIR с прямоугольным окном. Использование для этих целей IIR эквивалентно по ресурсам но даёт некоторые преимущества в предметной области.
Явный признак теоретика - это предложение завести 100`000 горутин. Странно, что Вами осталась незамеченной именно связка горутин и каналов, как сильная сторона go.
О! Экстрасенсы в треде!
Но ничего, наберётесь опыта - тяга к д`артаньянству пройдёт.
А при вытесняющей ни одна из них за это же время так и не закончит своё выполнение. Все выполнятся ровно на 99% ... Что там с откликом, Ась?
И что, интересно, собираетесь делать в горутине более 10 мс между операциями ввода-вывода? (Про то, что в GO вытеснение происходит раз именно в 10 ms вообще молчу)
а Вы не замечали, что всё, что есть в индустрии - это 60-е и 70-е. ... Ничего нового собственно и нет
Горутины в совокупности с каналами - это очень хорошая абстракция
А вот это конкретно подпора для тех, кто боится что ктонить напишет while(true){}
Однозначно по многим параметрам. Есть, конечно, родовые травмы, но горутины и каналы на уровне языка - явный гуд.
На вкус и цвет все фломастеры разные.
Так и про мьютексы можно написать.
А как у нас с многопоточностью этого огромного switch/case ?
Вроде с этого требования начинали.
Есть фундаментальные ограничения на взаимные блокировки в параллельных средах исполнения. Сколько лет уже SQL базы пилят, но нет решения, как избежать дедлоков. Серебряной пули нет, к сожалению (((
"Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам" (с)
Perl это уж очень сильно на любителя, имхо.
Возразить вообще нечего. (Ну может если только RTFM?)
Тем не менее, ядра пишутся, работают.
ErlangElexir конечно нужно всем посмотреть, но писать на нём лично я - пас. Go выглядит значительно привлекательнее по многим параметрам.Оно и без кластера ничего не гарантирует - NTP не даст соврать.
Оффтоп: ну уж Вам лучше этой темы не касаться ))
Вас? Да упаси хосподи! Уж точно кем- кем, а идиотом Вас считать ну совсем нет никаких оснований! Манипулятором - возможно, но не идиотом.
Запросил значение и результат не интересен? А тут вдруг тот у кого запросили значение пришёл обратно (через длинную цепочку, с условиями, но так сложились звёзды...), и для ответа требуется запрошенное значение... Грусть-тоска.
Так, конечно, в мире где каждая транзакция не менее 50М (Зибвамбвийских?) не бывает, но жизнь немного сложнее hello world, и по этому ответ на вопрос "обеспечивает ли акторная модель отсутствие дедлоков" однозначен - нет.
Значит ли, что акторная модель не применима? Конечно не значит.
Более того, она является пожалуй наилучшей (из универсальных) при реализации взаимодействия между процессами, идущими на разных ядрах, но как указывал уважаемый @rsashka, замечание которого про то, что сколько гринтредов ни крутятся в рамках одного треда ОС - подход к примитивам взаимной синхронизации совершенно иной, при этом в большинстве случаев примитивы синхронизации вообще не требуются, к сожалению, остался без должного внимания, хотя это лучший вариант с точки зрения обеспечения производительности.
Уже показывал дедлок в длинной связи:
Связи могут быть длинные A ждёт B, B - C, C - ...., ... - Z, Z-A. И усё.
Понятно, что по существу у Вас аргументов не имеется. (((
Парадигма или даёт гарантии или нет. Нельзя быть немного беременной.
Напомню, что изначально разговор шёл об ужасных дедлоках в ООП при применении мьютексов.
P.S. Но всё равно большое спасибо за Ваши статьи, они заставляют вернуться к обдумыванию важных вопросов и вне зависимости от выводов, которые мы сделаем, периодически размышлять на эти темы крайне полезно.
Связи могут быть длинные A ждёт B, B - C, C - ...., ... - Z, Z-A. И усё.
Понятно. Парадигма не обеспечивает. Ужос-Ужос!
Так можно и про мьютексы сказать - "словить дедлок можно только ожидая уже захваченный мьютекс". Однако такое определение счастья не приносит.
Подождите, мы вроде про парадигмы говорим, а не про некоторый тулинг, который чёто там может отловить (или не отловить).
Кроме того, зависимости бывают сложные, например, наличие зависимости по некоторому условию, и тулингу будет мешать теорема об останове исключить ложно положительные срабатывания.
Реальный параллелизм всегда сложен и, по своей природе, потенциальные дедлоки ему всегда сопутствуют при появлении взаимного влияния частей системы. Даже в пропагандируемой автором акторной модели дедлоки возможны: A ждёт ответа от B а B - от A.
Подход с иммутабельными объектами безусловно решает ряд проблем, таких как внутренняя консистентность объекта, но тянет за собой местами излишние копирование на каждый чих и при этом не является единственно возможным подходом. Это спор скорее религиозный. (Во многих реальных случаях изменение объекта на spinlock для сохранения консистентности не оставит конкурентам ни малейшего шанса в вопросах производительности)
Серебряной пули нет (с)