LINUX.ORG.RU

В Debian намерены добавить Rust в число обязательных зависимостей к APT

 , , ,


1

6

Джулиан Андрес Клоде (Julian Andres Klode), основной сопровождающий проект APT, объявил о решении добавить код на языке Rust в пакетный менеджер APT, а также включить в число обязательных зависимостей компилятор Rust, стандартную библиотеку Rust и PGP-инструментарий от проекта Sequoia, написанный на Rust. Изменения намерены реализовать не раньше мая 2026 года, чтобы дать разработчикам портов Debian полгода на реализацию корректной работы инструментария Rust или сворачивание порта.

На Rust планируют реализовать компоненты APT, требующие повышенного внимания с точки зрения безопасности, такие как парсеры форматов deb, ar и tar, а также код для проверки цифровых подписей. Ранее, в состав APT 3.0 уже была добавлена возможность использования написанной на Rust утилиты sqv для проверки цифровых подписей вместо вызова gpgv.

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

Ранее сообщалось, что из-за ошибки в uutils в Ubuntu 25.10 перестала работать автоматическая проверка наличия обновлений.

Оригинал:

Hi all,

I plan to introduce hard Rust dependencies and Rust code into
APT, no earlier than May 2026. This extends at first to the
Rust compiler and standard library, and the Sequoia ecosystem.

In particular, our code to parse .deb, .ar, .tar, and the
HTTP signature verification code would strongly benefit
from memory safe languages and a stronger approach to
unit testing.

If you maintain a port without a working Rust toolchain,
please ensure it has one within the next 6 months, or
sunset the port.

It's important for the project as whole to be able to
move forward and rely on modern tools and technologies
and not be held back by trying to shoehorn modern software
on retro computing devices.

Thank you for your understanding.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

>>> Источник



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от Sm0ke85

Ты глупость сморозил

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

Иди мат часть учи.

Стоицизм – направление в античной философии, согласно которому человек должен освободиться от страстей и влечений и жить, повинуясь разуму. (c)

Не увидел про плети.

Не фантазируй себе лишнего

Я просто попытался проникнуться эмпатией.

diamond_cat
()
Ответ на: комментарий от diamond_cat

Эдвард Сноуден много шуму наделал. Да блин, тот же бэкдор в xz. Если обнаружиться, что какая либо компания действительно целенаправленно устраивала слежку и отключения по собственной частной инициативе - её отменят. А если по инициативе государства - то не отменят. И это плохо, согласен.

Там был и с Ираном недавно, кажется, прецендент, но суть одна, если ты из «договороспособной» страны - ты можешь поискать правду, в противном случае - «пишите письма…»

Sm0ke85
() автор топика
Ответ на: комментарий от Sm0ke85

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

Тупые аналогии это как чугунная редиска…

Если бы ты про тех луддитов

Я и про тех, и про этих читал. Чудное единение в кретинизме, с одинаково ничтожным результатом в итоге.

Смотреть надо на корень проблем…

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

zabbal ★★★★☆
()
Ответ на: комментарий от hateyoufeel

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

firkax ★★★★★
()
Ответ на: комментарий от Sm0ke85

Там был и с Ираном недавно, кажется, прецендент, но суть одна, если ты из «договороспособной» страны - ты можешь поискать правду, в противном случае - «пишите письма…»

И какие выводы из этого? Противостоять тем странам? Реалполитик? Глупость.

Саму концепцию, что такое может происходить, надо подвергнуть сомнению.

diamond_cat
()
Ответ на: комментарий от zabbal

А зачем его собирать? Он ведь уже собран.

Собирают сборщики.

usermod
()
Ответ на: комментарий от usermod

Сборка должна вестись в отдельных контейнерах, в управляемом окружении, а не вот это все…

«Вы знаете, я тут подумал, можно обновлять ПО по сети, без использования cd-rom».

Офигеть ты гений конечно - сумел переоткрыть общепринятую примерно с момента изобретения этих самых контейнеров практику. С нетерпением жду новых откровений - уверен что ты ещё не раз сумеешь порадовать :-D

zabbal ★★★★☆
()
Ответ на: комментарий от diamond_cat

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

Может глупость, а может и нет, вот только в том сообщении был юмор и сорказм…

Стоицизм – направление в античной философии, согласно которому человек должен освободиться от страстей и влечений и жить, повинуясь разуму. (c)

Не увидел про плети.

Потому что ты не читал стоиков, например, Марка Аврелия, Эпиктета - они были достаточно суровы к себе, т.к. только через лишения и дискомфорт можно адекватно воспринимать окружающую действительность и себя…

