Почему Discord сменил Go на Rust. Блог разработчика.

Это как раз хорошо.

Это хорошо, но ничего принципиально не изменит. Еще несколько лет, и раст окончательно обгонит цэпэпэ по общей юзабельности.

Если конечно не случится чудо, и в цэпэпэ не завезут официальный менеджер пакетов, который все ломанутся использовать.

Вот пример, вышло ненужно за разработку под которое тебе не заплатят и 2 килобакса за месяц работы.

Лучше уж в макдак идти.

Под какие задачи ты не можешь найти библиотеки?

Последний раз товарищу надо было помочь, искал билиотеку для DBF, не нашёл. Для питона нашёл и в пару строк прочитал файл.

Никому нет дела до лефтпадов и прочего шлака.

который все кому не лень запихивали в зависимости и не по одной версии, тем не менее. И подобного «шлака», как раз в репозиториях «со своей экосистемой» почему-то очень много.

Я пользуюсь одним очень полезным для меня приложением на js - WebPlotDigitizer - и, как ни странно, зависимостей там не так много.

Нет, я не топлю конкретно за C++. Но нельзя утверждать, что там совсем ничего нет. При этом я не скажу, что всё прекрасно. Очевидно, что наличие определённых библиотек определяется потребностью в них. Кому-то потребовалось - реализовал; либо реализовал в закрытом продукте, если вещь уж слишком узкоспецифичная.

Тот же Blitz++ что-то заброшен опять, хотя библиотека достаточно хорошая и заявлена как очень быстрая. Но чаще пользуются Eigen, так как слишком многомерные массивы большинству не нужны оказались.

andalevor

искал билиотеку для DBF, не нашёл. Для питона нашёл и в пару строк прочитал файл.

https://www.whitetown.com/cdbfapi/ ?

Я бы сразу с питона или чего-то подобного начал в этом случае, даже при отсутствии библиотеки.

Еще несколько лет, и раст окончательно обгонит цэпэпэ по общей юзабельности.

Удачи, особенно в плане поддержки пакетов в дистрибутивах. Пример telegram-desktop показателен. Он хоть и не на rust, но из-за того как раскидан проект и его зависимости репозитории 2 дистрибутивов уже забили на его поддержку.

Если конечно не случится чудо, и в цэпэпэ не завезут официальный менеджер пакетов, который все ломанутся использовать.

Надеюсь, не завезут, а то начнётся нытьё, что какая-то библиотека не поставляется через менеджер и «что теперь делать!?».

Удачи, особенно в плане поддержки пакетов в дистрибутивах. Пример telegram-desktop показателен. Он хоть и не на rust, но из-за того как раскидан проект и его зависимости репозитории 2 дистрибутивов уже забили на его поддержку.

У меня такое впечатление, что ты не особо понимаешь о чем пишешь и пересказываешь все байки из интернетов, которые смог найти.

Еще раз - я довольно неплохо разбираюсь в том о чем пишу. Делюсь опытом, т.к. довелось побывать с обеих сторон. Если тебе не нужны объяснения - не вопрос. Но избавь меня от откровенно холиварных «аргументов», т.к. тратить время впустую мне не интересно.

Это ты не понимаешь, что пакетные менеджеры актуальны там, где нет динамической линковки. И что в рамках современных систем сборки менеджер не нужен.

чьей корпорации js?

Я привел конкретные примеры для эмбедов. Из реальной жизни. На кой ты придумываешь очередной кейз о котором не было речи? Тебе заняться нечем?

У тебя логика хакера. Вместо того, чтобы понять, где от пакетных менеджеров огромная польза, ты выискиваешь кейзы, где фича не работает. Это не конструктивно и лично для меня не интересно. Видишь ли, я могу привести примеры, с которыми неплохо знаком, но я не собираюсь что-то доказывать тому, кому это не нужно.

И что в рамках современных систем сборки менеджер не нужен.

Будет здорово, если вместо идеальных шарообразных современных систем сборки ты начнешь ссылаться на что-то конкретное. С понятными пояснениями.

Я не придумываю кейсы, я знаю, как как на самом деле делают с использованием систем сборки в совокупности систем контроля версий. И никаких проблем при этом разработчики не испытывают, используя в том числе библиотеки на других языках.

