Доказана эффективность Rust

Ну так я вам как раз о том, что не смотря на распространенность Qt, для плюсов много работы по написанию нового кода и без GUI, и без Qt.

Дада. В с++ вообще ничего нету. А если и есть то ЭТО ЖЕ ДРУГОЕ!

Что ты зацепился за этот qt. Ты с++ только на его уровне знаешь? Тогда это многое объясняет. Qt когда то был интересен из-за гуйни, но в 21 веке писать гуи, прибитый к языку…гуйней вообще должны ux заниматься а не девелоперы

https://github.com/redox-os/orbtk
Это говно, а не GUI.

чем оно хуже по сравнению с qt? (кроме того, что написано на расте, который мало кто знает)

Мне криптошлюхи ещё год назад предлагали. Тебе что-то нормальное? Я не видел ни одной приличной вакансии.

https://github.com/fffaraz/awesome-cpp

Шарп ещё, я фигею с количества вакансий на нём.

C: CompCert, VST, Frama, …

Rust: целое нигде не стандартизированное подмножество, которое верифицировали сто лет назад и оно с тех пор пять раз изменилось, «афигенский рокетсайнс»

Так и я вам о том же. Если нужно пилить поверх текущей C++ базы - то это понятно. Туда Rust никто тащить не будет. Но если нужна системщина или wasm - то это уже другой разговор.

Если GUI либа не умеет в ШГ - это уже приговор. Все растовские либы не умеют. Поэтому я и пилю порт harfbuzz.

Ещё бы в гугл послал. Мне бы ссылки на конкретные проекты.

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

Написал он бред по поводу проверок в unsafe. Пример со ссылками

Нет, это враньё. Ссылка - нелепая пропаганда

это буквально выстрел себе в ногу и удивление от того, что ногу прострелил. Явно написал unsafe, явно преобразовал к указателям, явно затерел лайфтаймы. Явно удивляется, почему лайфтаймы затерлись. Пусть попробует то же самое со ссылками (спойлер: не сработает). Такая семантика.

Ни эффективность, ни типобезопасность Rust не доказывал никто. Доказательство показывает ровно то, что сферический safe Rust в вакууме типобезопасен, если никакой код под капотом не использует unsafe (либо приняв, что unsafe под капотом корректен). Вот сюрприз-то, кто бы мог подумать.

Дядь, гуйню писать на чем-то нужно. Пока девелоперы тулкит не сделают, никакие ux ничего написать не смогут, потому как не на чем.

на C++ >= 14

Обоснуй фильтр.

Если нужно пилить поверх текущей C++ базы - то это понятно.

Не обязательно поверх. Достаточно просто иметь людей с несколькими годами опыта в C++ и наличия готовых и проверенных библиотек на C или C++. И уже околосистемные вещи на плюсах писать проще, чем на Rust, специалистов в котором на рынке около нуля.

ХЗ что вы называете «современными и удобными» библиотеками. Но вот для разбора аргументов командной строки в последние 4-5 лет доводилось использовать Boost.ProgramOptions, args и Clara (правда, Clara уже все, вместо нее теперь развивается Lyra). Полет нормальный во всех случаях.

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

Не нужно. Сейчас инструментов для этого уже выше крыши. Не умеешь отделить гуйню от приложения с логикой? Ну так это твои проблемы.

По хорошему, нужно было вообще C++17, ибо только там завезли optional и variant, без которых нормальный API невозможен. А тащить ещё одну реализацию данных контейнеров в проект - нет, спасибо.

наличия готовых и проверенных библиотек на C или C++

Дык нет их. Единственная либа для работы с XML - это наркоманский libxml2. Для ШГ - ещё более убогий freetype, который не умеет в многопоточность. Нормальной либы для работы с архивами вообще нет. Нужна графическая либа, которая не тянет Qt или пол гнома - тоже финиш. И тд. и тп.

Если вы ворочаетесь в очень узкой нише, в которой и так всё хорошо - не вопрос. Но на деле, из современных, адекватных C++ либ можно вспомнить только json. Даже банальный csv парсер не найти, ибо для него нужны нормальные строки.

то лучше иметь что-то, что ты сам можешь расширить и углубить.

Ору! И этот человек ругает сишников за закат солнца вручную.

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

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

то лучше иметь что-то, что ты сам можешь расширить и углубить.

Ору! И этот человек ругает сишников за закат солнца вручную.

Сказал человек, пытающийся переписать готовые, оттестированные годами C++ библиотеки на своем язычке. Что это, как не закат солнца вручную, Флакон?

оттестированные годами C++ библиотеки

А вот и городские легенды пошли.

Дык нет их.

