На JIT языках без предкомпиляции нельзя писать приложения с быстрым стартом, а на компилируемых языках можно. Вот и вся разница.
Быстрый старт, как правило, нужен в двух случаях — тяжелые утилиты командной строки и GUI приложения. Если в первом случае оставлять экземпляр в памяти после завершения выполнения имеет смысл, то во втором — значительно страдает UX, т.к. юзер либо долго ждет первого запуска, либо приложение загружается при старте системы — замедляя загрузку и потребляя память.
Я имел в виду отсутствие зависимостей, которые нужно ставить на целевую систему. Давайте оставим в покое телефоны, у них свой подход к деплойменту. У Go немного другая сфера применения.
Сама jvm стартует быстро, да. helloworld запускается меньше, чем за миллисекунду. Но загрузка и JIT занимают существенное время и способа написать на java большое быстро стартующее приложение нет. Предкомпиляция в java9 может улучшить ситуацию, но не принципиально — она выдает на выходе объектники в 100-200 мегабайт.
Категорически не согласен со статьей. Нам тоже нужна была высокопроизводительная durable очередь (от 3 тыс сообщений в секунду) и вот мои выводы:
Про гарантию доставки и in-memory queues.
Этого недостаточно. Микросервисная архитектура для раскрытия всего своего потенциала требует сохранения работоспособности системы при отказе любой машины. Это позволяет хоститься на облаках с не очень надежными машинами, позволяет CD без даунтайма, позволяет A/B тестирование и т.д.
Теперь рассмотрим REST сервис, который должен гарантировать доставку. Классический протокол выглядит так:
клиент посылает запрос
сервер обрабатывает запрос, сохраняет и коммитит результат, и только потом возвращает 200 OK.
если сервер вернул не 200 или не вернул ответ, клиент перепосылает запрос. В этом случае у нас будут дубликаты (решается наличием уникального id запроса и базы этих id на стороне сервера), но запрос никогда не будет потерян
Если мы используем in-memory очереди, то возникает две проблемы:
Если в любой момент времени сообщение хранится в памяти только одной машины, то при отказе этой машины мы теряем сообщение
если мы используем кластер in-memory, то отказ одной машины проблемой не станет, НО усложняется деплоймент собственно кластера очереди сообщений (надо переводить ноду в readonly, дождаться окончания репликации, и только потом делать рестарт) И что делать, если очередь переполнится? Места на диске, как правило, значительно больше, чем в памяти.
Если обработку запроса предполагается закончить за разумное время (меньше минуты), я предпочитаю синхронные запросы по TCP и повторную отправку в случае ошибки со стороны клиента. Кол-во параллельно висящих подключений для современных сетевых библиотек проблемой не является, а гарантию доставки такая схема дает. К тому же, она проще для понимания и отладки.
Про RabbitMQ.
RabbitMQ тянет несколько тысяч запросов в секунду с одной ноды и работает хорошо, НО если объединить ноды в кластер, то мы наблюдали очень нестабильную работу под нагрузкой — кластер "разваливается" и не чинится автоматически. Также при падении одной из нод сама она в кластер не возвращается.
Про Kafka.
Стандартный кластер из трех нод на aws m3 тянет 20000 сообщений на запись или на чтение. Нормально переживает падение и возврат в кластер своих нод. Позволяет делать выбор между быстродействием и прочими свойствами очередей — гарантированным порядком сообщений, наличием повторов при отказе получателя и т.п.
В целом ТС как-то странно понимает гарантию доставки.
Ужасная статья, особенно концовка. Одна из причин, по которым я не собираюсь покидать Россию, это то, что у нас нет толпы правозащитников, выбивающих особые условия женщинам/геям/инвалидам/собачкам/кошечкам/хомячкам в ущерб большинству населения.
Ну а что еще живо в 21 веке? :-)
массовый программист сидит на гите
олдскул — на SVN
неформалы — на Mercurial
заплесневелые корпоративщики — на Perforce
Я сам использую исключительно гит, но плохо быть фанатом.
submodules очень неудобно использовать даже программистам, а уж предлагать корпоративным юзерам...
я же написал по умолчанию
глянул документацию по gitolite. как и ожидалось, его предел — контроль доступа на уровне бранчей
В плане submodules показателен пример твиттера — они используют монорепозиторий, но потратили кучу усилий на патчинг как гитового клиента, так и сервера, лишь бы не связываться с submodules.
Git не является универсальным решением для всего. Из-за ряда особенностей он непригоден для хранения двоичных документов. Конкретнее:
git не позволяет сделать checkout отдельного каталога, только репозитория целиком. Для хранилища документов, объем которого легко может перевалить за 10Гб, работа будет очень медленной
git по умолчанию выкачивает все ревизии, а не только последнюю. Это очень много данных.
git не позволяет задавать права на конкретные каталоги для разных пользователей
Это называется защита прав трудящихся, достижение СССР. А штрафовать, кстати, можно:
Статья 241. Пределы материальной ответственности работника
За причиненный ущерб работник несет материальную ответственность в пределах своего среднего месячного заработка, если иное не предусмотрено настоящим Кодексом или иными федеральными законами.
"иное" — это наличие материальной ответственности, умысла, опьянения, вины (есть протокол об административном правонарушении)
переопределение operator new/operator delete/operator delete[] с использованием нестандартного менеджера памяти, который работает быстрее за счет увеличения расхода памяти/отказа от многопоточности/использования специфичных для приложения паттернов работы с памятью
При внедрениях такого рода надо начинать как раз с убеждения руководящего состава. И доводы-то есть — разделение прав, невозможность порчи/удаления/потери документов, история правок...
Работал в компании, где это замечательно функционировало на tortoiseSVN. Включая бухгалтерию и продажников.
Мерджить ничего не надо — если в общей шаре старый файл всегда перетирается, то в свн есть выбор. Можно перетереть, можно посмотреть, кто правил, и спросить что именно.
Нет, зачем? Трояны-шифровальщики опасны только для содержимого папки "мои документы" доверчивого пользователя + некая "общая шара" которая обычно имеет место быть в организации для обмена документами.
Всё, что вы перечислили, крутится на серверных машинах и для шифровальщиков недоступно, разве что лопухнется лично доменный админ.
суды работают немного не так — либо ты выдашь личную информацию, либо заплатишь штраф. Никакие отговорки и объяснения не помогут — будешь виноват в том, что не обеспечил возможность дешифровки по требованию.
Какая уж тут субъективность :-)
На JIT языках без предкомпиляции нельзя писать приложения с быстрым стартом, а на компилируемых языках можно. Вот и вся разница.
Быстрый старт, как правило, нужен в двух случаях — тяжелые утилиты командной строки и GUI приложения. Если в первом случае оставлять экземпляр в памяти после завершения выполнения имеет смысл, то во втором — значительно страдает UX, т.к. юзер либо долго ждет первого запуска, либо приложение загружается при старте системы — замедляя загрузку и потребляя память.
Я имел в виду отсутствие зависимостей, которые нужно ставить на целевую систему. Давайте оставим в покое телефоны, у них свой подход к деплойменту. У Go немного другая сфера применения.
Вот интересный ремейк Exolon: http://retrospec.sgn.net/game/exolon
Сама jvm стартует быстро, да. helloworld запускается меньше, чем за миллисекунду. Но загрузка и JIT занимают существенное время и способа написать на java большое быстро стартующее приложение нет. Предкомпиляция в java9 может улучшить ситуацию, но не принципиально — она выдает на выходе объектники в 100-200 мегабайт.
Категорически не согласен со статьей. Нам тоже нужна была высокопроизводительная durable очередь (от 3 тыс сообщений в секунду) и вот мои выводы:
Про гарантию доставки и in-memory queues.
Этого недостаточно. Микросервисная архитектура для раскрытия всего своего потенциала требует сохранения работоспособности системы при отказе любой машины. Это позволяет хоститься на облаках с не очень надежными машинами, позволяет CD без даунтайма, позволяет A/B тестирование и т.д.
Теперь рассмотрим REST сервис, который должен гарантировать доставку. Классический протокол выглядит так:
Если мы используем in-memory очереди, то возникает две проблемы:
Если обработку запроса предполагается закончить за разумное время (меньше минуты), я предпочитаю синхронные запросы по TCP и повторную отправку в случае ошибки со стороны клиента. Кол-во параллельно висящих подключений для современных сетевых библиотек проблемой не является, а гарантию доставки такая схема дает. К тому же, она проще для понимания и отладки.
Про RabbitMQ.
RabbitMQ тянет несколько тысяч запросов в секунду с одной ноды и работает хорошо, НО если объединить ноды в кластер, то мы наблюдали очень нестабильную работу под нагрузкой — кластер "разваливается" и не чинится автоматически. Также при падении одной из нод сама она в кластер не возвращается.
Про Kafka.
Стандартный кластер из трех нод на aws m3 тянет 20000 сообщений на запись или на чтение. Нормально переживает падение и возврат в кластер своих нод. Позволяет делать выбор между быстродействием и прочими свойствами очередей — гарантированным порядком сообщений, наличием повторов при отказе получателя и т.п.
В целом ТС как-то странно понимает гарантию доставки.
java, .NET, python...
"Go быстрый" — сомнительно мне очень
"Go простой" — слишком простой, я бы сказал.
И не указаны уникальные преимущества этого языка:
Ужасная статья, особенно концовка. Одна из причин, по которым я не собираюсь покидать Россию, это то, что у нас нет толпы правозащитников, выбивающих особые условия женщинам/геям/инвалидам/собачкам/кошечкам/хомячкам в ущерб большинству населения.
И да, в IT никакой гендерной дискриминации нет.
Ну а что еще живо в 21 веке? :-)
массовый программист сидит на гите
олдскул — на SVN
неформалы — на Mercurial
заплесневелые корпоративщики — на Perforce
Что я еще не назвал?
pmap показывает виртуальную память, это не совсем то.
Я сам использую исключительно гит, но плохо быть фанатом.
В плане submodules показателен пример твиттера — они используют монорепозиторий, но потратили кучу усилий на патчинг как гитового клиента, так и сервера, лишь бы не связываться с submodules.
Git не является универсальным решением для всего. Из-за ряда особенностей он непригоден для хранения двоичных документов. Конкретнее:
Это называется защита прав трудящихся, достижение СССР. А штрафовать, кстати, можно:
"иное" — это наличие материальной ответственности, умысла, опьянения, вины (есть протокол об административном правонарушении)
Как интересно, а есть опыт настройки SSL под http/2? Мне никак не удается настроить forward secrecy c http/2, поэтому мой предел —
A-.operator new/operator delete/operator delete[]с использованием нестандартного менеджера памяти, который работает быстрее за счет увеличения расхода памяти/отказа от многопоточности/использования специфичных для приложения паттернов работы с памятьюВ контексте обсуждения, это, скорее, п.3
При внедрениях такого рода надо начинать как раз с убеждения руководящего состава. И доводы-то есть — разделение прав, невозможность порчи/удаления/потери документов, история правок...
В моем случае руководящий состав и внедрял.
Работал в компании, где это замечательно функционировало на tortoiseSVN. Включая бухгалтерию и продажников.
Мерджить ничего не надо — если в общей шаре старый файл всегда перетирается, то в свн есть выбор. Можно перетереть, можно посмотреть, кто правил, и спросить что именно.
Нет, зачем? Трояны-шифровальщики опасны только для содержимого папки "мои документы" доверчивого пользователя + некая "общая шара" которая обычно имеет место быть в организации для обмена документами.
Всё, что вы перечислили, крутится на серверных машинах и для шифровальщиков недоступно, разве что лопухнется лично доменный админ.
В целом, я не понимаю, откуда минусы-то.
В чем-то вы правы, если компания хранит все свои документы в свн с настроенными правами, то дать шифровальщикам потопить компанию будет проблематично.
Есть простое и надежное, как кирпич, решение: SVN.
суды работают немного не так — либо ты выдашь личную информацию, либо заплатишь штраф. Никакие отговорки и объяснения не помогут — будешь виноват в том, что не обеспечил возможность дешифровки по требованию.