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

окей, давайте отмотаем стэк.

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

в тред при этом набегаются фанатики и вещают про «убийцу С и С++». последнее слушать смешно, ибо на расте тупо нету критически важных библиотек, без которого он язык для фанатиков.

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

Я тоже, но это, судя по всему, так специально задумано. И что характерно (или удивительно) многим нравится.

Так что ниши для хорошего нативного языка с GC, имхо, есть.

Может и так.

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

Дык, на это был ответ:

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

Хотя я данную штуку тоже считаю весьма сомнительной.

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

Сейчас ты в фанатика превращаешься. Потому что если говорить объективно, то не всем нужны эти «критически важные библиотеки», а некоторые готовы сами их писать. Или скажешь, что все, кто перечислен вот тут, фанатики?

О каком менеджере вообще идёт речь? Если не считать libc, то у автора полный доступ к памяти, без каких либо менеджеров.

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

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

В данном случае у раста много шансов. И я делаю всё, чтобы их стало больше.

И всё это забито уязвимостями и сегфолтами. Упоминать надёжность плюсов и KDE - это вообще анекдот.

нету критически важных библиотек

Это каких?

Упоминать надёжность плюсов и KDE - это вообще анекдот.

Упоминать надежность плюсов — это, действительно, анекдот. Ибо язык специально создавался таким, чтобы дать разработчику возможность делать то, что он (т.е. разработчик) хочет. Хочет верить в то, что malloc никогда не возвращает NULL — пожалуйста. Хочет кастовать char* к int* — нет проблем.

Так что надежность программ на C++ определяется программистом, а не языком. Считает программист, что исключения зло, шаблоны слишком сложны и не должны использоваться в «промышленном» коде, а STL — это вообще говно, ну так и качество программы будет соответствующим. Только виноват, почему-то, будет инструмент.

Судить о надежности по огромному OpenSource проекту — это тоже достаточно специфический взгляд на происходящее. Надежность, как и качество ПО, — это вещи, требующие и инвестиций, и дисциплины. И с тем, и с другим в OpenSource, по объективным причинам, довольно печально.

Кроме того, кидать какашки в KDE можно будет после того, как что-то подобное будет написано на Rust-е. Пока что жизнь показывает, что на C++ проекты масштаба KDE можно создавать, а вот про Rust в этом плане ничего не известно.

Спасибо. Я в курсе. Это был ответ на унылый вброс. Не стоило воспринимать его серьёзно.

С другой стороны GNOME начинают переписывать на Rust. Посмотрим, что получится.

Проблема С++ не в том, что он кривой, а в том, что людей умеющих на нём писать - единицы. Rust решает эту проблему с минимум затрат. Как со стороны разработчика, так и со стороны CPU.

Rust решает эту проблему с минимум затрат. Как со стороны разработчика, так и со стороны CPU.

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

Уже обсуждали же этот вброс. Всё разжевано тут:

https://news.ycombinator.com/item?id=12474445

https://www.reddit.com/r/rust/comments/5295nf/why_im_dropping_rust/

Да ладно. Фанаты Rust-а дружно сказали чуваку: ты мудакламер и так делать нельзя. Только самого главного не поняли: он хотел сделать так, как ему проще и удобнее. Раз на Rust-е это не получается, то ну этот Rust в /dev/null. И таких чуваков, которые будут смотреть на проблему со своей колокольни, а не с позиций настоящих растоманов, будет еще немало.

Это верно только про реддит. На HN не одни растоманы.

Ну и ваш тезис не верен. Человек с тем же успехом мог наехать на C++, ибо в нём нет привычного ему GC. Значит и он в /dev/null.

В данном случае всё честно: человек выбрал неверный инструмент и разочаровался в результате. Rust можно заменить на любой другой язык - суть не поменяется.

Значит и он в /dev/null.

Так и есть. Там, где нужен GC, С++ в /dev/null.

