Corrode, проект транслятора из C в Rust, получил финансирование Mozilla

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

Речь про другое. Вот в Rust-е заморочились такими багами, которые возможны в C++ и ввели лайфтаймы на уровне системы типов. И теперь это везде. Тогда как в C++ никто тебя не будет защищать от твоих ошибок. Но зато есть возможность не париться о вещах, в которых лайфтаймы не являются проблемой:

void do_something_as_user(valid_name vn) {
  ... // Работа с vn.name_
}
...
const std::string user_name = ...;
do_something_as_user(valid_name(user_name));

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

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

к тому же мозилла не единственная кто банит исключения, есть еще гугол: пруф

Блин, ну сколько уже можно?

Но зато есть возможность не париться о вещах, в которых лайфтаймы не являются проблемой:

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

struct ValidName<'a> {
    name: &'a str,
}

impl<'a> ValidName<'a> {
    fn new(name: &'a str) -> Self {
        ValidName { name: name }
    }
}

fn do_something_as_user(_: ValidName) {}

let user_name = "eee";
do_something_as_user(ValidName::new(user_name));

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

Даже в ветке раста?

общепринятая регламентированная на уровне языка модель владения и управления ресурсами?

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

С уважением, ваш Кэп.

Тонкий инструмент (читай как «функция»/«процедура»/«костыль»/«велосипед») под конкретную задачу в рамках конкретной программы всегда лучше универсального

Неверно.

Походу, у вас «говно» == «малый размер».

Только прога на раст слинкованная с std статически весит меньше, чем на C++. И да, смысла от маленькой std нет. Вон в расте есть базовый no_std, для эмбдеба. И std для белых людей. А в плюсах всё через одно место.

C++хейтерства

Я на плюсах пишу лет 5 уже. О какой хейтерсве идёт речь? Для многих моих задач раст подходит лучше. Поэтому я на него и свалил. Ни о какой фанатизме тут речи не идёт.

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

Лол. Расскажите что там в браузере кроме движка то есть? Насколько я знаю, в том же хроме blink(бывший webkit) занимает большую часть кодовой базы. Потом идёт v8 и уже потом сам «браузер».

А вообще, если я правильно помню, движки для Netscape, Opera и KHTML появлялись как раз за 1.5-2 года разработки.

Опять напарываетесть на неверные сравнения. Эти движки писались во времена html4, css2 и почти полном отсутствии js. За последние 20 лет, знаете ли, многое изменилось.

Для сравнения, у меня новая версия KDE (у меня gentoo) собирается 1-1.5 часа, а chromium - 5. Там миллионы строк кода, которые нереально написать за пар лет. Тем более с такой маленькой командой. Ну и не будет забывать, что Servo - это эксперимент по переосмыслению подхода написания движка. В частности сейчас они активно экспериментируют с layout'ами и рендером.

Сравните её с растовской и всё станет на свои места.

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

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

В каком месте? У cppstd нет даже работы с fs.

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

А в плюсах всё через одно место.

Что-то из вас конкретику клещами вытаскивать нужно. Покажите на примере что и где через одно место.

Я на плюсах пишу лет 5 уже. О какой хейтерсве идёт речь?

О самом настоящем. Ну и да, 5 лет как раз подходящий срок, когда типа что-то знаешь, что-то видел и мнение имею.

Расскажите что там в браузере кроме движка то есть?

GUI, IO, интеграция с ОС.

Эти движки писались во времена html4, css2 и почти полном отсутствии js. За последние 20 лет, знаете ли, многое изменилось.

Изменилось. Только тогда все приходилось делать с нуля. И алгоритмы обработки html-элементов во время подкачки страницы, и эффективную работу с css и пр. вещи нужно было выдумывать, пробовать, переделывать.

что Servo - это эксперимент по переосмыслению подхода написания движка

О том и речь, что даже Servo оказался экспериментом. Т.е. самая большая разработка на Rust-е на данный момент — это даже не продакшен код. Так что говном в C++ бросаться легко, ибо на Rust-е ничего сравнимого по объему и сложности просто нет, посему Rust весь такой в белом.

Покажите на примере что и где через одно место.

А смысл? Вы опять начнёте рассказывать, что всё хорошо и так быть должно.

GUI, IO, интеграция с ОС.

Ну так это в эти 5% и попадает.

Об остальном даже говорить не буду. Ваш фанатизм не перестаёт удивлять.

А смысл?