Я просто попытался проникнуться эмпатией.

Вот почитай все таки про стоицизм, там эмоции отдельно рассматриваются…

Sm0ke85
() автор топика
Ответ на: комментарий от her_s_gory

Ты правда с логикой не очень?

Ты как будто в первый раз это заметил. Он же системг-фанатик, там здравого ума ждать не стоит. У него почти в каждом сообщении позор происходит.

firkax ★★★★★
()
Ответ на: комментарий от BerlinFall

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

А почему, собственно? По-моему просто возможности писать императивный код вполне достаточно.

WebAssembly не очень практично для этой цели

Это же просто деталь реализации, а не принципиальное ограничение.

Языки вроде OCaml плохо ложатся на эту архитектуру

Почему? Он же компилируемый - под какую архитектуру надо, под такую и ляжет.

zabbal ★★★★☆
()

На Rust планируют реализовать компоненты APT, требующие повышенного внимания с точки зрения безопасности…

Если так важна безопасность, то почему выдумали Rust, а не взяли уже давно существующий Ada?

Mischutka ★★★★★
()
Ответ на: комментарий от diamond_cat

И какие выводы из этого? Противостоять тем странам? Реалполитик? Глупость.

Саму концепцию, что такое может происходить, надо подвергнуть сомнению.

А это проблематично, т.к. такому положению дел около 10 тыс. лет, и особых свидетельств удачного подвержения сомнениям данной концепции особо мне не попадалось…

Sm0ke85
() автор топика
Ответ на: комментарий от her_s_gory

Это стало причиной добавлять компилятор плюсов в обязательные зависимости apt?

Да, через build-essential. Предлагаешь добавить туда вместо самого apt? Полностью поддерживаю.

zabbal ★★★★☆
()
Ответ на: комментарий от zabbal

Можно, разрешаю.

А ты кто? Очередной упал, намоченный?

dataman ★★★★★
()
Ответ на: комментарий от Sm0ke85

Может глупость, а может и нет, вот только в том сообщении был юмор и сорказм…

В каждой шутке доля правды ;)

Потому что ты не читал стоиков, например, Марка Аврелия, Эпиктета - они были достаточно суровы к себе, т.к. только через лишения и дискомфорт можно адекватно воспринимать окружающую действительность и себя…

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

И мне ближе мораль добродетели. Но вообще да, надо читать и читать…

diamond_cat
()
Ответ на: комментарий от Saakx

ядро уже от Rust зависит

Пока нет, но очень надеюсь что в ближайшем будущем именно так и будет.

zabbal ★★★★☆
()
Ответ на: комментарий от zabbal

Пока нет, но очень надеюсь что в ближайшем будущем именно так и будет.

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

Проблемы пока не решены. Можно собирать только если проект сам тащит все от чего зависит. И тогда начинаются проблемы с отслеживанием всего что тащат.

x86_64 ★★★
()
Ответ на: комментарий от firkax

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

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

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

Stanson ★★★★★
()

Перечитал весь мейлинг лист. Короче «за» только ОП и чувак (Angsar) с эмодзи в никнейме.

А вот по пунктовая критика, озвученная тут: https://lists.debian.org/debian-devel/2025/11/msg00039.html от David Kalnischkies:

(далее перевод от робота, чтобы вы не утонули в тонне английского)


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

Пт, 31 октября 2025 г., 21:48:46 +0100, написал Julian Andres Klode:

В частности, наш код для разбора .deb, .ar, .tar и т. д.

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

Мы «нуждаемся» в этом коде в двух местах:

  • apt-ftparchive, устаревающий инструмент, который, насколько я знаю, серьёзно используется только вашим работодателем — в Launchpad, верно?

    Конечно, наши тесты (да, у нас они есть, даже если вы утверждаете обратное) активно используют его тоже, но под «серьёзно» я в основном подразумеваю часть, связанную с BDB. Даже если предположить, что нам придётся сохранять его навсегда, всё равно стоит вынести его из исходников apt — это позволит, например, внедрять новые способы подписания репозиториев и создавать их в новых версиях так, чтобы администраторы могли перейти на них проще и безопаснее, чем обновлять весь apt только ради генерации репозиториев нового формата.

    Язык реализации здесь не имеет большого значения — никто не требует, чтобы порт был полностью самодостаточным; например, dak написан на Python.

    Также отмечу, что я не могу вспомнить последнюю ошибку работы с памятью в этом месте — и вообще не считаю это серьёзной проблемой, поскольку предполагается, что deb/tar/ar-файлы, которые мы здесь обрабатываем, являются доверенными данными. Если это не так, то проблемы с памятью — самое меньшее, о чём стоит беспокоиться… (хотя, учитывая Launchpad, полагаю, вы обязаны смотреть на это иначе).

  • apt-extracttemplates — инструмент, который вообще не должен был оказаться в исходниках apt, но, как известно, ничто не бывает таким постоянным, как временное решение.

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

    К тому же старый или заново портируемый дистрибутиву вообще всё равно, на каком языке это написано — никто не станет оспаривать выбор языка реализации как преимущество.

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

