Логику нормально писать на любом production-языке. Проблема в том, что разные языки предоставляют разной степени выразительности различные парадигмы для выражения и структуризации бизнес-логики, и _каждая_ парадигма сильно ограничивает возможности. За это любят пайтон и руби — они весьма выразительны и мультипарадигменны, что позволяет лаконично делать то, что удобнее программисту, а не компилятору/интерпретару языка программирования.
В этом смысле эрланг очень сильно ограничивает возможности и заставляет усложнять логику, просто из-за ограниченности парадигмы чистого функционального программирования.
Go точно так же подходит под аргументы статьи — язык изначально заточен под удобную параллелизацию, и есть удобная синхронизация между серверами. И, да, не приходится насиловать бизнес-логику дополнительным разбиением на 100500 функций, потому что immutable переменные и прочие ограничения.
В целом, статья не отличается новизной, с «глубоким» выводом вида «купоны => пирамида => лохотрон». При этом наиболее содержательной информации по теме, а именно интервью с Муртазиным, в статье нет. На мой взгляд странно давать инвайт за такое.
Подозреваю, проблема с Erlang'ом была в том, что тот не приспособлен под хоть сколько-то содержательную императивную логику — там удобно разве что фильтровать и перенаправлять потоки данных. Ну и производительность, очевидно, ниже.
За 2.5 года пользования у меня арч падал при обновлении всего дважды и оба раза из-за невнимательного чтения сообщений при обновлении. Подозреваю, что в Ubuntu к таким болезненным обновлениям достаточно будет просто добавлять нормальные скрипты миграции.
Если у вас равноправные датацентры, вы никуда не денетесь от большого трафика между ними и задержек, связанных с синхронизацией. Так что для поддержания консистентности можно просто использовать любое кластерное решение, поддерживающее распределённые блокировки, например, zookeeper.
Мне кажется, проблема спора SQL vs NoSQL в желании людей найти серебряную пулю, которую можно просто поставить и просто с ней работать, по меньшей мере в их случае. Понятно, что для ненагруженного сайта/приложения важна скорее не производительность, а latency и удобство разработки. Но когда перестаёт хватать ресурсов выделенного под БД сервера, меняется проблематика: сразу становится важна ресурсоёмкость запросов к отдельным видам данных и удобство разбиения базы на несколько серверов (альтернатива — расширять сервер — заметно дороже, т.к. стоимость сильно растёт, непропорционально ресурсоёмкости). Очевидно, что для небольшого объёма часто меняющихся и читающихся данных NoSQL — хорошее и удобное решение, а для жирных данных, только малая часть из которых прямо сейчас читается приложением — удобнее SQL, из-за лучше проработанных файловых индексов и прочих нюансов работы с файлами.
Проблему мудаков бесполезно решать — они будут всегда, вне зависимости от массовости расстрелов, и мудачества будут видны, пока это будет выгодно. А выгодность определяют именно законы и регуляторы.
Круто, ещё и не поленились минус влепить от ненависти! Так держать!
Не знаю, насколько вам это трудно, но попробуйте хоть чуть-чуть абстрагироваться от ситуации, и посмотреть на картину в целом. Вопросы морали прекрасны и замечательны, чтобы градуировать людей/компании на мудаков и добро, но при этом сильные флуктуации морали всегда есть. В результате рано или поздно найдётся компания, которая как литрес будет требовать от гугла удалить приложения, т.к. те мешают их бизнесу. Поэтому основа проблемы здесь — исключительно законодатели и регуляторы, которые позволяют литресу так делать.
А так, безусловно, гораздо проще ненавидеть всех мудаков, а заодно и всех, кто не называет в каждой фразе мудаков мудаками. И чёрт с тем, что проблема глубже, ведь очевидно же, что если истребить всех мудаков, сразу всё станет замечательно и проблемы исчезнут!
Я знаю, спасибо. Дело ведь в том, что коммерческая компания может быть в рамках закона сколько угодно аморальна, и это нормально. Поэтому подобные прецеденты заведомо являются следствием серьёзных проблем в законодательстве и работе регулирующих органов исполнительной власти.
«Подвиг Брейвика» стоит повторять разве что в отношении законодателей, дающих возможность ЛитРесу в судебном порядке надавить на Google. Сам же литрес — обычная комерческая компания, зарабатывает деньги как может.
Из плюшек языка, был netchannel (канал в терминах go, но по сети). До 1.0 он был непосредственно в package'ах языка, в ближайших релизах обещают вернуть. Я его руками делал в несколько десятков строк из gob'ов поверх обычного сетевого сокета.
В целом, сам язык способствует удобной и лаконичной межсерверной работе, засчёт многопоточной асинхронности и заточенности на потоковую обработку. В качестве примера есть прекрасный github.com/ha/doozerd — кластер наподобие zookeeper'а.
Нет, при инкапсуляции структуры в структуре во внешней доступны все методы внутренней. play.golang.org/p/Qqw6v1oWNF
Мне кажется, go не стоит воспринимать как объектно-ориентированный язык — удобней просто работать со структурами, методами структур и интерфейсами — тогда всё логично, просто, легко, и всего хватает.
Основная фишка go в _крайне простой_ параллелизации, засчёт каналов и go-рутин. Кроме этого, от прочих асинхронных языков и фреймворков go отличает не ограниченная многопоточность (например, node.js однопоточная), экономная работа с памятью (а не как scala), сравнительно быстрая общая работа (т.к. статически типизированный), и довольно быстрый сборщик мусора.
В целом, это системный язык со встроенным обеспечением параллельности и синхронизации между серверами, при этом с лаконичным синтаксисом и прочими плюшками (например, import прямо с гитхаба).
Относительно Elixir'а вы несколько загнули — это скорее загибающаяся на сегодняшний день штука для тех, кому трудно освоить синтаксис эрланга.
В этом смысле эрланг очень сильно ограничивает возможности и заставляет усложнять логику, просто из-за ограниченности парадигмы чистого функционального программирования.
kad.arbitr.ru/Card/5b5d58e0-7657-4fe3-ae85-248a6247f541
В целом, статья не отличается новизной, с «глубоким» выводом вида «купоны => пирамида => лохотрон». При этом наиболее содержательной информации по теме, а именно интервью с Муртазиным, в статье нет. На мой взгляд странно давать инвайт за такое.
Не знаю, насколько вам это трудно, но попробуйте хоть чуть-чуть абстрагироваться от ситуации, и посмотреть на картину в целом. Вопросы морали прекрасны и замечательны, чтобы градуировать людей/компании на мудаков и добро, но при этом сильные флуктуации морали всегда есть. В результате рано или поздно найдётся компания, которая как литрес будет требовать от гугла удалить приложения, т.к. те мешают их бизнесу. Поэтому основа проблемы здесь — исключительно законодатели и регуляторы, которые позволяют литресу так делать.
А так, безусловно, гораздо проще ненавидеть всех мудаков, а заодно и всех, кто не называет в каждой фразе мудаков мудаками. И чёрт с тем, что проблема глубже, ведь очевидно же, что если истребить всех мудаков, сразу всё станет замечательно и проблемы исчезнут!
В целом, сам язык способствует удобной и лаконичной межсерверной работе, засчёт многопоточной асинхронности и заточенности на потоковую обработку. В качестве примера есть прекрасный github.com/ha/doozerd — кластер наподобие zookeeper'а.
play.golang.org/p/Qqw6v1oWNF
Мне кажется, go не стоит воспринимать как объектно-ориентированный язык — удобней просто работать со структурами, методами структур и интерфейсами — тогда всё логично, просто, легко, и всего хватает.
В целом, это системный язык со встроенным обеспечением параллельности и синхронизации между серверами, при этом с лаконичным синтаксисом и прочими плюшками (например, import прямо с гитхаба).