У Rust-а, как здесь, на LOR-е неоднократно говорили, своеобразный взгляд на ООП. Поэтому Rust идет в /dev/null для всех, кому такой взгляд не нравится.

А так же для тех, кому кажется диким использовать unsafe для реализации двухсвязного списка.

А так же для тех, кому не нравится взгляд Rust-а на многопоточность.

И т.д. и т.п. Так что нужно еще посмотреть на то, как оно на самом-то деле пойдет. Пока что-то даже сама Mozilla не может взять и Servo в продакшен выкатить. Это успех, однозначно.

Опять таки, языков не похожих на C++ полно, но это не мешает им жить. То, что раст не похож на C++ не делает его плохим.

Ну вот OCaml, например, живет, да. Только что-то не видно на нем ни браузеров популярных, ни СУБД, ни того же KDE.

А если сравнивать востребованность OCaml-а и, например, востребованность Java или JavaScript, то и жизнью это назвать сложно.

Пока что-то даже сама Mozilla не может взять и Servo в продакшен выкатить

Вы знаете сколько людей работает над Servo и сколько над Firefox? Какой у них бюджет? Какие у них планы? Нет? Тогда ваши тезисы об «успехе» беспочвенны.

Если верить репе на гитхабе, то Servo пишет человек 10. Сам проект создали 4-е года назад, а активно пишут последние 2. Пока всё идёт своим чередом.

Ну если Servo еще не в продакшене, то ethereum вполне себе и сейчас самой стабильной его реализацией признана реализация на расте.

Но Java(Script) тоже не похожи на С++ от слова совсем. Но они намного популярнее. Для большинства JS разрабов C++ - страшный сон. Значит его нужно в /dev/null.

Планы Mozilla сейчас сосредоточены вокруг Quantum: http://www.opennet.ru/opennews/art.shtml?num=45385 Что наводит на мысль о том, что сам Servo оказался тупиковым экспериментом и Mozilla будет внедрять код на Rust-е в свой браузер очень осторожно и по чайной ложке. При том, что Mozilla-овцы постарались обкарнать C++ по самое нехочу:

Mozilla code only uses a subset of C++. Runtime type information (RTTI) is disabled, as it tends to cause a very large increase in codesize. This means that dynamic_cast, typeid() and <typeinfo> cannot be used in Mozilla code. Also disabled are exceptions; do not use try/catch or throw any exceptions. Libraries that throw exceptions may be used if you are willing to have the throw instead be treated as an abort.

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

Для большинства JS разрабов C++ - страшный сон. Значит его нужно в /dev/null.

На данный момент так оно и есть.

Выводы у вас есть, а вот их правильность под сомнением. Слишком много имхо.

Что наводит на мысль о том, что сам Servo оказался тупиковым экспериментом

Всё правильно сделали. Лучше плавно переписывать, чем писать с нуля.

Mozilla старательно наживали себе геморрой

Вырубили всё говно C++ и правильно сделали.

Не получилось, видимо, из Rust-а серебрянной пули.

Еще использовать не начали, а уже не получилось. Ну вы ванга.

Лучше плавно переписывать, чем писать с нуля.

Ну т.е. написать что-то большое с нуля не получилось даже у Mozilla.

Вырубили всё говно C++ и правильно сделали.

Да я знаю уже почему вам в C++ некомфортно, а в Rust-е норм: исключения говно, STL говно и т.д.

Еще использовать не начали

Кто ж виноват, что сама Mozilla за все годы, вложенные в Rust, ничего на нем не сделала?

наводит на мысль о том, что сам Servo оказался тупиковым экспериментом

Я не знаю цели Servo, но прямо указывалось, что прямое замещение Firefox такой целью не является. А в остальном - эксперимент продолжается, над Servo работает всё больше людей.

Ну т.е. написать что-то большое с нуля не получилось даже у Mozilla.

Ваши интерпретации в свою пользу не перестают удивлять.

исключения говно, STL говно и т.д.

Это факт.