Надо же, а мужики-то и не знают.

Хотя нет, знают. Просто смотрят на мир несколько проще, чем вы.

Единственная либа для работы с XML - это наркоманский libxml2.

В С++ных проектах вокруг libxml и/или libexpat/tinyxml написали уже столько заточенных под специфику проекта оберток, что про чистую сишку внизу и забыли давно. Либо Apache Xerces используют.

Но на деле, из современных, адекватных C++ либ можно вспомнить только json.

На деле лучше задасться вопросом об адекватности судьи.

Ору! И этот человек ругает сишников за закат солнца вручную.

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

Только вот когда вам потребуется

Очевидно же что не потребуется пока не запилили нужный крейт

А вот и городские легенды пошли.

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

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

но нативный гуй будет эффективнее. Никуда ты не денешься от этого

нативный

Въетнамскими флешбеками проносятся gnomeShell, tcl/tk, qml, xaml, swift-ui, flutter и прочий «нативный» гуй

IPC на фоне любого из этих персонажей не даст ощутимых тормозов. А правильный IPC, без json и прочей хипстоты вообще не будет заметен

Все он правильно сказал. Либо аллоцировать в куче и возвращать указатель, либо через аргументы передавать указатели/ссылки и возвращать errno. Лишние аллокации – плохо, передача через аргументы неэргономична ни капли.

От Option оверхэд нулевой – признак наличия значения компилятор может пихать в неиспользуемые биты, даже в худшем случае этот байт ты все равно бы получал как errno и проверял. Зато польза от нормальной типизации огромная.

Это же применяется ко всем variant types в целом.

всё, у вас исчезает 90% сложных багов без повышения трудоемкости написания кода.

Самый умный, да? ЯП нет нормальных только и только ввиду ущербности x86 архитектуры. Никогда ничего быстрее (а значит и лучше) сишки не появится под x86. Меняйте архитектуру, бояре, и будет вам щастье.

без которых нормальный API невозможен

Ок, допустим.

нет, спасибо

Обоснование 80 lvl.

Меняйте архитектуру, бояре, и будет вам щастье.

elaborate, please

написали уже столько заточенных под специфику проекта оберток

То есть опять всё писать самому?

libexpat/tinyxml

Примитивны до безобразия. tinyxml вообще C с классами.

Apache Xerces

Говно мамонта, которое даже RAII не использует, а про unicode слышало только краем уха? При этом содержит 150к строк кода. Я не зря написал про C++14.

все готовые чужие решения начинают стремительно блекнуть

А как же прекрасная экосистема C/C++? Непонятно.

Ну уж поболее оттестированные, проверенные и полноценные

Я же говорю - городские легенды. У половины системщины на лине вообще нет тестов. Хороший пример - fontconfig. Или даже librsvg. Как тестируют FreeType я так и не понял.

чем твое бесконечное переписывание

Я переписываю не либу, а алгоритм. И он получается проще, быстрее и надёжнее.

Любой, кто имел дело, тебе скажет что API с sum-types гораздо приятнее, чем на каждый чих выделять объект в куче (nullptr vs value), иметь некоторое «особенное» значение в возвращаемом результате (0-254 - Ok, 255 - Error), писать результат в аргумент-ссылку (Который перед этим должен быть инициализирован). Тут даже не «Ой, смотрите как раст хорош», тут нужно смотреть только на то что сектанты-крестовики обгадились. Здоровый человек не будет выдавать костыли и извращения за фичу.

И, вот же неожиданность! Люди это понимают!

• Rust
• C++
• C

Правда не очень быстро. https://i.imgur.com/5UtgVuh.png (Rust почти не видно, но судя по числам, у него 1:20 отношение к C, и примерно столько же - к C++. Но что важно, так это то, что к нему растёт интерес, а к C/C++ - падает. Похороны будут, но будут не очень скоро. А апарышам вроде нашего монарха больно это видеть - вот они и изливают здесь свою зловонную рвоту.

Как я могу объяснить удобство API человеку, который пишет на Go?

Перечисленные именно что «нативные». Например, гномощели и qml воткнуты интерпретаторы js и css, в flutter’е богомерзкий dart.

То есть опять всё писать самому?

Многие вещи уже написаны и переиспользуются от проекта к проекту. Какие-то из этих вещей доступны в виде библиотек, скажем в POCO была, емнип, обертка вокруг libexpat, пользоваться которой можно было начать буквально с полпинка.

tinyxml вообще C с классами.

Вам шашечки или ехать? Огромное достоинство C++ в том, что вы запросто можете использовать готовую библиотеку хоть из 1990-х, если она решает вашу задачу.

А как же прекрасная экосистема C/C++? Непонятно.

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

