Очень прошу зарепортить в апстрим данный баг, так как он звучит достаточно важным. Потому что если не зарепортите, то шанс на его починку намного меньше, чем с репортом :) Возможно, что дело не в баге, а в какой-то "скрытой" настройке или чём-то странном ещё.
На количество issue можете не ориентироваться особо - они могут быть разной приоритетности и тому прочее.
Именно для FTP сразу на ум не приходит ничего, кроме самописных скриптов по крону. Быстрый поиск дал вот такой плагин для fluentd: https://github.com/kzk/fluent-plugin-ftp . Но поциент-плагин скорее мёртв, чем жив.
Я ни в коем случае не ставил своей целью убедить кого-либо переходить на Vector. По проблемам, описанным в статье - это скорее уж анти-реклама, чего таить :)
Решение о том, нужен ли вам Vector в конкретно вашей ситуации - зависит исключительно от выбирающего, его контекста и множества других факторов. Я всего лишь подсвечиваю грабли, которые ждут вас, если вы таки подумаете в сторону вектора.
С другой стороны, Vector уже тоже достаточно известен-популярен - просто смотря с чем сравнивать.
на это ловятся все бездарные тупорылые дошколята, которые нажрались пропаганды и пошли блеять. Т.е. ЦА раста является дошколятский биомусор, который код писать не может
почему ЦА говнораста - это веб-обезьяны и бездарные докшоялта? Почему всё, что пишется - это всякая дристня, которую пишут на жс/дристоне/другой скриптухе?
ещё раз. Какой может быть с тобою "по делу", если ты жертва пропаганды? Ты не можешь существовать вне
в любом случае молодец
Зная вышеперечисленные факты (и многие другие), сложно воспринимать сравнение так называемого языка программирования Rust с чем-то нормальным всеръёз. Для более подробного и глубокого обсуждения рекомендую присоедениться к чату: https://t.me/proriv_zaparti2
Кстати и обычные STL контейнеры довольно просто можно сделать constexpr. Я занимался подобным патчингом libc++, когда готовил предложения по constexprфикации STL-ных контейнеров. Из минусов хочу отметить, что там по дороге нужно разметить как constexpr большую часть библиотеки. И ещё компилятор на тот момент (Clang trunk) очень часто уходил в ICE.
Взять любой обучающий С++ ресурс и начать писать. Это может быть книга, видеокурс, whatever. К сожалению, у С++ нет своего бесплатного аналога Rustbook пока что (это вопрос для SG20, который должен решить это, имхо), но есть много уже готовых книг\курсов. Выбор тут явно есть. Ну а по статьям на хабре о 17 способах инициализации судить — это хохма какая-то :)
Если ты стоишь перед выбором что учить, то учить C++ желания не возникает
Это называется маркетинг. И тут Rust действительно показал, как нужно работать на данном поле. И этому у Rust стоит поучиться многим.
Но это будет лишь текущий статический срез, который не даст представление о best practices и общепринятых способах решения проблем.
Так если мы пишем кодовую базу с нуля, то нам как раз таки и нужен статический срез свежака без всего это легаси. Нам и нужен именно тот самый Modern C++. И нет нужды в знании старого С++. Вам нужно знание более старого С++ только если вы работаете с кодовой базой, которая также на нём написана. Я не вижу смысла для себя в 2020 знать, как там проблемы решались в С++98 (хоть и знаю, так как раньше работал с таким кодом, но теперь я с ним не сталкиваюсь).
Только тогда человек точно знает: как, почему и для чего появилась та или иная возможность или особенность стандарта.
Я считаю такие знания бесполезными для пользователей. Он не должен думать о причинах, он должен знать средства для решения проблем, не более того. Причины, историю и так далее оставим ребятам в Комитете, это их хлеб.
Ни одна книга не даст этого опыта. Этот поезд уже ушёл, и максимум, на что можно рассчитывать — зацепиться за последний вагон, чтобы потом ехать снаружи.
Не вижу в этом ничего плохого. Если работаете только с новой кодовой базой — то почему бы и нет? Если приходится и старое трогать (а в любом развивающемся языке будет старая и новая кодовая база — это неизбежно), то по ходу дела можно и подучить. Тут ничего уникального у С++ нет.
С другой стороны, Rust только начинает развиваться. И у новичков, которые зайдут в этот поезд прямо сейчас, есть уникальная возможность развиваться вместе с ним, отслеживая все нововведения и разворачивающиеся вокруг дискуссии.
… И через парочку ревизий языка им придётся знать несколько Editions. То есть кардинально ситуация не поменялась :) Я не считаю, что пользователи должны за всем этим следить. Просто должны проверять к каждому Edition штуки, какие завезли, думать об апгрейде компилятора, если это возможно в их ситуации, обдумывать, как применять новые фишки. Зачем читать все эти дискуссии и так далее — без понятия.
Забыл добавить. По крайней мере на моём опыте я совершенно недавно начал писать абсолютно новую кодовую базу (то есть легаси ровным счётом ноль). Но как «нативный» ЯП я выбрал именно С++. Не потому, что я его лучше знаю (более чем уверен, что мне хватило бы 2-3 недель, чтобы на него пересесть более-менее нормально), а потому, что не нашёл нужных мне библиотек (там нет аналога SObjectizer) и просто потому, что Rust не решает проблем лучше С++, с которыми я сталкиваюсь в разработке. Повторюсь, именно те проблемы, с которыми сталкиваюсь я (у вас возможно и будет решать). Но у меня современный С++17 (я бы на С++20 переключился, но не считаю его достаточно стабильным), у меня CMake, Conan, статический анализ (который в том числе и ловит (хоть пока что и не все, как Rust) lifetime ошибки (но у меня пока что ни одной не поймал, потому что ни одной и не было. Не факт, что так будет у вас :)). В целом у меня достаточно современный стек, чтобы на него жаловаться.
Хвала богам, что у меня нет самописной билд-системы, подтягивание библиотек с помощью вызова Сатаны и много других прелестей, которые до сих пор имеют многие С++ проекты (по причине их нежелания мигрировать на современные средства).
Во-первых прочитайте статью (и комментарии к ней) от humbug — станет яснее.
Borrow checker в Rust отлично работает, зря вы так.
Поэтому я совершенно не понимаю зачем он вообще нужен и почему бы не улучшать тот же с++, вместо того чтобы плодить еще одну экосистему со своими проблемами.
Это действительно хороший вопрос. Многие считают, что С++ уже не исправить. Лично я так не считаю и своим развитием С++ показывает, что он умеет эволюционировать. Смысл в том, что C++ сейчас как раз и движется в сторону многих вещей, которые Rust уже предлагает. Кому не хочется ждать и сразу писать на готовом (но при этом без кучи библиотек, наработанных за всё время на С++) — могут использовать Rust. Для тех, кто хочет использовать уже готовые решения — используйте С++ и дальше, обмазывая его, как вы правильно заметили, уже практически идущим в комплекте статическим анализом, пакетниками и так далее и будет вам счастье.
Так хуже ведь не станет всё равно :) Просто теперь алгоритм немного поменялся:
1) Выбрали библиотеку
2) Проверили, есть ли в Conan
3) Если есть, то за 15 секунд подключили
4) Если за 15 секунд не справились — плюнули и подключили по старинке.
Времени дольше не заняло, а шанс того, что сэкономите время заметно увеличивается. И чем дальше, тем больше либ появляются в Conan и исправляются рецепты.
К тому же на плюсах сложно писать асинхронный код.
Если stackful — Boost.Coroutine2 и вперёд. Если stackless — то C++20 с корутинами + cppcoro и вперёд (но я бы лично сейчас так не делал).
Нужна асинхронная либа для http-сервера — restinio.
Если вы интересуетесь вопросами ускорения программ, то могу посоветовать пересобрать PostgreSQL с Profile-Guided Optimization (PGO): https://ru.wikipedia.org/wiki/Profile-guided_optimization . Я собираю результаты применения PGO к разным приложениям (в том числе и БД) вот тут - https://github.com/zamazan4ik/awesome-pgo , с результатами для PostgreSQL можно ознакомиться здесь - https://github.com/zamazan4ik/awesome-pgo/blob/main/postrgresql_results.md .
Очень прошу зарепортить в апстрим данный баг, так как он звучит достаточно важным. Потому что если не зарепортите, то шанс на его починку намного меньше, чем с репортом :) Возможно, что дело не в баге, а в какой-то "скрытой" настройке или чём-то странном ещё.
На количество issue можете не ориентироваться особо - они могут быть разной приоритетности и тому прочее.
В апстрим зарепортили проблему? Если да, то можете дать ссылку на репорт, пожалуйста?
Хм, не знал о таком поведении. Спасибо! Плюс одни грабли для высоконагруженной среды :)
Оставлю для истории ссылку на большее количество материалов о PGO, вдруг кому интересно будет: https://github.com/ZaMaZaN4iK/awesome-pgo
Именно для FTP сразу на ум не приходит ничего, кроме самописных скриптов по крону. Быстрый поиск дал вот такой плагин для fluentd: https://github.com/kzk/fluent-plugin-ftp . Но поциент-плагин скорее мёртв, чем жив.
Я ни в коем случае не ставил своей целью убедить кого-либо переходить на Vector. По проблемам, описанным в статье - это скорее уж анти-реклама, чего таить :)
Решение о том, нужен ли вам Vector в конкретно вашей ситуации - зависит исключительно от выбирающего, его контекста и множества других факторов. Я всего лишь подсвечиваю грабли, которые ждут вас, если вы таки подумаете в сторону вектора.
С другой стороны, Vector уже тоже достаточно известен-популярен - просто смотря с чем сравнивать.
Зная вышеперечисленные факты (и многие другие), сложно воспринимать сравнение так называемого языка программирования Rust с чем-то нормальным всеръёз. Для более подробного и глубокого обсуждения рекомендую присоедениться к чату: https://t.me/proriv_zaparti2
Это что получается, обратно свой продакшн веб-сервисы с ржавы на С++ переписывать? :)
Рассматривался ли Matrix в качестве протокола для чата?
Кстати и обычные STL контейнеры довольно просто можно сделать constexpr. Я занимался подобным патчингом libc++, когда готовил предложения по constexprфикации STL-ных контейнеров. Из минусов хочу отметить, что там по дороге нужно разметить как constexpr большую часть библиотеки. И ещё компилятор на тот момент (Clang trunk) очень часто уходил в ICE.
О мертвых либо хорошо, либо никак.
Не хватает описания того, зачем собственно он вообще нужен ещё один такой.
Взять любой обучающий С++ ресурс и начать писать. Это может быть книга, видеокурс, whatever. К сожалению, у С++ нет своего бесплатного аналога Rustbook пока что (это вопрос для SG20, который должен решить это, имхо), но есть много уже готовых книг\курсов. Выбор тут явно есть. Ну а по статьям на хабре о 17 способах инициализации судить — это хохма какая-то :)
Это называется маркетинг. И тут Rust действительно показал, как нужно работать на данном поле. И этому у Rust стоит поучиться многим.
Так если мы пишем кодовую базу с нуля, то нам как раз таки и нужен статический срез свежака без всего это легаси. Нам и нужен именно тот самый Modern C++. И нет нужды в знании старого С++. Вам нужно знание более старого С++ только если вы работаете с кодовой базой, которая также на нём написана. Я не вижу смысла для себя в 2020 знать, как там проблемы решались в С++98 (хоть и знаю, так как раньше работал с таким кодом, но теперь я с ним не сталкиваюсь).
Я считаю такие знания бесполезными для пользователей. Он не должен думать о причинах, он должен знать средства для решения проблем, не более того. Причины, историю и так далее оставим ребятам в Комитете, это их хлеб.
Не вижу в этом ничего плохого. Если работаете только с новой кодовой базой — то почему бы и нет? Если приходится и старое трогать (а в любом развивающемся языке будет старая и новая кодовая база — это неизбежно), то по ходу дела можно и подучить. Тут ничего уникального у С++ нет.
… И через парочку ревизий языка им придётся знать несколько Editions. То есть кардинально ситуация не поменялась :) Я не считаю, что пользователи должны за всем этим следить. Просто должны проверять к каждому Edition штуки, какие завезли, думать об апгрейде компилятора, если это возможно в их ситуации, обдумывать, как применять новые фишки. Зачем читать все эти дискуссии и так далее — без понятия.
Хвала богам, что у меня нет самописной билд-системы, подтягивание библиотек с помощью вызова Сатаны и много других прелестей, которые до сих пор имеют многие С++ проекты (по причине их нежелания мигрировать на современные средства).
Borrow checker в Rust отлично работает, зря вы так.
Это действительно хороший вопрос. Многие считают, что С++ уже не исправить. Лично я так не считаю и своим развитием С++ показывает, что он умеет эволюционировать. Смысл в том, что C++ сейчас как раз и движется в сторону многих вещей, которые Rust уже предлагает. Кому не хочется ждать и сразу писать на готовом (но при этом без кучи библиотек, наработанных за всё время на С++) — могут использовать Rust. Для тех, кто хочет использовать уже готовые решения — используйте С++ и дальше, обмазывая его, как вы правильно заметили, уже практически идущим в комплекте статическим анализом, пакетниками и так далее и будет вам счастье.
Какой путь больше подходит — решать Вам.
1) Выбрали библиотеку
2) Проверили, есть ли в Conan
3) Если есть, то за 15 секунд подключили
4) Если за 15 секунд не справились — плюнули и подключили по старинке.
Времени дольше не заняло, а шанс того, что сэкономите время заметно увеличивается. И чем дальше, тем больше либ появляются в Conan и исправляются рецепты.
Если stackful — Boost.Coroutine2 и вперёд. Если stackless — то C++20 с корутинами + cppcoro и вперёд (но я бы лично сейчас так не делал).
Нужна асинхронная либа для http-сервера — restinio.