Ну реально интересно.

Вы опять начнёте рассказывать, что всё хорошо и так быть должно.

Не начну, обещаю.

Тут вот какая штука. Для меня STL — это не вся стандартная библиотека C++. В стандартную библиотеку C++ входит и изрядная часть стандартной библиотеки C, и такая неоднозначная вещь, как iostreams.

А STL — это то, что привнесли в C++ Степанов и Ли в середине 90-х, в первую очередь шаблоны классов vector, set, list, deque и т.д., включая концепцию внешних итераторов (которая при этом замечательно согласуется с унаследованными из C указателями).

Так вот когда вы говорите, что STL говно, очень интересно узнать почему. Мне довелось попользоваться той же Java, когда в ней генериков еще не было. И убедиться, что STL — это реально крутая вещь, отсутствие которой очень быстро ощущается.

Ну так это в эти 5% и попадает.

Правда? Кросс-платформенный GUI — это 5% от рендера страничек. Афигеть.

Кросс-платформенный GUI — это 5% от рендера страничек

Вы не поверите. (С)

Что там хроме от GUI? Верхня панелька вот и всё. Системную тему он не умеет, выглядит везде чужеродно. Движок GUI у него вообще свой. Вот и получаем, что от GUI там рожки да ножки. К примеру тот хромиум, который QtWebEngine весит почти столько же, сколько и хром, но не включает в себя гуи.

Понятное дело что я по сорцам не лазил, и все лично не сравнивал. Поэтому это лишь моё логическое заключение.

vector, set, list, deque

А там больше ничего и нет. Достаточно посмотреть какое количество классов содержит буст и Qt. В случае раста, весь QtCore уже реализован. И не нужно в каждой либе реализовывать свой костыль.

Но если вы просите - пожалуйста. Список того, что мне не хватает в std по аналогии с Rust:

• option (есть в бусте, но кривой/небезопасный)
• result (чуть менее чем полностью нереален под плюсами)
• fs (path, file, etc.)
• строки
• кроссплатформенный доступ к аргументам CLI, а не указатель на char, который может содержать что угодно
• тоже самое, но для env
• slice (есть отдельные реализации, да)
• any
• нормальный print, а не убожество типа iostream и не грабли типа printf.
• возможность запуска процессов, типа qprocess
• работа с потоками, futures (уже есть немного, но пока примитивное)

Вот в целом и всё. Библиотека rust не намного впереди, но всё нужное есть и реализовано для людей и без UB. Все остальные ништяки в cargo.

Я даже больше скажу: меня больше бесит не убогость cppstd, а невозможность её расширения. boost не в счёт, ибо он еще более наркоманский. А все остальные пишут как хотят, изображая свои контейнеры, модели владения, синтаксис, апи и вообще все что только можно. В итоге половину либ без врапперов использовать нереально, а вторая половина не работает под всеми ОС/компиляторами.

Ну и еще 100500 претензий, но они решаются только сменой языка. Типа удобных tuple, enum и прочего.

result (чуть менее чем полностью нереален под плюсами)

Можно подробнее? Я набыдлил себе Result и в основном доволен. Акробат Александреску набыдлил Expected.

Список понятен. Кратко характеризуется так: «хочу иметь все, что нужно _мне_ в stdlib, не хочу брать это из сторонних библиотек и мне абсолютно похрен, что кому-то от stdlib нужно что-то другое». Складывается впечатление, что на C++ вы программировали только и исключительно в рамках уютненького мирка Qt.

Одна из реальных проблем C++ в том, что в нем нет и не предвидится аналога cargo (Maven, RubyGems, cabal и иже с ними). Тут у Rust-а неоспоримое преимущество.

Ирония, однако, в том, что часть вашего списка попадет в С++ stdlib еще до того, как на Rust-е напишут что-то большое и полезное.

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

Вы не поверите. (С)

Наличие std::thread ни о чём не говорит. Продвинутой работы, типа pthread тут нет. Удобств типа QtConcurrent тоже.

Я находил: https://github.com/oktal/result, но без растовских энамов не такой удобный.

Expected - это https://github.com/ptal/expected Зависит от буста, еще и жирный. Почти 5к строк.

хочу иметь все, что нужно _мне_ в stdlib, не хочу брать это из сторонних библиотек и мне абсолютно похрен, что кому-то от stdlib нужно что-то другое