Я не ищу кейсы, где фича не работает - я регулярно пользуюсь кейсами, где она не сработает и не будет работать. HPC - нет там никакого толку ни от пакетных менеджеров, ни от горы библиотек сомнительного качества.

пересказываешь все байки из интернетов, которые смог найти.

Какие байки? Байка - исходный код librsvg, где понапихано куча зависимостей в виде одних и тех же пакетов разных версий?

Я не придумываю кейсы, я знаю, как как на самом деле делают с использованием систем сборки в совокупности систем контроля версий. И никаких проблем при этом разработчики не испытывают, используя в том числе библиотеки на других языках.

Если ты всю жизнь обходился без менеджера пакетов, это не значит что он не нужен и с ним хуже.

Я не ищу кейсы, где фича не работает - я регулярно пользуюсь кейсами, где она не сработает и не будет работать. HPC - нет там никакого толку ни от пакетных менеджеров, ни от горы библиотек сомнительного качества.

Я тебе конкретные примеры привел, где с менеджером пакетов удобнее. То что у тебя другие кейзы, как-то делает мои собственные не валидными? Зачем ты рассказываешь мне, пользующемуся пакетным менеджером через platformio, про кейзы когда пакетный менеджер не работает?

Какие байки? Байка - исходный код librsvg, где понапихано куча зависимостей в виде одних и тех же пакетов разных версий?

Еще раз. Один плохой пример не может перечеркнуть сто хороших. Ты целенаправленно выискиваешь только плохие. Зачем - не знаю.

Ты целенаправленно выискиваешь только плохие.

Можно пример хороших, пусть даже невостребованных? Это, к слову, один из ключевых проектов - я его специально не искал.

Дело не в том, что пакетный менеджер существует, а в том, во что это в итоге вылилось.

Уточни вопрос. Вроде кейзы уже я говорил и примеры обсуждали. Для си и сипипи хорошего нет (с охватом проблемы)

IMHO в расте хороший.

Под си и плюсы, для эмбедов есть platformio. Вот пример https://github.com/lvgl/lv_platformio. Есть конан, но я им не пользовался.

Если вопрос о другом - уточни.

Я тебе конкретные примеры привел, где с менеджером пакетов удобнее

естественно, проприетарщину удобно пилить с менеджером пакетов.

Проблема в том, что тут обсуждался совсем другой кейс - когда ты пилишь пакет для линуксового дистра, с зависимостями от других пакетов в этом дистре, динамической линковкой и т.д. В этом кейсе проекты на расте - головная боль, их очень трудно поддерживать. А с течением времени вообще будет невозможно. По, опять же, озвученным выши причинам.

Да, кстати, менеджер пакетов в расте - дерьмо и копипаста с npm. Go модули на 2 головы выше.

естественно, проприетарщину удобно пилить с менеджером пакетов.

Все что угодно удобно пилить с менеджером пакетов. Зачем ты передергиваешь? Это не добавляет смыслов.

Проблема в том, что тут обсуждался совсем другой кейс - когда ты пилишь пакет для линуксового дистра, с зависимостями от других пакетов в этом дистре, динамической линковкой и т.д.

Я не шарю в этой кухне. И не знаю, насколько реально там все разрулить на уровне теории. Но в кейзе с эмбедами профит велик, тут я точно разбирался лично.

Понимаешь, если есть неудобные кейсы, это не значит что я тоже соглашусь уродоваться. Просто я реалист, конкретно сейчас мне выгоднее писать эмбеды на цэпэпэ, хоть я его и недолюбливаю. Но как только в расте доведут всякие утилитарные моменты до ума, я с радостью на него свалю. А там не так много доводить - добавить в инсталлятор помимо компилятора еще и прошивалки на все платформы, ну и привернуть всякий сахарок с отладчиком к чему-то типа vscode.

Да, кстати, менеджер пакетов в расте - дерьмо и копипаста с npm. Go модули на 2 головы выше.

Тонкости менеджеров пакетов я обсуждать не готов. Могу только разницу между наличием и отсутствием. Возможно, кому-то надо с плюсов переходить не на раст а на го. Но спрашивали про раст.