И как именно язык программирования и тестирование связаны с Rust, я не совсем понимаю. Писать модульные тесты можно и на C++ — мы это делаем. Основная проблема в том, что кто-то должен эти тесты написать. Как и документацию.

Ваш новый решатель (solver), например, вообще не имеет тестов (кроме наших старых интеграционных). Вы ведь не утверждаете серьёзно, что это из-за C++? Если вам не нравится GoogleTest, который мы используем сейчас, я мог бы предложить doctest (как уже предлагал ранее). Существует множество других фреймворков с разными подходами.

Код проверки подписи HTTP действительно выиграл бы от языка с безопасностью памяти и более серьёзного подхода к модульному тестированию.

Может, тогда стоит и транспорты вынести отдельно? Системы, которым не нужен http-транспорт, — это, вероятно, единороги, которым несложно его установить в любом случае. Но и тут польза от выделения транспорта в отдельный компонент очевидна — он мог бы выпускаться и обновляться независимо от самого apt. Я не стану на этом настаивать, но факт остаётся фактом — этот участок тоже не относится к тем, где у нас бывают проблемы с памятью. (Если честно, проблемы с памятью вообще не характерны для apt… или вы можете назвать последний сбой, вызванный именно языком, а не реализацией на любом языке, как, скажем, [#1119056]?).

Для тех, кто не в курсе — транспорты это отдельные бинарные программы, которые выполняются libapt и общаются с ним по текстовому протоколу. Вынести их из исходников apt — тривиально. Как и переписать их на любом языке, который вам нравится.

Теоретически, мы могли бы даже иметь разные реализации: например, нашу «старую» собственную реализацию HTTP/1.1 со всем исторически накопленным багажом — и новые, использующие внешние библиотеки для работы с более современными версиями HTTP, написанные на Rust (или хоть на Perl, Python или Brainfuck — всё равно).

Разумеется, у нас есть и другие участки кода, вроде парсеров deb822, которые действительно являются «горячими путями». И хотя в этом письме вы их не упомянули, уверен, вы тоже думаете о том, чтобы переписать их. Для таких случаев, как справедливо отметил Russ в своём письме, стоит провести серьёзный анализ выгод (который, как он полагал, уже был сделан). И простое клише вроде «это язык с безопасностью памяти» здесь явно не аргумент.

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

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

Лично я сомневаюсь, что введение ещё одного языка в уже и без того сложную систему, над которой, по очевидным причинам, никто¹ не хочет работать, — это хорошая идея. Да, язык модный и популярный, но Python тоже популярен, а я что-то не вижу бурной активности вокруг python-apt (или каких-либо других языковых биндингов, если уж на то пошло).

Может быть, просто дело не в языке реализации?

С наилучшими пожеланиями, Дэвид Кални́шкис (David Kalnischkies)

¹ Поскольку я сейчас — ведущий «никто» по количеству вкладов в исходный код apt (согласно git shortlog), лёгкая гипербола, надеюсь, простительна. В конце концов, после 16 лет я всё ещё, технически, самый «новый» участник команды apt — и, значит, формально имею право на «защиту новичка».

P.S. Учитывая, что apt по своей сути — антитеза концепции «бандлинга» и статической компоновки, можно утверждать, что apt сам по себе — ретро-технология, и не должен мешать современным инструментам и технологиям, которые не заботятся о таких наследиях, как разделяемые библиотеки, форматы пакетов, зависящие от дистрибутива, и связанные с ними менеджеры.

Все эти участники Debian, которые «впихивают» современное ПО в пакеты для ретро-технологий вроде apt и dpkg… (Я шучу… или нет?)

PPP328 ★★★★★
()
Ответ на: комментарий от x86_64

Проблемы пока не решены. Можно собирать только если проект сам тащит все от чего зависит.

Это как? Есть ссылка на обсуждение?

zabbal ★★★★☆
()
Ответ на: комментарий от aol

Там автор программулины флаг забыл. Новость растиражировали, а на самом деле автор пакета «с багом» - косячник. У uutils было несколько других, реальных багов открыто за месяц использования, почти все уже кстати закрыты.

ac130kz ★★★
()
Ответ на: комментарий от zabbal

Почему? Он же компилируемый - под какую архитектуру надо, под такую и ляжет.

Потому что функциональная программа нетривиальным образом транслируется в императивную, например, появляется необходимость тянуть либо GC в рантайм, либо линейные типы в компилятор, либо ещё какое‐нибудь ухищрение или допущение; и наоборот, в лямбда‐исчисление транслируется напрямую (чего и следует ожидать), в тривиальных случаях и вовсе простым стиранием типов.

Эти проблемы, конечно, хорошо изучены; но всё равно такая трансляция представляет собой дополнительный и, что важно, нетривиальный слой абстракции. Особенно если мы рассуждаем о языке с верификацией и/или системном языке, каждый такой слой — дополнительная проблема, потому что встаёт вопрос о корректности этого слоя. Другими словами, язык может иметь корректный тайп‐чекер, который гарантирует memory safety (может быть, даже с математическим доказательством этого), но если транслятор в машинный код постоянно генерирует некорректную бурду, то никакой тайп‐чекер не спасёт от падений в рантайме.

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

А почему, собственно? По-моему просто возможности писать императивный код вполне достаточно.

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

BerlinFall
()
Ответ на: комментарий от zabbal

Да по ссылке здесь же (как в панамку накидали) пошел.

А там обсуждение проблем статической компоновки. И отсылка к тем кто firefox собирает. Типа они же как-то решили. Один из них честно сказал, что никак не решили.

Ну и дальше обсуждались технические детали.

x86_64 ★★★
()
Ответ на: комментарий от x86_64

Ага, так решили, что из-за сложности саппорта пакетов раста фокс несколько недель сидел без решения 76+ багов.

PPP328 ★★★★★
()
Ответ на: комментарий от BerlinFall

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

И? Ты же сам говоришь:

Эти проблемы, конечно, хорошо изучены

Они ещё и решены несколькими разными подходами.

если транслятор в машинный код постоянно генерирует некорректную бурду

То это будет выловлено на этапе разработки транслятора

то никакой тайп‐чекер не спасёт от падений в рантайме

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

упрощение структуры в целом увеличивает надёжность

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

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

если мы хотим тащить в системный язык функциональные возможности

Конечно хотим. Я бы вообще везде их затащил :)

нужно тащить всю необходимую сложность

Вообще проблемы не вижу. Ну нужно, да. Без труда - из пруда и всё такое.

в системных вопросах её и так достаточно

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

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

zabbal ★★★★☆
()
Ответ на: комментарий от zabbal

Собственно, триумфальное шествие rust в качестве замены С

Пациент неизлечим, уносите.

PPP328 ★★★★★
()
Ответ на: комментарий от x86_64

А там обсуждение проблем статической компоновки.

Там 100500 сообщений же - я только про vendoring нашёл, но оно к rust вообще никаким боком не относится.

и дальше обсуждались технические детали.

Так именно они же и интересны - мы ж всё-таки на техническом форуме :)