Кто ж виноват, что сама Mozilla за все годы, вложенные в Rust, ничего на нем не сделала?

Какие годы? Повторяю: «проект пишут 2-а года».

не получилось даже у Mozilla.

Еще раз: «servo пишет человек десять». Это явно не «вся Mozilla».

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

в AMD правила были еще жестче с драйвером именно потому, что сумасшедших разрабов хер остановишь если дать им волю.

Они их запретили по всем известным причинам: тормоза (на x86_64 полегче, но всё равно), раздувание бинаря, неочевидность, поддержка до недавних пор была отвратная.

Ваши интерпретации в свою пользу не перестают удивлять.

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

Еще раз: «servo пишет человек десять». Это явно не «вся Mozilla».

10 человек, минимум, 2 года. На супер-пупер языке. Ну говорю же, успех, очевидный.

как я понимаю, эксепшены они запретили не от хорошей жизни

Запретили из-за того, что корни их разработок идут еще из древнего Netscape-шного кода, который писали хрен знает когда и когда поддержка C++ных исключений была еще не во всех компиляторах.

Static linking... не - не слышал!

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

Ты серьёзно думаешь, что желающих и умеющих ковыряться в паскале больше чем в С и С++?

Тех кто залез бы подкрутить в паскаль без мегакомпенсации за вредность, думаю что больше. Всё-таки паскаль развивается во многом из любви к искусству, без серьёзного финансирования корпорациями. Другое дело, если автор программы накрутил в ней тонны фич ООП и новшеств компилятора просто ради крутизны и ЧСВ, то такой код тоже сложен.

Так что надежность программ на C++ определяется программистом, а не языком.

Ну не совсем. Всё-таки от языка зависит то, насколько легко допустить ошибку случайно. Одно дело когда опечатался или просто написал ерунду, а компилятор молча проглотил, другое когда он бьёт по рукам и требует более явно намерения выражать. Да, в последнем случае тоже нет гарантий, но надёжности слегка побольше.

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

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

исключения говно

Скорее вкусовщина.

STL говно

Факт. Оглянитесь вокруг. У остальных популярных языков (окромя недоязыков типа JS) std просто конфетка. В то время как у C++ страх и ненависть. А у Rust вообще даблкилл, ибо у него прекрасная std + cargo.

На супер-пупер языке.

Вы вместе с GoodRiddance вообразили себе какой-то свой rust. Он не супер-пупер. У него куча своих проблем, которые понемногу фиксят. Но уже сейчас для многих задач он в разы лучше С++.

2 года.

Расскажите свою историю успеха о написание такого титанического проекта, как браузер, за 2-а года.

Только самого главного не поняли: он хотел сделать так, как ему проще и удобнее.

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

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

Это верно только про реддит. На HN не одни растоманы.

На реддите тоже.

Честно говоря, не понял. С++ ведь тоже не выставляет наружу «нестабильные функции из ядра» - это всё детали реализации стандартной библиотеки. И чем тогда это отличается от «прослоек»?

А много в той стандартной библиотеке есть, если на каждый чих надо подключать зависимости? Фактически, стандартная библиотека, это почти аналог модуля system, только типов данных там поменьше, что побуждает либописателей использовать переменные нестабильной длины. А самые нужные системнозависимые фичи у FPC сконцентрированы в модулях unix, linux, windows, dos. В первых двух не много чего и есть, но вроде как хватает, а последний такой няшка, что на нём можно писать и в линуксе. Весь линукс сжался до двух модулей, а виндовс до одного:) Есть ещё особенности - модули-прослойки компиляются тем же компилятором, что и весь остальной код, а стандартная библиотека, она внешняя, из допустимого диапазона версий.

Там, где нужен GC, С++ в /dev/null.
А так же для тех, кому не нравится взгляд Rust-а на многопоточность.

