Google профинансирует работу над Rust for Linux

Да никто никого не убивает. Вон ещё Делфи не убили, а тут уже про С++ разговорчики в строю.

Про то что Rust убил С++, это выдумка плюсовиков чтобы легко было в срачах опровергать лёгкое для битья утверждение которое они сами придумали и против которого борцуют

Ну, я когда-то как глупенькая школьница считал что плюсы лучше Фортрана. С удивлением читал в статье почему это не так. Но это никак не объясняет твою попаболь от того, что похоже весь мир хочет оклеветать твои любимые плюсы. И «недопрограммист» был прав, действительно в плюсах нет рефлексии в рантайме, но при этом плюсы всеми силами провоцируют на использование наследников вместо родителей. Такой вот нелепый язык, ни в ООП нормально, ни в красную армию. С одной стороны его поджимают сделанные правильно шарпы с жабами, с другой - не пытающийся прикидываться ООПшным Раст. И там и там можно сделать, например, сериализации, где-то в рантайме, где-то в компайлтайме. В плюсах нельзя, для макросов он слишком гордый, для рефлексии тоже.

Это к тому, что ваш пост мне «по душе» …

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

Публиковать пока ничего не буду.

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

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

Надо не только лишь говорить. А то собирать всё это из кусочков анонимных постов — это всё равно, что бодаться с борроу-чекером: разбираться почему «вот эта вот переменная ну никак не может быть проброшена воооон туда».

Извини дружище, пока так …

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

даже меньше

Собрать ядро быстрее, чем за 30 секунд?

а клятые ржавофанатики хотят отобрать эту радость

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

# pacman -S rust

или

# apt install rustc cargo

должно помочь…

Можно и дальше даже писать на rust создав Makefile без всяких скачиваний гигабайтов для hello world с cargo :)

Шутка

а клятые ржавофанатики хотят отобрать эту радость

Их уже «вычислили» см. https://www.linux.org.ru/add_comment.jsp?topic=16377200&replyto=16379277

Они

Если так задуматься - в штаны сутся и на форумах срутся, на улице теряются, ещё и памятью управлять как-то надо

Одни клоуны проспонсируют другой трэш. Эт чё, новость что ли?? И так понятно, «дураку - дураково», в библии ещё сказано.

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

твою попаболь

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

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

Про то что Rust убил С++, это выдумка плюсовиков чтобы легко было в срачах опровергать

Ну вот конкретно в данном случае это был тезис человека, продвигающего Rust против C/C++.

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

Хы, я в такие моменты представляю типичного толстопузого попа, херачищего в гору крестик освятить… прямо экспедиция на месяц :-D

У нас здесь тоже поп от Ц++ появляется, махает стандартами, борется с инакомыслием, Цпарь.

Google профинансирует работу над Rust for Linux

В inet имеются статьи тех кто использовал Rust не один год.
Скорее всего их мнение ценнее например моего во много раз …
А пока суждение такое.

Тебя C/C++ устраивает?  
Да.  
Вот и используй их. 

Прямо уж конец шоу. Прямо уже софт нельзя написать без лапши вроде boost или что там.

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

Так не получается. Они почему-то видят в Rust опасность, против которой нужно воевать.

Так не работает. Они почему-то видят в Rust опасность, против которой нужно воевать.
Типа

Призрак ходит по Европе.  
Призрак Rust-a.

Кодовую базу терять не надо, вон она лежит, на сях написанная. Работает, компиляй и вызывац. Что теряется от нового языка - так это возможность копировать пятистрочные куски со старых проектов или со стековерфлоу. Иначе нельзя, ну добавишь ты в плюсы какой-нибудь gsl и напишешь к нему утиль, который в соответствии с этой разметкой будет проверять, вот тут вся твоя наработанная кодовая база и посыпет ошибками. И дальше либо переписывать, либо отключать валидацию, или изначально делать её opt-in. Ну а дальше все очевидно, приходит джун на проект, а там 2 файла на C++, в одном из них пользоваться X можно, а в другом нельзя, потому что этот файл создан на 3 года позже, когда новые практики уже ввели. И всё это ради того чтоб формально спасти сишечку.

Странным решением было создание C++. Тогда как-то дико повезло и на фоне моды на ООП прокатило. Новые попытки гальванизировать труп уже не идут, Страуструп пишет книжки о том, как правильно не пользоваться наследием C, Статтер вместе со Страуструпом с помпой представляют борроучекер для плюсов и толку ноль.

Конечно. Знание ассемблера это очень важно.

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

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

В смысле «если плохо с языком знаком, то сложно понимать»? Да. Но компилятор поправит если не так понял.

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

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

«Ворнинги» работают.