zabbal ★★★★☆
()

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

А компилятор нафига?

router ★★★★★
()
Ответ на: комментарий от zabbal

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

Ага, триумфальностью все заплескало, один отсчипенец его единой волей толкает и в понамку получает, еще только просто решили переписать уже баги готовятся ловить на 4 года вперед…

Там гугл Фуксию частично на русте написали - оно оказалось никому не нужным, триумфально бери его, ни в чем себе не отказывай, ахах))))

Sm0ke85
() автор топика
Ответ на: комментарий от zabbal

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

Это совершенно точно ЛИШНЯЯ и бесполезная зависимость. Если, конечно, язык копилируемый (как rust), а не интерпретируемый (как perl)

router ★★★★★
()
Ответ на: комментарий от router

Это совершенно точно ЛИШНЯЯ и бесполезная зависимость.

А как ты собрался компилировать без компилятора?

zabbal ★★★★☆
()
Ответ на: комментарий от zabbal

А как ты собрался компилировать без компилятора?

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

Ну разве что кулхацкерам

router ★★★★★
()
Ответ на: комментарий от Sm0ke85

один отсчипенец

Линус что ли? Кстати, в курсе, что GStreamer тоже потихоньку пишет новые компоненты и переписывает старые на расте?

unC0Rr ★★★★★
()
Ответ на: комментарий от router