Лол, ват? Я хочу то, что уже есть в других std. Я ничего своего не придумываю. Список выше состоит из того, что есть в rust, что мешает иметь это в cpp?

исключительно в рамках уютненького мирка Qt.

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

Ирония, однако, в том, что часть вашего списка попадет в С++ stdlib еще до того, как на Rust-е напишут что-то большое и полезное.

Какая выборочная вы ванга. Значит это попадёт в stdc++, а раст не влетит. Отсыпьте и мне.

не предвидится аналога cargo

И единого стиля форматирования.

без растовских энамов не такой удобный.

Ну, ADT тоже можно изобразить довольно близко. Конечно, это не Rust и не Ocaml, но довольно близко. Никакого «полностью нереален».

Есть примеры?

Список выше состоит из того, что есть в rust, что мешает иметь это в cpp?

Например, то, что Rust пока еще нигде всерьез не используется. Есть всего один вендор (как компилятора, так и стандартной библиотеки). Нет диверсификации, как в C++, где в hard-real time используют один C++, а в каком-нибудь Facebook-е совсем другой.

Вы, видимо, никогда не сталкивались с ситуациями, когда люди отказывались использовать классы из STL (те же std::string и std::vector) в интерфейсах своих библиотек. При этом приводя кучу причин в качестве обоснования (не все из них имели смысл, но людям это не мешало).

Выглянешь оттуда, аж страшно становится.

Вы не поверите, но в C++ community есть куча людей, которым страшно становится от заглядывания в мир Qt.

С++ он сильно разный и используется в сильно разных областях. Плюс не имеет единого центра масс, как в случае с Rust-ом и Mozilla. Отсюда и очень медленное наполнение C++ной stdlib вещами, которые могут быть полезны более-менее значительно части пользователей, идет крайне медленно.

Однако, проблема в том, что вы позволяете себе называть STL говном не понимая всего этого.

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

Значит это попадёт в stdc++, а раст не влетит. Отсыпьте и мне.

Ну, если вы в словах «Ирония, однако, в том, что часть вашего списка попадет в С++ stdlib еще до того, как на Rust-е напишут что-то большое и полезное» видите тезис «раст не взлетит», то вам уже хватит. У вас и так трава позабористей моей.

Часть того, что вы описываете уже входит в C++17 (optional, filesystem, variant, any).

Акробат Александреску набыдлил Expected.

Это ты про Expected из folly? https://github.com/facebook/folly/blob/master/folly/Expected.h

Да.

Продвинутой работы, типа pthread тут нет.

Что такое «продвинутая работа типа pthread»?

Тогда это проблема зависимостей, разве нет?

А разве хороший ЯП не должен помогать их фильтровать? В С/С++ используются системные заголовки, польза этого для несистемных программ сомнительная. Чего в зависимости наворотят, то без тестинга и попадёт в пишущуюся программу, использующую свою версию ЯП. А вот если ЯП+компилятор поставляется с набором своих, альтернативных, заголовков, то нет необходимости, если нужный модуль-прослойка есть, клепать его самому или использовать системный заголовок устраивая тем самым его бетатестинг в пишущейся программе. Например, есть ЯП с компилятором пару-летней давности, поставил его в новую ОС и используешь его альтернативные заголовки и ничего лишнего в программу не тянешь.

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

Пользовался изделием на этом телефонно-линуксовом куте в винде - повисает хорошо, свистоперделок много. Этот куть сам превращается в ОС, которую контролирует через зарплаты погромистам какая-то контора(ы). Не на паперти же они на разработку собирают:) Интересы пользователей и корпораций слабо совпадают. А раз так, и ЯП тот же что и в линуксе, то следует ожидать повторения ситуации - получите линукс для плюсов не от Торвальдса, но не лучше и без дров.

Мало типов «стабильной длины», серьёзно?

Ими можно теперь пользоваться в программе вообще забив на остальные, линкуясь при этом со всем чем угодно?

Да-да, проходи мимо если нечего сказать.

Я не говорил что его вариант не подходит. Более общий инструмент != неподходящий.

Например, то, что Rust пока еще нигде всерьез не используется

https://www.rust-lang.org/en-US/friends.html

И что, где-то там уже есть кодовая база в 1MLOC на Rust-е?

алгоритмы обработки html-элементов во время подкачки страницы, и эффективную работу с css и пр. вещи нужно было выдумывать, пробовать, переделывать.

