Вы когда-нибудь ставили Visual Studio 2012 или 2013? Эта зараза пихает в систему ещё 30-40 компонентов. Ну и классика жанра, когда программа гадит в реестре, а при удалении за собой не подчищает.
Начну с конца. Про MSI не писал специально, т.к. опыта не сильно много. Но по тому, что есть — это формат-динозавр, на редкость монструозный и кошмарненький. Но это не экспертное, а сугубо личное мнение. Да и как он помогает в этом случае — не совсем понятно.
По поводу всего остального — да, невозможность держать несколько версий одной зависимости это проблема. Большая проблема. Её пытался решить NixPM. Однако, при работе с репозиториями бОльшая часть пакетов согласована. Косяки есть везде. И, как по мне, с пакетным менеджером лучше, чем без него.
1) Никто вам не мешает на другой машине выкачать пакет вместе с зависимостями. И поставить на целевой машине в оффлайне. К слову, под Windows онлайн-инсталляторы нынче в моде.
2) Аналогичная проблема с инсталляторами. Вендор удалил инсталлятор с сайта — и его больше негде достать.
3) Это так, чистая правда. Не хватает нового поколения пакетных менеджеров — смеси WinSxS хранилища и управления зависимостями APT, c «мягкими» версиями.
4) Опять же, для случая с APT вы его отключите в одном месте ровно один раз. А когда у вас Java Update + Chrome Updater Service + whatever…
В общем, пока две основные болячки пакетных менеджеров — бандлы, которые придут в виде снап-пакетов, и множество версий библиотеки на одной платформе. Но это как-то лучше, чем вообще без пакетного менеджера.
Увы, пакетные менеджеры не совершенны. Была как минимум одна попытка скрестить хранилище в стиле WinSxS и зависимости в стиле DPKG/APT — Nix Package Manager. Не взлетела. А было бы очень приятно иметь такую штуку.
WinSxS это не депенденси менеджмент ни разу. Это просто свалка одних и тех же библиотек разных версий. Причём даже без мягкого версионирования. В рамках WinSxS нельзя зависить от «любой 2.1 выше 2.1.9». А ещё их гениальнейший способ очистки — просто вычищать пакеты, к которым не обращались месяц или около того. Гениально, что сказать.
Если Вы про меня, я как раз знаю. Я только не понимаю, почему для того, чтобы корректно удалить программу в Windows, надо скачать другую стороннюю программу. Похоже, кто-то знает Windows лучше, чем инженеры MS.
Побуду Кэпом. В линуксе давным давно есть пакетные менеджеры с UI.
А теперь внимание. В Windows вы тащите инсталлятор. Руками. Ставите его. Инсталлятор ставит свой обновлятор и ещё кучу мусора. Плюс ещё по копии уже установленных системных либ. Когда вам не нужно это приложение — вы сначала сносите его, а потом долго и скрупулёзно вычищаете зависимости. Руками. Это если один из инсталляторов не был криво написан — так, что валится на процедуре деинсталляции.
Теперь линукс. Вы заходите в пакетный менеджер — и ставите нужный пакет. Вам не нужно думать, что для этого пакета надо доустановить ещё Mono и Python. Когда выходят апдейты — их наличие проверяет один (!) сервис. Который вы настроили один раз. Когда вам не нужен пакет — вы через тот же интерфейс пакетного менеджера помечаете его на удаление. После чего пакетный менеджер сам (!) проверяет, какие пакеты больше никому не нужны, и предлагает их удалить за компанию.
Пишу вам как человек, который почти всю свою сознательную жизнь просидел на Windows, а на Linux перешёл прошлой осенью.
Где-то на Хабре или Гиктаймсе пробегала идея — такой брелок, спаренный по Bluetooth со смартфоном. Пароли располовинить или использовать «подсаливание» на железке.
Да, точно, извиняюсь. Тогда мой предпоследний абзац:
Но правда и в том, что конкретно случая я не знаю. Может, эти кучи объектов потом перетасовываются так, что в нативе это действительно заморочно сделать.
По поводу "тщательной оптимизации" — вы ею уже занимаетесь, только при этом полагаетесь на такие неочевидные штуки как поведение JIT. Вы и так уже вставили "волшебный костыль".
По поводу "ручной работы с памятью" — я нигде не упоминал С. В С++ есть масса средств для полу-автоматического управления памятью. Кроме него, есть Golang — статика со сборкой мусора. Рекламировать крутизну некоего языка на R тут не буду.
По поводу "тестовых задач и числодробилок" — вот как раз на них JIT себя и показывает хорошо, из-за однообразного кода.
Но правда и в том, что вашего конкретно случая я не знаю. Может, у вас эти кучи объектов потом перетасовываются так, что в нативе это действительно заморочно сделать.
Ну а "не стоит связываться" — да, не стоит. Потому что нативный V8 API местами проектировали в горячечном бреду, не иначе. Один только C++ only чего стоит.
Да, оптимизация V8 хорошая. Но статический компилятор сможет лучше. Просто из-за более полной информации.
Впрочем, я не хочу превращать эту ветку в холивар "статика против динамики". Мне действительно интересно, почему вы полагаетесь на такую сравнительно зыбкую штуку как JIT и не выделяете нагруженную часть в нативный аддон.
Мне кажется, что если вы упираетесь в такие вещи, как скорость клонирования (!) объектов, вам надо переходить с JS на что-то более cтатичное. А пытаться писать хайлоад на динамическом языке, ещё и таком, как JS — не лучшая идея.
Проблема в том, что очень часто сталкиваешься с неадекватной деятельностью маркетологов и других "усиляторов продаж" как пользователь. Был хороший, логичный сайт — распилили, попрятали разделы, на главную какого-то лешего впихнули абсолютно бесполезное видео. Или LinkedIn, который постоянно хочет сунуть нос куда не надо. Просто как пример. Или Windows 10 Installer, позаимствовавший массу приёмов из фишинг-троянов, винлокеров и вирусов. Опять же как кпример.
Маркетологи вызывают ненависть именно с позиции производимых ими "тёмных паттернов". Поэтому маркетологам неплохо бы почаще спрашивать пользователей, чего они действительно хотят.
Циклические зависимости вполне возможны. Модуль A может зависеть от B::bar, а модуль B — от A::foo. Ничего плохого в этом нет. Проблема разрулить такие зависимости в рамках отдельных строительных блоков, чтобы там циклов не было.
Хотя мне это конечно напоминает аргументацию за введение синтаксиса 'auto foo(...) -> ret_type' тем, что компилятор якобы должен сначала увидеть определение аргументов, чтобы вычислять на их основе тип результата.
Я не могу, конечно, строго доказать, что в С++ в принципе нельзя добавить borrow checker. Но количество проблем и нестыковок будет просто зашкаливать. Не вижу смысла получать в стандарт ещё +200 страниц. Он и так толстый.
Ну придумают что-нибудь. Если уж даже из Python можно эти константы использовать, то и из C++ можно будет.
Поживём-увидим.
Я думаю, отсутствие Cargo — это следствие того, что на C++ неудобно писать. Не хотят хипстеры писать на C++, вот и нет единой популярной системы сборки и доставки зависимостей.
А вот мне хотелось бы писать на С++ удобно. А не танцевать с бубном, выбирая из нескольких вариантов подключить тот же Google Test. Java как бы тоже не хипстерная вещь, однако же есть Maven и его репозитории.
Это common misconception. В Go есть GC, что делает его непригодным для большого числа задач.
По поводу GC. Я специально написал "жёсткое байтоложество", т.е. максимальный уровень управления ресурсами. Для перемалывания тонн данных — нет. Писать прикладные утилиты — вполне. Rust в этом пункте не упомянул специально.
По поводу всего остального — да, невозможность держать несколько версий одной зависимости это проблема. Большая проблема. Её пытался решить NixPM. Однако, при работе с репозиториями бОльшая часть пакетов согласована. Косяки есть везде. И, как по мне, с пакетным менеджером лучше, чем без него.
2) Аналогичная проблема с инсталляторами. Вендор удалил инсталлятор с сайта — и его больше негде достать.
3) Это так, чистая правда. Не хватает нового поколения пакетных менеджеров — смеси WinSxS хранилища и управления зависимостями APT, c «мягкими» версиями.
4) Опять же, для случая с APT вы его отключите в одном месте ровно один раз. А когда у вас Java Update + Chrome Updater Service + whatever…
В общем, пока две основные болячки пакетных менеджеров — бандлы, которые придут в виде снап-пакетов, и множество версий библиотеки на одной платформе. Но это как-то лучше, чем вообще без пакетного менеджера.
А теперь внимание. В Windows вы тащите инсталлятор. Руками. Ставите его. Инсталлятор ставит свой обновлятор и ещё кучу мусора. Плюс ещё по копии уже установленных системных либ. Когда вам не нужно это приложение — вы сначала сносите его, а потом долго и скрупулёзно вычищаете зависимости. Руками. Это если один из инсталляторов не был криво написан — так, что валится на процедуре деинсталляции.
Теперь линукс. Вы заходите в пакетный менеджер — и ставите нужный пакет. Вам не нужно думать, что для этого пакета надо доустановить ещё Mono и Python. Когда выходят апдейты — их наличие проверяет один (!) сервис. Который вы настроили один раз. Когда вам не нужен пакет — вы через тот же интерфейс пакетного менеджера помечаете его на удаление. После чего пакетный менеджер сам (!) проверяет, какие пакеты больше никому не нужны, и предлагает их удалить за компанию.
Пишу вам как человек, который почти всю свою сознательную жизнь просидел на Windows, а на Linux перешёл прошлой осенью.
Да, точно, извиняюсь. Тогда мой предпоследний абзац:
Но правда и в том, что конкретно случая я не знаю. Может, эти кучи объектов потом перетасовываются так, что в нативе это действительно заморочно сделать.
Тогда напрашивается вывод, что (утрирую) для этой странички в 2 поля и 3 кнопки 400Кб скриптов явно многовато.
По поводу "тщательной оптимизации" — вы ею уже занимаетесь, только при этом полагаетесь на такие неочевидные штуки как поведение JIT. Вы и так уже вставили "волшебный костыль".
По поводу "ручной работы с памятью" — я нигде не упоминал С. В С++ есть масса средств для полу-автоматического управления памятью. Кроме него, есть Golang — статика со сборкой мусора. Рекламировать крутизну некоего языка на R тут не буду.
По поводу "тестовых задач и числодробилок" — вот как раз на них JIT себя и показывает хорошо, из-за однообразного кода.
Но правда и в том, что вашего конкретно случая я не знаю. Может, у вас эти кучи объектов потом перетасовываются так, что в нативе это действительно заморочно сделать.
Ну а "не стоит связываться" — да, не стоит. Потому что нативный V8 API местами проектировали в горячечном бреду, не иначе. Один только C++ only чего стоит.
Да, оптимизация V8 хорошая. Но статический компилятор сможет лучше. Просто из-за более полной информации.
Впрочем, я не хочу превращать эту ветку в холивар "статика против динамики". Мне действительно интересно, почему вы полагаетесь на такую сравнительно зыбкую штуку как JIT и не выделяете нагруженную часть в нативный аддон.
Мне кажется, что если вы упираетесь в такие вещи, как скорость клонирования (!) объектов, вам надо переходить с JS на что-то более cтатичное. А пытаться писать хайлоад на динамическом языке, ещё и таком, как JS — не лучшая идея.
Полу-оффтоп.
Проблема в том, что очень часто сталкиваешься с неадекватной деятельностью маркетологов и других "усиляторов продаж" как пользователь. Был хороший, логичный сайт — распилили, попрятали разделы, на главную какого-то лешего впихнули абсолютно бесполезное видео. Или LinkedIn, который постоянно хочет сунуть нос куда не надо. Просто как пример. Или Windows 10 Installer, позаимствовавший массу приёмов из фишинг-троянов, винлокеров и вирусов. Опять же как кпример.
Маркетологи вызывают ненависть именно с позиции производимых ими "тёмных паттернов". Поэтому маркетологам неплохо бы почаще спрашивать пользователей, чего они действительно хотят.
Извините, накипело.
Есть ещё "раскрутка стека".
Циклические зависимости вполне возможны. Модуль A может зависеть от B::bar, а модуль B — от A::foo. Ничего плохого в этом нет. Проблема разрулить такие зависимости в рамках отдельных строительных блоков, чтобы там циклов не было.
Хотя мне это конечно напоминает аргументацию за введение синтаксиса 'auto foo(...) -> ret_type' тем, что компилятор якобы должен сначала увидеть определение аргументов, чтобы вычислять на их основе тип результата.
Я не могу, конечно, строго доказать, что в С++ в принципе нельзя добавить borrow checker. Но количество проблем и нестыковок будет просто зашкаливать. Не вижу смысла получать в стандарт ещё +200 страниц. Он и так толстый.
Поживём-увидим.
А вот мне хотелось бы писать на С++ удобно. А не танцевать с бубном, выбирая из нескольких вариантов подключить тот же Google Test. Java как бы тоже не хипстерная вещь, однако же есть Maven и его репозитории.
ответил здесь: https://habrahabr.ru/company/yandex/blog/301514/#comment_9623684
По поводу GC. Я специально написал "жёсткое байтоложество", т.е. максимальный уровень управления ресурсами. Для перемалывания тонн данных — нет. Писать прикладные утилиты — вполне. Rust в этом пункте не упомянул специально.