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 в этом пункте не упомянул специально.
У меня за последний год сложилось ощущение, что в стандартную библиотеку C++ хотят/пытаются внести слишком много функционала.
Был сделан выбор в пользу современных тенденций и требований рынка. C#, Java, Python умеют очень многое из коробки и людям это нравится по мнигим причинам, например:
В некоторых компаниях запрещены библиотеки кроме стандартной (нужен variant/flat_set/shared_library? Пиши сам с нуля, в компании <имя практически любой ООО работающей с деньгами> спец требования к безопасности.)
Когда пишешь что-то с чем раньше не встречался, хочется использовать что-то идущее вместе с языком, а не выбирать пару дней из N библиотек.
Документации на стандартную библиотеку всегда больше чем на сторонние.
Java, project Jigsaw. С точностью до наоборот — распиливание стандартного рантайма на несколько кусков поменьше, для тех кому не надо всё.
Также, никто не тянет Spring, Hibernate, Entity Framework в стандартные библиотеки.
По поводу документации — гораздо легче воспринимать маленькие самодостаточные компоненты.
одна реализация в одном месте вместо кучи независимых под каждый компилятор
Одна реализация — это адище для разработчика библиотеки и медленное внесение исправлений под ошибки компиляторов. Посмотрите на количество #ifdef/#elif в коде Boost для каких-либо старых компонент… а ведь это при том, что Boost недавно отказался поддерживать некоторые античные компиляторы.
Зато для пользователей библиотеки адищем является целая пачка её разновидностей. А большое кол-во директив условной компиляции — следствие зоопарка компиляторов в прошлом.
>> Lifetimes начисто противоречат как минимум copy by default в C++
> Не вижу противоречий. Поясни?
Может, не совсем правильно выразил свою мысль. Попробую написать более развёрнуто.
Во-первых, тот самый copy by default. В С++ «первичны» именно байтики, составляющие значение, а не само значение, с его семантикой и смысловой нагрузкой. Выражается это в том, что без дополнительных телодвижений значение любого типа будет банально копироваться. Делая «умный указатель», надо не забыть в обязательном порядке или запретить копирование, или правильно его обработать. Как следствие — можно схлопотать implicit copy, после чего дважды уничтожение одного и того же значения. Напротив, в Rust происходит move by default. Т.е. хочешь сделать копию — явно опиши как, а если не нужно — не будет лишних ошибок.
Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
В общем, чисто теоретически можно написать для С++ стороннюю утилиту, которая будет выполнять проверки на время жизни. Но геморроя будет слишком много. Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт. Как результат — низкоуровневые уши торчат наружу. В то же время в Rust семантика значения первична на уровне с его представлением.
>> к тому же придётся мучительно аннотировать весь код чтобы это работало
> Не мучительнее, чем в Rust.
Компилятор обругает за каждое пропущенное место. Как поступать с пропусками аннотаций в С++ — неясно.
>> Препроцессор останется с нами навсегда во имя совместимости.
> Пусть остаётся. Но пользоваться им будет не обязательно.
Макро-константы. Их валом до сих пор.
>> Аналога же Cargo вообще не предвидится в обозримом будущем.
> Вот уж совсем не проблема языка C++. Cargo не требует стандартизации даже.
Верно. Однако IDE вы, например, хотите. Как инструмент, конечно. Стандартизировать IDE нет никакого смысла. Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
>> несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
> Это утверждение справедливо для любого другого языка программирования.
В принципе да. Конкретно этот мой аргумент наверное несостоятелен. Генератора биндингов из Python в Ruby я не видел :)
>> единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода
> C++ на данный момент — единственный инструмент, который позволяет эффективно писать производительный код, и причина вовсе не в legacy.
Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Короче, в С++ накопилось слишком много проблем, часть из них не имеют адекватного решения без поломки обратной совместимости.
Я бы очень даже за. Даже всерьёз начал переделывать один микросервис, просто посмотреть как пойдёт. Остановили генерация биндингов (непонятно что делать с кучей констант, заданных макросами; автора макро-констант убить мало) и zeroing drops — т.е. объект с деструктором распухает, а мне это сильно мешало делать обёртки над хендлами.
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 в этом пункте не упомянул специально.
Java, project Jigsaw. С точностью до наоборот — распиливание стандартного рантайма на несколько кусков поменьше, для тех кому не надо всё.
Также, никто не тянет Spring, Hibernate, Entity Framework в стандартные библиотеки.
По поводу документации — гораздо легче воспринимать маленькие самодостаточные компоненты.
Зато для пользователей библиотеки адищем является целая пачка её разновидностей. А большое кол-во директив условной компиляции — следствие зоопарка компиляторов в прошлом.
> Не вижу противоречий. Поясни?
Может, не совсем правильно выразил свою мысль. Попробую написать более развёрнуто.
Во-первых, тот самый copy by default. В С++ «первичны» именно байтики, составляющие значение, а не само значение, с его семантикой и смысловой нагрузкой. Выражается это в том, что без дополнительных телодвижений значение любого типа будет банально копироваться. Делая «умный указатель», надо не забыть в обязательном порядке или запретить копирование, или правильно его обработать. Как следствие — можно схлопотать implicit copy, после чего дважды уничтожение одного и того же значения. Напротив, в Rust происходит move by default. Т.е. хочешь сделать копию — явно опиши как, а если не нужно — не будет лишних ошибок.
Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
В общем, чисто теоретически можно написать для С++ стороннюю утилиту, которая будет выполнять проверки на время жизни. Но геморроя будет слишком много. Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт. Как результат — низкоуровневые уши торчат наружу. В то же время в Rust семантика значения первична на уровне с его представлением.
>> к тому же придётся мучительно аннотировать весь код чтобы это работало
> Не мучительнее, чем в Rust.
Компилятор обругает за каждое пропущенное место. Как поступать с пропусками аннотаций в С++ — неясно.
>> Препроцессор останется с нами навсегда во имя совместимости.
> Пусть остаётся. Но пользоваться им будет не обязательно.
Макро-константы. Их валом до сих пор.
>> Аналога же Cargo вообще не предвидится в обозримом будущем.
> Вот уж совсем не проблема языка C++. Cargo не требует стандартизации даже.
Верно. Однако IDE вы, например, хотите. Как инструмент, конечно. Стандартизировать IDE нет никакого смысла. Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
>> несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
> Это утверждение справедливо для любого другого языка программирования.
В принципе да. Конкретно этот мой аргумент наверное несостоятелен. Генератора биндингов из Python в Ruby я не видел :)
>> единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода
> C++ на данный момент — единственный инструмент, который позволяет эффективно писать производительный код, и причина вовсе не в legacy.
Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Короче, в С++ накопилось слишком много проблем, часть из них не имеют адекватного решения без поломки обратной совместимости.
Я бы очень даже за. Даже всерьёз начал переделывать один микросервис, просто посмотреть как пойдёт. Остановили генерация биндингов (непонятно что делать с кучей констант, заданных макросами; автора макро-констант убить мало) и zeroing drops — т.е. объект с деструктором распухает, а мне это сильно мешало делать обёртки над хендлами.