Для си и сипипи хорошего нет (с охватом проблемы)

Чего нет? Я вообще не о кейсах.

IMHO в расте хороший

Кто хороший?

Уточняю: я привёл примеры 2 известных и востребованных проектов (librsvg, mercurial), которые решили переписать/сделать реализацию на rust. Претензия не в том,что переписали и что на rust, а в том, что при переписывании они оба тащат тонны дублирующихся зависимостей по несколько версий на каждый чих. Именно это выглядит дикостью. Вот и интересны проекты, где подобный подход с использованием зависимостей используется более аккуратно.

Я не шарю в этой кухне Тонкости менеджеров пакетов я обсуждать не готов

не шаришь, не готов, но тем не менее заявляешь

Все что угодно удобно пилить с менеджером пакетов

нет, не удобно. С cargo у тебя есть 2 стула: либо пилить десятки и сотни микропакетов для даже самых небольших проектов, либо вендорить всё в этот проект. В обоих случаях непонятно, кто будет поддерживать это всё в дистре. Точнее понятно, что никто. А еще в любом случае типичные размеры установок такого дистра разрастутся до размеров винды.

Понимаешь, если есть неудобные кейсы, это не значит что я тоже соглашусь уродоваться

ну это работает и в обратную сторону. Почему пользователи линукс должны соглашаться уродовать свои дистры из-за того что это удобно проприетарщикам?

не шаришь, не готов, но тем не менее заявляешь

Я не стесняюсь делиться тем что знаю, и четко формулировать в чем разбираюсь а в чем нет. Если у тебя с этим какие-то проблемы или травмы - иди к доктору, не пытайся это решить за мой счет нелепыми предъявами.

нет, не удобно.

У меня есть проекты на гитхабе, где удобно. Ты пытаешься объяснить примерно что их нет. Зачем - не знаю.

ну это работает и в обратную сторону. Почему пользователи линукс должны соглашаться уродовать свои дистры из-за того что это удобно проприетарщикам?

Пользователей линукса никто ни к чему не принуждает. Даже тех, кому в каждой розетке мерещатся проприетарщики.

Уточняю: я привёл примеры 2 известных и востребованных проектов (librsvg, mercurial), которые решили переписать/сделать реализацию на rust. Претензия не в том,что переписали и что на rust, а в том, что при переписывании они оба тащат тонны дублирующихся зависимостей по несколько версий на каждый чих.

IMHO критериев уместности можно придумать до бесконечности. Но не все они влияют на результат. Можно например, прикопаться к величине отступов.

Самый понос с зависимостями обычно в dev deps, но что тянут утилиты разработки мало кого парит. В самих библиотеках обычно либо чисто, либо со временем чистят. Раст просто еще молодой. А на примере ноды можно было наблюдать все завихрения, от полного нуля до стабильной экосистемы.

Именно это выглядит дикостью. Вот и интересны проекты, где подобный подход с использованием зависимостей используется более аккуратно.

• https://github.com/speedcontrols/ac_sc_grinder
• https://github.com/puzrin/dispenser

Свои поделки под platformio считаются?

Эти 2 и предыдущий пример ж на C. О_о

что тянут утилиты разработки мало кого парит.

Некоторых разработчиков даже мало что парит : «у меня собирается, ничего не знаю, разбирайтесь сами».

Эти 2 и предыдущий пример ж на C. О_о

У меня такое впечатление, что ты готов вместо менеджера пакетов обсуждать любую херь, которая не имеет к делу отношения.

Там плюсовый компилятор и местами используются плюсовые фичи. То, что я не сделал все идеально на плюсах, имеет какое-то отношение к аккуратности зависимостей? Вот они прям раз, и стали неправильными?

Некоторых разработчиков даже мало что парит : «у меня собирается, ничего не знаю, разбирайтесь сами».

IMO ты занимаешься вкусовщиной и регулярно съезжаешь с темы. Лично меня, как разработчика, волнует управляемость и поддерживаемость проекта. Если за это надо заплатить дублированием зависимостей - иногда так выгодно. Иногда не выгодно. Но я предпочитаю принимать решения по ситуации, а не заниматься сектанством, провозглашая единственный правильный способ разработки.

