Эмма Смит (Emma Smith) и Кирилл Подопригора (Kirill Podoprigora), входящие в число ключевых разработчиков Python (core team), опубликовали предварительное предложение (Pre-PEP) о постепенном добавлении возможности использования языка Rust в кодовой базе CPython, эталонной реализации языка программирования Python. Изначально Rust предлагают использовать для необязательных модулей стандартной библиотеки, размещаемых в директории Modules/. В перспективе, к версии Python 3.17, Rust может стать обязательной зависимостью при сборке CPython...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64275
RIPэтот конкретный случай по многим признакам смахивает на заказной саботаж
В каждом втором крупном питон проекте уже есть зависимость от PyO3, для меня удивительно что Rust в ядре только сейчас начали разрешать
requests зависит от cryptography, cryptography зависит от Rust, но таких зависимостей гораздо больше
>В каждом втором крупном питон проекте уже есть зависимость от PyO3сколько нам открытий чудных
Что ты тут открыл-то? Каждый первый крупный пихонопроект рекурсивно зависит от всех лефтпадов с пиписки и еще десятка напрямую из гитшлака. Очень странно, если хотя бы куда-нибудь не затянет и хрустоподелку.А что на пихоне просто не надо писать крупные проекты - знают только первоначальные авторы hg и trac. Но они уже никому не расскажут, дело закрыто за отсутствием улик.
Самые лучшие утилиты для питона написаны на rust. Например ruff и uv.
Кто решил, что они лучшие? По каким критериям?
Скорость
Функциональность
Минимум ложных срабатыванийЕщё вопросы?
Все так
Все не так
Так ты и на эти не ответил.
Так кто решил, что они лучшие? Парочка опеннетных экспертов?
А теперь пруфы по каждому заявленному критерию или гуляй.
Всё продвижение rust в принципе смахивает на заказной саботаж.
Кто саботирует? Ради чего, какую конечную цель преследует(-уют)?
США, очевидно же. У них там требование госдепа писать только на безопасных языках. Конечно, питонистов никто это делать не заставляет, но без ржавчины они скорее всего потеряют в госзаказах, получении различных грантов и целевых выплатах. Вот поэтому сишные проекты и ринулись переписывать на хрусте. Выходит криво, косо, на зато можно сказать, что проект написан с использованием безопасного языка, а значит можно будет получить некоторое преимущество в борьбе за деньги спонсоров.
Чтобы заменить GPL софт своим с пермиссивной лицензией и перетащить контроль опенсурса на себя.
+ зарубежный товарищ major одобряет централизированный репозиторий карго.
опенсурс уже перестаёт быть опен: то там сырцы задерживают, то сям...
>опенсурс уже перестаёт быть опенНе перестаёт, а начинает. Свободное - это gpl и подобные, открытое - bsd, mit и подобное.
>то там сырцы задерживаютЗажимать исходники у открытого софта - это дело целиком и полностью правильное. Если вы не хотите зажатых исходников - выбирайте софт под свободными лицензиями.
боюсь спросить, а ты точно понимаешь термины open и free?
Упрощённо, да понимаю. Этого достаточно.
>боюсь спросить, а ты точно понимаешь термины open и free?Для начала, этот вопрос следует задать вам. Open идеален для корпораций, например Sony может абсолютно бесплатно взять FreeBSD и выпустить PlayStation. Выгода для Sony в том, что можно взять полностью готовую ОС, немного поправить под свои нужды, и выпустить, не делясь ни с кем. Столлман основал Free - код под GPL(и подобными лицензиями) нельзя просто так взять и забрать себе, им нужно обязательно поделиться. Засилье Open вместо Free как раз и приводит к текущей ситуации.
хоть кто-то понимает очевидные вещи
> Ради чего, какую конечную цельДля начала прочитай лицензию на компилятор.
Ассемблер, вернись!
> RIP
> этот конкретный случай по многим признакам смахивает на заказной саботажАндроидный самарт и любимый Firefox уже похоронил?
Да. Пришлось сменить платформу.
И kernel назло мамке выкинул поди?
Kernel и без Rust спокойно собирается.
> Kernel и без Rust спокойно собирается.Но а) Как бы это сказать... уже "не весь" и б) "они над этим работают"
> Да. Пришлось сменить платформу.На какую? iOS? Или может Posh? 😂
>> Да. Пришлось сменить платформу.
> На какую? iOS? Или может Posh? 😂java ME, чтобы Ъ же!
Использую кнопочный телефон, браузер Dillo, ядро 2.4.
Забавно, что ты не рассматриваешь вариант того, что раст более пригоден для разразботки и поэтому на него переходят. Потому, что хотят им пользоваться. Но нет, если ты лично с чем-то несогласен, значит остальная часть человечества должна также думать. Или саботаж. Других вариантов нет.Как же вам непросто жить.
> Как же вам непросто жить.Чтобы ты понимал, он гентушник.
Гентушник возмущается тем, что ему, оказывается, надо собирать софт. Ну надо же. Интересно, а где претензии к крестам(chromium) и сишке(https://www.opennet.dev/opennews/art.shtml?num=56449)?
> Гентушник возмущается
> а где претензии к крестам(chromium) и сишкеА он возмущается только тогда, когда удобно. А когда неудобно - уплетает за обе щеки Андроид с Файрфоксом.
И да, когда в Питон втянут Раст, наш гентушник таки продолжит кушать Генту, ведь она от него зависит (напр. portage на нем написан).
Лицемеры, что с них взять...
> Гентушник возмущается тем, что ему, оказывается, надо собирать софттем, что собирать софт на раст гораздо дольше при прочиx равныx (сравнивая с С/C++ pgo/lto), а бинарники получаются гигантскими из-за статической линковки и (не только из-за статической линковки, но и из-за принципиальной дефективности языка) тормознутыми
тем, что мне противно держать корпорастический рак, призванный поставить на карачки опенсорс, у себя на компе, но приxодится
рабочиx distcc/ccache для раста так и не завезли
> тем, что мне противно держать корпорастический рак, призванный поставить на карачки опенсорс, у себя на компе, но приxодитсяА почему при этом ты не называешь "корпорастическим раком" само ядро, почти 100% вклада вкоторое вклада делают сугубо те самые корпорации? Или ядро тоже противно, но когда альтернатив нет - можно и потерпеть?
потому что без расторака корпорасты не пытались лишить коммьюнити контроля над ядром. тебе и правда банальнейшие вещи нужно объяснять? попробуй немного подумать
> почти 100% вклада вкоторое вклада делают сугубо те самые корпорации?1) ты очень скучный
2) ты отвечаешь не на моё сообщение, а на свои ассоциации-нарративчики, связанные с моим сообщением
>тем, что собирать софт на раст гораздо дольше при прочиx равныxДоказательства? И да, включать время сборки компилятора во время сборки софта - неправильно. И да, померяйте сколько там llvm и gcc собираются, это тоже далеко не мгновенно.
>сравнивая с С/C++ pgo/ltoЯ очень сомневаюсь, что весь софт на расте на вашем компе будет собираться дольше хромого.
>а бинарники получаются гигантскими из-за статической линковкиС подключением. Почти все компилируемые языки собирают бинарники статически. Вы ненавидите почти все компилируемые языки?
>не только из-за статической линковки, но и из-за принципиальной дефективности языкаПро отладочные символы, я так полагаю, вы не слышали.
>тормознутымиОпять ноль доказательств
он непригоден для рантайма абсолютно. А разработчики могут у себя в слоновой башне свой питон сколько угодно разрабатывать, толк будет только если для рантайма пригодно. А растоподелки для рантайма абсолютно непригодны, ибо память жрут, это by design. Следующим этапом каждую либу в свою SEV-огороженную виртуальную машину засунут, "ради безопасности детей", а камни без SEV или аналогов заблаговременно дропнут.
> 12yoexpert
> RIPТы же говорил, что у тебя Gentoo? Что собираешься делать, когда в Python втянут Rust? Ведь Гента зависит от Питона.
страдать ещё больше, чем сейчас: браузер уже не собирается без раста
А что ты ожидал от тех, кто на зарплате у Майкрософта?
Хорошо, что у Python куча реализаций есть и не будет проблемой заменить в будущем на нормальную.
был бы смысл, питон уже давно менять на нормальный язык
>питон уже давно менять на нормальный языкПолностью поддерживаю. Лучше сразу писать на расте, а не использовать его через прослойки.
ОК, продолжу на C++.
Плохо что эти реализации совместимы только с хеловротами, и то не всегда.(потому что современный пихонокот на две строки на пихоне содержит гигабайт лефтпадов, большая часть из которых - бинарные)
с другой стороны - нехрен, конечно, такое и использовать.
Удобно, конечно. Потихоньку перепишут код на Rust и забудут об этом недоразумении под названием питон
FF-шку за более чем 10 лет переписать не осилили. В ведре пока тоже полностью опционально для жаждущих :)Но уже понятно что - додавят. GPL-ю готовят на выход, хорошо это или плохо ... ХЗ!
Как почти во всех проектах с передачей прав - пусть умрёт.
А вот как случайно у яжефины вышло - показало и нужность и робастность, причём не в тЭории а сугубо практически. Но ведь тоже убьют :( Причем RH будет впереди на лихом коне ...
Нихрена они не совместимы, большинство модулей совместимы только с CPython, более того, только с версия-специфичным API, а ограниченное, портативное между версиями, разрабы внедрять просто не хотят, даже если это делается элементарно добавлением пары флагов (но муторно в каждый проект их вручную добавлять). А во многие проекты внедрить Limited API так просто не получится. А сторонние реализации если и дают хоть какую-то совместимость с CPython в плане использования модулей, во-первых делают это исключительно с Limited API, во вторых даже так большинство скомпиленных модулей не работает. По факту наличие официальной реализации гарантирует, что большая часть кода будет прибита гвоздями к этой официальной реализации.
Сомневаюсь, что RustPython способен заменить оригинальный CPython,
но я не пробовал, так как не вижу особенно потребности.Если у вас есть время, то можете попробовать заменить и изучить
размер используемой памяти.
Как быть с тем, что llvm всё не научили генерировать нормальный код? В 100% случаев код у gcc был более адекватным и универсальным к входным данным. И бсолютно быстрее, где была возможность прогнать pgo. Привязываться к llvm несколько недальновидно.
Жди релиза gccrs
gccrs до релиза сильно дольше чем cg_gcc
> gccrs до релиза сильно дольше чем cg_gcccg_gcc не решает буквально ни 1 проблемы хруста начиная с экосистемы хайпующих токсиков "скачайте ночнушку" жестко пофигистичным к проблемам эксплуатации.
>экосистемы хайпующих токсиков "скачайте ночнушку"У сишников уже более чем полвека было, но альтернативы почему-то нет.
У сишников как раз таки альтернатива есть.
Покажите эту альтернативу без UB?
Сколько десятилетий раст разрабатывают? И пока ни одного стандарта. Вот ещё пару раз по столько.
> Жди релиза gccrsВот да, gcc-based фронтэнд было бы здорово. А все эти cogegen-gcc с проблемным rustc и его скачиванием ночнушек - не, спасибо. Пусть те господа 3930сами это юзают. Gcc куда более комфортный и дружественный по дефелопу тулчейн чем rustc, имхо.
> более комфортный и дружественный тулчейнНу вот и озаботились третьим "Е" в "ЕЕЕ" - чё непонятного :(
События пойдут лавинообразно. Будет "весело" ...
В случае проблем с LLVM отправить им патч и ждать ответного гудка. Гусей не трогать.
А никто и не привязывается, работа над gcc идёт параллельноhttps://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-38
> With LTO done, the remaining big tasks are:
> Finish debug info support
> Add support for other architectures
> Fix issues with unwinding
> Rustup distribution
Пропадёт же весь смысл LLVM IR, в котором есть строгая типизация, на которую, скорее всего, опирается Rust (очень похожи обозначения i8, i32 и т.д.).
> скорее всего
> очень похожи обозначенияТолсто.
А какая разница, какая типизация в LLVM IR для божественного Rust? Скажу по секрету - x86-машинный код вообще бестиповый, а в него компилируется и Си, и Раст
Разница большая, от типизации напрямую зависит производительность.
Питончик такой медленный, потому что любой его простой тип динамический и иммутабельный одновременно (sic!).
Это значит, что когда вы модифицируете int, вы не изменяете его, а создаёте новый объект того же динамического типа с той же ссылкой в памяти.
В Питоне да. Но какое это имеет отношение к божественному Расту или LLVM IR?
>Скажу по секрету - x86-машинный код вообще бестиповыйРазмер регистра и тип операции - дают тебе полноценный тип.
>>Скажу по секрету - x86-машинный код вообще бестиповый
> Размер регистра и тип операции - дают тебе полноценный тип.Очень условно и только для примитивных типов. Даже просто аналог сишного struct на асме соорудить - уже свербеж в дюзах.
Поэтому структурированные апи? С адекватным на глаз восприятием? Пониманием что и с какими параметрами куда сабмитится? Ух, это не про асм. ТАм и к сям то можно прикопаться на этот счет. В плюсах можно явно лучше. А на асме получается как правило неструктурированное спагетти - с столь же бесформенным "апи" к нему.
Но никакой проверки типа там нет, в том же смысле, какая есть в Си или в божественном Rust. Что видит команда процессора, то и перемалывает, покуда не упадет с рантайм ошибкой
> Пропадёт же весь смысл LLVM IR, в котором есть строгая типизация, на
> которую, скорее всего, опирается Rust (очень похожи обозначения i8, i32 и
> т.д.).Не полагается, в случае с llvm и полагаться нельзя, потому что когда он собран без assertions он валится в сегфолт на каждом шагу, проверок в нём полезных для пользователя нет.
Rust сам всё проверяет, и всегда выдаёт валидный IR.
> Rust сам всё проверяет, и всегда выдаёт валидный IR.Да-да, верим-верим: https://arxiv.org/html/2503.23985v1
>> Rust сам всё проверяет, и всегда выдаёт валидный IR.
> Да-да, верим-верим: https://arxiv.org/html/2503.23985v1И что тут про невалидный IR? Ни слова не вижу
Я думал типизация Rust как раз за счёт LLVM IR. Ну или хотя бы дополнительно контроллируется. Можно же на голом LLVM IR писать.
>Я думал типизация Rust как раз за счёт LLVM IR.Он даёт не типизацию, а контроль за размерами типов.
> Я думал типизация Rust как раз за счёт LLVM IR. Ну или
> хотя бы дополнительно контроллируется. Можно же на голом LLVM IR писать.У llvm очень простая типизация относительно Rust.
Нет, Rust генерирует валидный IR, и любая ошибка от llvm считается фатальной ошибкой компилятора rustc
Аналогично себя ведут другие компиляторы на базе llvm, к слову
LLVM свои входные данные не особо проверяет, только если его с assertions собирать, но в этом случае оно в несколько раз медленнее чем без них. По этой же причине на голом ir руками тоже не то чтобы удобно писать (не говоря уж про то что текстовое представление ir ломается регулярно, и ir надо строить либо через код, либо в бинарном виде)
>Как быть с тем, что llvm всё не научили генерировать нормальный код? В 100% случаев код у gcc был более адекватнымРазумеется, писать об этом на форуме, вместо того, чтобы писать код. Ведь тогда проблема возьмёт и решится, поныть не получится.
Скорее как быть с тем, что раст поддерживает только две платформы - x86_64 и aarch64.
В других новостях с серьезным фейсом они утверждают что другие платформы не нужны.То есть понял как у них мозги устроены: если у Раста чего-то не реализовано, то оно не нужно. Примерно как у яблочников.
Это ложь. Смотри доклад Яндекса ещё много лет назад - они от gcc отказались полностью. Сейчас, по крайней мере по моим бенчам, разрыв ещё больше увеличился.
Больше докладов смотри. Или открой дизассемблер и не пори чушь.
Открыл, LLVM генерирует более эффективный код.
Ты хотел сказать, более раздутый. Я вполне конкретно сказал, у gcc код более универсальный. Прогони pgo, и он будет более быстрый. Но это си. В случае с плюсами, у шланговой libcxx не получается столь же оптимальный код.
Мне особенно понравилось, как шланг внезапно начал вставлять неподдерживаемые инструкции в arch=native билды, признак профессионализма.
> Открыл, LLVM генерирует более эффективный код.Новые версии LLVM генерят - какую-то дичь, делая код тормозным, пухлым, а если совсем не повезло - вообще некорректным. Видимо гугло или эпл нагнало совсем индусов по объявлениям. И теперь оно - так.
Сейчас питон собирается в 4 потока ~5 минут.
Без прогона тестов?
> Без прогона тестов?Без. Сейчас попробовала снова после make clean - результат 1m1,692s
У меня питон2 10 минут после сборки тесты жевал, лол.
Но я не отключаю, мусть будет
тесты могут быть нужны только если ты собираешь питон для кого-то кроме себя. (а могут и не быть)> Но я не отключаю, мусть будет
ну да, буковки с цифирками бегут по экрану, можно делать умное лицо...
Ну, для второго питиона уже желательно бы, бо пакет уже выпилен и остался только в ауре.> ну да, буковки с цифирками бегут по экрану, можно делать умное лицо...
Поэтому ты так делаешь?
твой хеловрот либо работает, либо не работает. (причем во втором случае ты ничего сделать не сможешь)
Зачем ты расходуешь невосполнимые ресурсы планеты и свою жизнь на совершенно бесполезную хрень?Собрался - пользуйся. Не собрался или падает хеловрот - ну значит приехали, дальше ехать некуда, ищи замену своему васяноскрипту.
Чувак, попробуй немного потоньше, а?
Ну даже для меня слишком грубо работаешь.
Это местный алконавт предпенсионного возраста. Просто отфильтруй его посты в игнор через плагин User JavaScript and CSS. Я давно так сделал, чтобы меньше визуального мусора было.
Думаю, что задействую что-то аналогичное родному сворачиванию, скриптом, да
Внимание страусам - пол бетонный!(С)Заметание мусора и проблем под коврик ... чирЬевато ... ну как минимум сурпризами :)
> Ну, для второго питиона уже желательно бы, бо пакет уже выпилен и
> остался только в ауре.эээээ... а если ну вот контейнер под это дело взять, то...? Дай угадаю - взамуж не возьмут?
А зачем, если задача решается простой сборкой пакета?
> А зачем, если задача решается простой сборкой пакета?Ну так "вот это всё" начиная с, собственно, пакетных менеджеров как раз таки и городили, чтобы сборкой "по месту" не озадачиваться, не?
> Ну так "вот это всё" начиная с, собственно, пакетных менеджеров как раз таки и городили, чтобы сборкой "по месту" не озадачиваться, не?Неа, рекомендую покурить вопрос глубже.
Пакетники делали не для "ты не компилируешь дома" - иначе возможности сборки и опакечивания были бы не развиты - а больше для решения проблемы dependency hell, которая возникла буквально сразу после появления динамических библиотек (вообще безотносительно их формата: dll, so, чёрт-лысый) не виндовым способом, а грамотным разбиением софтового месива на пакеты
> для решения проблемы dependency hell, которая возникла буквально сразу после появления динамических библиотекВ итоге проблема осталась)
У вас не правильный жлиб-ц, идите в пень (с)> не виндовым способом, а грамотным разбиением софтового месива на пакеты
Но не получилось.
В винде запускается софт или игрушки которым десятилетия, а в лялексе как повезет.
Еще и на упаковывании пакетиков зачастую какие-то дебиаллинны сидят.
>У вас не правильный жлиб-ц, идите в пень (с)Поставь несколько glibc, в чём проблема?
>В винде запускается софт или игрушки которым десятилетия, а в лялексе как повезет.Есть как минимум NixOS.
>>У вас не правильный жлиб-ц, идите в пень (с)
> Поставь несколько glibc, в чём проблема?
>>В винде запускается софт или игрушки которым десятилетия, а в лялексе как повезет.
> Есть как минимум NixOS.Действительно.
>> Ну так "вот это всё" начиная с, собственно, пакетных менеджеров как раз таки и городили, чтобы сборкой "по месту" не озадачиваться, не?
> Неа, рекомендую покурить вопрос глубже.
> Пакетники делали не для "ты не компилируешь дома" - иначе возможности сборки
> и опакечивания были бы не развиты - а больше для решения
> проблемы dependency hell, которая возникла буквально сразу после появления динамических
> библиотек (вообще безотносительно их формата: dll, so, чёрт-лысый) не виндовым способом,
> а грамотным разбиением софтового месива на пакетыНу, причин, разумеется, было больше чем одна - но freebsd ports это "система сборки", а apt/dnf - пакетные менеджеры, которые про эту самую сборку знают вот "ничего" и вполне себе с этим живут.
> Ну, причин, разумеется, было больше чем одна - но freebsd ports это
> "система сборки", а apt/dnf - пакетные менеджеры, которые про эту самую
> сборку знают вот "ничего" и вполне себе с этим живут.Экспертиза так и прет. У пакетников есть и - скачка сорца, и билд депсов, и ребилд пакетов, внезапно. И свои хелперы-обвес для ребилда в соответствии с практиками дистро.
Просто это все - опциональное наглухо для эксплуатации и мир вокруг этого не вертится. Но если стало надо - пакет в дебиане пересобирается (возможно с моим патчем) парой команд буквально.
Одна из причин по которым BSD ушли на второй план. Не, никто не собирается ребилдить полсистемы на прод серверах или своих воркстейшнах во имя луны. Это неэффективно по времени и деньгам. Поставить бинарные пакеты и патчить только то что ну вот совсем капец как мешает - куда эффективнее.
>> Ну, причин, разумеется, было больше чем одна - но freebsd ports это
>> "система сборки", а apt/dnf - пакетные менеджеры, которые про эту самую
>> сборку знают вот "ничего" и вполне себе с этим живут.
> Экспертиза так и прет. У пакетников есть и - скачка сорца, и
> билд депсов, и ребилд пакетов, внезапно. И свои хелперы-обвес для ребилда
> в соответствии с практиками дистро.И ты снова - опять - как всегда - ничего не понял, но "несдержал-в-себе" важное-и-нужное, да? Граждани-иии-иин! Примерно во всем мейнстриме "система сборки" ОТДЕЛЕНА от "пакетного менеджера" и нахрен - совсем-и-полностью-наглухо - опциональна.
Пакетный менеджер сделан в общем-то очень во многом именно для того, чтобы с "системой сборки" не любится - в этом исходный тезис. Ну теперь-то понял, ну? Или кроме разжевывания еще и переварить нужно?
>> Без прогона тестов?
> Без. Сейчас попробовала снова после make clean - результат 1m1,692sДля чистоты эксперимента рекомендуется перед каждым прогоном чистить кеш ОС.
# sync; echo 3 > /proc/sys/vm/drop_caches
А в чем преимущество сборки перед уже готовыми пакетами?
> А в чем преимущество сборки перед уже готовыми пакетами?* Если ты хочешь сам собрать и не доверяешь тем, кто собирал. Например, если бутстрапишь систему.
* Добавить нужные опции при сборке. Вроде как для того же nogil нужно пересобирать.
Не всегда они есть, готовые пакеты.
Или есть, но древних версий.
Или есть, но реально хз от кого, на сюзевской OBS и "добавьте строчки в список реп".
Или нужно настроить пакет до сборки.
Есть некая программа, в ней есть питон. Однажды, после очередного обновления ты обнаруживаешь, что твой проект не полностью (полностью не) открывается из-за разности версий питонов. Да, питоны совместимы между собой чуть менее, чем никак. Дистры на этот случай сделали взаимоисключающую установку таких версий. Поставить старый питон из готовых пакетов ты не можешь - система начинает сносить всё по цепочке, включая пакетный манагер и далее...
>Дистры на этот случай сделали взаимоисключающую установку таких версий.2025 год на дворе, а вы до сих пор не осилили Nix. Стыдно должно быть.
> 2025 год на дворе, а вы до сих пор не осилили Nix.
> Стыдно должно быть.Костыль для разведения террариума в вашем зоопарке^W системе.
> Дистры на этот случай сделали взаимоисключающую установку таких версийЭто ложь. Везде без проблем ставятся несколько мажорных версий питона и параллельные деревья модулей для них.
Зачем вам вообще самим собирать питон? Есть же человеческие бинарные пакеты
> Зачем вам вообще самим собирать питон? Есть же человеческие бинарные пакетыАрчегенту...особенности, скажем так. Проходите мимо, не стойте у клетки - обитатели ээээ... активизируются ).
> Сейчас питон собирается в 4 потока ~5 минут.А то добавится ещё время сборки самого Раста.
>А то добавится ещё время сборки самого Раста.Вы на каждый проект раст собираете?
У меня пока нет ни одного пакета в системе на Раст. А так придётся его собирать после каждого выпуска.
Просто напоминаю что "поддерживаются Rust как минимум на уровне Tier 2" означает что хрустокомпилятор на этой платформе как-то вообще запускается. (И совершенно не означает что хотя бы запустится собранный для нее хеловрот)Причем чинить никто даже и не собирался.
Стандартный поток лжи от растохейтера.>Причем чинить никто даже и не собирался.
У тебя конечно же есть опрос всех разработчкиков из которого твои слова подтверждаются?
Стандартный пук от растофанатика. Открываем https://doc.rust-lang.org/beta/rustc/platform-support.html и читаем (растофанатик в английский умеет, или только на родном?):Tier 2 targets can be thought of as "guaranteed to build".
Перевод фразы "guaranteed to build" оставим деточке в качестве домашнего задания.
Собрать должны пользователи этих платформ, а не собираются они потому что их нет.
Спойлер: их и не будет, если софт туда не портировать.
эпически. Можно даже сказать, сказочно )
Однако, одного только раста с проверками боровов в дополнение к питону очевидно маловато для запуска скриптика на питоне. Очевидно, что в зависимостях должны ещё появиться как минимум жс и бонусом можно прилепить бейсик с паскалемА после - объявить о новом, инновационном и безопасном питоне 4, который ломает совместимость с 3-м не хуже, чем 3-й со 2-м. С тем нюансом, что, где есть питон - там гарантированно будут пакеты с упомянутыми ЯП и нередко более стабильные в плане обратной совместимости, а код в любом случае придётся переписывать
Ты забыл про node + v8, жс как язым можно и на встроенном интерпретаторе выполнять.При компилировании питоньего скрипта в .pyc в таком Питон4 небось нужно будет:
- каждый раз вызывать ноду, которая будет искать модули для себя в NPM (со свежими лефтпадами и вирусами)
- обновлённая нода будет БЕЗОПАСТНО выкачивать модули из pip, которые при развёртывании будут уже сами запускать в контексте себя по ещё одному экземпляру ноды для БЕЗОПАСНОЙ скачки своих зависимостей, конечно с обновлением своего набора лефтпалов из NPM и так рекурсивно для каждой ветки дерева зависимостей
- скрипт на ноде будет запускать и контролировать контролиующий его самого скрипт на питоне, который сгененрирует скрипт на пёрле, чтобы выполнить предварительные билдтаски
- файлы перед сборкой будут скормлены чекателю боровов, который достанет афиногенно-аффинажные мутные типы и померит им череп, а также степень "проснутости" кода. При нахождении лексемы типа "бро", "ниггер", "slave", "master", "три хандред бакс" и прочих - откажется собирать этот неполиткорректный код.
- после проверки ржавым проверяльщиком скрипт на джс должен будет запросить паспортные данные сборщика, его ЭП, его цели сборки, провести тест на политическую сознательность и соответствие текущим нарративам CNN и отправить все в ЦРУ. Если тест пройден не менее чем на 95% - сборка разрешается, иначе высылается зондеркоманда.
- после чего код собирается
- после чего прогоняются тесты
- после чего выполняются посбилд-таски на смеси из пёрло-джеэсного кода, формирующие выхлоп на похапэ
- после чего результат пакетируется
Жир начал сочиться из системного блока рано утром. Солнце только показалось из-за горизонта, запели первые утренние пташки, а под компом уже была порядочная жирная лужа. Я не понимал в чём причина этого явления и просто протёр лужу. Когда я включил компьютер, жир начал вытекать уже и из монитора тонкой но непрерывной струёй. Я терпел, я думал это пройдёт. Но всё же была непонятна причина столь активного жироотделения. Когда я зашёл на опеннет, жир потёк таким потоком что нужно было подставлять тазик под монитор и системник и выносить их каждые 20 минут. Потом я открыл эту новость... Это было нечто невообразимое, это был уже не поток, это было какое-то цунами жира! Он хлынул из компа, ничто уже не могло его остановить! Поток жира нёсся, снося всё на своём пути. Не знаю каким чудом мне удалось уцелеть, ибо от моего дома остались одни руины, двор сейчас похож на пустыню с барханами из жира. Погибли люди, некоторые лишились крыши над головой. Жироватт, что же ты наделал?
> Ты забыл про node + v8, жс как язым можно и на встроенном интерпретаторе выполнять.Никогда, даже в стршаных снах не думал что это скажу ... но может тогда typescript?
Его "отцам" бабла отвалили на написание нового не то компила не то транспила (на Go кстати) ...Чё-то с каждым месяцем typescript мне всё меньшим и меньшим злом видится ... может в отпуск пора? :-DDDD
раста достаточно, у него и у llvm проприетарная лицензия и рубильник на собственном репозитории библиотек
Похоже это намеренное внедрение расто-зависимости ради блага самого раста. Ведь раст нужно развивать ВСЕМ, потому раст это ПРАВИЛЬНО. А остальное - нет.
Сейчас тут начнется традиционный вой воинов против Раста и гентушников. В то время как все нормальные люди устанавсливают готовые бинари и от изначального языка им не горячо не холодно.
Если сидеть на конформистском железе типа x86_64, то да. А если на x86 (32-бит), то уже проблема. Не говоря про другие архитектуры (не буду упоминать всуе), где физически нет компилятора Rust (ну или есть, но работает чуть лучше, чем никак).
> типа x86_64Поправочка: уже x86_64_v2
> x86_64_v2Features match the 2008 Intel Nehalem architecture, excluding Intel-specific instructions.
v3 скоро уже 13 лет будет, окститесь.
Проблема в том, что расширения v3 отсутствуют в недорогих процессорах внезависимости от их года выпуска.
В каких? У AMD всё что на Ryzen ядрах (и что-то более старое, не помню) давно v3. Интел уже поплатился за своё вольное случайное разбрасывание инструкций по процессорам, недорогой Atom N100 v3 уже поддерживает.
> другие архитектуры (не буду упоминать всуе), где физически нет компилятора RustНа каких конкретно аохитектурах нет Раста, но есть CPython?
Не парься, есть только x86-64 и ARM-64!
Причём, хоть раст в этом и участвует, но он здесь даже не на третьих ролях ...
arm64 тоже нет (потому что нет такого процессора).apple M - есть (и дайте угадаю - скоро-скоро не каждая цифирка после М будет одинаково полезной)
> А если на x86 (32-бит), то уже проблема.Почему прблема?
Даже на официальном сайте есть бинари:
https://forge.rust-lang.org/infra/other-installation-methods...
Готовые бинари непортабельны часто по архитектурам, а собраны криво.
> Готовые бинари непортабельны часто по архитектурамБинари и не могут быить портабельны по архитектурам.
> собраны криво.
Ну да, левый васян-то знает, как собирать правильно.
Я будучи достаточно лояльным к Rust вынужден признать, что это уже ПЕРЕБОР. Начинают посещать мысли, что делается это всё умышленно.
Тут и так всё на поверхности: раст проталкивают и кнутом, и морковкой :) только непонятно, ЗАЧЕМ это всё - понятно ведь, что язык - тупиковый, его даже если всем миром расширять и использовать, гнилая концепция с указателями сводит всё на нет.
Понятно, _зачем_, но непонятно, КТО.У кого есть столько денег и людей?
Да в общем то картина уже практически прояснилась. Тут недавно были новости про количество Ржавого в Андроиде...
Ну раз NSA призывает использовать его, то понятно, что безопастный он для кого надо.
> Начинают посещать мысли, что делается это всё умышленноУмышленно внедряют Раст в CPython? А дожны были неумышленно внедрить, или что?
> Умышленно внедряют Раст в CPython? А дожны были неумышленно внедрить, или что?А что тобой такого не происходило?
Кодил кодил и тут бац!, случайно добавил новый язык программирования в проект.Судя по комментариям с анонами такое постоянно случается)
Python собирается избавляться от Global Lock. Так что внесение в зависимости языка, который позволяет серьезно упростить написание многопоточного кода это вполне разумный шаг.
> А что тобой такого не происходило?
> Кодил кодил и тут бац!, случайно добавил новый язык программирования в проект.Пострадавший шел, шел, и случайно упал своим лицом - прямо на мой кулак. И так 5 раз подряд, представляете?!
>Я будучи достаточно лояльным к Rust вынужден признать, что это уже ПЕРЕБОР.Лояльным? А что по вашему нужно - сишные дырени в каждой программе? Ну не хотят сишники писать нормальный код, хотя сишке уже больше чем полвека стукнуло.
Ну не хотят Ржавые писать нормальный код, хотя Ржавому уже 10 лет стукнуло.
https://www.opennet.dev/opennews/art.shtml?num=64093
https://www.opennet.dev/opennews/art.shtml?num=64226Исправил, не благодарите.
>Исправил, не благодарите.О, и это говорит человек, не осилившиый xml парсер. Вот вы не можете доказать несостоятельность раста в плане порчи памяти, поскольку гарантии раста ВНЕЗАПНО работают.
>>Исправил, не благодарите.
> О, и это говорит человек, не осилившиый xml парсер.xml парсер даже гугл не осилил из недавней новости...
> О, и это говорит человек, не осилившиый xml парсер. Вот вы не
> можете доказать несостоятельность раста в плане порчи памяти, поскольку гарантии раста
> ВНЕЗАПНО работают.Отлично сработали - только что завалили клаудфларь наповал по всему глобусу! Вместе с всем что она прикрывала, ня. Всего на пару гигабаксов планету поставили. А может и больше. Так что у титула самой дорогой ошибки в ПО - появился достойный контестант наконец!
Вы забыли привести доказательства.
> Ну не хотят Ржавые писать нормальный код, хотя Ржавому уже 10 лет стукнуло.Не хотят дыpяшечники писать нормальный код, хотя Дыpяхе уже полтиник стукнуло.
www.opennet.ru/opennews/art.shtml?num=64255
www.opennet.ru/opennews/art.shtml?num=64138
www.opennet.ru/opennews/art.shtml?num=64022
www.opennet.ru/opennews/art.shtml?num=63946Исправил, не благодарите.
>> Ну не хотят Ржавые писать нормальный код, хотя Ржавому уже 10 лет стукнуло.
> Не хотят дыpяшечники писать нормальный код, хотя Дыpяхе уже полтиник стукнуло.Вон там нормальный код от таких как вы - вырубил клаудспайварь и все что она закрывала на несколько часов. Чудный у вас там яп с его unwrap'ом. Не менее чудный сказ что оказывается, "это для девелопа" а в проде оказывается так ни-ни. Вот ща индусики будут код в прод переписывать vs dev, самим то не смешно с такого бреда?!
А так замечательный яп получился - по ревью и майнтенансу - мегакорп переписал, обделался с брызгами, и уделал в крапинку всех кастомеров. БезопасТно так с памятью поработали, заодно и в panic() здоровый прод вынесли...
> Начинают посещать мысли, что делается это всё умышленно.Так и есть. Не представляю, как мы раньше пользовались питоном без Rust'а.
С гилом
> Начинают посещать мысли, что делается это всё умышленно.Конечно!
Так же как каменные топор заменялся на железный.
Пахаря с сохой и лошадкой заменил трактор.
А самобеглые кареты вытеснили гужевые.Кончено это делается умышленно.
Да было и будет копротивление. Вон против машин даже запретительные законы принимали.
Но прогресс это не остановило.
>Так же как каменные топор заменялся на железный.Было бы верно, если С заменили бы на С++, а Rust - это такой же каменный топор, только с боровом, а он прекрасно заменяется умными указателями и семантикой перемещения.
Ну-ну. Полечи ещё гонки данных в меогопоточном коде, избавься от нулпоинтеров, поддежки модулей и готовых библиотек в экосистеме. потом думай чего ещё не хватает в крестах.
По крайней мере C++ программисты делают это за деньги.
А у раста это делает компилятор бесплатно. И кому же будут корпы денег платить за разработку софта? Команде дыряшечников и неопределённого поведения шликающих на коредвадуо, или паре хипстеров с макбуками, гоняющих клиппи по кругу?
Заменить везде питон на perl5 и делов то.
на C++. он сегодня куда удобнее чем раньше.
Действительно. Вот, свежий Visual Studio таких ли предупреждений навыдаёт на код из примеров, и так противится компиляции даже потенциально небезопасного кода. А Xcode это обычно спокойно скомпилирует. Прололчу про разработку в vim и подобном.
> обычно спокойно скомпилирует. Прололчу про разработку в vim и подобном.В что - vim? Там ругаться будет - компилер. И вот что-что а у gcc и clang статический анализ и варнинги очень сильно подтянули. В gcc аж вообще статический анализатор встроили в последних версиях.
Не говоря о том что билдсистема может делать что угодно - от пуска полдюжины сторонних анализаторов и рулес чекеров до какого-нибудь аплоада версии коверити на анализ.
А еще есть горе-"разработчики" которые без сильных мира сего не могут ступить и шагу, но почему-то мнят себя силой достойной внимания. Хотя являются - винтиками в корпоративных схемах, не более. Если все что вы можете это запустить "свежий visual studio" то в общем то - это не ваша заслуга. И в приличных местах вас соответственно не ждут.
>И вот что-что а у gcc и clang статический анализ и варнинги очень сильно подтянули. В gcc аж вообще статический анализатор встроили в последних версиях.Да? А покажи предупреждение, что разыменновывается нулевой указатель. Или как всегда лжёте?
>Не говоря о том что билдсистема может делать что угодноВот в том то и дело, что может делать что угодно, например не проверять ошибки вообще. А нужно строго наоборот - всегда проверять как минимум определённый список ошибок.
>А еще есть горе-"разработчики" которые без сильных мира сего не могут ступить и шагуА есть ещё настоящие сишники, понаделовшие кучу ошибок. В иксах до сих пор баги из 1990-ых исправляют, в 2025 году. Позор.
> Да? А покажи предупреждение, что разыменновывается нулевой указатель. Или как всегда лжёте?растодеточка, обновляй методичку.
```c
int main()
{
int *x = 0;
return *x;
}
``````shell
$ gcc a.c -Werror -Wnull-dereference -O2
a.c: In function ‘main’:
a.c:4:16: error: null pointer dereference [-Werror=null-dereference]
4 | return *x;
| ^~
cc1: all warnings being treated as errors
```
> -Wnull-dereferenceА без этого костылика сможешь?))
Вы даже определиться не можете какой знак у обычного char, о чем с вами еще говорить)
>А без этого костылика сможешь?))Всё просто: нужно просто попросить сишников провести аудит каждого пакета и попросить отчитатся о каждом флаге сборки. Хотя-бы каждого, что есть в NixOS, а там дальше видно будет.
>растодеточка, обновляй методичку.Вот вы знаете, я вот как возьму, да как проверю
int test(int* x)
{
return *x;
}int main()
{
int *x = 0;
return test(x);
}Вот мне интересно, я даже флаги компиляции не трогал, а предупреждение куда-то исчезло. Не подскажите куда?
CppCheck, прямо в среде разработки:/home/<...>main.cpp:264: Possible null pointer dereference: x
А вот такое чудно скомпилилось растом, без всяких предупреждений, и благополучно вылетело при старте:
fn deref_and_print(ptr: *const i32) {
unsafe {
println!("Разыменованное значение: {}", *ptr);
}
}fn call_with_zero() {
let zero = 0i32;
let ptr = zero as *const i32;
deref_and_print(ptr);
}fn main() {
call_with_zero();
}и в чем тонкая разница? в словечке unsafe?
>CppCheck:Отлично, только вот где этот CppCheck есть? Неуж-то нигде?
https://archlinux.org/packages/extra/x86_64/cppcheck/
>Required By (3)Я аж чувствую гордость, за такое большое количество программ.
>>И вот что-что а у gcc и clang статический анализ и варнинги очень сильно подтянули. В gcc аж вообще статический анализатор встроили в последних версиях.
>Да? А покажи предупреждение, что разыменновывается нулевой указатель. Или как всегда лжёте?
>>Не говоря о том что билдсистема может делать что угодно
>Вот в том то и дело, что может делать что угодно, например не проверять ошибки вообще.Спасибо, что подтвердили оба факта: стандартные компиляторы вообще никак не проверяют даже такую простейшую ошибку, а так же то, что при сборке 99.99% софта никакой проверки не происходит.
> Отлично, только вот где этот CppCheck есть? Неуж-то нигде?
> https://archlinux.org/packages/extra/x86_64/cppcheck/И что ты показал, что cppcheck есть в репозиториях любого приличного дистрибутива? ок, спасибо, кэп.
>И что ты показал, что cppcheck есть в репозиториях любого приличного дистрибутива?И никем не используется. Вы возьмите и натравите его на все подряд пакеты, заодно и скрипт сюда скниньте. Сколько строк логи будут?
> И никем не используетсяПруфы? Или болтаем-с?
> Вы возьмите и натравите его на все подряд пакеты, заодно и скрипт сюда скниньте
Может мне еще и сплясать? Ну, чтоб тебе не скучалось?
>Пруфы? Или болтаем-с?Вам уже привели ссылку на пакет в арче, много вы там использования увидели? Мне вот просто интересно, как этот cppcheck будет использоваться при сборке того же питона, если он не указан в качестве сборочной зависимости?
Да не мелочись, требуй PVS-Studio в зависимостях к python сразу! Гулять так гулять! Ну и чтоб два раза не ходить, сразу чтоб при закачке исходников python по почте отдельный ноутбук для сборки высылали.
>Да не мелочись, требуй PVS-Studio в зависимостях к python сразу!Вот удивительно, но крестовик(или сишник?) даже не догадывается, что для того, чтобы на крестах получить результат хотя-бы сравнимый с rust-ом, ocaml-ом или haskell-ем, нужно добавить в зависимости хотя-бы один статический анализатор. Как и ожидалось от крестовика, баги сами себя не напишут.
Вот удивительно, но ржавовик (или ржавник?) не догадывается, что не весь инструментарий для ржи устанавливается автоматом как зависимость.> баги сами себя не напишут.
Конечно, судя по новостям про Cloudflare их успешно напишут растопитеки.
>Вот удивительно, но ржавовик (или ржавник?)Не угадали. Я пишу на языке с GC.
>что не весь инструментарий для ржи устанавливается автоматом как зависимость.Только вот банальнейшие проверки уже включены в компилятор.
>Конечно, судя по новостям про Cloudflare их успешно напишут растопитеки.И вы опять забыли привести доказательства.
>Не угадали. Я пишу на языке с GC.Кстати, даю подсказку: в нём есть алгебраические эффекты и он жадный.
> И никем не используется.Как вы это определили? Вы - экстрасенс?)) А можете сказать - использую я cppcheck или нет? А что я прям сейчас делаю?))
> Вы возьмите и натравите его на все подряд пакеты, заодно и скрипт сюда скниньте. Сколько строк логи будут?
На бинарные пакеты?)) А ничего, что cppcheck для проверки исходных кодов?)) И нормальные люди его обычно в IDE интегрируют. Или код перед релизом на всякий случай на предмет ошибок проверяют.
Но обсуждали мы не вашу некомпетентность...
Мы обсуждаем то, что РЖАВЫЙ НЕ НУЖЕН ))
>Как вы это определили? Вы - экстрасенс?))Я вам даже ссылку процитировал: по количеству обратных зависимостей. Неуж-то вы это не поняли?
>А можете сказать - использую я cppcheck или нет?Дайте подумать... https://github.com/ProfessorNavigator/mylibrary Ctrl+F cppcheck - фраза не найдена, хотя зависимости указаны. Кто бы мог подумать, что иделогический противник раста не использует статические анализаторы.
>На бинарные пакеты?)) А ничего, что cppcheck для проверки исходных кодов?))А ничего, что в репозитории отображаются сборочные зависимости тоже?
>И нормальные люди его обычно в IDE интегрируют.У нормальных людей сборка в случае ошибок не проходит, вот прям совсем не проходит. И не важно, в чём кто код пишет - в виме или IDE. А у вас даже в той же IDE, но без плагина все ошибки дойдут до релиза.
>Или код перед релизом на всякий случай на предмет ошибок проверяют.Пойдите и проверьте xorg перед релизом на ошибки. Или linux, а то сидят и позоряться своими ошибками пред растерами. Вот пойдите и проверьте, докажите ненужность раста. Потом будем на вас как на главного эксперта ссылаться.
Ты количество установок считаешь по числу обратных зависимостей? Ну что тут сказать...> У нормальных людей сборка в случае ошибок не проходит, вот прям совсем не проходит
Странно, у меня в примере выше сборка на ржавом с явно кривым кодом вполне прошла... И без предупреждений, ЧСХ.
>Ты количество установок считаешь по числу обратных зависимостей?У вас логика отсутствует напрочь. Вы можете себе хоть три миллиона установок сделать на свою машину, в реальности подавляющее количество проектов, гораздо больше чем 99.99% статическим анализатором не проверяются. И в случае проверки просто утонут в ошибках. Вы, как настоящий крестовик(или вы прикидываетесь?) можете запросто форкнуть условные иксы, добавить туда статический анализ, и скинуть сюда ссылку, в качестве доказательства того, что код там хороший. Но вы этого не делаете по той простой причине, что сами прекрасно понимаете, что очень быстро натолкнётесь на проект, где таких предупреждений будут тысячи. А если делать это для каждого пакета в репозитории, то вы утоните в предупреждениях.
>Странно, у меня в примере выше сборка на ржавом с явно кривым кодом вполне прошла...В вашем коде есть слово unsafe, которое можно обнаружить простым grep-ом. Дырени и ошибки в си простым grep-ом не обнаружить.
>И без предупреждений, ЧСХ.Вам скинули ссылку, как отключить unsafe код, известно это уже более 8 лет, но вы до сих пор этого не узнали.
> И никем не используется. Вы возьмите и натравите его на все подряд
> пакеты, заодно и скрипт сюда скниньте. Сколько строк логи будут?Вот я им пользуюсь. И свои фирмвары мк регулярно им проверяю. Т.е. поздравляю, вы чисто технически - лжец. Ибо 1 меня достаточно для доказании ложности вашего заявления.
И чем это отличается от вон того прописывания на кривой козе в deny unwrap? При том еще и с каким-то ультра-контринтуитивным "clippy". Это вообще что за скрепыши и нэйминг такой левый? Пятнадцатилеток вместо архитектов наняли? По дизайну ЯП заметно - знатное месиво получилось.
>Вот я им пользуюсь.Ну и? Более 99.99% всё равно не используют. Вы лучше это число оспорьте.
>И чем это отличается от вон того прописывания на кривой козе в deny unwrap?Тем, что разыменновывание нулевого указателя - это UB с абсолютно любыми последствиями, а unwrap - паника, в ходе которой программа не может повредить память.
>А вот такое чудно скомпилилось растом
>unsafeСлишком толсто, вам пора на диету.
> Слишком толсто, вам пора на диету.В рже кем-то запрещен unsafe? Что сказать-то хотел? Я вообще удивлен, что unsafe запросто вызывается не из unsafe контекста, но что есть то есть. Кушайте.
>В рже кем-то запрещен unsafe?А вы - молодец. В документации как минимум 8 лет https://github.com/rust-lang/nomicon/blame/master/src/safe-u... об этом сказано, мне лень искать более ранние ссылки. Ещё немного, и за это время уже родившийся ребёнок с нуля осовоит раст.
В документации к C/C++ черным по белому испокон веку -- нельзя разыменовывать nullptr. Всё в порядке, это есть в документации, расходимся.
>В документации к C/C++ черным по белому испокон веку -- нельзя разыменовывать nullptr.Хорошо, а как мне найти все места, где это может происходить? Может быть простым grep-ом? Каким флагом отключить это? Как это никак? Вы почитайте блог psv-studio, сколько ошибок находится в обычном проекте, и это при том, что они описывают далеко не каждую ошибку.
> А вот такое чудно скомпилилось растом, без всяких предупреждений, и благополучно вылетело при старте:А теперь повтори то же самое, добавив
#![forbid(unsafe_code)]
Ну, для начала собери ржавую же стандартную библиотеку с такой строчечкой, потом те ошметки растокода, что в андроиде, ну и так далее...
>Ну, для начала собери ржавую же стандартную библиотеку с такой строчечкойА давайте больницы закроем, рак же лечить не могут. Ну а все остальные пускай умирают.
>ну и так далее...Ой, оказывается unsafe может быть не 100% исходника, и даже не 50%. Непорядок, нужно чтобы все 100% было.
Ага, вот именно, не лечат по факту нигде, но на больничке "rust" повесили табличку "лечим от трёх видов рака". Но зато входить в нее надо на четвереньках, по коридорам ползать по пластунски.
>но на больничке "rust" повесили табличку "лечим от трёх видов рака"Ух-ты, вы, спустя столько лет, наконец-то узнали, что rust решает не все проблемы. Того и глядишь, лет за 16 наконец-то выясните какие именно проблемы он решает и как.
А теперь к вам вопрос: почему вы призываете отказаться от решения этих проблем прямо сейчас? Сколько ещё ждать, пока вы не согласитесь с тем, что места, где может быть разыменнован нулевой указатель, должны быть хотя-бы как-то помечены? Сколько ещё ждать, пока вы не согласитесь с тем, что гигиенические макросы всё-таки лучше, чем замена текста в стиле си?
>Но зато входить в нее надо на четвереньках, по коридорам ползать по пластунски.Фантазии не подкрепленые доводами, остаются фантазиями. Где ваше решение этой проблемы, но только нормальное? Как-так неужели никакого нет?
> Ну, для начала собери ржавую же стандартную библиотеку с такой строчечкой, потом те ошметки растокода, что в андроиде, ну и так далее...С какого перепугу? Разве авторы тех библиотек пишут такой гоvнокод, как ты привёл выше?
Ты продемонстрировал свою неадекватность, намеренно разыменовав указатель без предварительной проверки. Если бы ты работал в команде над проектом, приведённой строчкой тебе б запретили писать unsafe код.Даже медведя можно выдрессировать.
> Ты продемонстрировал свою неадекватность, намеренно разыменовав указатель без предварительной проверки. Если бы ты работал в команде над проектом, приведённой строчкой тебе б запретили писать unsafe код.А ржаванутый, который привел выше аналогичный код на плюсах, продемонстировал адекватность. Вы не понимаете, это другое, как же, как же. Если кривой код на плюсах -- то это язык плохой, если на ржавом -- то я виноват. Ожидаемые финты ушами у ржавозависимых.
> А ржаванутый, который привел выше аналогичный код на плюсах, продемонстировал адекватность.Это типичный код на Си.
> Вы не понимаете, это другое, как же, как же. Если кривой код на плюсах -- то это язык плохой, если на ржавом -- то я виноват.
На си/плюсах у тебя нет возможности написать иначе. А на расте есть. Поэтому да, виноват ты.
unsafe fn print(ptr: *const i32)
// инварианты должна соблюдать вызывающая сторонаfn print(ptr: &i32)
// инварианты проверяет компиляторfn print(ptr: *const i32)
// такой прототип ты никогда не увидишь как часть публичного интерфейса, разве что как приватный вспомогательный метод.Какой из вариантов выбрал ты?
> Ожидаемые финты ушами у ржавозависимых.
Нет. Код на расте более выразителен, чем на си/плюсах. А ты пытаешься упростить Rust до своего уровня.
Как всегда, ржастики горстями глотают этодругин.
> А теперь повтори то же самое, добавив
>
> #![forbid(unsafe_code)]
>А теперь попробуйте так - как вы сами предлагали - пересобрать практически существюущие пакеты. И что, хорошо пересобирается? Двойные стандарты - не рулят, господа...
Внезапно, но на расте есть пакеты содержащие только safe код. На си/крестах вы такое не сделаете.
под miri:error: Undefined Behavior: pointer not dereferenceable: pointer must be dereferenceable for 4 bytes, but got null pointer
--> src/main.rs:3:49
|
3 | println!("Разыменованное значение: {}", *ptr);
| ^^^^ Undefined Behavior occurred here
|
= help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
= help: see https://doc.rust-lang.org/nightly/reference/behavior-conside... for further information
> Да? А покажи предупреждение, что разыменновывается нулевой указатель.В зависимости от - может и быьт. Но для динамической аллокации это ессно не катит. И это как раз таки - то же самое что panic() примерно, только крепко подпертое железом. В отличие от.
И на минуточку, любители Rust только что показали что в Rust этот аспект полная днина. Завалив клаудфлару panic() на несколько часов. Офигенно обработали нехватку памяти - поставив полглобуса на паузу. Красавы!
> Или как всегда лжёте?
Вон тут правдорубы с памятью поработали. Положив клаудфларь по всему глобусу. А я тоже ща правду то порублю - рассказав что я думаю о таком качестве кода, годности синтаксиса для ревью и вообще, отличная обработка нехватки памяти и прочие unwrap-костыли. С предложениями аж код переписывать между dev и prod. Ничего умнее адепты rust предложить видимо не смогли.
> Вот в том то и дело, что может делать что угодно, например
> не проверять ошибки вообще.Вон там уже проверили ошибки, путем выноса Cloudflare на несколько часов нахрен. Поставили планету на несколько гигабаксов - своим чудным panic() и unwrap. Было бы неплохо взыскать убытки с горе-переписывальщиков. До последнего цента, нахрен. А что, думали хайповать - это просто так? На мой вкус - за факапы надо отвечать, да? Вы ж сами педалили тему, извольте! Не вижу оснований делать вам скидки! :D
> А есть ещё настоящие сишники, понаделовшие кучу ошибок. В иксах до сих
> пор баги из 1990-ых исправляют, в 2025 году. Позор.В 1990-х мир был - другой. У большей части выхода в интернет - не было. Вирусы на дискетах распостранялись как максимум. И модель безопасности была - вообще совсем другая. Никто вообще не парился вон тем. Переполнения буферов как максимум были досадной фигней, не более. Да и сейчас - с всеми ALSR, NX, stack-protector и проч - реально эксплуатируемых дыр на самом деле не так уж и много. И ессно работать над проблемами стали по мере их обнаружения.
Но вот что Rust с нехваткой памяти сделал, просто заметя проблему под ковер и делая panic() только что господам отлично вышло боком, вырубив половину интернета на несколько часов, achievement unlocked и вы таки уже - не отмоетесь ;). Вполне сравнимо с падением Arian V по стоимости уже вышло.
>Но для динамической аллокации это ессно не катит.Какая разница - динамическая аллокация или статическая? Вы про зависимые типы слышали? Или опять сделаете вид, что ни разу не слышали? Ну так узнайте, хотя бы сейчас.
>И это как раз таки - то же самое что panic() примерно, только крепко подпертое железомОпять сишники лгут, как впрочем и всегда. Разыменноывание нулевого указателя в си - это UB. Нет абсолютно никаких гарантий, что ваш код дойдёт в до железа в том виде, в котором вы ожидаете.
>И на минуточку, любители Rust только что показали что в Rust этот аспект полная днина. Завалив клаудфлару panic() на несколько часов.Порча памяти была? Нет, не было. Ну а панику можно написать на любом языке, хоть на си с assert-ом. У вас нет абсолютно никаких доказательств, что будь этот компонент написан на си, то гарантированно бы работал.
>годности синтаксиса для ревьюОчередной неосилятор синтаксиса. И да, где ваши патчи с нормальным, по вашему мнению синтаксисом?
>и прочие unwrap-костылиУдивительно, но данные строки можно тривиально обнаружить простым grep-ом, в отличии от си, где порча памяти происходит молча.
>В 1990-х мир был - другой.Нет, он был ровно таким же. До тех пор, пока программа очередного сишника не выставит CVE на весь интернет, этот самый сишник и не почешется этот самый CVE не допустить.
>Переполнения буферов как максимум были досадной фигней, не более.Ну а что сейчас изменилось? Мне тут сразу несколько аккаунтов доказывают, что отсутствие проверки на наличие UB при разыменноывании нулевого указателя - это нормально, и вы в том числе. Это не просто падение программы, это абсолютно произвольная проблема.
>Но вот что Rust с нехваткой памяти сделал, просто заметя проблему под ковер и делая panic() только что господам отлично вышло бокомПаника вызывается абсолютно прозрачно для конечного пользователя, включая номер строки и имя файла. Почему в данной компании так долго искали проблему - вопрос исключительно к ним.
>> обычно спокойно скомпилирует. Прололчу про разработку в vim и подобном.
> ругаться будет - компилер.Да, компиляторы сильно подтянули.
Но в упомянутом Visual Studio не то что предупредений больше, что то он вообще не рекомендует компилировать, то есть диагностика существенно сильнее.Я больше для контроллеров пишу, а там среды разработки скромнее, но фрагменты кода люблю в VS сперва прогонять.
>Если все что вы
> можете это запустить "свежий visual studio" то в общем то -
> это не ваша заслуга. И в приличных местах вас соответственно не
> ждут.А Вы не "доктор левой руки до локтя"?
Под Windows то, тоже приходится писать. А если инструмент все равно используется, зачем ещё сторонние инструменты. Кстати, и под Мак тоже приходится писать, и очевидно для пользователей лучше нативные приложения, а не кроссплатформенные Электроны и т.п.Вот если бы вся экосистема ограничивалась только Linux, то тогда не только другое дело, но и проблем меньше, из за отсутствия зоопарков систем.
> Но в упомянутом Visual Studio не то что предупредений больше, что то
> он вообще не рекомендует компилировать, то есть диагностика существенно сильнее.Вообще-то современные версии GCC могут запросто поспорить с этим утверждением.
> Я больше для контроллеров пишу, а там среды разработки скромнее, но фрагменты
> кода люблю в VS сперва прогонять.А мне как-то хватает GCC с -fanalyze + мой набор флагов и cppcheck для этого. Сий кстати даже правила MISRA может форсануть нашару если оно надо.
> А Вы не "доктор левой руки до локтя"?
Не знаю о чем это.
> Под Windows то, тоже приходится писать.
Кому приходится - тому и карты в руки. Этот кто-то к счастью буду не я :)
> и очевидно для пользователей лучше нативные приложения, а не кроссплатформенные
> Электроны и т.п.Вот лично я под винду уж точно ничего писать не собираюсь. Особенно - нативные приложения. Особенно - в вьюжлстудии. Чур меня от такого "счастья".
> Вот если бы вся экосистема ограничивалась только Linux, то тогда не
> только другое дело, но и проблем меньше, из за отсутствия зоопарков
> систем.Ну я примерно так и сделал - решил что я работаю только с линухами. На мой век задач точно хватит. А что там в винде - и тем более нативно что-то писать да еще в VS? Это просто без меня. Я элементарно не впишусь в такие задачи.
>А мне как-то хватает GCC с -fanalyze + мой набор флагов и cppcheck для этого.Не прокомментируете мой пример в другой ветке?
>Сий кстати даже правила MISRA может форсануть нашару если оно надо.А с правилами MISRA получится писать обычный код для повседневнвых задач? Там деревья повращать и всё такое?
>Вообще-то современные версии GCC могут запросто поспорить с этим утверждением.Что gcc, что cppcheck, что vs studio не имеют достаточно информации, чтобы полноценно анализировать код. Стоит его немного поменять, и код ВНЕЗАПНО молча ломается.
В нём до сих пор нет таких функций, как join и split для строк.
Есть. :)
std::views::join_with, std::views::split тебе ни о чем не говорят?
> std::views::join_with, std::views::split тебе ни о чем не говорят?Да можно проще)) Например так.
std::string str1(" - Rust is useless");
std::string str2("\n - Yes, it's true");
str1 += str2;
>
> std::string str1(" - Rust is useless");
> std::string str2("\n - Yes, it's true");
> str1 += str2;
>А чот, в хрусте overload оператора "+" для кастомного типа вообще можно запилить уже?
>>
>> std::string str1(" - Rust is useless");
>> std::string str2("\n - Yes, it's true");
>> str1 += str2;
>>
> А чот, в хрусте overload оператора "+" для кастомного типа вообще можно
> запилить уже?Вы меня спрашиваете? Я без понятия - я на нём не пишу)) Пример на С++.
Крестовик как всегда не различает функции и операторы. Как и ожидалось от крестовика.
> Крестовик как всегда не различает функции и операторы. Как и ожидалось от
> крестовика.Да что вы говорите... А может просто "крестовик" знает, что в С++ есть такая вещь, как перегрузка операторов? И тогда внезапно выясняется, что оператор - это тоже функция? Не всегда и не везде, но тем не менее... https://en.cppreference.com/w/cpp/language/operators.html Читать до просветления.
>И тогда внезапно выясняется, что оператор - это тоже функция?Мне стало очень интересно, как крестовик собирается передавать оператор в функцию fold.
>Не всегда и не везде, но тем не менее...Вот с этого и надо начинать. У join семантика несколько отличается от обычного сложения.
> Вот с этого и надо начинать. У join семантика несколько отличается от
> обычного сложения.При чём тут сложение, а? Вы понимаете, что означает термин "перегрузка операторов"? Видимо нет. Для особо "остроумных" поясняю: вы можете переопределить оператор каким угодно образом. То, что там есть "+" не означает сложение. Может перестанете уже демонстрировать свою "грамотность"? Хоть головой о стену бейтесь, но Rust не нужен ;)
На raku.
*на brainfuck
Запомните, юные авангардисты, чем глубже вы сегодня засовываете Раст, тем больнее его завтра будет вынимать. Так что особо не радуйтесь распространению ржы - она вам боком выйдет.
так они не думают про завтра. живут одним днём. а кто-то потом разгребать будет.но вообще, просто похоже на саботаж свободного софта.
> так они не думают про завтра.Странный вывод.
Они как раз думают про завтра.> живут одним днём. а кто-то потом разгребать будет.
Чушь.
Ничего все эти болтуны из комментарием не будут разгребать.> но вообще, просто похоже на саботаж свободного софта.
Так софт был и остался свободным.
А вот то, что всякий сброд побежал указывать разработчикам языка как им нужно жить, это показательно.
> Так софт был и остался свободным.Ну подумаешь - заменили GPL на ...
:)
Ну и где лицензия питона сменилась балабол ты наш
А кто говорил про Питон, демагог ты наш
> Запомните, юные авангардистыТам сам дед пожизненый диктатор условно дал добро. Хотя ему уже все равно вроде как.
> Хотя ему уже все равно вроде как.Раз в год квакнуть и ... ну копейка капает, а чего ещё на пензии надо?!
А зачем вы его куда-то засовывать?
На нем нужно просто писать код.
Как говорится "друзей не надо иметь, с ними нужно дружить!" (с)Просто новый инструмент, который используют те, кому это нравится.
Вам не нравится? Кнопочка "форк" в от том углу.
А.. вы не можете тк у вас лапка-из-дупки? Ну... sad to be you
У нас тут опенсорс и вам никто ничем не обязан.
"Иметь надо пользователей с помощью "друзей" (С)
Лучшие друзья опенсорса NSA (TM), CIA (TM) рекомендуют!
> Запомните, юные авангардисты, чем глубже вы сегодня засовываете Раст, тем больнее его завтра будет вынимать.Кек. Так они засовывают раст кому? Себе чтоле? Кому больнее-то будет? И зачем ты им об этом рассказываешь тогда? Чтобы они удвоили усилия?
Мне как питонисту неприятны такие новости. Jython и IronPython не готовы заменить CPython как не крути (годятся только для проектов с нуля без сторонних Python библиотек).
>Мне как питонисту неприятны такие новости.Ну и как питонист вы просто возьмёте и затерпите. Вы не будете изучать си и поддерживать независимую реализацию.
>не готовы заменить CPythonУ вас кто-то cpython забрал? Форкайте прямо сейчас, пока ещё не нужно по git log-у выяснять до какого коммита откатывать, а то дальше придётся страшный git bisect писать.
> причины внедрения Rust — обеспечение безопасной работы с памятьюЗвучит так дилетантски, будто из всех 200 ЯП никто не думал о безопасности и вдруг раз - изобрели Ржу! :)) Так тупо.... Даже "ассемблер с классами" - и тот давно имеет авто-указатели, ТОЖЕ БЕЗОПАСНО работающие с памятью, да ещё при этом являясь промышленным стандартом + ООП. Накой ляд тут ржа?? Чисто погемороить и без того зачуханых uндуcuков? От них вы точно не получите качественный код; "экономия на программистах" всегда оборачивается провалом проекта или превращением его в неподдерживаемого монстра.
>> причины внедрения Rust — обеспечение безопасной работы с памятью
> Звучит так дилетантски
> Даже "ассемблер с классами"
> Накой ляд тут ржа??Накой, спрашиваешь? Ну вот, например:
int a = 1;
int& b = std::max(a, 10);Вот мы и отстрелили себе ногу в твоем любимом "ассемблере с классами". И даже без динамического выделения памяти.
Теперь понятно, зачем нужен Раст?
> Теперь понятно, зачем нужен Раст?Язык для "не программистов" - создать у дилетанта иллюзию, что он "что-то может".
О, значит высосанные примеры кода из вашей методички ещё не убрали? Н-да, совсем дураков жизнь ничему не учит...
>О, значит высосанные примеры кода из вашей методички ещё не убрали?Ошибка компиляции есть? Нет? Ну так в чём проблема?
>>О, значит высосанные примеры кода из вашей методички ещё не убрали?
> Ошибка компиляции есть? Нет? Ну так в чём проблема?Очевидно же - в голове того, кто пишет такой код))
> Очевидно же - в голове того, кто пишет такой код))Какой "такой"?
Вообще-то оно даже не компилируется.> clang++ -Wall -Wextra 1.cpp
> 1.cpp:6:7: error: binding reference of type 'int' to value of type 'const int' drops 'const' qualifier
> 6 | int& b = std::max(a, 10);
> | ^ ~~~~~~~~~~~~~~~
> 1 error generated.
> О, значит высосанные примеры кода из вашей методички ещё не убрали?Не убрали возможность отстрелить ногу на ровном месте. И не из методички, а из языка.
Про высосаность вообще смешно, ибо такая проблема в реальной кодовой базе не будет локализирована в одной строчке кода (как в примере), а будет размазана по тысячам строкам логики. Висячие ссылки/указатели - одна из основных причин порчи памяти в плюсах.
>>> причины внедрения Rust — обеспечение безопасной работы с памятью
>> Звучит так дилетантски
>> Даже "ассемблер с классами"
>> Накой ляд тут ржа??
> Накой, спрашиваешь? Ну вот, например:
> int a = 1;
> int& b = std::max(a, 10);
> Вот мы и отстрелили себе ногуВообще-то тут будет ошибка компиляции.
> Вообще-то тут будет ошибка компиляцииТы об отсутствии const у b? Ну да, только суть-то примера не в этом. Добавь const - и скомпилируется.
>> Вообще-то тут будет ошибка компиляции
> Ты об отсутствии const у b? Ну да, только суть-то примера не
> в этом. Добавь const - и скомпилируется.Добавь опцию -Wdangling-reference
>> суть-то примера не в этом
> Добавь опцию -Wdangling-referenceВы упорно игнорируете тот факт, что в сколь-нибудь сложном коде ваш -Wdangling-reference не сработает. Какой-то копиум, ей-богу.
Ну ок, а какую опцию мне добавить для этого:
std::vector v{1, 2, 3};
const auto& i = v[0];
v.push_back(4);
std::cout << i << '\n';Расскажите мне теперь, как Раст не нужен.
Если по какой-то неведомой причине кровь из носу надо будет сделать именно так, то в C++ можно включить голову и решить проблему:
std::vector v{1, 2, 3};
v.reserve(100);
const auto& i = v[0];
v.push_back(4);
std::cout << i << '\n';В рже ты будешь бегать от чекера боровов до посинения. Ну а вообще процитирую ржавоеда (в мой адрес):
> Ты продемонстрировал свою неадекватность, намеренно <описание ошибки>. Если бы ты работал в команде над проектом, приведённой строчкой тебе б запретили писать unsafe код.
Вот у тебя примерно то же самое.
> v.reserve(100);Это какой-то позор xD
Нет, если в алгоритме есть оценка снизу на длину массива, но с другой стороны...
>Это какой-то позор xDПока гугл приближает js к скорости крестов, крестовики приближают кресты к прожорливости js.
>Если по какой-то неведомой причине кровь из носу надо будет сделать именно так, то в C++ можно включить головуРазработчикам xorg надо всего-лишь включить голову. Разработчикам linux надо всего лишь включить голову. Разработчикам chromium надо всего лишь включить голову. И так далее.
>В рже ты будешь бегать от чекера боровов до посинения.Оказывается, писать на языке, предлагающим ручное управление памятью, сложно. Нет, кто бы мог это подумать? И тут перед вами есть аж целых три варианта, как писать качественный код: продолжить писать на rust, мысля сугубо в его терминах; изобретать какую-то более сложную систему типов, которая будет обрабатывать и эти ситуации, как например в языке inko; отказаться от rust и перейти на язык с GC, вроде go или ocaml. Но вместо этого, вы хотите плодить баги, по этому продолжаете писать на крестах.
>v.reserve(100);Костыль подъехал. Отлично, теперь упадёт не сразу, а спустя ещё несколько элементов, при этом ровно на том же месте. Просто замените
>v.push_back(4);на цикл
>>Если бы ты работал в команде над проектом, приведённой строчкой тебе б запретили писать unsafe код.Осталось найти того, кто данную строку в крестах найдёт. Поскольку простым grep-ом её не найти.
> Осталось найти того, кто данную строку в крестах найдёт. Поскольку простым grep-ом
> её не найти.Есть такой:
==226503==ERROR: AddressSanitizer: heap-use-after-free on address 0x7b83b03e0010 at pc 0x557f4ea66dbc bp 0x7fff71b95c10 sp 0x7fff71b95c00
READ of size 4 at 0x7b83b03e0010 thread T0
#0 0x557f4ea66dbb in main ../../main.cpp:276А grep как инструмент анализа кода вообще не очень, это вас снова обманули.
>Есть такой:Который не используется более чем в 99.99% случаев. Вы мне так и не доказали обратное. Более того, берём первую попавшуюся статью https://habr.com/ru/articles/210226/
>Время работы — 5 минут. В глаза сразу бросается ошибка "(error) Internal error. Token::Match called with varid 0. Please report this to Cppcheck developers". Это означает, что вместо бага в анализируемой программе нашёлся баг в самом анализаторе:)
>Реально нашлась всего одна ошибка (с разницей в 2 строчки). Неплохо, возможно, что автор notepad++ сам пользуется cppcheck.Здесь замечательно буквально всё. Не смотря на то, что автор использует cppcheck, в проект просочилась целая ошибка. В других языках такой код не соберётся, и автор гарантированно не допустит ошибку.
>А grep как инструмент анализа кода вообще не очень, это вас снова обманули.Я не говорю про очень или не очень, я говорю про то, насколько легко там найти ошибку. А вот с cppcheck, как видим, люди не справляются.
> Не смотря на то, что автор использует cppcheckРечь про (встроенный в компилятор) ASans, при чем тут cppcheck? AddressSanitizer в выхлопе ни о чем не говорит? Ну, ожидаемо...
> Который не используется более чем в 99.99% случаев. Вы мне так и не доказали обратное.
Я должен тебе что-то доказывать? "Бремя доказательств -- на обвинении", вперед и с песней.
>>> суть-то примера не в этом
>> Добавь опцию -Wdangling-reference
> Вы упорно игнорируете тот факт, что в сколь-нибудь сложном коде ваш -Wdangling-reference
> не сработает. Какой-то копиум, ей-богу.
> Ну ок, а какую опцию мне добавить для этого:1. Читать документацию.
2. Использовать статический анализатор.
3. Использовать адрес санитайзер.
Ну, то есть, опции нет, и ни компилятор, ни умные указатели в этом случае никак не спасают.Но при этом мы все так же не понимаем, зачем нужен Раст.
>2. Использовать статический анализатор.Остался один маленький шаг: статический анализатор нужно объеденить с компилятором, а то как показывает практика, статические анализаторы крестовики почему-то не используют. Вот вы не знаете почему? И я не знаю.
>>2. Использовать статический анализатор.
> Остался один маленький шаг: статический анализатор нужно объеденить с компилятором,Некоторые проверки переходят в компиляторы, но нужно понимать, что статический анализатор делает гораздо больше проверок и требует донастройки. В том же расте есть clippy.
> а то как показывает практика, статические анализаторы крестовики почему-то не используют.
У каждого своя практика.
>но нужно понимать, что статический анализатор делает гораздо больше проверокДля начал, пускай компилятор будет показывать каждую строку с UB. Сишники это вообще хотя-бы чисто теоретически могут сделать? Или у них все файлы будут помечены как содержащие UB?
>У каждого своя практика.Вот скажите, а иксы, linux и прочие проекты, в которых регулярно видим уязвимости - они без статического анализа, или же анализаторы не в состоянии найти ошибку?
> Для начал, пускай компилятор будет показывать каждую строку с UB. Сишники это вообще хотя-бы чисто теоретически могут сделать?Каким образом, если ub проявляется во время выполнения? Нарпимер, раст не определяет во время компиляции переполениние знаковых целых. Провеки (флага переполнения) и гарантии (например, цикличности переполнения) - это доп. инструкции, которые нужно генерить компилятору, а потом исполнять. Это компромисс по скорости.
>Каким образом, если ub проявляется во время выполнения?Неверно. UB может привести к генерации бессмысленного кода.
>Провеки (флага переполнения) и гарантии (например, цикличности переполнения) - это доп. инструкции, которые нужно генерить компилятору, а потом исполнять. Это компромисс по скорости.Вот это - выглядит как хороший аргумент против раста.
В расте знаковое переполнение не является UB. Раст гарантирует очень даже well-defined поведение в этом случае.
> В расте знаковое переполнение не является UB. Раст гарантирует очень даже well-defined
> поведение в этом случае.Ценой доп. иснтрукций, про это и речь. А он хочет, чтобы во время компиляции проверялось.
> Ценой доп. иснтрукций, про это и речь.Не обязательно. Отсутствие UB не означает, что там вызывается какое-то исключение. Просто поведение при переполнении будет вполне себе определённым. А дальше зависит от архитектуры проца. Где-то такое поведение идёт из коробки, а где-то может понадобиться доп. инструкции, что бы обеспечить нужное поведение.
>> Ценой доп. иснтрукций, про это и речь.
> Не обязательно. Отсутствие UB не означает, что там вызывается какое-то исключение. Просто
> поведение при переполнении будет вполне себе определённым. А дальше зависит от
> архитектуры проца. Где-то такое поведение идёт из коробки, а где-то может
> понадобиться доп. инструкции, что бы обеспечить нужное поведение.В x86 обязательно. Более того по RFC раст не генерит проверки в релизе, только в дебаге.
> В x86 обязательно.Как раз на x86 ни чего дополнительного в релизный код не будет добавлено, т.к. в x86 целочисленная арифметика работает ровно так, как её гарантирует раст. Т.е. при переполнении целых будет выполняться "two's complement wrap" для знаковых, и "wrap around" для без знаковых.
Дополнительные инструкции понадобятся только на специфических архитектурах, в которых целочисленная арифметика работает по другому.
>> В x86 обязательно.
> Как раз на x86 ни чего дополнительного в релизный код не будет
> добавлено, т.к. в x86 целочисленная арифметика работает ровно так, как её
> гарантирует раст. Т.е. при переполнении целых будет выполняться "two's complement wrap"
> для знаковых, и "wrap around" для без знаковых.Мои сообщения вообще кто-то читает? В релизном нет проверки на переполение, в дебаге есть.
> Мои сообщения вообще кто-то читает? В релизном нет проверки на переполение, в
> дебаге есть.Ты говоришь про переполнение как ошибке в алгоритме. А тема была про UB в контексте этого переполнения - это немного про другое.
Для С переполнение является UB, т.к. он не гарантирует одинакового результата при переполнении, и в некоторых случаях компилятор может использовать этот факт для своих оптимизаций и сделать что-то "волшебное" на выходе.
Раст гарантирует, что поведение при переполнении будет одинаковым, и никакие оптимизации не испортят это. Т.е. я могу на расте рассчитывать на то, что
127i8 + 1 == -128i8
и безопасно строить на этом свою логику. На C я не могу на это опираться.
То есть разница в релизе только в гарантии цикличности. Но опять же в расте есть overflowing_add и прочие надстройки над встроенными функциями, как и в с23 есть stdckdint.h, который надстройка над интринсиками gcc. Так что если надо где-то сделать явную проверку без ub, то и в си это можно сделать.
>> В x86 обязательно.
> т.к. в x86 целочисленная арифметика работает ровно так, как её гарантирует растПроверка флага переполнения в рантайме компилятор раста генерит только в дебаге. Если по какой-то причине в дебаге этот код не отработает на граничных входных данных, то в проде ее не будет (по умолчанию) и привет переполнение.
>>но нужно понимать, что статический анализатор делает гораздо больше проверок
> Вот скажите, а иксы, linux и прочие проекты, в которых регулярно видим
> уязвимости - они без статического анализаИксы не знаю, в linux вроде был какой-то, а многие другие используют, например, тот же nvim или sudo.
> , или же анализаторы не в состоянии найти ошибку?
Конечно же анализаторы в текущем виде не панацея и не найдут всех ошибок. Более того, если взять какой-то сложный анализатор вроде PVS, то с ним нужно отдельно разбираться, чтобы отсеять false positive срабатывания.
Даже хваленый боров в расте много пропускает (смотри miri) и новые боров polonius.
>Иксы не знаю, в linux вроде был какой-тоВот в том то и дело что вроде.
>а многие другие используют, например, тот же nvim или sudo.Какой именно? Или как всегда у крестовиков, всё необязательно - если код в одной функции, то ошибка обнаруживается, а стоит перенести в другую - и всё?
>Конечно же анализаторы в текущем виде не панацея и не найдут всех ошибок.Зато оптимизирующие компиляторы это прекрасно находят и выкидывают целые блоки кода
>то с ним нужно отдельно разбираться, чтобы отсеять false positiveТот факт, что язык запутывает, добавляя false positive - ещё один минус языка.
>Даже хваленый боров в расте много пропускаетНу, это минус раста. Лично я на расте не пишу.
Попрошу не распространять фейки. "Хвалёный" боров наоборот многое не пропускает там где можно и пропустить. Polonius как раз решает проблемы с обнаружением сложных кейсов, где всё нормально в плане работы с памятью, но стандартный боров не может это определить и запрещает использовать такой код.Miri полезен для проверки кода, в котором есть unsafe. Если весь код safe то он, как понимаю, ни каких проблем не найдёт.
> Попрошу не распространять фейки. "Хвалёный" боров наоборот многое не пропускает там где
> можно и пропустить. Polonius как раз решает проблемы с обнаружением сложных
> кейсов, где всё нормально в плане работы с памятью, но стандартный
> боров не может это определить и запрещает использовать такой код.И чем это лучше? Продираться через false positive. Это еще хуже.
> Miri полезен для проверки кода, в котором есть unsafe. Если весь код
> safe то он, как понимаю, ни каких проблем не найдёт.На странице проекта есть примеры со вполне safe кодом https://github.com/rust-lang/miri/?tab=readme-ov-file#bugs-f...
И вообще это уже динамический анализ, а никак не статический. Давайте тогда под валгриндом запускать.
И еще
> All that said, be aware that Miri does not catch every violation of the Rust specification in your program, not least because there is no such specification. Miri uses its own approximation of what is and is not Undefined Behavior in Rust.
вот так растовщички. Шах и мат. Нет спецификации и точка. Поэтому ваш хваленый мири умывает руки и ничего не гарантирует вообщем-то. Какая неожиданность (нет).
> На странице проекта есть примеры со вполне safe кодомПосмотрел несколько первых примеров - они только "сверху" выглядят как safe, т.к. это safe обертки над unsafe кодом библиотек. Внутри как раз таки достаточно unsafe из-за которого и получаются UB.
В полностью safe версии кода на расте не должно быть UB - это одна из целей языка. Если UB и существует в таком варианте, то только как ошибка компилятора, которую ещё не нашли или не исправили.
>> На странице проекта есть примеры со вполне safe кодом
> Посмотрел несколько первых примеров - они только "сверху" выглядят как safe, т.к.
> это safe обертки над unsafe кодом библиотек. Внутри как раз таки
> достаточно unsafe из-за которого и получаются UB.То есть буквально это весь код. К примеру любые примитивы синхронизации, любой системный вызов будет unsafe обернутный в safe.
> В полностью safe версии кода на расте не должно быть UB - это одна из целей языка.
Нет полностью safe версии. Проблема в том, что в реальном коде внутри всегда unsafe.
> Нет полностью safe версии. Проблема в том, что в реальном коде внутри
> всегда unsafe.Да, это так. Дело остаётся за тем, что бы довести этот базовый unsafe код до идеала, что бы никому не надо было его изобретать самому, повторяя те же самые ошибки. Проекты, вроде Miri, как раз помогают достижению этой цели. Другой вариант - проводить серьёзный аудит unsafe кода. В Rust это несколько проще, т.к. unsafe код легко найти и проверить только его.
> Остался один маленький шаг: статический анализатор нужно объеденить с компилятором,Эврика! -fanalyze в GCC именно такое и сделал. Жаль что они воспользовались машиной времени для того чтобы стырить вашу идею и вы не получите кредитсы за нее.
>Эврика! -fanalyze в GCC именно такое и сделал.Вот интересно, почему сишные проверки такие кривые? Вот не работают и всё тут.
cat b.h
```
struct A {
int* p;
};void set_null(struct A*);
int print(struct A*);
```
cat b.c
```
#include "b.h"void set_null(struct A* a)
{
a->p = 0;
}int print(struct A* a)
{
int* x = a->p;
return *x;
}
```
cat a.c
```
#include <stdio.h>
#include "b.h"int main()
{
int y = 7;
struct A a = {.p = &y };
printf("%d", print(&a));
set_null(&a);
printf("%d", print(&a));
return 0;
}
```
gcc -fanalyzer b.c -c -o b.o && gcc -fanalyzer a.c -c -o a.o && gcc -fanalyzer a.o b.o -o a && ./a
Segmentation fault (образ памяти сброшен на диск)
Итог: вы второй человек, который пообщеал мне статический анализ, и который солгал.
>-fanalyzeЯ опять же рискну предположить, что данный ключ в подавляющем большинстве проектов не используется.
> Итог: вы второй человек, который пообщеал мне статический анализ, и который солгал.$ cat t.c
#include <stdio.h>struct A {
int* p;
};void set_null(struct A* a)
{
a->p = 0;
}int print(struct A* a)
{
int* x = a->p;
return *x;
}int main()
{
int y = 7;
struct A a = {.p = &y };
printf("%d", print(&a));
set_null(&a);
printf("%d", print(&a));
return 0;
}$ g++ -fanalyzer t.c
t.c: In function ‘int print(A*)’:
t.c:15:17: warning: dereference of NULL ‘x’ [CWE-476] [-Wanalyzer-null-dereference]
15 | return *x;
>$ g++ -fanalyzer t.cА второй файл куда дели? Почему обнаружение ошибок зависит от того, в одном файле код или в нескольких?
>>$ g++ -fanalyzer t.c
> А второй файл куда дели? Почему обнаружение ошибок зависит от того, в
> одном файле код или в нескольких?Потому что юниты трансляции разные. Используй -flto и все будет работать.
> Я опять же рискну предположить, что данный ключ в подавляющем большинстве проектов не используется.Какая разница что кто-то его не использует? В расте unwrap() тоже как бы не рекомендуется (только в процессе разработки), а вот в внезапно в самой Cloudflare этому не следуют https://www.opennet.dev/opennews/art.shtml?num=64282 И что дальше?
>Какая разница что кто-то его не использует?Большая. Такие ошибки приводят к UB.
>В расте unwrap() тоже как бы не рекомендуетсяПаника не портит память.
> В расте unwrap() тоже как бы не рекомендуется (только в процессе разработки)Не надо распространять легкомысленные высказывания. Нормально всё с unwrap в расте. Ни какой это не отладочный инструмент. Это вполне себе production-ready решение, которое позволяет программисту упростить обработку очень редких ошибок, допустив в этом случае завершение приложения с паникой.
Максимум что можно про него рекомендовать - по возможности не злоупотреблять им, если хотите написать приложение, которое обрабатывает ошибки менее топорно, чем запаниковать.
Использование uwnrap не нарушает гарантии по безопасной работе с памятью, которые даёт раст. А то что приложения не будут никогда падать - этого разработчики раста не обещали.
>> В расте unwrap() тоже как бы не рекомендуется (только в процессе разработки)
> Не надо распространять легкомысленные высказывания. Нормально всё с unwrap в расте. Ни
> какой это не отладочный инструмент. Это вполне себе production-ready решение, которое
> позволяет программисту упростить обработку очень редких ошибок, допустив в этом случае
> завершение приложения с паникой.Да, мы все видели https://www.opennet.dev/opennews/art.shtml?num=64282 И по поводу легкомысленных высказываний можешь там же смотреть.
> Да, мы все видели https://www.opennet.dev/opennews/art.shtml?num=64282 И по поводу легкомысленных высказываний можешь там же смотреть.Вы видите только то, что хотите видеть. Вам ткнули пальцем в unwrap на Rust и вы забыли про все остальные факты, которые привели к проблеме у Клаудфлары.
Как по мне, так основная причина этого косяка в том, что разработчики бот-фильтра не правильно оценили вероятность возникновения ошибки в файле конфигурации, которую создают сами же системы Клаудфлара. И потому они использовали unwrap() как допустимый, по их мнению, вариант для случая, который может выстрелить с вероятностью меньшей, чем допускает их SLA.
Совершить такой промах очень легко кому угодно. Часто ли вы проверяете только что приготовленный вами чай/кофе на наличие в нём яда? Вот и тут разработчики решили, что только псих подсунет неправильный конфиг, который не соотносится с лимитами выставленными для фильтра. Наверное даже в документации описали этот кейс: "Надо увеличить лимит, если число параметров в конфиге будет больше текущего лимита".
Раст, как язык программирования, тут вообще не при делах. Он отработал ровно так как от него и ожидалось, как было написано в коде - завершил приложение с паникой и без UB. Без выполнения стороннего кода и без слива приватных данных.
Вы вините раст и разработчиков на нём в том, чего они никому не обещали.
Растик ожидаемо сел в лужицу, которую сам и напрудил:
int a = 1;
int& b = std::max(a, 10);пытаемся скомпилировать:
main.cpp:21: ошибка: binding reference of type ‘int&’ to ‘const int’ discards qualifiers
> main.cpp:21: ошибка: binding reference of type ‘int&’ to ‘const int’ discards qualifiersНу добавь const. Суть-то не в этом.
> Суть-то не в этом.А суть в том, что растсеры не знают Си.
> & = std::max
> не знают СиТы видишь Си там, где его нет.
> Ну добавь const. Суть-то не в этом.Вот не буду ничего тебе рассказывать про const T& в C++, позорься дальше.
> Вот не буду ничего тебе рассказывать про const T& в C++Так он и не просил тебя что-то рассказывать про const T& (да и что ты можешь рассказать?). Смысл того примера кода не понял ты, а якобы позорится при этом почему-то он. Странный ты какой-то...
О, еще один наивный чукотский вьюнош. А зря не попросил, потому что код
int a = 1;
const int& b = std::max(a, 10);
std::print("{}\n", b); // к примерувполне корректен и не содержит UB, почему -- велкам в документацию C++
> вполне корректен и не содержит UB, почему -- велкам в документацию C++И плевать, что компилятор тебе прямым текстом говорит:
> warning: possibly dangling reference to a temporary [-Wdangling-reference
> the temporary was destroyed at the end of the full expression 'std::max<int>(a, 10)'Твоя экспертиза как всегда 10/10. 😂
> велкам в документацию C++
Например, в cppreference.com, где пямым текстом написали:
Capturing the result of std::max by reference produces a dangling reference if one of the parameters is a temporary and that parameter is returned:
Да, признаю, ошибся. Это UB и висячая ссылка. Посыпаю голову пеплом и все такое. Правильно так:int a = 1;
const int &b = std::ranges::max({a, 10});здесь результат вернется по значению, и будет удерживаться ссылкой.
>Да, признаю, ошибся. Это UB и висячая ссылка.Крестовик не знает где ub, а где не ub, а компилятор ему в этом никак не помогает. Как и ожидалось от крестовиков.
>>Да, признаю, ошибся. Это UB и висячая ссылка.
> Крестовик не знает где ub, а где не ub, а компилятор ему
> в этом никак не помогает. Как и ожидалось от крестовиков.Потому что это сложная тема и нужно пользоваться автоматизированными инструментами для поиска ub. Как бы растовщички (большинство местных) верит, что в расте нет ub)))
> Да, признаю, ошибся. Это UB и висячая ссылка. Посыпаю голову пеплом и
> все такое.Ты все верно написал. const ссылка проделвает время жизни временного объекта и тут нет ub.
>> Да, признаю, ошибся. Это UB и висячая ссылка. Посыпаю голову пеплом и
>> все такое.
> Ты все верно написал. const ссылка проделвает время жизни временного объекта и
> тут нет ub.К сожалению, вынужден признать, что даже в C++23 -- это не так. Проверил с GCC 15.2, -std=c++23 -O0. Хотя, справедливости ради, только полному идиоту придет в голову использовать const T& для хранения результата функции, тут сам пример притянут за уши. Auto и быстрее написать, и заведомо правильно.
Хорошая новость -- ASans такое ловит влёт.
> Накой, спрашиваешь? Ну вот, например:
> int a = 1;
> int& b = std::max(a, 10);Rust вчерась тоже пример подогнал своим unwrap - как положить полпланете сайты на несколько часов. Замечательный синтаксис. И тут вдруг после такого шит-парада началось мяукание что unwrap оказывается фи, костыль, и вообще? :)
>Даже "ассемблер с классами" - и тот давно имеет авто-указатели, ТОЖЕ БЕЗОПАСНО работающие с памятьюА так же дающие прямо из коробки кучу UB.
Давайте сразу пройдёмся по всему списку вашей методички, чтобы не тратить ни наше, ни ваше время.1) Неопределённое поведение (чушь, почему - объяснено уже тысячу раз, но можно и в тысячу первый: любое UB связано с работой аппаратной части, если вы не можете это обойти - не садитесь программировать)
2) Безопасная работа с памятью. Т.е. просто встроенные в компилятор статический анализатор. Которые ещё и глючить может.
3) Мифическая архитектура языка, которая позволяет избежать ошибок. А ещё волосы после неё становятся шелковистыми.
4) Облить оппонента грязью и обвинить в теориях заговора.
5) Высосанные из пальца примеры кода, которые в реальной жизни никто и никогда не использует.Вроде ничего не забыл. Но если и забыл - не страшно, вы меня сейчас всё равно поправите.
>Давайте сразу пройдёмся по всему списку вашей методичкиДавайте. Вот ни один апологет крестов/сишки мне до сих пор не объяснил, зачем ему нужные не гигиенческие макросы, переполнение при работе с массивами, возможность потерять нулевой терминатор при работе со строками. Ну что, будете первым?
>любое UB связано с работой аппаратной частиКаждому сишнику железо мешает. Вот только объясните мне, почему на уровне типов нельзя разделить возможно нулевые и гарантированно не нулевые указатели? Вы так громко молчите, что я вообще ничего не слышу. Можете повторить?
>Которые ещё и глючить может.Каковы ваши доказательства?
>Мифическая архитектура языка, которая позволяет избежать ошибокДоставайте опровержение, оно вам понадобится.
>Облить оппонента грязью и обвинить в теориях заговора.Нет вы.
>Высосанные из пальца примеры кода, которые в реальной жизни никто и никогда не использует.Ссылку на баги в иксах прямиком из девеяностых приводить или сами найдёте?
> возможность потерять нулевой терминатор при работе со строкамиЭто решается просто использованием средств работы со строками из STL вместо ковыряния в байтах строки.
>Это решается просто использованием средств работы со строками из STL вместо ковыряния в байтах строки.Особенно решается при работе с сишными библиотеками, да.
Вот же провокаторы. Пусть делают форк и называют его RPython, а CPython оставляют как есть.
> Вот же провокаторы. Пусть делают форк и называют его RPython, а CPython оставляют какесть.
RustyPython Flying Circus. Это диды на пенсию вышли, но шоу совсем закрыть постеснялсь :)
> Вот же провокаторы. Пусть делают форк и называют его RPythonТы не поверишь, но RPython - это язык в pypy https://rpython.readthedocs.io/en/latest/
> В перспективе, к версии Python 3.17, Rust может стать обязательной
> зависимостью при сборке CPython.А можно оттуда еще питон дропнуть и оставить только Rust? В таком виде я б пожалуй против питона меньше возражал :D
Я понимаю что Вирт мёртв, но... давно ничего не было про Оберон.
> Я понимаю что Вирт мёртв, но...Но модула нынче в GCC ... жаль пока дед был жив - не осилили... :(
> давно ничего не было про Оберон.
Ну тут ХЗ. Оно на вкус фантиков - даже луДше модулы ... но ...
PS: Не моя поляна - увы. Я в войне пасквилянтов с насильниками - насильничал ;) Хотя дедушку Вирта - уважаю. Таких больше не делают!(С) :(
Оберон вдохновил Go.https://www.oreilly.com/api/v2/epubs/9780134190570/files/gra...
Что же он в него дженерики недовдохнул?
> Что же он в него дженерики недовдохнул?Out of scope для тех задач, для которых он создавался изначально. Go, всё-таки, это не совсем general purpose язык.
Ждем реализации RUST для отечественных архитектур процессоров !
за отечественные можешь не переживать - новости про buy-к@л можешь сам погуглить. Эксперимент оказался успешен, но нет сырья и кадров.
В общем, bye-bye.Проблема что никаких других скоро тоже не будет - кроме x86-64-Vутебяуженемодныйкупиновый и arm 64, который нужен только яблу, поэтому только на ЕГО процессорах все и будет работать более-менее нормально.
Китайцы с расширенным "mips" закроют любые потребности от железа до ос
жиантяны обычно очень посредственные кодеры.
Что они смогут портировать на свой шмяпс хотя бы вот хрустопихон - это прям вот очень навряд ли.
> за отечественные можешь не переживать - новости проУже есть свой техпроцесс 150нм :)
Не буду ничего писать, всё равно модеры потрут, ну оно и правильно - развесистый неприкрытый мат и нужно тереть :)
Нужно название отечественное.
Разработчикам питона виднее, на чём разрабатывать, сами разберутся.Интересно другое. Если антприв... антирастеры считают, что в их стране это не нужно и они всё прекрасно на Си напишут - ну так пишите. Вы ведь умеете без ошибок работы с памятью. Продолжайте фигарить всю критическую инфру, боевые системы на сишечке. А потом будете рассказывать, когда вас поимеют о том, как "просто надо уметь".
А мы в Штатах и Гейропах будем всё делать на расте. Посмотрим, кто останется в каменном веке.
Самое забавное, что автор Питона - за перевод разработки на раст, но экспертам опеннета виднее.
> Самое забавное, что автор Питона - за перевод разработки на раст, но экспертам опеннета виднее.Так ты сравнил какого-то автора питона с самыми экспертными ыкспертами!
Понятно что они разбираются лучше)
Он давно уже отошёл от дел и поэтому не в теме.
Так точно. Мнение создалетя языка важно только тогда, когда совпадает с мнением эксперта с опеннета. Во всех остальных случаях - "дедушка отошёл от дел", "дедушке пох", "он работает в МС, его купили" и так далее.Когда уже в стране с лучшим в мире образованием начнут в школах преподавать ошибки мышления (bias)?
> Мнение создалетя языка важно только тогда, когда совпадает с мнением ...... руководства компании. Разработчик JS тому пример.
> Самое забавное, что автор Питона - за перевод разработки на растА еще он работает в ms
А еще он апрувнул коммит про джит в обход пеп, на что жаловались из гуглаИ дальше что?
> он работает в msЧто-то слишком много "линуксоидов" работает в MS.
АяЁтАкоГа?!? Платиновый спонсор - все дела! Всё как вы любите!
Опяить же - решающий вклад в линукЗЪ, что Azure Linux что WSL - всё на благо!
Правдо на чьЁ именно благо ... :)
> Опяить же - решающий вклад в линукЗЪ, что Azure Linux что WSL
> - всё на благо!
> Правдо на чьЁ именно благо ... :)наше, наше. Уж лучше wsl чем протухт rhbm. (последнее их достижение - выпилили ftp. В венде поганой, где уже в общем-то и неясно, кому нужен, есть клиент, а в лючшем юникс чем юникс - не будет, неположено вам!)
А докеры в докере под докером в венде даже удобней запускать.
Пихоноподелки собранные вместе с пихоном в экзешник, кстати, тоже. Никаких тебе поисков по закоулкам OBS уникально собранного кривого сошника.
Как в 90е, только ещё монопольнее: Гугл - хозяин интернетов, МС - хозяин десктопов, Оракл - хозяин серверов. Только гугл тут полностью новая морда, в 90е хозяином серверов была Сан, купленная Орками.
> в 90е хозяином серверов была Сан, купленная Орками.не был. Серверов было - оппой жуй.
От еще не вымерших окончательно микроvax до интелов-переростков с isc unix (это были не совсем уже писюки, и стоили дороже самолета, но все же это были интелы с более-менее стандартной архитектурой) со всеми промежуточными остановками, от хепе до ibm.
Java Server Pages, не? У Сан была и архитектура процессора, она же выпускала и сервера, и ОС для них, и Java Server Pages. Sun - это Apple эпохи доткомов. У орков теперь в добавок единственная имеющая смысл серверная база данных, и потоковое решение CDC, которое тоже фактически industry standard.
Раст - мёртворождённый проект, в данный момент его жизнь поддерживается исключительно искусственными вливаниями.
> Раст - мёртворождённый проектну не знаю ... а Haskell тогда что? И ничего - живёт.
rust - просто ещё один язык, некоторые из них тоже пихали прямо подобным же образом - и даже слоганы про безопасТность были похожие :) С некоторыми - даже получилось, но они уже (через 30 лет то!) медленно вываливаются из популярности ... ну и решили что нужна замена, контролируемая ...
Haskell много честнее ржи, он не обещает больше, чем может дать, но то что обещает -- то дает.
>> Раст - мёртворождённый проект
> ну не знаю ... а Haskell тогда что? И ничего - живёт.язык для любителей математических закорючек. Живет, где-то там на обочине цивилизации. Далеко-далеко от системного программирования, потому что вообще далек от реального компьютера.
И, заметь - никто на нем ничего не переписывает "чтоб безопастно" или с любой другой целью.Так-то пролог наверное тоже где-нибудь живет.
Нет, дорогой, мертво - это всё, что вливаниями не поддерживается. А что вливаниями поддерживается - будь оно хоть 100 раз мертво, тебе придётся на него перейти.
Ну чтож, C# так C#...
Браво!!! Гуманитарии всех стран, соединяйтесь! Добавим ещё больше бардака в экосистему питона подколодного!
Показатель зрелости языка это когда он написан на самом себе. Питон давно уже (пере-)со-зрел, а вот всё ещё не самом себе. Пожтому логично, если бы разработчики написали интерпретатор на статически типизируемом его подмножестве - Cython. Cython - компилятор, к тому же.
> Показатель зрелости языка это когда он написан на самом себе. Питон давно уже (пере-)со-зрел, а вот всё ещё не самом себе. Пожтому логично, если бы разработчики написали интерпретатор на статически типизируемом его подмножестве - Cython. Cython - компилятор, к тому же.PyPy же. :) Ну почти:
> PyPy состоит из стандартного интерпретатора и транслятора. Интерпретатор полностью реализует язык Python. Сам интерпретатор написан на ограниченном подмножестве этого же языка, называемом RPython (Restricted Python). В отличие от стандартного Python, RPython является статически типизированным для более эффективной компиляции
Питон надо на питоне переписать, чтобы он из Питона и бутстрапился. Пока невозможно? Ну так переписывайте как можно больше на Питоне и выкидывайте как можно больше Си, нафига Раст там?
Ну дык так можно и не дождаться пока он соберется
Я конечно не настоящий сварщик, а нельзя на C создать библиотеку, где реализована "безопасная работа с памятью" и просто её использовать везде, вместо того чтобы другой язык тащить в проект?
Ну или я не знаю, написать эту библиотеку на rust и пропихнуть её в системы в качестве базы наряду со всякими libc чтобы использовали её во всех проектах, где парятся о "безопасности".
А вообще если полностью перейдут на rust, то пофиг.
> а нельзя на C создать библиотеку, где реализована "безопасная работа с памятью""Не, мужик, так ты слона не продашь" (с)
Все нормальные так и делают - для работы со структурами данных, использующих динамическую память - хорошо отлаженная и оттестированная библиотека, и нет проблем! Тысячи программ на Си 24/7/365 молотят и обеспечивают нашу информационную жизнь, а растисты только ноют и козыряют надуманными CVEшками.
Нельзя это сделать, проблема будет в кривом использовании функций этой библиотеки. За свободу С надо платить. Даже если писать на С++ в безопасной манере, не выделяя память и не освобождая самому, а только через smart pointers, все равно возможны проблемы. Которые раст решит.
Можно сделать, проблем не будет. А с растом половина мирового интернета слегла, уж решил как решил.
Источники ошибок на Си - корпорасты с их порочными методиками «быстрой» разработки!
Ну, я б не сказал что среди любителей сплошь одни гуру.
Да там и не нужно особым гуру быть, достаточно писать программы аккуратно и сосредоточенно, а не с анимешкой на фоне.
любители пишут то, что нужно лично им, и никто их не торопит
У любителей свободного от работы и личной жизни времени не так много, там тоже многие пишут лишь бы как-то получить результат побыстрее.
тебе-то откуда знать? как-нибудь попробуй у них спросить вместо того, чтобы самому придумывать, как у них "там" и что
> тебе-то откуда знать?Я новости на opennet.ru регулярно читаю.
Да пофиг все равно скоро будет программировать на естественном языке.
Rust нормальный язык, но смешивать код на разных языках это дичь
> Rust нормальный язык, но смешивать код на разных языках это дичьДичь была бы, если они решили разом переписать всё на Rust, что бы не было в проекте разных языков. Ушли бы в "нирвану" на 2-3 года, забив на новые релизы, и только потом бы сделали красивый релиз на одном языке.
А так как они придумали - это правильно. Начнут этот процесс постепенно, эволюционно.
Хэх учитывая что Rust с Сями взаимодействует через огород обвязок, то кодовая база будет еще сложнее и запутанее(и медленней обвязка=до вызов функции)
> Хэх учитывая что Rust с Сями взаимодействует через огород обвязок, то кодовая
> база будет еще сложнее и запутанее(и медленней обвязка=до вызов функции)Если функция на С достаточно большая и часто используемая, то в случае её использования из С-кода тоже мала вероятность, что компилятор сделает для неё inline. Будет использован такой же call с соответствующими затратами времени. А всякую мелочь, которая будет тормозить раст-код по причине отсутствия инлайнига, со временем найдут и портируют в раст.
Си это морально устаревший язык, который не развивается с 90-х годов, только в этом причина взлета RustСи это ноль удобства, максимум скорости, минимум лишнего кода в бинарнике итого микроконтролле онли язык, где сложнее массива структур не используют
После того как Rust стал никому/мало кому (судя по рейтингам) нужен решили запихнуть принудительно в Python
Новость из параллельного мира?
Надеюсь gentoo это поветрие не коснётся и всё ещё можно будет собрать систему без этого "модно-молодёжного". Иначе я ливаю из мира линуксов, с вами было хорошо, но это уже перебор.
