Ubuntu 26.10 полностью переводит Coreutils на Rust и лицензию MIT после аудита и исправления десятков проблем

запустил тест-проверил

Возьмём банальный off-by-one и обращение на один символ за пределы массива как в этом коде: Mergiraf — новый движок разрешения конфликтов в коде (комментарий). Тесты проходят, вывод работает, всё отлично на первый взгляд. А потом понадобится изменить размер массива, и выход на один символ за пределы приведёт к обращению неаллоцированной страницы памяти и сегфолту. И поймать это можно на этапе разработки только если уже знать, что ищешь. Либо использовать язык, в котором такая ситуация невозможна.

нужна динамическая типизация + repl

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

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

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

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

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

Какой из путей короче, в принципе уже всем понятно

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

Вопрос цены тому коду пока остаётся открытым.

По моему опыту, на языках со строгой статической типизацией, писать (и особенно рефакторить) легче. Когда в питоне у тебя вылетит неожиданный «TypeError:‘str’ object is not callable.» на четвёртом часу работы программы, ты идёшь и смотришь весь код в попытках понять, откуда просочилась строка. В расте тебя ткнут носом в ту самую строчку при первой же попытке компиляции.

А это не одно и то же? Путь из Москвы в Ярославль по М8 быстрее и дешевле, чем с заездом в Сочи.

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

А это не одно и то же? Путь из Москвы в Ярославль по М8 быстрее и дешевле, чем с заездом в Сочи.

То есть шутка про полёт из Магадана в Анадырь через Москву вам неизвестна? Я тоже летал из Чикаго в Белиз через Монреаль. Да, такое бывает. Бывает, что и дешевле и, что забавно, быстрее.

repl lisp’а помогает гораздо лучше. В лиспе я могу написать функцию, которая, вообще говоря, некорректна по типам, но работает ровно для того частного случая, который я хочу прямо сейчас проверить. А хаскель так не умеет, нужно править не только код, связанный с проверяемой гипотезой, но ещё и кучу всего вокруг него. Это всё ещё гораздо лучше и быстрее, нежели «правка → компиляция → прогон тестов», но раздражает своим несовершенством.

Мешает там, где хотят чуток подкрасить, зажать патчи

Я вообще не обязан никуда «высылать патчи». Я могу этот кусок кода выложить у себя на сайте и все.Или сделать еще проще, что никто не докопался. Так-же могу выложить свою, правленную версию библиотеки и так длаее. Что-то кому-то высылать я - совершенно не обязан :)

вытеснить оригинал

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

Но переписывать то, что и так хорошо работало - непонятно.

Как раз таки понятно. Попробуй напиши что-то новое, да так, чтобы оно стало лучше и популярнее давно существующих аналогов. Сложно?

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

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

lfs дистры станут самыми стабильными..

В питоне тоже можно упарываться за статическую типизацию, обмазываясь тайпчекерами (pyright, mypy, prefly, ty и т.п.). А можно просто запускать код безо всяких проверок. Это не исключающие возможности, а дополняющие друг дружку.

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

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

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

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

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

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

Это можно сказать про любой инструмент. Впрочем, плюс Питона в том, что это достигается легко.

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

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

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

Если сделать ошибочные состояния программы невыразимыми, то поймает.

А если не получается - назвать их фичами?

«Любая дичь» сводится к одному из пяти пунктов:

Этого джентльменского набора более чем достаточно для всякой дичи.

В Rust вообще никто не знает, что является UB, прикинь, даже авторы!

И авторы допускают кучу UB в unsafe-секциях в стандартной библиотеки.

Авторы Си — наркоманы? (комментарий)

Авторы Си — наркоманы? (комментарий)

Авторы Си — наркоманы? (комментарий)

И это всплывает на практике: Авторы Си — наркоманы? (комментарий)

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

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

Пользуются в полный рост.

И это - один из драйверов толкания законов об авторских правах в сферу ИИ. Сейчас пока анархия - можно все :).

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

Может быть тогда автор - Мосфильм? Ну, тогда и отвечать за непотребство в ролике должен Мосфильм. Вот такая вот проблемка.

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

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

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

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

Да, это может стать проблемой. Будем посмотреть.

сразу показывает ошибку

как она показывает ошибки ещё на этапе написания

Как известно, проблема вывода ошибок коммандой GCC была изначально игнорирована. Почему так вопрос отдельный. Когда начинался LLVM, этой проблеме было уделено особое внимание. Упор был сделан не столько на подробное объяснение, что произошло, но где это произошло, как могло произойти, и как исправить. Вот это «как исправить» особенно важно для человека. Ясно, что современный компилятор должен не только быть лучше LLVM, но и ориентироваться на современные средства разработки (например, я бы подумал, как вывести часть MLIR для некоторых частей кода, это помогло бы и в оптимизации и при отладке).

Ничто не мешает создать универсальный API для взаимодействия компилятора и кодогенератора минуя медленного и глупого оператора. Кстати, это может позволить прямо корректировать backend, минуя язык программирования как таковой. Упс, есть подозрение, что эта идея не всем понравится :).

До первого апреля вроде бы далеко ещё.

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

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

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

Не для спора ради спора, а в качестве иллюстрации ввиду следующий тезис. В коммерческой разработке участники предыдущего этапа почти никогда не участвуют в следующем этапе. Вообще, количество участников проекта, которые участвуют в проекте в течение всего его жизненного цикла, очень маленькое. Обычно это менеджмент высшего и редко среднего звена. Конечные исполнители практически никогда не участвуют в планировании. Именно поэтому ситуация «а чё это они имели в виду?» при рассматривании deliverables вообще повсеместно, и странно, если тех. задание понятно от начала до конца. «Это неправильно!» - как говорил Джигарханян в «Раз на раз не приходится».

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

Этот мешающий флуд и в gcc теперь добавили, я его разумеется везде отключил. Нет, нормальному программисту не нужны советы от компилятора о том, как что-то исправить, ему нужно только точное указание на проблемное место. В большинстве случаев достаточно даже просто номера строки в файле, и при взгляде на неё и так будет ясно что с ней не так, иногда полезно и собственно описание ошибки (короткое, вида «undefined identifier XXX» или «incompatible typecast in argument 5»).