И вот тут ты подменяешь понятия. Одно дело «нужно», другое - «не нравится». Второе вполне может быть причиной выбора, но объективным оно не станет. И на джаве можно не пользоваться GC,а выделить память один раз и потом вручную в ней копаться. И такое решение может быть оправданным, если, конечно, не делается просто чтобы не писать на «ужасном С++».

Пока что-то даже сама Mozilla не может взять и Servo в продакшен выкатить. Это успех, однозначно.

Дык, растовый код уже в фаерфоксе имеется. А Servo - это ведь не тупо «переписать на расте», а ещё и про распараллеливание всего чего можно. Мне что-то подсказывает, что на любом другом языке оно тоже быстро не взлетело бы.

Скорее вкусовщина.

Ну окай. Хотя симптоматика характерная.

В то время как у C++ страх и ненависть.

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

cargo.

Ну вот cargo у Rust-а — это действительно киллер-фича по сравнению с C++.

Но уже сейчас для многих задач он в разы лучше С++.

Если из C++ выбросить все хорошее, что в нем есть, а потом еще и добавить C++хейтерства, то да, на Rust-е для C++неосиляторов будет в разы лучше и проще. Это уже многократно доказывалось, хоть с ObjectPascal, хоть с Java, хоть с C#.

Расскажите свою историю успеха о написание такого титанического проекта, как браузер, за 2-а года.

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

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

Что наводит на мысль о том, что сам Servo оказался тупиковым экспериментом и Mozilla будет внедрять код на Rust-е в свой браузер очень осторожно и по чайной ложке.

Меня оно наводит на совсем другие мысли.

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

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

Всё-таки паскаль развивается во многом из любви к искусству, без серьёзного финансирования корпорациями

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

Другое дело, если автор программы накрутил в ней тонны фич ООП и новшеств компилятора просто ради крутизны и ЧСВ, то такой код тоже сложен.

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

В то время как у C++ страх и ненависть.

И что такого ужасного в плюсовой стандартной библиотеки? Ну кроме банальностей про строки - с ними всё понятно.

Речь шла о том, что в KDE можно камнями кидаться, потому что KDE (да и вообще проекты масштаба KDE и больше) на C++ есть. И как себя ведет в проектах большого масштаба и сложности, уже известно.

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

Так что Rust-оманам либо следовало бы перестать бросаться камнями в большие C++ные проекты, либо показать, что Rust позволяет делать что-то подобное.

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

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

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

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

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

Есть всякие там STLport.

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

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

либо показать, что Rust позволяет делать что-то подобное.

Время покажет.

Хотя любой результат никак не помешает кидаться какашками, причём обеим сторонам. (:

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

Все так, но поинт был в другом: язык C++ специально был сделан таким, что у пользователя есть широкое поле для свободы. Откуда и получаются вещи вроде:

const std::string & make_name() {
  std::string name;
  name = ...;
  return name;
}

struct valid_name {
  const std::string & name_;
  valid_name(const std::string & name) : name_(name) {
    ensure_name_validity(name_);
  }
};
valid_name make_name() {
  std::string name;
  name = ...;
  return valid_name(name);
}

// Определяется и реализуется в другой единице трансляции.
// Возможно, в другой so/dll-ке.
struct valid_name_holder {
  std::string name_;
  valid_name_holder(const std::string & name);
};
// А в совсем другом месте...
valid_name_holder make_name() {
  std::string name;
  name = ...;
  return valid_name_holder(name);
}

God bless C!

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

Пример должен иллюстрировать «сложное» время жизни? Тогда он мне как раз кажется удачным для раста.

Пример должен иллюстрировать «сложное» время жизни?

Пример иллюстрирует грабли, которые есть в C++. Но которые, при этом позволяют во многих случаях не забивать себе голову деталями по поводу владения.

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

Дык, valid_name_holder и valid_name_holder make_name() на расте точно так же тривиально будут выглядеть:

struct ValidNameHolder {
    name: String,
}

fn make_name() -> ValidNameHolder {
    let mut name;
    name = ...;
    ValidNameHolder { name: name }
}

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