Именно это и происходит сейчас в Servo. Основная цель проекта — параллельный браузерный движок. Алгоритмы есть, но их нужно параллелизовать, причем эффективно, а не воткнуть пару openmp директив и радоваться.

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

Активности фанатов больше, но как только у них наступает лень или кончается время, то кто со стороны поправит недоделки? Например, авидемукс (у него морда на кутях есть, наверно за С++ программу тогда частично сойдёт) есть почти во всех дистрибутивах, за исключением тех что для ~микроконтроллеров, и есть в нём недоделанный много лет назад фильтр для встраивания логотипов, add logo - кто его сейчас доделает и обучит хотя бы жевать png из современного гимпа? Как гуглишь в интернете, так там авидемукс рекламируется, даже видел его в списке лучших программ для встраивания логотипов, а это самое встраивание логотипа поправить некому. Или замечательный, в винде замечательный, свободный кодек lagarith, написан на виндовых плюсах и всё - в линукс не встроишь, портировать желающих нет. А ещё народ видеоредакторы в линуксах хорошие хочет - кто ж их им счас на плюсах напишет, если сообщество с одним С++ кодеком для редактирования справиться не может.

Delphi - не паскаль?

Паскаль, но так сразу и не вспомню того, кто его именно покупает. Зато интерфейсы классов из дельфей и емнип шарпа для свободной версии паскаля заимствуются.

Дык, новшества должны давать удобства или новые возможности. Иначе нафиг такие новшества?

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

1MLOC за год? Не смешите.

Тогда почему вы выдаете этот список за примеры _серьезного_ использования Rust-а?

не сталкивались с ситуациями, когда люди отказывались использовать классы из STL

Увы, сталкивался. И это печально.

позволяете себе называть STL говном не понимая всего этого.

И продолжу это делать. Ведь мои претензии вы не опровергли (муть на тему «так и надо» не подходит под оправдание).

Потому, что серьезное использование != 1MLOC. Вы сами выдумываете критерии, а потом, задним числом, их озвучиваете.

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

Я знаю что оно будет в 17, но то, как оно реализовано меня убивает.

Даже в ветке раста?

Ага: мне периодически попадаются комментарии, которые написаны явно не «растоманами». Да и почему нет? Про (некоторые) другие языки тоже интересно почитать, я и сам так делаю.

Первая ссылка в гугле: https://stackoverflow.com/questions/13134186/c11-stdthreads-vs-posix-threads/...

Ну eao197 указывал на наличие конкретно фанатиков.

Ваши познания о программировании просто поражают.

Мне довелось попользоваться той же Java, когда в ней генериков еще не было. И убедиться, что STL — это реально крутая вещь, отсутствие которой очень быстро ощущается.

А мне довелось попользоваться более свежими версиями Java с нормальным Collections API, где не надо на каждый чих передавать пары итераторов и нет таких невыразительных идиом, как erase-remove. С появлением ranges в стандарте ситуация, по видимому, улучшится, но пока это случится (а в С++17 уже не случится), в менее ретроградских языках появится ещё множество фич, которых будет не хватать в плюсах (впрочем, их и так достаточно).

Потому, что серьезное использование != 1MLOC. Вы сами выдумываете критерии, а потом, задним числом, их озвучиваете.

Задним числом? У вас с головой все в порядке. Здесь уже несколько страниц вокруг вот этого тезиса: «Так что говном в C++ бросаться легко, ибо на Rust-е ничего сравнимого по объему и сложности просто нет, посему Rust весь такой в белом.»

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

А 60KLOC на Rust-е в Dropbox-е — это, может быть и примечательно для фанатов Rust-а, но, блин, не идет ни в какое сравнение с уже упомянутыми здесь Chrome и Firefox. И, блин, именно поэтому Mozilla выбрала путь очень медленного включения в FF кода на Rust-е.

Увы, сталкивался. И это печально.

Печально и что? Валить на Rust? Тем, у кого миллионы строк на C++?

А ну да, это же не серьезно.

И продолжу это делать.

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

Ведь мои претензии вы не опровергли (муть на тему «так и надо» не подходит под оправдание).

Вы правильно указали: ваши претензии. Кроме ваших претензий есть еще и претензии других людей, которым на вас начхать так же, как и вам на всех остальных. Язык C++ существует в этих условиях уже не один десяток лет. Поэтому он такой, какой есть. И библиотека у него именно такая. И, по определению, чтобы в стандарт не включили, всегда будут недовольные, вроде вас.

Что-то не так написал?