Ну справедливости ради в первой статье тоже дурацкие причины.
"Увидеть альтернативы", "разобраться в контейнерах" и "подготовиться к будущему" это причины поковырять технологию в свободное время, а не переходить в продакшене.
Непонятно почему они не приводят как причину увеличение безопасности — контр-меру от выхода из контейнера и получение рута на хосте, т.к. демон под рутом.
С т.з. adoption хорошо что они совместимы с докером. С другой стороны, в той же vagga есть супер-полезные вещи, которых в мейнстрим-контейнерах нет и видимо ещё долго не будет:
Авто-версионирование и очистка старых образов/контейнеров. Заниматься этой уборкой в докере абсолютно осточертело.
Прокидывание прокси с хоста — зачем в докере эти пляски с такой тривиальной вещью, абсолютно непонятно.
В vagga сборка идёт серьёзно быстрее за счёт некоторых трюков, например libeatmydata.
Командно-ориентированный процесс вместо контейнеро-ориентированного. Контейнеры стартуют за миллисекунды. В конфиге описываются команды, а контейнеры под них поднимаются/опускаются автоматически.
Вот этого я вообще не понимаю.
Ну no-carrier и что? Интерфейс-то остался и когда carrier появится всё продолжит работать. Это вообще от меня не зависит, удалённый конец питание потерял.
Не могу сказать что мне они чем-то не угодили, просто из коробки в той же Ubuntu они сейчас не работают, и при отключении NetworkManager выбирая между откатом назад на них, и переходом вперед на netplan + networkd я выбрал второе. Я в целом думаю что systemd это довольно правильно, и интегрировать туда управление сетями тоже выглядит разумно.
Со стороны старых interfaces — а они поддерживают, для примера, продвинутые настройки Wi-Fi (WPA2 Enterprise)?
Неплохая штука, но сырая.
На днях начал пытаться подключиться к копроративному Wi-Fi с WPA2 Enterprise и токеном — требуется много совсем неочевидных настроек, которые даже не поддерживаются в версии netplan из Ubuntu 18.04. Пришлось поставить из исходников отсюда — конфигурация распарсилась, но что-то развалилось дальше. Понять что, почему и как починить опять сложно.
Впарили китайцам компанию, и ещё убедили в том, что она не провальна.
Вот это бизнес-хватка!
А так, был у меня YotaPhone 2, поменял из-за старости. Вполне приличный аппарат. Купил бы третий, если бы он вышел год назад — а так, вышел в Китае, а обещания запустить продажи у нас "через некоторое время" так и остались невыполненными.
Извините если я чего-то не понял, но у double check lock есть применения кроме глобальной инициализации?
Если нет — то первые 2 паттерна в Rust покрываются sync::Once, lazy_static, при необходимости — mut_static. Ещё есть scoped_tls. Советовать писать такую колбасу для задач глобальной или ленивой инициализации не надо.
От стандартной библиотеки ощущение куцести. Например, есть родная поддержка Юникода, но например Core.Char с юникодными символами не работает — только с ASCII
Официальная документация местами хромает. Например, в Svg куча функций, к которым даже краткое описание не написано. Помимо этого, практически нигде нет примеров того, как пользоваться пакетами. Просто "вот вам API, делайте с ним что хотите".
Тоже смотрел на Elm с прицелом на фронтенд-язык на будущие года 3-5. Понравилось:
Статические типы, хорошие сообщения об ошибках
Машинная проверка совместимости API по semver
Очень просто начать
Инструменты и поддержка редакторов. В Emacs завелось сразу всё (форматирование, автодополнение и т.д.), правда проверка кода на лету сделана своей штукой вместо flycheck и есть некоторые проблемы с интеграцией. elm-reactor тоже порадовал.
Простой код. 3 вещи, о которых надо заботиться, всё по MVC. Никаких компонентов, биндингов, корней модели и прочей чепухи, которую предлагают в том же Angular 2.
Подытоживая, "встроенный в язык фреймворк".
Не понравилось:
В основном, делает 1 человек.
У проекта 1 хоть сколько-нибудь серьёзный коммерческий пользователь (NoRedInk). Там работает второй заметный участник проекта.
Никаких гарантий стабильности, не всегда работают инструменты апгрейда версии Elm. Deprecation warning'и делаются недели за 2 до выхода версии.
Релизы "от балды", нет чёткого расписания и процедура непрозрачна.
Процесс разработки новых версий в целом не особо прозрачен, непонятно чего ждать.
При условии использования императивного языка на бэкенде, impedance mismatch между фронтендом и бэкендом. Тяжело переключаться с одной парадигмы на другую, если ты "fullstack".
Практически невозможно нормально использовать готовые библиотеки на JavaScript.
Вёрстка через исходный код. Может быть сложно научить вертальщика и деплоить.
Встроенный в язык фреймворк. Может быть минусом, если хочется гибкости.
Итого:
Очень круто для энтузиастов, но переписывать мир на Elm без серьёзной поддержки коммерческих пользователей никто не будет, а она пока отсутствует.
Это проект одного человека. В плане юзабилити для разработчика большой шаг вперёд.
В плане серьёзного продакшена это конечно большой недостаток.
Одного для одного другое для другого.
Вы ансиблом супервайзите сервисы в продакшене?
Ну справедливости ради в первой статье тоже дурацкие причины.
"Увидеть альтернативы", "разобраться в контейнерах" и "подготовиться к будущему" это причины поковырять технологию в свободное время, а не переходить в продакшене.
Непонятно почему они не приводят как причину увеличение безопасности — контр-меру от выхода из контейнера и получение рута на хосте, т.к. демон под рутом.
Они подразумевают под этим Operations, тех кто эксплуатирует систему после завершения разработки.
В этой статье пишут, что его нет
С т.з. adoption хорошо что они совместимы с докером. С другой стороны, в той же vagga есть супер-полезные вещи, которых в мейнстрим-контейнерах нет и видимо ещё долго не будет:
Много философии, мало технологии.
Вот этого я вообще не понимаю.
Ну no-carrier и что? Интерфейс-то остался и когда carrier появится всё продолжит работать. Это вообще от меня не зависит, удалённый конец питание потерял.
Не могу сказать что мне они чем-то не угодили, просто из коробки в той же Ubuntu они сейчас не работают, и при отключении NetworkManager выбирая между откатом назад на них, и переходом вперед на netplan + networkd я выбрал второе. Я в целом думаю что systemd это довольно правильно, и интегрировать туда управление сетями тоже выглядит разумно.
Со стороны старых interfaces — а они поддерживают, для примера, продвинутые настройки Wi-Fi (WPA2 Enterprise)?
Неплохая штука, но сырая.
На днях начал пытаться подключиться к копроративному Wi-Fi с WPA2 Enterprise и токеном — требуется много совсем неочевидных настроек, которые даже не поддерживаются в версии netplan из Ubuntu 18.04. Пришлось поставить из исходников отсюда — конфигурация распарсилась, но что-то развалилось дальше. Понять что, почему и как починить опять сложно.
Декларативный язык "сделай мне вот так, мне всё равно как" и интеграция в networkd.
На Rust структуры данных пишутся так, чтобы работало быстро, а не со счётчиками ссылок на пустом месте. Там unsafe внутри и это нормально.
Впарили китайцам компанию, и ещё убедили в том, что она не провальна.
Вот это бизнес-хватка!
А так, был у меня YotaPhone 2, поменял из-за старости. Вполне приличный аппарат. Купил бы третий, если бы он вышел год назад — а так, вышел в Китае, а обещания запустить продажи у нас "через некоторое время" так и остались невыполненными.
А почему "Игрушечный релиз?"-то?
Извините если я чего-то не понял, но у double check lock есть применения кроме глобальной инициализации?
Если нет — то первые 2 паттерна в Rust покрываются sync::Once, lazy_static, при необходимости — mut_static. Ещё есть scoped_tls. Советовать писать такую колбасу для задач глобальной или ленивой инициализации не надо.
А что с mutable aliasing? Гонки данных ловит?
И ещё пару пунктов вспомнил:
Тоже смотрел на Elm с прицелом на фронтенд-язык на будущие года 3-5. Понравилось:
Не понравилось:
Итого:
Очень круто для энтузиастов, но переписывать мир на Elm без серьёзной поддержки коммерческих пользователей никто не будет, а она пока отсутствует.
Если вас симпатизирующих целая рота, то конечно вы можете послать командира к черту, только тогда всей ротой пойдете в штрафбат.