Одной из главных фишек языка Go является удобная работа с конкурентностью. Однако, в больших проектах всё равно возникают некоторые проблемы:
утечка горутин
некорректная обработка паник в горутинах
плохая читаемость кода
необходимость писать повторяющийся код из раза в раз
Как указывает автор библиотеки в своей статье, он часто сталкивается с ошибками при работе с горутинами, что побудило его создать новую библиотеку conc.
В данной статье речь идёт об Erlang, но всё сказанное в равной степени применимо и к Elixir — функциональному языку, работающему поверх той же виртуальной машины BEAM. Он появился в 2012 году и сейчас активно развивается. Elixir получил более привычный большинству синтаксис плюс обширные возможности метапрограммирования, сохранив преимущества Erlang.
Статья от 2016 года, но речь в ней идёт о базовых концепциях, которые не устаревают.
Ссылки на понятия и комментарии от меня (переводчика) расположены в квадратных скобках [] и снабжены указателем "прим. переводчика".
Если вы найдёте какие-то части перевода недостаточно корректными, особенно в плане терминов, или столкнётесь с любыми другими ошибками — дайте мне, пожалуйста, знать, с удовольствием исправлю.
Отдельное спасибо Яну Гравшину за помощь в вычитке и редактуре текста.
Это свободная расшифровка (или долгий парафраз?) моей презентации на организованной Genetec конференции ConnectDev'16.
Я полагаю, что большинство присутствующих здесь людей никогда не программировало на Эрланге. Возможно, вы слышали о нём, или вам знакомо название. Поэтому моё выступление затронет только высокоуровневые концепции Эрланга, причём таким образом, чтобы оказаться полезным в ваших рабочих или побочных проектах даже если вы никогда не сталкиваетесь с этим языком.
В 2009 году решили поставить федеральный эксперимент по переводу закупок в цифровую форму. Это для открытости, чтобы активисты и конкуренты могли подавать друг на друга жалобы в ФАС и другие контролирующие органы, а ещё чтобы больше поставщиков приходило на торги, что тоже способствует снижению уровня коррупции.
Эксперимент сначала провели на Москве, благо закупки города больше, чем у нескольких субъектов Федерации. По некоторым позициям они вообще сопоставимы с общероссийскими.
Те, кто помнит 2010 год в Москве: у нас тут уже было цифровое общество. В регионах тогда не верили не то что в ЭЦП, а даже в оплату товаров картой. Причём не с доставкой, а просто в магазине. Именно это стало главной проблемой эксперимента: поставщики просто «не дружили» с компьютерами. Скажите спасибо, что у них (это по большинству — заводы) хотя бы Интернет был.
Параллельно обкатывалась другая идея: сделать площадку для публикации информации о торгах и просто объявлять, что происходит в бумажных процедурах. Это то, чем сейчас стал сайт Госзакупок (ЕИС): на нём содержится вся информация о предстоящей процедуре.
Читать полностью »
Обработка данных в реальном времени ровно один раз (exactly-once) — задача крайне нетривиальная и требующая серьезного и вдумчивого подхода на всей цепочке вычислений. Некоторые даже считают, что такая задача невыполнима. В реальности хочется иметь подход, обеспечивающий отказоустойчивую обработку вообще без каких-либо задержек и использование различных хранилищ данных, что выдвигает новые еще более жесткие требования, предъявляемые к системе: concurrent exactly-once и гетерогенность персистентного слоя. На сегодняшний день такое требование не поддерживает ни одна из существующих систем.
Предложенный подход последовательно раскроет секретные ингредиенты и необходимые понятия, позволяющие относительно просто реализовать гетерогенную обработку concurrent exactly-once буквально из двух компонент.
Разработчик распределенных систем проходит несколько стадий:
Стадия 1: Алгоритмы. Здесь происходит изучение основных алгоритмов, структур данных, подходов к программированию типа ООП и т.д. Код исключительно однопоточный. Начальная фаза вхождения в профессию. Тем не менее, достаточно непростая и может длиться годами.
Стадия 2: Многопоточность. Далее возникают вопросы извлечения максимальной эффективности из железа, возникает многопоточность, асинхронность, гонки, дебагинг, strace, бессонные ночи… Многие застревают на этом этапе и даже начинают с какого-то момента ловить ничем не объяснимый кайф. Но лишь единицы доходят до понимания архитектуры виртуальной памяти и моделей памяти, lock-free/wait-free алгоритмах, различных асинхронных моделях. И почти никто и никогда — верификации многопоточного кода.
Стадия 3: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.