Давай без кавычек. Человек написал про ворнинги компилятора. Я ответил. Если сейчас под ворнингами мы уже вплоть до нанятого тестировщика станем понимать, то далеко мы не уедем.

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

Давай без кавычек.

Давай. Дополнительные инструменты и встроенные проверки компилятора С++ позволяют вылавливать значительное количество ошибок. А линейные типы — не панацеля, так как позволяют отлавливать только часть ошибок из всего множества. И они не заменяют эти самые инструменты валидации и верификации. Кроме того, unsafe-блоки никак не локализуют возникший UB внутри себя. Если у тебя покорраптилась память, то проявится это далеко за пределами блока unsafe.

Я конечно не интересовался, но вроде нет…

Там его вроде подпилили…

пишут, многим нравится…

Я не пишу на раст, и не спец…

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

нет такой штуки, как C98, есть C89 и С99. Просто оставлю это здесь: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust Почему такой безопасный rust не помешал написать все эти CVE (иногда даже с double free)?

Очень сомневаюсь. На 96 потоках ты скорее всего получишь тот же результат. Компилятор раста, вместе с LLVM и почти всем тулингом на моём Ryzen 4700U, 16Gb DDR4, NVMe компиляется минут за 30-40. Делишь на 12 (96 - в 12 раз больше) и получается 3-4 минуты. Так что не надо пороть чушь (:

При том даже такое сравнение некорректно.

Всё, что Unsafe-блоки нам дают, это облегчают работу UB-санитайзеру,

Человеку ищущему ошибки они еще больше облегчают работу, плюс сильно уменьшают необходимый объем тестов.

Ты там выпил что ли? LLVM и компилятор раста но нормальном языке сделаны. Реальность немного другая - берёшь 30-40 и умножаешь на 10-20 и получаешь время компиляции аналогочного расто проекта.

Давай. Дополнительные инструменты и встроенные проверки компилятора С++ позволяют вылавливать значительное количество ошибок

Безусловно. Например если я попытаюсь передать функции, принимающей параметром ссылку на t1 объект типа t2, то компилятор это заметит. А знаешь почему? Потому что я, в соответствии с неплохим языком C++ объяснил ему про типы. Это очень полезно, в частности защищает от повреждения памяти если размеры t1 и t2 отличаются. Но это не гарантирует от всех ошибок. Поэтому добавляют тесты, санитайзеры. Нужна ли вообще система типов? Ради объявления структур и прототипов функций компилятору C/C++ приходится включать заголовочные файлы и тратить время на компиляцию включённого, зачем, ведь есть IDE которая прототипы функций может кэшировать и подсказывать названия параметров, а вместо структур передавать адреса буферов. Ну и раз в неделю прогонять санитайзера, который отловит проблемы с типами.

Или нет? А если нет, то почему информация о том, что вот эти 64 бита указывают на char, а эти на структуру должны отражаться в системе типов, а вопрос о соответствии лайфтаймов - нет?

Сейчас ещё будет вопрос, требующий напряжения всей твоей демагогической мысли: как быть с enum class? Были уже нормальные енумы, удобные, и по сути тот же инт, зачем добавлять в систему типов контроль за тем, из правильного ли мешка были взяты константы? Если я ошибся и передал FOO_DEFAULT вместо BAR_DEFAULT, то это почти наверняка безопасно, потому что и там и там это 0, а если передал Foo::Default вместо Foo::Bar, то это наверняка серьёзная ошибка, которую enum class не поймает. Следовательно, проблема «передали не ту константу» решается типизированными перечислениями только отчасти. Следуя твоей логике, из этого следует, что enum class не нужен. Удаляем?

А линейные типы — не панацеля, так как позволяют отлавливать только часть ошибок из всего множества.

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

Кроме того, unsafe-блоки никак не локализуют возникший UB внутри себя.

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

Извините Вы молоды ? Вы в курсе что юних это по сути Си

Как я и писал, чем дальше в лес тем больше бреда.

Во-первых, какой юникс? Нет давно никакого юникса, последний из этого рода под именем freebsd где-то в заповедниках обитает.

Во-вторых, собственно на unix, работавший на машинах с ~64 КБ памяти сейчас и смотреть. Те соображения, которые были истинны при выборе языка для того маленького unix’а для современных сложных систем уже неактуальны.

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

О мой бог, ты даже не вдупляешь разницу между enum’ами, и тонкости их использования. Твой опыт использования Ц/Ц++ стреимится к нулю.

Когда аноним пишет «ты ничего не понимаешь», и при этом не может сформулировать суть претензии - это сильно. Ты меня победил

Ты сам всё сформулировал. Любой, кто имеет минимальный опыт поймет какое ты трепло. Вот это даже не скомпилится:

enum A{a};
enum B{b};
void f(A q) {}

int main() {
    f(b);
}

Конечно ты сейчас начнешь съежать и говорить, что имел в виду не то, ожидаемо.

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

Ты не поверишь. Код пишут программисты. За компиляцию отвечают программисты инфраструктуры. А запускают тестировщики.

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

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

Даже Иисусу подсрачники в начале давали, просто за то что он новый.

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

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

Раз начал трепаться дальше - ответь, для чего ставят тип функции, которая принимает enum == простому int’у вместо самого enum’a?

тип функции, тип параметра функции

Или нет? А если нет, то почему информация о том, что вот эти 64 бита указывают на char, а эти на структуру должны отражаться в системе типов, а вопрос о соответствии лайфтаймов - нет?

В С++ будут лайфтаймы. С ними лучше, чем без них.

Следуя твоей логике, из этого следует, что enum class не нужен. Удаляем?

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

Я так же сказал, что в своем коде я полагаюсь на расширенные техники валидации и верификации. А не только на безопасность памяти. Если мне нужно, я могу написать плагин к Clang, который будет выполнять дополнительные статические проверки, специфичные для моего приложения. Могу так же написать свой санитайзер.

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

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

Два момента.

1. Про просачивание UB я сказал потому, что есть популярное утверждение, что код на rust безопасен. Нет, он безопасен лишь на столько, на сколько безопасны блоки unsafe.

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

Если же кода в unsafe много, скажем, 10% приложения, и он нетривиален, то толку от такого разделения будет не сильно много.

Так же я указывал на свой опыт, когда у меня в unsafe попадало много нетривиального кода, так как у меня прямая работа с памятью, которая не ложится 1 в 1 на систему типов С-подобных языков.

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

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

Если ты с этим не согласен - жду объяснение, почему такую полезную фичу отключили.

Раз начал трепаться дальше - ответь, для чего ставят тип функции, которая принимает enum == простому int’у вместо самого enum’a?

Я знаю 2 ответа. Один - который ты задумал. Второй - правильный.

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

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

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

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

typedef int mode_t;
enum mode_e : mode_t {
   e_mode_read,
   e_mode_write,
   ...
};
void fn(mode_t m);
int main() {
   fn(e_mode_read|e_mode_write);
}

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

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

Ещё раз - ты тему не понимаешь, сними корону и не считай всех этих Сишников тупыми ретроградами.

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

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

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

Ну а добавление лайфтаймов в плюсы ничего не даст. Это будет опциональная (для обратной совместимости) фича, которую надо дописать чтоб потом компилятор ел тебе мозг. И вообще ты, как опытный программист на C++, не обязан знать новые стандарты, да и стабильный компилятор это не поддерживает, короче будет овердофига отговорок почему не надо. Сколько лет приучали вместо qsort std::sort использовать? Это при том, что std::sort проще.

Ну вот есть проект Мозилла Файрфокс, который понемногу переходил на Раст, и чего-то кодовую базу они не теряли.

Я теряю, потому что у меня много TMP. Можно было бы обернуть это всё макросами и так переиспользовать, но я уже имею опыт много-языковой разработки, и я решил, что проще запилить линейные типы в С++ в виде плагина для Clang, чем городить вот это вот всё.

Опыт других людей может, конечно же, отличаться. Потому что у меня уже есть опыт хакания Clang, и для меня это не проблема. Но я где-то полгода одним только Clang и занимался: разбирался и изучал. Не все могут себе это позволить. Т.е. я нормально отношусь к аргументу, что в Rust мы «вот это вот всё» получаем сразу из коробки, сразу поддерживаемое и развиваемое сообществом. Это валидный аргумент. Ну так и эти инструменты, о которых я говорю, можно тоже социализировать.

Ну а добавление лайфтаймов в плюсы ничего не даст. Это будет опциональная (для обратной совместимости) фича, которую надо дописать чтоб потом компилятор ел тебе мозг.

Так допишем, какие проблемы?))

Сразу скажу, что Clang-ом не обязательно компилировать код. Достаточно просто проверять.

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

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

А вот ты на мой вопрос не ответил: почему такую полезную фичу убрали? Почему не завели, я не знаю, enum union, который сохранял бы строгий тип но при этом имел бы битовые операции? Ты ведь не думаешь, что в комитете не нашлось никого кто про такой хак не слышал?

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

Ты уже показал, что теоретик, остановись. Никто обычный enum не выкидывал, это твои фантазии, я прямо сейчас в проекте юзаю как enum, так enum class. И все эти нюансы понимаешь на практие, которой у тебя просто нет. Ты прочёл пару статей каких-то «умных», прочел методичку и пошёл тут всем рассказывать, что твой «папа» самый-самый, работает в Газпроме, каратист и медведя убивает с одного удара. Клоун.