Подожди, я уже 2 страницы жалуюсь на устройство проектов с примерами на rust (и не только в них - скорее любого беспорядочного месива из внешних библиотек), а ты продолжаешь приводить в пример проекты на C, когда я прошу привести пример проекта на rust, где нет упомянутого безобразия.

Если для того, чтобы выйти из дома нужны носки разного размера, то что-то явно идёт не так. Та же самая ситуация, когда требуется несколько версий одного пакета для сборки конечного.

Вот такой вопрос: проект X линкуется статически с библиотекой A и B, каждая из которых линкуется статически с библиотекой k-1.0 и k-2.0, соответственно. Отлично, вызовы библиотеки k вроде бы должны быть доступны и внутри X. Из какой версии библиотеки k (1.0 или 2.0) будет производиться вызов в проекте X? Или нужно явно ещё раз слинковать одну из библиотек статически ещё раз?

Гм… я вроде отвечал на вопрос «что есть такое в расте, чего нет в цэ[пэпэ]». Ответ был - «пакетный менеджер».

При этом валидным примером является не только «что на расте хорошо», но и «что на цэпэпэ исправляется (а что остается прежним), если подпереть костылями». Вот последний пример я тебе привести могу, первый - не могу (ну не юзал я раст в проектах).

Но в дистрибутивах уже есть пакетный менеджер.

Очевидно, что в репах cargo, nmp, pypy пакеты сами тоже не материализуются.

Это разные уровни абстракции, и под разные задачи. Если ты активно развиваешь и меняешь библиотеку - она в линуксовых дистрах будет протухать. Когда библиотека закабанеет - тогда и через дистр можно пропихивать. Некоторые мои жыэсовские библиотеки пакетируют в дебиан (я плохо понимаю нахрена, но не вижу смысла бугуртить)

Другой пример - мои эмбедные поделки собираются на любой оси. Лунуксовые репы сюда ну никак не примотать.

Очевидно, что в репах cargo, nmp, pypy пакеты сами тоже не материализуются.

Там где пакетные менеджеры доступны искаропки - юзерам не в напряг делиться наработками и подхватывать чужие. Когда у тебя на старте больше всяких поделок - со временем тоже больше толковых выплывает.

Там где нет возможности быстро подхватить чужую поделку (пусть даже бредовую) - с доведением до ума регулярные проблемы.

Если тебе в основном приходится иметь дело с десктопами и толстыми фреймворками, ты мог вообще не пересекаться с тем о чем я пишу. Это само по себе ни хорошо ни плохо. Ну просто тебе не надо. Не вижу проблемы.

я вроде отвечал на вопрос «что есть такое в расте, чего нет в цэ[пэпэ]». Ответ был - «пакетный менеджер».

Там где пакетные менеджеры доступны искаропки - юзерам не в напряг делиться наработками и подхватывать чужие. Когда у тебя на старте больше всяких поделок - со временем тоже больше толковых выплывает.

Да что тебе мешает подхватывать чужие поделки то? Если мы сейчас за скобки вынесем конан, то у тебя есть git submodules, ExternalProject_Add от cmake, всякие cpm, hunter.

А если юзер не осливает заливкку проекта на гит, то может пусть пока повременит с показом своего хелоу ворлда миру? Одним говнокодом меньше будет.

Да что тебе мешает подхватывать чужие поделки то? Если мы сейчас за скобки вынесем конан, то у тебя есть git submodules, ExternalProject_Add от cmake, всякие cpm, hunter.

• В первую очередь - мешает отсутствие чужих поделок на интересующие меня темы.
• Далее напрягает отсутствие соглашений по структуре библиотек.
• нужен будет ручной контроль версий и подзависимостей.

Ну в общем, свои собственные вопросы c зависимостями я закостылял через platformio. Но это только с загрузкой и сборкой. Этого IMHO слишком мало чтобы мотивировать массовое клепание библиотек как в «более других языках»

Так не работает. Как только юзеры натыкаются на ненужные трудности, они просто забивают болт и переключаются на что-нибудь другое. В итоге полезное тоже радикально сокращается.