Ну и как бы на С++ не делают проекты, которые нужно на коленке слабать за полчаса, а через час после первого запуска выбросить и забыть.

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

Сделать обертку над сишными библиотеками – тривиальная задача. Закинуть в репозиторий портянку, в build.rs ее скомпилировать, декларации прописать. Целый 1 (прописью: один) шаг относительно использования сишных библиотек в С++, причем декларации отлично пишутся с помощью одного макро.

Для специфических проблем ни в одном ЯП нет готовых решений.

Категорически не согласен. В том же питоне/js есть либа на каждый чих. Почему их нет в C/C++? Потому, что писать либы на этих языках - боль. ПМ нет, нормальная std в зародышестве. Соответственно получаем или очередное ненужно, которое собирается только на машине автора, или очередной фреймворк типа буста, poco, Qt и тд.

Для меня главное преимущество раста - это cargo + std. Ака экосистема, а не сам язык. C++ уже не сможет достичь этого уровня. Разве что все либы перепишут на C++17 и заведут единый ПМ. О чём я и писал выше.

в том же питоне

нет в С/С++

Определитесь уже, либо в питоне все либы на С, либо на С либ нету.

А кроме C++ных есть еще и C-шные проекты, которые в C++ затаскиваются вообще без усилий.

4.2 Любая сишная либа изобретает свой OOP и RAII, из-за чего использовать их с умными указателями не выйдет чуть менее чем никак. Тут недавно был пост нытья от чувака, который пытался прикрутить вяленый к расту - не смог. Так вот к C++ его также прикрутить не выйдет, ибо Сишка.

Вы не туда читаете.

Странно странно.

https://imgur.com/KelQuLt вот другая статистика.

Не так уж он и падает, а? Да и даже то, что он «падает» относитльно других это вполне закономерно, ибо «других» сейчас как грязи появляется, поэтому они все вносят свои доли процента. Ну и вся эта статистика еще и по другой причине бесполезна. У меня 2 репы с С++ проектом и 6 с растом. 3 моих хелоуворлда, 3 - клоны чужих хеловордов.

пытался прикрутить вяленый к расту

Буду благодарен, если найдется ссылка. Чистый вяленый к расту прикручивается спокойно, проблемы начинаются на wlroots и ко.

Я же все написал.

вырезать под корень все нуль-терминированные строки

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

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

Операции с указателями и есть сущность x86. Именно они делают данную архитектуру хоть сколько юзабельной. Их нельзя убрать. Убирая «небезопасные» операции, ты убираешь x86 и городишь какую-то виртуальную машину поверх.

должны обзавестись проверкой границ даже если производится какое-то копирование памяти

Опять лишний код, лишнее время.

у вас исчезает 90% сложных багов без повышения трудоемкости написания кода.

А так же исчезает 90% скорости работы приложения. Пишите на java, зачем мелочиться?

Придумав и запилив железячную архитектуру для high level программирования, что адепт тут и предлагает, улучшим и все остальное. Все проверки итп итд будут на уровне железа (скорость света). Лисп машины вот удачный пример. Но, к сожалению, корпорасты в виде Intel задушат любой удачный проект ибо знают, что он их похоронит. Илону Маску бы подкинуть идейку. У него может и хватит денег.

4.2 Любая сишная либа изобретает свой OOP и RAII, из-за чего использовать их с умными указателями не выйдет чуть менее чем никак.

Ну вот есть, например, libhttp-parser. С хрена ли ее нужно использовать с умными указателями – хз.

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

Это вы пионеру выше объясните, в его реальности вообще проблем нет.

Удобство субъективно.

Ну… Не такая уж она и другая. Только раст здесь выглядит ещё лучше. И если уж говорить о HelloWorld-ах, ты же осознаёшь, что на GitHub-е куча лабораторок от студентоты. Вот только Rust то не преподают - он же не популярен (:

Странно странно.

https://imgur.com/KelQuLt вот другая статистика.

Я здесь Раст и не заметил сразу, ЛОЛ.

Его и на последним из моих графиков не было заметно, так то.

Вы русский язык понимаете? Речь шла о создании биндингов, а не об удобстве использования получившегося. В худшем случае получается та же сишка, но с дополнительным шагом в виде ffi. Проблемы с владением там действительно есть, и начинаются они тогда, когда пишутся обвязки к всему этому, пытающиеся перевести этот самопальный RAII-ад в нативную модель Rust. Какие-то библиотеки транслируются нормально, какие-то нет. Но через голый unsafe работать можно без проблем.

Вот только Rust то не преподают - он же не популярен (:

Pascal преподают, и? Сильно ему это помогло?