Это задача программиста и мейнтейнера.

И именно они и хотят себе соответствующую зависимость. Ты-то с чего пригорел вдруг?

Для запуска приложения, написанного на компилируемом языке, компилятор не нужен

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

zabbal ★★★★☆
()
Ответ на: комментарий от zabbal

И именно они и хотят себе соответствующую зависимость. Ты-то с чего пригорел вдруг?

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

Обрани внимание, не в сборочные зависимости, а в зависимости

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

Кхм. Ты с менеджером пакетов работал? Зависимости и сборочные зависимости - две большие разницы

router ★★★★★
()
Ответ на: комментарий от router

Обрани внимание, не в сборочные зависимости, а в зависимости

Уже обронил. Это письмо в профильную рассылку для технарей - там не нужно вытирать сопли и пояснять очевидные детали, все и так в курсе.

Зависимости и сборочные зависимости - две большие разницы

Естественно. С какого перепугу ты решил что rust хотят включить в рантайм-зависимости, а не просто в зависимости? В оригинале про это ни слова.

zabbal ★★★★☆
()
Ответ на: комментарий от zabbal

И часто у тебя такое случается?

Неважно, часто или не очень; тут и не только тут достаточно, условно говоря, утверждающих, что у них и утечки памяти никогда не происходят, но это не повод игнорировать существование проблемы (как решать — другой вопрос), пускай и кажущейся чисто теоретической в настоящее время. Вот я выше сослался на формальную модель x86, которую там используют для верификации бинарного файла (что, кстати, очень интересно); но зачем они это делают, если проблемы при генерации машинного кода так редки?

Компилятор brainfuck проще некуда, его даже формально верифицировать можно, хоть и бессмысленно.

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

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

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

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

BerlinFall
()
Ответ на: комментарий от zabbal

Это письмо в профильную рассылку для технарей - там не нужно вытирать сопли и пояснять очевидные детали, все и так в курсе.

Вау. В профильной рассылке для технарей общаются на языке менеджеров? Убиться веником :)

С какого перепугу ты решил что rust хотят включить в рантайм-зависимости, а не просто в зависимости?

Имеенно об этом сказано в тексте новости

router ★★★★★
()
Ответ на: комментарий от firkax

Потому что -O2 корректно компилирует ограниченное подмножество языка

А авторы компиляторов об этом знают? Мб им стоит баг-репорты написать?

hateyoufeel ★★★★★
()
Ответ на: комментарий от BerlinFall

Неважно, часто или не очень;

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

зачем они это делают, если проблемы при генерации машинного кода так редки?

Классическая академическая работа:

представляет некоторую учебную ценность

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

zabbal ★★★★☆
()
Ответ на: комментарий от zabbal

Так можно и Rust списать со счетов: опять же, по утверждениям некоторых, проблемы с памятью редки, а максимально распространённые классы ошибок — это алгоритмические ошибки (что бы это ни значило), и вообще, линейные типы и прочее — какой‐то академический прикол. Но это же глупость, верно?

BerlinFall
()
Ответ на: комментарий от router

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

C чего ты взял? У тебя с английским не очень?

Имеенно об этом сказано в тексте новости

Где конкретно? Там вообще ни слова про рантайм зависимости.

zabbal ★★★★☆
()
Ответ на: комментарий от hateyoufeel

Авторы компиляторов немного не в себе и слать им багрепорты бесполезно. Вот допишу свой в нём всё будет норм из коробки.

firkax ★★★★★
()
Ответ на: комментарий от BerlinFall

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

Кому интересны эти некоторые если есть нормальная статистика с bug bounty?

Но это же глупость, верно?

Естественно. Однако речь же про системный ЯП - это нишевое применение, и ограничения этой ниши всё-равно придётся учитывать.

Никто не будет писать драйвера используя трюки с зависимыми типами мощность в 100 миллиОлег :)

zabbal ★★★★☆
()
Ответ на: комментарий от firkax

Авторы компиляторов немного не в себе и слать им багрепорты бесполезно. Вот допишу свой в нём всё будет норм из коробки.

Ну то есть, как я уже писал:

Погоди. Но ведь это ты тут жалуешься на то, что компиляторы тебе код ломают своими оптимизациями при включении -O2 или -O3. Или это другое?

Это не ты неправильно используешь Си, а компиляторы плохие. Чем это отличается от

Надо просто гнать нафиг всех тех кто жалуется на «ой, компилятор меня не верифицировал и поэтому я допустил баг».

?

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от zabbal

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

Stanson ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.