Я ж из реального опыта рассказываю. На node.js с нуля наблюдал как разные пакеты менялись. То что при переключении на с/cpp с библиотеками ощутимый напряг - тоже на собственных проектах ощутил.

use lazy_static::lazy_static;

Сейчас модно использовать once_cell.

Почему разработчики на rust не поддерживают mercurial?

Как они должны это делать и зачем?

написанная в том числе частично на rust

Ну значит кто-то «поддерживает».

копипаста с npm

И это плохо потому что?..

Go модули на 2 головы выше.

Расскажи почему.

Cargo уже научился собирать для других языков?

Зависит от того как это определять, но вообще да.

Я не буду втягиваться в этот спор, оглянись вокруг.

Ну то есть, объяснить почему за растом стоит «дырявая корпорация», а за С++ - нет ты не можешь.

Активно помогать дописывать/переписывать. Использовать активнее. Пихуль то не взлетел, а то одна мозилла за всех отдувается и использует меркуриал.

Например? Мне попадается какая-то возня с build.rs для линковки и макросы для вставки кода.

До тех пор, пока раст не будет стандартизироваться так же мучительно и таким же колхозом как цпп, даже говорить не о чем. Ты ещё скажи, что за шарпом с джавой не стоят дырявые корпорации.

Как обычно бесполезно. Вы в курсе какой стандарт используется trunc версией gcc по-умолчанию? Нет? Тогда надо было добавить -std=c++20.

Впрочем, не важно. Часть http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html , относящаяся к UB при signed overflow, не была принята.

Активно помогать дописывать/переписывать.

Но зачем? Вот я «программист на раст», но гит мне удобнее.

Пихуль то не взлетел

Как будто у него были шансы.

ну добавь туда этот флаг, разрешаю. Кстати, макака, зачем ты постишь сюда эти ссылки? Ты же ни черта в них не понимаешь, как и английский в целом.

какая-то возня с build.rs

Ну да. Но цель «или собрать библиотеку или слинковаться с готовой» вполне достигается.

Всё-таки cargo инструмент весьма простой (и это замечательно), но через build.rs можно сделать всё остальное, если припрёт.

Я скажу, что за «цпп колхозом» стоят те же самые «дырявые корпорации», но когда удобно, то можно на это закрывать глаза.

https://www.whitetown.com/cdbfapi/

Какая-то дохлая проприетарь.

Те же, да не те же. Цели совсем иные, Ц/ЦПП - это основа, на нем все паразитируют и строят свои экосистемы, поэтому он нужен. А «убивать» его у раста кишка развяжется, скорее цпп возьмет все лучшее от раста (хотя мне не понравилось) и запилит в каком-нибудь цпп-26, а раст пополнит список среди шарпов и подобного. Посмотрим.

скорее цпп возьмет все лучшее от раста (хотя мне не понравилось) и запилит в каком-нибудь цпп-26

Тут даже мои тапочки рассмеялись (цитата)))

мои тапочки будут смеяться последними. Ты правда думаешь, что все сейчас ломануться переписывать все либы за несколько десятилетий на божественном расте? Ага.

Нет, я так не думаю. Речь идёт о долговременных трендах. Копролиты утонут сами, новые проекты начинаются на других языках.

C++ это как жить без трусов, но с двумя крестиками ))) (вольная цитата с хабра)

Она не работает?

Ну не надо так напрягать извилину, пытаясь оскорбить. Мне это пофиг. В первых версиях пропозала было предложение определить поведение при signed overflow. Предложение не прошло, его убрали. Я был не в курсе. Теперь в курсе (не из-за Lrrr, а потому что посмотрел состояние пропозала), всё, разобрались.

Аналитиг из тебя так себе. А на чем твои цифры основываются (на цпп проектов не начинают)? Почему на гитхабе проектов на Ц/ЦПП больше, чем на go, чем на шарпе (хотя странно сравнивать со скриптухой, которая паразитируют на ц/цпп на 100%)?. Жабу уже хоронят. На чем сегодня начинают проекты с нативом и не абы как, а что бы было видно статистику (ты ведь откуда-то цифры взял, ты ведь болтун какой-то)?