В мире разработки программного обеспечения, особенно в области системного программирования, языки C и Rust занимают особое место. C, как проверенный временем язык, десятилетиями служил основой для создания операционных систем, включая Linux. Однако с появлением Rust, который позиционируется как более безопасный и современный ЯП, начались жаркие споры о том, стоит ли переписывать части ядра Linux на Rust или оставить всё как есть. Дискуссия вышла на новый уровень, когда разработчики Linux начали активно сопротивляться внедрению Rust. Кристоф Хеллвиг даже сравнил нововведение с «раковой опухолью». Что стоит за этим противостоянием, и почему Rust вызывает такие полярные мнения?
Почему Rust вызывает бурные дискуссии?
Rust был создан с целью устранить недостатки C и C++, такие как уязвимости, связанные с управлением памятью, и неопределенное поведение. Rust действительно устраняет целый класс проблем, связанных с use-after-free, double free, null dereference и data race благодаря системе владения (ownership) и строгой проверке заимствования (borrowing). Однако именно эти особенности делают его сложным для интеграции в существующие проекты, написанные на C, такие как ядро Linux.
Кристоф Хеллвиг (Christoph Hellwig), один из ключевых разработчиков ядра Linux, высказал резкую критику в адрес Rust. Он заявил, что поддержка многоязыковых проектов, таких как ядро Linux, где одновременно используются C и Rust, является «болью» и усложняет процесс разработки. Хеллвиг, как сказано выше, сравнил внедрение Rust с «раковой опухолью», подчеркнув, что это не относится к самому языку, а скорее к проблемам, которые возникают при смешивании разных языков в одной кодовой базе.
Одной из главных проблем, на которую указывают противники Rust, является сложность поддержки кода, написанного на разных языках. Ядро Linux — это огромная кодовая база, которая развивалась десятилетиями. Внедрение Rust требует создания интерфейсов между C и Rust, что увеличивает сложность и может привести к ошибкам.
Хеллвиг подчеркивает, что интерфейсы к API, таким как DMA (Direct Memory Access), должны оставаться в читаемом коде на C, чтобы их было легче поддерживать. Он также выразил сомнение в том, что Rust сможет стать полноценной заменой C в ядре Linux, учитывая его относительную новизну и отсутствие опыта использования в таких масштабных проектах.
Rust сам по себе не является универсальным решением. У этого языка и его интеграции в ядро Linux есть свои недостатки, которые нельзя игнорировать.
Например, несмотря на все преимущества Rust, полностью отказаться от C в ядре Linux пока невозможно. В некоторых случаях разработчики вынуждены идти на компромиссы между безопасностью, которую предлагает Rust, и производительностью, которую обеспечивает C. Скажем, низкоуровневые операции или критически важные для производительности участки кода могут требовать использования C, чтобы упростить работу с абстракциями Rust.
Есть и проблемы с производительностью из-за рантайм-проверок. Одной из ключевых особенностей Rust является его система владения и заимствования, которая предотвращает множество ошибок на этапе компиляции. Однако в некоторых случаях это требует дополнительных проверок во время выполнения, что может негативно сказаться на производительности. Для ядра Linux, где каждая микросекунда на счету, такие накладные расходы могут стать серьёзной проблемой.
Более того, внедрение Rust в ядро Linux — это не только технический, но и организационный вызов. Многие разработчики, годами работающие с C, не готовы переходить на новый язык. Кто-то не согласен с таким решением, кто-то не хочет тратить время на изучение Rust, а кто-то просто считает, что текущий подход с использованием C достаточно эффективен. Это приводит к конфликтам и длительным дискуссиям, которые часто выходят за рамки технических вопросов. Именно такие «нетехнические споры» и упоминал Ведсон Алмейда Фильо, когда говорил о «бесполезной ерунде», которая мешает прогрессу.
Аргументы в пользу Rust
Несмотря на критику, у Rust есть множество сторонников, которые видят в нем будущее системного программирования. Кис Кук (Kees Cook), разработчик из Google, утверждает, что Rust может значительно повысить безопасность ядра Linux. По его словам, многие уязвимости в ядре связаны с ошибками управления памятью, которые Rust помогает предотвратить на этапе компиляции.
Проект Rust for Linux, запущенный в 2020 году, ставит своей целью внедрение Rust в ядро Linux. Однако этот проект столкнулся с серьезными трудностями. В сентябре 2024 года один из ключевых разработчиков проекта, Ведсон Алмейда Фильо (Wedson Almeida Filho), покинул его, сославшись на «бесполезную нетехническую ерунду» и отсутствие прогресса.
Мини-драйвер как катализатор конфликта
Одним из триггеров для обострения споров стал небольшой патч, который позволял драйверам, написанным на Rust, использовать функцию C API DMA dma_alloc_coherent(). Этот патч вызвал бурную реакцию Хеллвига, который потребовал не добавлять код Rust в раздел kernel/dma. Хотя позже выяснилось, что патч был добавлен в другой раздел, это не остановило критику.
Мигель Охеда (Miguel Ojeda), один из участников проекта Rust for Linux, попросил Хеллвига предложить альтернативу, но получил резкий ответ: «Сохраняйте оболочки в своем коде, вместо того чтобы усложнять жизнь другим». Хеллвиг также заявил, что интерфейсы к API DMA должны оставаться в читаемом коде на C, чтобы их было легче поддерживать.
Несмотря на сопротивление, многие разработчики продолжают выступать за внедрение Rust в ядро Linux. Они считают, что Rust может стать важным инструментом для повышения безопасности и надёжности ядра. Однако процесс интеграции Rust в Linux замедлился, и будущее проекта Rust for Linux остается под вопросом.
Гектор Мартин (Hector Martin), руководитель проекта Asai Linux, считает, что последнее слово в этом споре должно остаться за Линусом Торвальдсом (Linus Torvalds), создателем Linux. По его мнению, если Торвальдс примет pull request с кодом на Rust, то это станет сигналом для дальнейшего развития проекта. Если же нет, то Rust for Linux, скорее всего, будет заброшен. В ответ Торвальдс отметил, что медиа-кампании не способствуют решению технических вопросов и предложил сосредоточиться на технических обсуждениях.
Споры вокруг Rust в ядре Linux отражают более широкую дискуссию о будущем системного программирования. С одной стороны, Rust предлагает современные решения для повышения безопасности и надёжности кода. С другой, его интеграция в существующие проекты, такие как Linux, сопряжена с серьёзными техническими и организационными трудностями.
Пока разработчики Linux продолжают спорить, ясно одно: будущее Rust в ядре Linux зависит не только от технических преимуществ языка, но и от готовности сообщества принять изменения. Возможно, Rust действительно станет «лекарством» для Linux, но только если разработчики смогут преодолеть свои разногласия и найти компромисс.
Комментарии (146)
Free_ze
09.02.2025 09:38TL;DR.: Некий Christoph Hellwig устраивает срачи в сообществе, будучи противником второго языка в проекте. Конкретики и технических деталей относящихся к языкам в статье нет.
AnimeSlave
09.02.2025 09:38Тут история как раз наоборот. Срач устроили адепты Rust. В привычной им манере выйти в Twitter, и там написать гневное письмо. Я даже видел срачи во всяких Rust пабликах. А по факту, если разбирать конкретную ситуацию, можно заметить, что Кристоф не отказывает авторам патчей на Rust воспользоваться другим путём, добавив не обобщённую обвязку на весь DMA API, а на каждый драйвер в отдельности. И в этом есть рациональное зерно. Потому что если проблема будет только в драйвере, то его можно одного будет откатить или заблокировать без серьёзных проблем. А если проблема будет во всём DMA, то восстановление работоспособности может быть проблемой, так как нужно будет искать проблему не в коде одного языка программирования. И это сложно. Я это знаю, так как работал с многоязыковой кодовой базой. Тот ещё геморрой
Free_ze
09.02.2025 09:38Я не в курсе ситуации, претензия была к качеству пустопорожней статьи, которая местами одну мысль гоняет трижды) "TL;DR.:" предваряет основные тезисы для экономии времени читателя.
krendelbok
09.02.2025 09:38И в этом есть рациональное зерно. Потому что если проблема будет только в драйвере, то его можно одного будет откатить или заблокировать без серьёзных проблем.
Не правда. Крис предлагает копипастить одни и те же обвязки в каждый драйвер и если в С коде что-то поменяется, то все эти обвязки нужно будет такой же копипастой менять. Главное, чтобы в его папке никакого раст кода не было, а то проект будет тяжело "грепать"
What does "your code" mean? Duplicated in every driver?
Yes, interfaces to the DMA API should stay in readable C code and not
in weird bindings so that it reminds greppable and maintainable.AnimeSlave
09.02.2025 09:38Не правда. Крис предлагает копипастить одни и те же обвязки в каждый драйвер и если в С коде что-то поменяется, то все эти обвязки нужно будет такой же копипастой менять. Главное, чтобы в его папке никакого раст кода не было, а то проект будет тяжело "грепать"
А я по вашему не это же написал? Его предложение связано с поддержкой. И я его предложение понимаю. Потому что я знаю, что из себя представляет кодовая база из разных языков.
krendelbok
09.02.2025 09:38Его предложение связано с поддержкой.
Нет, раст код будет поддерживаться только раст командой и будет работать только если в конфиге раст включить. Если же выключить, то это никак не повлияет на С код.
Потому что я знаю, что из себя представляет кодовая база из разных языков.
Ну прям достижение. Я всю свою карьеру работал с разными языками в одном проекте и ничего, разобрался как-то. Для веба это вообще-то характерно, совмещать бек и фронт в монорепе.
AnimeSlave
09.02.2025 09:38Нет...
А вы читали то, что сам Кристоф писал? Он именно о поддержке кодовой базы писал. И я имел в виду именно это. Почему вы отрицаете это? У вас проблемы с тем, что Rust притесняют? Не хотите молчать об этом?
Я всю свою карьеру работал с разными языками в одном проекте и ничего, разобрался как-то
А в вашем проекте писали ли код на двух языках для одной библиотеки? Когда одна часть библиотеки написана на Pascal, а другая на C. И это одна библиотека. А на трёх? Или писали ли вы C#/C++/CLI код? И вы один, кто весь этот код поддерживает. Не группа программистов, каждый из которых знает только свой язык и отвечает только за свою область компетенции. А всего один человек. Я вижу, что вы не понимаете всю особенность той проблемы о которой пытался рассказать Кристоф. Потому что у вас странное отношение к ситуации. Особенно с учётом того, что Кристоф сам не программист на Rust.
У программистов на C (или других структурных языков) другой склад ума, так как код для них должен быть линеен. Rust, из-за наличия trait'ов и макросов может скрывать реализации алгоритмов, что для программистов на C не приемлемо. В свой время по схожей причине отказались от C++ в ядре. В итоге даже кода на Pascal нет в ядре, так как у Pascal есть особенности с размещением данных в памяти. А ведь Pascal в каком-то смысле менее подвержен ошибкам, чем C.
Чтобы было понимание, я сам не против Rust. И только за развитие его в ядре. Но проблема из-за которой появился этот пост - сугубо инфантильная. Сообщество программистов ядра робеет за стабильность. Именно поэтому они отказываются от серьёзных изменений в ядре
krendelbok
09.02.2025 09:38А вы читали то, что сам Кристоф писал? Он именно о поддержке кодовой базы писал
А вы читали, что "раст фанатики" писали или сами придумали?
Again, no one asks you to deal with or maintain this piece of Rust code.
Чуваку явно 2-3 раза повторили, что от него не требуется никакая поддержка. Как можно такое пропускать?
Почему вы отрицаете это?
У программистов на C (или других структурных языков) другой склад умаМне все ясно. Можете дальше не продолжать, с другим складом ума вам наверное пора в спецучереждение для людей "с другим складом ума"
AnimeSlave
09.02.2025 09:38А вы читали, что "раст фанатики" писали или сами придумали?
Я прочитал всё ветку. И знаю, что предлагали Rust программисты. Но вы не просто так указали про фанатиков, верно? Вы мне так противопоставляете какие-то мои слова. Но ведь я про фанатиков нигде не писал. Я указал адептов ранее, в контексте, что неразобравшись в проблеме они понесли новость, будто их святыню - Rust - обидели в ядре linux.
Чуваку явно 2-3 раза повторили, что от него не требуется никакая поддержка. Как можно такое пропускать?
Почему не требуется поддержка, если это его прямая обязанность? Как раз у людей, кто раздул из этого срач, проблема с восприятием, особенно непонимающих, как это - работать с кодом, которому уже больше 30-и лет. Что просто так людей не меняют в проекте только из-за того, что кто-то другой в код влил патч. Rust'у в ядре быть, но не так как хотят авторы rust-кода.
Мне все ясно. Можете дальше не продолжать, с другим складом ума вам наверное пора в спецучереждение для людей "с другим складом ума"
Если вы здесь, значит там день открытых дверей
krendelbok
09.02.2025 09:38Если вы здесь, значит там день открытых дверей
Для меня программисты такие же люди, как и любой другой профессии. Нету ни у кого никакого "другого" склада ума, особенно у "С" программистов. Всего лишь дело привычки и навыка, который может развить любой человек. Зато сразу понятен ваш уровень ЧСВ. Попроще надо быть.
AnimeSlave
09.02.2025 09:38То есть вы бросаться оскорблениями можете, а другим нельзя? А не у вас ли ЧСВ? Я здесь вам только оппонирую. Если бы хотели остановиться, то остановились бы. Но я вас задел, ведь. И вы не можете молчать
krendelbok
09.02.2025 09:38То есть вы бросаться оскорблениями можете
Примеры будут?
Но я вас задел, ведь
Не перепутали? Это я вас так задел, что аж про "другой" склад ума полезло. А то лезут всякие "тупые" в священную башню со слоновой кости. Меня это очень позабавило. Я вообще к расту отношения не имею, мне все равно на каких языках ядро написано, лишь бы работало хорошо.
AnimeSlave
09.02.2025 09:38Примеры будут?
Вы «на двачах» учились беседы вести?
Можете дальше не продолжать, с другим складом ума вам наверное пора в спецучереждение для людей "с другим складом ума"
А то лезут всякие "тупые" в священную башню со слоновой кости.
Вот примеры.
Это я вас так задел
Ну задели, и задели. Если вас это порадует, то можете себе записать ранение. Мало ли вас таких в интернете. Я на себя не проецирую. Лишь указываю на ваши ошибки.
...что аж про "другой" склад ума полезло.
Потому что я работал с чисто C программистами. И у них совершенно другой подход в архитектуре кода из-за простоты языка. Отсюда как раз выходят особенности, как построения кодовой базы, так и её поддержки. Архитектура кода Go или Java, да даже Rust сильно отличается от того с чем работают программисты на C. И именно из-за не соответствия подходов к работе над кодом возникают конфликты.
Я вообще к расту отношения не имею, мне все равно на каких языках ядро написано, лишь бы работало хорошо.
Странно тогда видеть вас в комментариях
IUIUIUIUIUIUIUI
09.02.2025 09:38Он именно о поддержке кодовой базы писал.
Он писал взаимоисключающие параграфы «мне не нужны помощники, мне норм самому» и «я не хочу мейнтейнить растобайндинги, потому что это слишком сложно».
Это имеет смысл только в том случае, если он относится к коду как к своей территории, и не хочет пускать на эту территорию чужаков. А это — профнепригодность для мейнтейнера.
А в вашем проекте писали ли код на двух языках для одной библиотеки?
В моих — да. У меня даже были проекты (например, с кусками на C++ и на питоне), и я не знал один из этих языков и не хотел его знать, и при этом всё нормально работало, потому что поддержка соответствующих частей была на энтузиастах этого языка.
Были и проекты на двух языках в одной либе, которые я поддерживал один, и тоже норм было.
И вы один, кто весь этот код поддерживает.
С чего бы? Ему предлагают помощь, он отказывается.
Я вижу, что вы не понимаете всю особенность той проблемы о которой пытался рассказать Кристоф.
Я как раз прекрасно понимаю эту проблему. Кристоф хочет продолжать быть королём в своём уютном загончике, а тут опасно близко подходят люди, могущие показать, что король-то голый.
У программистов на C (или других структурных языков) другой склад ума, так как код для них должен быть линеен.
Что программисты на C (те, которые не осилили другие языки) не могут рассуждать о коде, давно известно, ведь the first letter in "CVE" stands for the C Programming Language. Даже две строки сконкатенировать без того, чтобы remote shell дать, получается не всегда. Совсем не всегда.
Особый склад ума. Единственный ваш тезис, с которым я согласен.
Rust, из-за наличия trait'ов и макросов может скрывать реализации алгоритмов, что для программистов на C не приемлемо.
Знаете, как в ядре разные штуки сделаны в окрестности тех же ФС или драйверов? Там структурки с указателями на функции лежат, и эти структурки ровно этим занимаются: скрывают реализации алгоритмов. Или я что-то пропустил, и разные кристофы и анимерабы их уже выпилили?
Более того, даже простой вызов
sortили там, не знаю,list_add_rcuровно это и делает: скрывает реализации соответствующих алгоритмов. Это основа и вообще raison d'etre процедурного программирования, и она появилась даже до С (и поэтому в С эта революционная технология присутствует).Дальше, по предыдущему вашему офигительному тейку:
И в этом есть рациональное зерно. Потому что если проблема будет только в драйвере, то его можно одного будет откатить или заблокировать без серьёзных проблем.
Это настолько вызывающе неверно, что, во-первых, смешно, а, во-вторых, вы точно занимаетесь программированием дальше хобби-проектов-однодневок?
Если проблема в обвязках, то их точно так же можно откатить или «заблокировать» (что бы это ни значило) без серьёзных проблем для сишного кода. Централизованные обвязки здесь не делают хуже.
Если проблема в обвязках, то драйвера на расте будут страдать независимо от того, что представлены эти обвязки одной копией рядом с исходной сишной реализацией, или методично скопированы в каждый раст-драйвер. Ну просто потому, что код один и тот же, блин. Копирование здесь не делает лучше.
Исправление проблем в обвязках потребует исправлять их в каждой из копий, которые неизбежно (эмпирический закон эволюции копипасты) разойдутся в мелочах (и не очень), что потребует куда больше усилий. Копирование здесь делает строго и существенно хуже.
Предлагать копипастить, особенно с таким обоснованием, как у Кристофа — это чисто политический манёвр «ну я же предложил что-то, чё эти несогласные бухтят, вечно недовольны». Абсолютно так же вёл себя один мой коллега на одной работе, например, выступавший против автоформаттеров кода (и консистентного форматирования кодовой базы вообще), мол, они ограничивают его свободу. Только он предложил мне мне самому написать по-быстрому форматтер кода для плюсов (у которых неразрешимая по Тьюрингу грамматика для начала, напомню), так как ни clang-format, ни один из кучи других форматтеров его не устраивали, и «у нас была очень специфичная база со специальными потребностями». Менеджмент схавал, а больше и не надо.
vkni
09.02.2025 09:38Абсолютно так же вёл себя один мой коллега на одной работе, например, выступавший против автоформаттеров кода (и консистентного форматирования кодовой базы вообще), мол, они ограничивают его свободу.
Ну откровенно же бесят эти автоформаттеры. Правда не настолько, чтобы упираться рогом, в конце-концов, за исключением паталогий вроде
ocamlformat, вопрос выеденного яйца не стоит.IUIUIUIUIUIUIUI
09.02.2025 09:38Единственный автоформаттер, который меня действительно бесит — ormolou. clang-format же достаточно неплохо настраивается.
В любом случае
std::string foo(int * ptr, int*otherptr) { if (doStuff) { if(otherStuff) { doSomething(); doThings(); } } else { doMoreThings(); return "success"; } }бесит больше, особенно когда строк не 10, а 100.
И нет, я не утрирую, весь код за авторством товарища был таким.
vkni
09.02.2025 09:38И нет, я не утрирую, весь код за авторством товарища был таким.
У нас в той группе, где я работал, долгое время подход был простой: противно смотреть, ну отформатируй. Но в целом, всем было насрать - все профессионалы, значит без особого напряжения могут прочесть любой стиль форматирования (и приведённый выше тоже читается, хоть и противно). Основное время же всё равно тратилось на выяснение того, что откуда вызывается, и как это изменить, чтобы не поломать. Но там, как правило, код был более-менее отформатирован, просто несколько разных стилей применялось в разных библиотеках/файлах.
Единственный автоформаттер, который меня действительно бесит — ormolou.
Ocamlformat'овцы несколько кладут на обратную совместимость по форматированию. Что уж проще проверки регрессий для автоформатировщика?
AnimeSlave
09.02.2025 09:38Он писал взаимоисключающие параграфы «мне не нужны помощники, мне норм самому» и «я не хочу мейнтейнить растобайндинги, потому что это слишком сложно».
А где здесь взаимоисключающие параграфы? Вы то же из тех кто не понимает, но «со вселенской несправедливостью нужно бороться»?
Даже больше, оба ваших перевода неверны. И вы просто набрасываете. Как собственно все неравнодушные адепты Rust'а в пабликах, как только переписка всплыла в новостях.
Единственная верная суть в этом, что поддержка большой кодовой базы - это не биндинги написать. Не даром сам Торвальдс дал комментарий. Суть которого сводится к тому, что это не Rust плохой, а программисты на Rust плохие. Плохие для ядра linux. Им нужно меняться. Это был для них по сути совет. Как мальчик, которого бросают в воду, чтобы он научился плавать, не может изменить физику воды. Так и программисты на Rust не могу сломать принятые стандарты разработки внутри ядра linux. Когда-нибудь это произойдёт, но не в ближайшее время.
А пока что, всё то, что происходит вокруг таких новостей и постов - это просто вбросы ради просмотров.
...потому что поддержка соответствующих частей была на энтузиастах этого языка.
Это как раз показывает ваше непонимание. В ядре linux никто не будет ждать, что за дело возьмётся энтузиаст своего языка. Сломалось? Нужно чинить сразу. А лучше вообще не ломать. Отсюда эта неприязнь нововведений. Которая оправдана. Это в махровом энтерпрайзе на поддержке на аутсорсе исправление ошибок могут ждать неделями. Ядро linux - критическое ПО.
Я как раз прекрасно понимаю эту проблему. Кристоф хочет продолжать быть королём в своём уютном загончике, а тут опасно близко подходят люди, могущие показать, что король-то голый.
Вы думаете только один Кристоф работает над DMA? Он там далеко не один. И его решение поддерживают. Бугуртят в основном именно обиженки из Rust загона. В то время как никто им не запрещает работать над ядром, им рекомендуют делать это в контролируемых рамках.
Знаете, как в ядре разные штуки сделаны в окрестности тех же ФС или драйверов? Там структурки с указателями на функции лежат, и эти структурки ровно этим занимаются: скрывают реализации алгоритмов. Или я что-то пропустил, и разные кристофы и анимерабы их уже выпилили?
А что они скрывают? Реализация остаётся реализацией внутри своего же отдельного блока кода, и даже единицы трансляции. Структура определена. Это не макрос или трейт, которые могут быть в других крейтах. Если трейт это ещё более менее определённая штука, то макрос может быть вообще чем угодно. Или я опять что-то упустил?
Если проблема в обвязках, то их точно так же можно откатить или «заблокировать» (что бы это ни значило) без серьёзных проблем для сишного кода. Централизованные обвязки здесь не делают хуже.
Это как раз вы не понимаете. Если было изменение в обвязке, то просто так откатить ей не просто, так как все драйвера будут задеты изменениями, в отличии от изменений отдельного драйвера.
Копирование здесь не делает лучше.
Копирование делает поддержку проще.
Предлагать копипастить, особенно с таким обоснованием, как у Кристофа — это чисто политический манёвр...
Нет там никакого политического манёвра. Это фантазия. Заменят Кристофа - будет кто-то другой. Адепты Rust пусть попытают удачу в этом направлении. Это же не сложно - на собрании выдвинуть свою кандидатуру в мейнтейнеры DMA. Примут ли их кандидатуру? Вот в чём вопрос
krendelbok
09.02.2025 09:38А где здесь взаимоисключающие параграфы? Вы то же из тех кто не понимает, но «со вселенской несправедливостью нужно бороться»?
Рассказываю на пальцах, ELI5:
Есть функция на С, которая будет использоваться в 5 драйверах на расте. Можно сделать одну обвязку и использовать эту обвязку 5 раз. А можно в каждом драйвере одну и ту же обвязку копипастить. А потом С функция поменяется и что надо будет делать? Правильно, либо изменить одну обвязку, либо 5 одинаковых обвязок копипастой. Надеюсь теперь более понятна суть претензии?AnimeSlave
09.02.2025 09:38Надеюсь теперь более понятна суть претензии?
Она изначально была понятна. Как это меняет суть отказа? В этой части кода ядра важна стабильность. Мейнтейнеры хотят продолжать поддерживать эту стабильность. И для меня лично понятно почему. Если вы этого не понимаете? Штош. Результат отказа всё равно это не изменит
IUIUIUIUIUIUIUI
09.02.2025 09:38А где здесь взаимоисключающие параграфы?
Потому что если бы было норм самому, то не было бы «слишком сложно». А если слишком сложно, то помощники не помешают.
Я прямо чувствую себя неудобно, объясняя базовые логические выводы.
Даже больше, оба ваших перевода неверны.
Я взял переводы по ссылке товарища выше. Конечно, понятное дело, переводы верны, когда надо опровергнуть исходную статью, и переводы неверны, когда из них следуют неприятные для вас вещи.
Как собственно все неравнодушные адепты Rust'а в пабликах, как только переписка всплыла в новостях.
Я не знаю раст, не хочу его знать, и в мои планы не входит его изучение. Попробуйте адхом ещё раз.
Единственная верная суть в этом, что поддержка большой кодовой базы - это не биндинги написать.
Ага. А ещё поддержка большой кодовой базы — это не драйвер написать. И не бинарный блоб для amd влить. И что это говорит о всех тех людях, которые этим занимаются?
Не даром сам Торвальдс дал комментарий.
Ух! Сам Яжефинн Торвальдс!
Суть которого сводится к тому, что это не Rust плохой, а программисты на Rust плохие. Плохие для ядра linux. Им нужно меняться. Это был для них по сути совет. Как мальчик, которого бросают в воду, чтобы он научился плавать, не может изменить физику воды.
Дискурс уровня базара (не в смысле того, что противопоставляется Собору Рэймондом, о котором я говорил выше, а в смыле базарных бабок).
Это как раз показывает ваше непонимание. В ядре linux никто не будет ждать, что за дело возьмётся энтузиаст своего языка. Сломалось? Нужно чинить сразу.
Вы снова врёте: ждать не нужно, потому что люди вполне себе готовы взять на себя обязательства по мейнтейнерству.
А лучше вообще не ломать. Отсюда эта неприязнь нововведений. Которая оправдана.
Да, в ядре линукса же ничего никогда не вводят (даже когда уже что-то работает, см. фолианты, скажем), не ломают, и так далее.
Ядро linux - критическое ПО.
Для этого есть LTS-релизы.
Вы думаете только один Кристоф работает над DMA? Он там далеко не один.
Конечно. Царёк в загончике тоже не один. Но царёк опирается на безапелляционный авторитет у прочих членов загончика, который в linux kernel пока ещё хотя бы на словах следует меритократическим принципам.
А что они скрывают? Реализация остаётся реализацией внутри своего же отдельного блока кода, и даже единицы трансляции.
Нет, конечно. Если бы это было так, то у вас все функции были бы в одной единице трансляции, в одном большом таком .c-файле, а это, очевидно, не так.
Вы точно понимаете, о чём пишете, или просто какие-то умно звучащие слова накидываете?
Если трейт это ещё более менее определённая штука, то макрос может быть вообще чем угодно.
Что, в ядре линукса и сишные макросы уже запретили?
Если было изменение в обвязке, то просто так откатить ей не просто, так как все драйвера будут задеты изменениями, в отличии от изменений отдельного драйвера.
Казалось бы, сишник с его #include должен понимать, что нет никакой разницы вообще с точки зрения влияния изменений между #include "foo.h" и копированием содержимого foo.h на место инклюда. У меня таки начинают закрадываться некоторые подозрения.
Копирование делает поддержку проще.
Лол.
AnimeSlave
09.02.2025 09:38Потому что если бы было норм самому, то не было бы «слишком сложно». А если слишком сложно, то помощники не помешают.
А исключение здесь где? То, что помощники могут помочь ещё не означает, что они нужны. И то, что кто-то не хочет делать дополнительную работу, не значит что ему нужны помощники. Взаимоисключения здесь нет. В ту же логику можно принести - зачем усложнять там, где усложнения не требуется. Или зачем исправлять то, что и так работает хорошо.
Я взял переводы по ссылке товарища выше. Конечно, понятное дело, переводы верны, когда надо опровергнуть исходную статью, и переводы неверны, когда из них следуют неприятные для вас вещи
Так вы оригиналы посмотрите, чтобы не терять смысл заявлений. И для более детальной картины всех заявлений Кристофа. Потому что переводы не верны, а дёргать отдельные выражения без контекста - портить суть его слов и своего лично понимания.
Ага. А ещё поддержка большой кодовой базы — это не драйвер написать. И не бинарный блоб для amd влить. И что это говорит о всех тех людях, которые этим занимаются?
Так и Кристов не драйверы пишет. Он сопровождает одну из критических подсистем ядра.
Вы снова врёте: ждать не нужно, потому что люди вполне себе готовы взять на себя обязательства по мейнтейнерству.
А где я вру? Мои слова описывают ситуацию, когда есть кодовая база двух языков, где один язык поддерживается одним, а другой - другим мейнтейнером. И для исправления ошибки кто-то в любом случае будет ждать выполнения работы другого. Вы же не знаете как будет, как будет и сколько это времени займёт. И я не знаю. И Кристоф не знает. Но с точки зрения простой логики зачем создавать сложности на ровном месте и вносить дополнительный процент риска там где он не нужен.
Для этого есть LTS-релизы.
А для тестов и экспериментов отдельный ветки и форки.
Конечно. Царёк в загончике тоже не один. Но царёк опирается на безапелляционный авторитет у прочих членов загончика, который в linux kernel пока ещё хотя бы на словах следует меритократическим принципам.
Все кто находится в загончике чувствуют себя хорошо. И им не нужна помощь. О чём собственно написал Кристоф. Всё остальное, в том числе и эта статья - это всё из-за «вселенской несправедливости».
Что, в ядре линукса и сишные макросы уже запретили?
А C-макросы могут генерировать код? Я вроде думал, что они просто подменяют текст.
Лол.
Это понимание приходит со временем.
IUIUIUIUIUIUIUI
09.02.2025 09:38А исключение здесь где? То, что помощники могут помочь ещё не означает, что они нужны.
Если человек не может выполнять работу сам, значит, нужны.
В ту же логику можно принести - зачем усложнять там, где усложнения не требуется.
Если не требуется. А переход на rust — это вполне себе полезное изменение.
Так вы оригиналы посмотрите, чтобы не терять смысл заявлений. И для более детальной картины всех заявлений Кристофа. Потому что переводы не верны, а дёргать отдельные выражения без контекста - портить суть его слов и своего лично понимания.
Окей, покажите, где что выкинуто из контекста, и где переводы неверны. С отсылкой к оригиналу, конечно.
Так и Кристов не драйверы пишет. Он сопровождает одну из критических подсистем ядра.
А будет сопровождать вместе с кем-то ещё на пару, как ему и предлагают. Не вижу ничего страшного.
А где я вру? Мои слова описывают ситуацию, когда есть кодовая база двух языков, где один язык поддерживается одним, а другой - другим мейнтейнером. И для исправления ошибки кто-то в любом случае будет ждать выполнения работы другого. Вы же не знаете как будет, как будет и сколько это времени займёт. И я не знаю. И Кристоф не знает.
После принятия этих байндингов и покажут себя. Пока драйверов на расте немного, так что ничего страшного в этом нет.
А гарантий времени реакции нет ни у кого, даже у Кристофа. Или какое у него там SLA и что будет, если он его нарушит? Поэтому избирательно напирать на отсутствие гарантий от этих мейнтейнеров, когда их нет ни у кого — это признак либо глупости, либо интеллектуальной нечестности. Выбирайте сами.
Все кто находится в загончике чувствуют себя хорошо.
Конечно, ведь неславящих царька оттуда выкидывают.
Но это не подходит для критического, общественно важного ПО.
А C-макросы могут генерировать код? Я вроде думал, что они просто подменяют текст.
А с этим текстом потом что происходит, знаете?
И, кстати, макросы достаточно близки к тьюринг-полноте в теории (не отличаясь по выразительной силе от шаблонов, которые считаются тьюринг-полными несмотря на наличие зафиксированных в стандарте возможных ограничений на количество инстанциирований) и на практике (см. boost.preprocessor — там и циклы, и условия, и контейнеры, и много чего интересного можно сделать).
Это понимание приходит со временем.
Если вы хотите свести дискуссию к сверканию регалиями, то результат будет сильно не в вашу пользу. Я бы не рекомендовал.
Говорить, что копипаста помогает поддержке — это показывать, как говорится, что иногда старость приходит одна.
AnimeSlave
09.02.2025 09:38Если человек не может выполнять работу сам, значит, нужны.
Так он может выполнять работу. Свою. Ему чужая не нужна. А ему почему-то пытаются навязать другую работу.
А переход на rust — это вполне себе полезное изменение.
Может быть. Время покажет.
Окей, покажите, где что выкинуто из контекста, и где переводы неверны. С отсылкой к оригиналу, конечно.
К примеру
мне не нужны помощники, мне норм самому
Он написал просто
And I also do not want another maintainer.
И не потому что они ему не нужны. У него уже есть помощники. Другие мейнтейнеры.
я не хочу мейнтейнить растобайндинги, потому что это слишком сложно
Он этого не писал.
Maintaining multi-language projects is a pain I have no interest in dealing with.
Вот его слова. Он писал не конкретно про байдинги rust кода.
А будет сопровождать вместе с кем-то ещё на пару, как ему и предлагают. Не вижу ничего страшного.
У него уже есть помощники.
После принятия этих байндингов и покажут себя. Пока драйверов на расте немного, так что ничего страшного в этом нет.
Вот когда примут, тогда и приходите. Пока что ваши же слова ниже
Поэтому избирательно напирать на отсутствие гарантий от этих мейнтейнеров, когда их нет ни у кого — это признак либо глупости, либо интеллектуальной нечестности. Выбирайте сами.
относятся и к вам в равно степени. Я же лишь вижу текущую ситуацию просто раздутой из-за нелепицы. Не приняли код на Rust в одном месте. Пусть попытает счастье в другом.Тем более, что не во всех подсистемах ядра такие отказы есть.
Говорить, что копипаста помогает поддержке — это показывать, как говорится, что иногда старость приходит одна.
А ещё спутником старости для некоторых является деменция.
IUIUIUIUIUIUIUI
09.02.2025 09:38Так он может выполнять работу. Свою. Ему чужая не нужна. А ему почему-то пытаются навязать другую работу.
В каком месте пытаются? Ему говорят, что обвязки готовы мейнтейнить другие люди.
Может быть. Время покажет.
Уже показало в опыте других компаний, от гугла с андроидом до cloudflare.
И не потому что они ему не нужны. У него уже есть помощники. Другие мейнтейнеры.
Где в процитированной вами фразе написано, что у него уже есть помощники?
Кстати, какие есть гарантии, что эти другие мейнтейнеры будут реагировать на проблемы в данный срок, как вы требовали ранее?
Вот его слова. Он писал не конкретно про байдинги rust кода.
Контекст дискуссии — растобайндинги. Вы говорите, что я не учитываю контекст высказываний, а потом сами берёте и выкидываете этот контекст.
А кодовая база, кстати, уже многоязычная. Проприетарные прошивки-блобы на каком языке написаны, по-вашему? Скрипты для системы сборки на чём написаны?
У него уже есть помощники.
В процитированной вами фразе этого нет.
Вот когда примут, тогда и приходите.
Говорить на серьёзных щщах «Я не буду принимать эти изменения в мой проект, пока эти изменения не покажут себя в моём проекте» не может даже сишник.
Не приняли код на Rust в одном месте. Пусть попытает счастье в другом.
Мне нравится, как легко вы распоряжаетесь чужим временем и усилиями при полном отсутствии технических причин для отказа.
А ещё спутником старости для некоторых является деменция.
Мои соболезнования, конечно, но это многое из ваших офигительных высказываний объясняет.
AnimeSlave
09.02.2025 09:38В каком месте пытаются? Ему говорят, что обвязки готовы мейнтейнить другие люди.
В том же где ему присылают патч с Rust кодом. Как и вы пишите выше.
Если человек не может выполнять работу сам, значит, нужны.
Он как мейнтейнер всей подсистемы отказал в патче считая, что это навредит сопровождению. Он имеет право на это. Он готов принять отдельный код на каждый драйвер, о чём написал, но не на всю систему в целом. Из-за этого начался конфликт в переписке. Из которой начали писать статьи. Будут ли помогать, не будут. Это уже не важно. Ситуация уже произошла. Решение уже принято.
Уже показало в опыте других компаний, от гугла с андроидом до cloudflare.
Красивые лозунги в новостях многие умеют писать. Это ещё ничего не говорит. Google до сих пор с заменой Java на Kotlin не разобралась у себя. Rust при этом заметно больше лет, чем Kotlin.
Где в процитированной вами фразе написано, что у него уже есть помощники?
Они прописаны в списке мейнтейнеров. Зачем их упоминать, когда они уже есть?
Контекст дискуссии — растобайндинги. Вы говорите, что я не учитываю контекст высказываний, а потом сами берёте и выкидываете этот контекст.
Потому что проблема не в самих растобайдингах. А том, где они располагаются. Кристофу инкриминируют по сути неприязнь языка Rust. В то время как сам Кристов писал, что у него нет негатива против языка. Он против тех изменений, что пришли с патчем и дал вариант решения. Это вариант решения не понравился rust-сообществу. И они разнесли это по интернету, как очередную ситуацию с притеснением языка. Из-за чего Самому Яжефинн Торвальдсу (это ваша цитата) пришлось писать комментарий на это конфликт. Весь конфликт раздут искусственно. Я комментирую, чисто из-за скуки. А вас, как мне кажется, что-то задевает. Ведь Rust'у отказали, какая же несправедливость.
IUIUIUIUIUIUIUI
09.02.2025 09:38В том же где ему присылают патч с Rust кодом.
Нет, конечно. Достаточно дать им мейнтейнить соответствующую субдиректорию, и нет никаких проблем.
Он как мейнтейнер всей подсистемы отказал в патче считая, что это навредит сопровождению. Он имеет право на это.
Он имеет право даже отказать в патче, у которого первый символ каждой строки, начиная с 17-й, не складывается в фразу "c{hristoph is the greatest man on earth}". Вопрос в адекватности этих отказов, и мы обсуждаем именно его.
Он готов принять отдельный код на каждый драйвер, о чём написал, но не на всю систему в целом.
Исключительно потому, что отдельный код на каждый драйвер никто не будет делать, и он это понимает.
Это уже не важно. Ситуация уже произошла. Решение уже принято.
Высечено в граните прям?
Красивые лозунги в новостях многие умеют писать. Это ещё ничего не говорит.
Там кроме лозунгов ещё есть отчёты по дырявости кодовой базы на сях и плюсах и кодовой базы на расте в андроиде, например. И есть конкретные работающие продукты, которые выбрано делать на расте. Но это всё, конечно, мелочи и лозунги.
Они прописаны в списке мейнтейнеров.
Покажите, где в списке мейнтейнеров указано, что они конкретно помощники Кристофа.
Кристофу инкриминируют по сути неприязнь языка Rust.
Ну либо это, либо он царёк с ЧСВ, тут выбора нет.
В то время как сам Кристов писал, что у него нет негатива против языка.
Человек в одном комментарии пишет по смыслу «красивые лозунги мноиге умеют писать, поэтому неважно, что говорят» и «ну раз человек что-то написал, то это должно быть правдой, буду исходить из этого».
Спасибо вам за дискуссию, вы даёте повод орать в голосину просто в каждом комментарии.
А вас, как мне кажется, что-то задевает. Ведь Rust'у отказали, какая же несправедливость.
Про своё отношение к расту я уже писал. В данном же случае меня задевает только непроходимая, фанатичная глупость некоторых персонажей, защищающих такие решения и всерьёз предлагающих копипастить код для улучшения его поддерживаемости, или очень избирательно применяющих аргументы уровня «технология может быть опасной, она не всегда приводит к тому, что хочется». Но это скорее даже не задевание, а персональный челлендж такой — получится ли что-то донести человеку, который даже осилил открыть браузер и набрать там эйч эй би ар дот ком <enter>, поэтому обладает, наверное, какими-то когнитивными способностями, или не.
AnimeSlave
09.02.2025 09:38Вопрос в адекватности этих отказов, и мы обсуждаем именно его.
А в чем неадекватность отказа со стороны Кристофа? Он поставил стабильность выше нововведений. Неадекватными пока что только выглядят адепты Rust. Особенно Гектор Мартин. Который ушёл из мейнтейнеров из-за обиды на слова Торвальдса. Опять же чисто эмоциональный поступок. Не прагматика движет, а эмоции. Возможно даже инфантилизм. Но это уже отдельная история.
И есть конкретные работающие продукты, которые выбрано делать на расте. Но это всё, конечно, мелочи и лозунги.
Так и на Zig сейчас проекты пишут. На Nim, Odin. (любой другой новый красивый язык) И что с того? Это нормально, что язык развивается.
Исключительно потому, что отдельный код на каждый драйвер никто не будет делать, и он это понимает.
А зачем делать на каждый драйвер? Достаточно на несколько. Показать стабильность работы кода. Объяснить, доказать верность замены. Можно попробовать так пойти. Но пошли другим путём - сраться в пабликах.
alan_dani
09.02.2025 09:38Гектор Мартин пару дней назад заявил об уходе из разработки ядра Линукс как раз в связи с описанной Вами ситуацией.
Своим поляризирующим и излишне эмоциональным стилем изложения собственной позиции на грани флуда, он больше вредил R4L. На что ранее в мягкой форме ему было указано Торвальдсом.
johnfound
09.02.2025 09:38Ну, если растеры хотят в ОС, то кто мешает им написать свое ядро и пусть лучший победит. Да, хоть пусть клонируют Линукс и начнут переписывать на Rust. Никто им слово не скажет. А так выходит, они хотят примазаться к уже налаженные процессы и сделать их намного сложнее, зачем? Чтобы разрекламировать язык который им нравится.
MountainGoat
09.02.2025 09:38Тут такой парадокс. Ядро на Rust миру нужно, а вот второе ядро для Linux миру не нужно. Написать микроядро для ОС людям в теме вполне под силу, а вот обеспечить совместимость с 40 лет истории и драйверов без 40 лет финансирования не сможет никто.
IndyCar
09.02.2025 09:38100%, никуда не денешься, тот же Линус был голым и босым, и только сейчас приобрёл всё то влияние, что у него есть, а прежде было у Ричарда Столлмана
feelamee
09.02.2025 09:38А так выходит, они хотят примазаться к уже налаженные процессы и сделать их намного сложнее, зачем?
Любое развитие как ни крути требует изменений. А мы, люди, внутренне часто сопротивляемся изменению наших привычек. Я думаю тут проблема не в решении (использовать раст или нет), а в его отсутствии. Часть людей хочет, часть не хочет - в итоге это разваливает выстроенное годами комьюнити. Видел хороший комментарий на hn об этом.
Чтобы разрекламировать язык который им нравится.
Почему вы так считаете? Понятное дело что у Раст комьюнити есть мода на переписывание всего подряд. Но трудно отрицать, что при сравнении С и Раст в лоб, у второго есть гора преимуществ. Вам не кажется что такой важный для всей сферы IT проект как Линукс может стать лучше вместе c Раст?
johnfound
09.02.2025 09:38Но трудно отрицать, что при сравнении С и Раст в лоб, у второго есть гора преимуществ.
Мне легко. Я все пишу на ассемблере. С хорошим таким успехом, очень небольшим количеством багов и прекрасной производительностью. Мне даже переход на C кажется неоправданным.
sci_nov
09.02.2025 09:38Видимо на ассемблере нет программного UB, только лишь спецификация архитектуры процессора. И отвечаешь сам за выделение памяти и прочее.
Yuri0128
09.02.2025 09:38Ошибку программиста (а почти все дыры ими и являются) никто не отменял. В том числе на языке ассемблера.
SIISII
09.02.2025 09:38Это да, но очень многие ошибки на Си возникают из-за неопределённого поведения, разрешённого стандартом, но нелепого с точки зрения здравого смысла. И если на старые версии стандартов повлиять, понятное дело, нельзя, то в новых можно было бы радикально сократить количество UB -- но это не делается.
ViacheslavNk
09.02.2025 09:38По опыту написания драйверов для Windows/Linux я не могу согласиться что много ошибок/багов было именно из языка Си, 99.9% ,багов были связаны с логикой/ алгоритмами (шифрование, репликация, файловые фильтры, сеть), дополнительно где то особенности железа кастомера привносила свое.
Yuri0128
09.02.2025 09:38Железо к программноой части (и утечке памяти в частности) то при чем. Ошибки железа - там и остаются, они на выход за пределы массива как-то не влияют. А вот невнимательность программиста - очень даже влияет.
ViacheslavNk
09.02.2025 09:38Да я все понимаю, но повторюсь именно ошибок/багов, связанных с выходом за границу массива, двойного удаления, разыменование нулевого поинтера и пр, было на уровне статистической погрешности.
Vitaly83vvp
09.02.2025 09:38Для C/С++ постоянно выходят новые стандарты, которые добавляют новые возможности. Почему нельзя сделать такой стандарт, который исключит все эти неопределённые поведения?
И необходимости перехода на другие языки уже не будет.
Если есть конструкция и она работает так как разработчик и задумал на разных машинах с разными разных архитектурами и с разными флагами компиляции, то это правильно.
Сейчас C уже не так популярен. C++ пока ещё используется спросом. Но больше выбирают/учат "модным" языкам.
ZirakZigil
09.02.2025 09:38Почему нельзя сделать такой стандарт, который исключит все эти неопределённые поведения
Оптимизации на них держатся. А чтобы не держались нужно дизайнить совсем другой язык.
Vitaly83vvp
09.02.2025 09:38Ну, в C есть неопределённые поведения, а в Rust есть unsafe. Т.е. разработчики языка сделали его максимально безопасным, но при этом добавили возможность писать небезопасный код. Это потенциально опасная возможность, вкупе с человеческим фактором (куда же без этого), может стать источником ошибок.
Я не совсем объективен, т.к. пока ещё не осилил Rust - уж очень специфичный синтаксис. С Go, было проще, хотя и его синтаксис не сказать что привычный.
Yuri0128
09.02.2025 09:38Ну и с малым размером. Ибо писать что-то большое и серъезное на асме - это наказание. Особенно, если потом надо в это через пару лет разбираться и немного переделывать. Ну и все равно используется API ядра для выделения памяти под оверлеи. Или вы не под Линукс пишете а в эмбединг?
johnfound
09.02.2025 09:38Ну, большое – не большое, а под 500kloc писал и пишу. Вообще-то у меня большинство проектов можно скомпилировать и под Linux и под Windows – типа переносимые. И почему-то все думают, что методы написания больших проектов под асм не работают. Но это не так. Переиспользование кода, модульные архитектуры, структурное и ООП программирование – это все абстрактные сущности, которые в ассемблере работают ничуть не хуже чем в других языках программирования. И я этим пользуюсь на все 100%. И после пару (а то и больше) лет разбираюсь и переделываю легко и непринужденно. :)
Yuri0128
09.02.2025 09:38И после пару (а то и больше) лет разбираюсь и переделываю легко и непринужденно. :)
Вы гений... Я в своих на асме после 5 лет уже не очень, требуется довольно много времени чтобы въехать в структуру и реализацию.
500kloc - ну, не большой проект, но уже и не маленький. У меня на асм таких немного (но есть)... Сейчас на асме только драйвера или весьма требовательные куски кода пишу, остальное - C. Недавно в проекте на Python (ARM) применил асм - вполне пошло, для ускорения.
ООП на асме - ну.... Такое себе...
SIISII
09.02.2025 09:38Ну, были ж проекты и на несколько миллионов строк на ассемблере -- правда, не в одно рыло, но тем не менее. А в одиночку вполне реально написать проект на 50-100 тысяч строк. (Ядро RSX-11 имеет меньше, если что, -- а это, как ни крути, полноценная многозадачная ОС, пускай и с очень скромным API, если сравнивать с современными монстрами).
А насчёт переделок -- с кодом на Си ничуть не лучше, если его не комментировать. Ведь без комментариев непонятно, почему автор сделал так, а не иначе -- а, вполне может быть, для иногда очень странного кода есть разумная причина (скажем, нужно обходить ошибку в железе, совершая странные телодвижения с регистрами устройства).
Yuri0128
09.02.2025 09:38Ну, на Сях все-ж проще. Причем заметно проще.
А работа с регистрами - это в основном к драйверам, там объем небольшой.
SIISII
09.02.2025 09:38От задачи зависит. Если там, главным образом, вычисления или нечто подобное, то язык высокого уровня будет сильно читаемее, конечно. А вот если сплошные "проверить бит -- установить бит", то на асме, как по мне, даже лучше оказаться в плане читаемости может. Поэтому, скажем, драйвер некоей железяки на асме если и сложней в плане читаемости будет, чем на сях, то несильно, а вот какой-нить мозговыносительный научный расчёт... (вспомнил советскую программу расчёта зарплаты для детсадов, школ и т.п. учреждений, написанную горячими литовскими парнями на ассемблере М-5000 и затем крутившуюся на спецпроцессоре СМ-1600 -- и как весело было, когда Союз распался и потребовалось увеличивать разрядности полей данных :) ).
Yuri0128
09.02.2025 09:38А вот если сплошные "проверить бит -- установить бит", то на асме, как по мне, даже лучше оказаться в плане читаемости может.
Стопудово.. Я иногда скучаю о асмовских командах установки/тестирования битов. Особенно на портах ввода/вывода (они то как раз атомарные!!!).
ahabreader
09.02.2025 09:38А вот если сплошные "проверить бит -- установить бит", то на асме, как по мне, даже лучше оказаться в плане читаемости может
Стопудово.. Я иногда скучаю о асмовских командах установки/тестирования битов. Особенно на портах ввода/вывода
Вы серьёзно? Они при желании доступны через inline-ассемблер, его (или версию на C) можно завернуть в макрос, можно в функцию, можно заменить функцией или макросом из HAL-библиотеки к железке или самостоятельно написать такую (некого Аскольда Волкова интернет не помнит, а его макросы помнит).
feelamee
09.02.2025 09:38то что у вас это получется, по моему мнению, говорит не в пользу ассемблера перед высокоуровневыми языками, а лишь о вашей неординарности.
johnfound
09.02.2025 09:38Спасибо, но не думаю. Я довольно средний программист. Это вопрос преодоления предрассудков и прежде всего желания написать что-то реальное на ассемблере, вопреки все традиции и обычаи которые вопят: «Нельзя такое делать!»
feelamee
09.02.2025 09:38Это вопрос преодоления предрассудков и прежде всего желания написать что-то реальное на ассемблере
конечно и это тоже, но для меня не это самая главная проблема. Главная - человеческий фактор. Это в особенности усугубляется когда людей становится больше одного.
На простом примере. Я думаю все согласятся что стандартизировать правила именования в коде это хорошо. Но как это лучше сделать? Один вариант просто документ, а второй инструмент который будет вам говорить что имя которое вы дали не выполняет требования. Для меня второй вариант просто легче. С ним мне не нужно держать в голове: "я написал функцию, нужно проверить соответствует ли это правилам именования". Конечно, можно возразить что они быстро запоминаются и тогда вносят минимальную нагрузку, но не стоит забывать про обычную невнимательность, которая присуща всем, и про новых разработчиков.
Для меня это просто вопрос перекладывая ответственности и снижения нагрузки.
Я не отрицаю что можно все это делать самостоятельно, но считаю что это значительно менее продуктивно.
johnfound
09.02.2025 09:38Каждый отказ думать и каждое перекладывание ответственности, конечно делает работу легче, но и одновременно с этим отнимает свободу и ведет к деградации. А самое страшное, что по итогу ничего не меняется – программы как были с багами, так и остались с ними, только работают медленнее и требуют больше памяти. А мы, из-за нашего выбора даже не осознаем что они такие и считаем все нормальным. А когда поймем, что программы плохие, то мы осознаем, что не знаем как они работают. Что там под капотом происходит. Для нас программирование превращается в магию – сбор заклинаний, которые сочинил какой-то архимаг или даже бог. Никто не знает что они означают, но ведь работают и ладно.
venanen
09.02.2025 09:38Каждый отказ думать и каждое перекладывание ответственности, конечно делает работу легче, но и одновременно с этим отнимает свободу и ведет к деградации.
Как говаривал мой тимлид - линтер подобен страховке на кране. Сковывает, мешает, болтается - но без нее нельзя, она спасает жизни. Потому что это у Вас свобода превращается в быстрый и красивый проект, а у Васи с соседнего отдела свобода превращается в односимвольные переменные и магические константы, а править за Васей нужно будет Вам.
А самое страшное, что по итогу ничего не меняется – программы как были с багами, так и остались с ними, только работают медленнее и требуют больше памяти.
Кмк, это ошибка после - не значит в следствии. Поменялся системный подход и майндсет пользователей. Пользователь (генеральная совокупность, а не суровые хабровские гики) хочет красивости, анимации, а бизнес хочет три тысячи фичей уже вчера. И линтер спасает. Люди даже изобрели статическую типизацию для языков с динамической типизацией (хотя это не баг, а фича языка) - чтобы ошибок не было. Да и то далеко не все - посмотреть на тот же V8 - за шутками про оперативную память мы не замечаем, насколько он быстр. Чертовски быстр.
Для нас программирование превращается в магию – сбор заклинаний, которые сочинил какой-то архимаг или даже бог. Никто не знает что они означают, но ведь работают и ладно.
Так это вроде нормально. Базу какую-то знать нужно, но можно же и дальше пойти - вот Вы на асме пишите, понимаете ли вы какие вентили в какое время переключаются в процессоре? Можно ли сказать, что
mov eax, ebx- это магия?
В этом же и есть вектор развития и разделения - кто-то литографы проектирует, кто-то чипы, кто-то компиляторы, кто-то уже на верхнем уровне пишет.johnfound
09.02.2025 09:38Вы на асме пишите, понимаете ли вы какие вентили в какое время переключаются в процессоре? Можно ли сказать, что mov eax, ebx - это магия?
Ну да, конечно понимаю. Если не на количественном уровне (информация закрытая и современны процессоры слишком сложные) то на качественном уж точно. Это абсолютно необходимо для программирования (не только на ассемблере) и оно обязательно входит в курс обучения в университете. Все кто заканчивал какое-то программирование этого проходили.
ZirakZigil
09.02.2025 09:38абсолютно необходимо
Зачем? Можно даже на два вопроса разбить: зачем необходимо, и почему аж абсолютно.
johnfound
09.02.2025 09:38Потому что такие знания очень сильно улучшают качество создаваемого кода, а стоят по сути очень недорого. Вне зависимости от языка программирования.
ZirakZigil
09.02.2025 09:38Каким именно образом улучшают? Вам на асме, может, и улучшают, но вот рядовой погромист на рядовых плюсах (с++17) пишет идиоматичный высокоуровневый код, что он сможет у себя улучшить, если освоит как и почему те или иные элементы работают?
johnfound
09.02.2025 09:38Если программист хотя бы приблизительно осознает как его код будет выполняться на самом деле процессором, то он сможет сделать лучший выбор кода для данной задачи. Даже если и с точки зрения языка высокого уровня разницы нет. Да и вообще, согласитесь, что всегда лучше если знаешь что происходит на самом деле. Хотя, если вы считаете что "кто умножает познания, умножает скорбь", то ладно, живите так.
Yuri0128
09.02.2025 09:38А ведь программист гарантировано не будет знать правду о том, как проц будет исполнять его код. Ибо в другой редакции проца/на другой архитектуре исполнение кода буде проводиться совсем по другому. И ну уж никак не обязательно программисту досконально знать архитектуру всех возможных к применению процов. Ибо повесится он.
Согласен только на знания архитектуры кеширования. Остальное - только забивание головы мусором.
johnfound
09.02.2025 09:38Ибо в другой редакции проца/на другой архитектуре исполнение кода буде проводиться совсем по другому.
Вроде как логично, но все равно неправильно. Код всегда выполняется более/менее одинаково. И соображения, которые работают на одной архитектуре, будут более/менее работать и на всех других. Конечно не в подробностях, но в подробностях вообще никто не знает как работают процессоры, даже те, которые их проектируют и создают.
vkni
09.02.2025 09:38Код всегда выполняется более/менее одинаково.
Это с учётом того, что ассемблер x86-64 - это компилируемый язык среднего уровня? Реальный-то язык современного десктопного процессора, в который компилируется x86-64, закрыт и, видимо, сильно разный для AMD/Intel.
IUIUIUIUIUIUIUI
09.02.2025 09:38Реальный-то язык современного десктопного процессора, в который компилируется x86-64, закрыт и, видимо, сильно разный для AMD/Intel.
Лол, он сильно разный даже просто для разных поколений Intel. Мой любимый пример — разное поведение по зависимостям между 128- и 256-битными версиями simd-регистров в зависимости от конкретного поколения микроархитектуры интелов (где-то vzeroupper надо делать, чтобы OOO нормально работало, где-то — нет).
IUIUIUIUIUIUIUI
09.02.2025 09:38Если программист хотя бы приблизительно осознает как его код будет выполняться на самом деле процессором, то он сможет сделать лучший выбор кода для данной задачи.
Можете пояснить, как конкретно понимание физического уровня до вентилей помогает в написании прикладного кода?
Знакомы ли вы с математической логикой, теорией типов, теорией категорий, и если нет, то почему? Не считаете ли вы, что они тоже улучшают качество кода?
johnfound
09.02.2025 09:38А вы слепому человеку можете объяснить что такое персиковый цвет и почему он имеет значение? Конечно есть разница – слепые редко могут прозреть, как бы им и не хотелось. А программист всегда может изучить что-то новое. А если не хочет – что же, насильно мил не будешь, это его выбор и его код.
IUIUIUIUIUIUIUI
09.02.2025 09:38Интерпретирую ваш уклончивый ответ как «нет, не могу пояснить».
Ну что тут скажешь? Продолжайте необоснованно верить, что знание вентилей делает ваш код на ассемблере для обычных десктопных процессоров лучше.
IUIUIUIUIUIUIUI
09.02.2025 09:38Про кэш достаточно знать, что он есть, у него есть ассоциативность, и что через него синхронизируются разные ядра (поэтому держать два счётчика, дёргаемых двумя разными ядрами, в одном кешлайне не очень хорошая идея). Где здесь физический уровень вентилей?
Один сторонник знания физического уровня и RS-триггеров уже, впрочем, обзывал меня зубрилой потому, что я просто гулю таблички с латентностью разных уровней кэша, ассоциативностью, и так далее, для нужной мне железки, вместо того, чтобы ну вот просто понимать RS-триггеры и выводить эти параметры из первых принципов и электрической схемы процессора. Впрочем, продемонстрировать вывод той же латентности кэша какого-нибудь Skylake из первых принципов и его схемы он почему-то отказался.
Ну и заодно отвечая на ваш соседний комментарий
В эмбединге, где счет на наносекунды, - таки необходимо.
Насчёт эмбеддедов и эмбеддингов не знаю, а вот в HFT, где счёт точно идёт на наносекунды, при написании кода для обычных x86_64, скажем, никакого смысла нет в знании физического уровня до вентилей.
Да, есть FPGA, но FPGA-шники не знают C++ так, как я, например, и не все задачи делаются на FPGA или требуют FPGA.
Yuri0128
09.02.2025 09:38Насчёт эмбеддедов и эмбеддингов не знаю, а вот в HFT, где счёт точно идёт на наносекунды
HFT - это имеется в ввиду "High Frequency Trade"? Если оно - то там нету наносекунд, тама транспортный уровень все съест.
А вот на управлением мощными электромоторами - очень даже идет, ибо при промахе в 200 нс можно получить неплохой такой феерверк.
FPGA-шники вполне о Си знают - ибо есть комбайны FPGA+контроллер (интерфейный/загрузочный).
IUIUIUIUIUIUIUI
09.02.2025 09:38HFT - это имеется в ввиду "High Frequency Trade"? Если оно - то там нету наносекунд, тама транспортный уровень все съест.
Транспортный уровень у всех одинаковый, там даже длину кабелей уравнивают от серверов участников до биржевого сервера. Выигрываете вы как раз за счёт наносекунд.
А вот на управлением мощными электромоторами - очень даже идет, ибо при промахе в 200 нс можно получить неплохой такой феерверк.
Ну так как знание вентилей-то помогает?
Yuri0128
09.02.2025 09:38Ну так как знание вентилей-то помогает?
Нет. Конкретно в этом случае - знание как работает компаратор и величина задержки при записи в порт.
Yuri0128
09.02.2025 09:38Ну, обычный код не улучшают, кроме случая работы с кешированием - там можно раз в 10 ускориться. Но и утверждение что это стоит недорого - сильно спорное.
Yuri0128
09.02.2025 09:38В эмбединге, где счет на наносекунды, - таки необходимо. В остальных случаях я не вижу значимого смысла.
А про абсолют - ну так водка и есть водка.
venanen
09.02.2025 09:38И все таки у меня есть ощущение некого самообмана. То, что проходят в университетах про логику работы и вентили настолько далеко от настоящего современного процессора, что общего там только базовая логика. Это как понимание того, как работает сверточная сеть для MNIST-датасета ничего особо не дает кроме базовой математики, потому что современные трансформеры и другие архитектуры очень, очень далеки от базы, и, возможно, действительно переходят черту "магии", понять которую могут очень далеко не все.
Я бы сказал словами классика: "Знать все на свете нерельно", и всегда будет та грань, после которой на своем уровне начинается магия.sci_nov
09.02.2025 09:38В реальности используется многое из того, что преподают в университете. В итоге получается комбайн из многих базовых концепций. И вся техника построена так. Искусство состоит в том, чтобы правильно комбинировать базовые алгоритмы/техники и получать требуемый продукт.
Например, многие изучая код Хаффмана, думают что он не применяется в реальности. На самом деле применяется, но не только он один, потому что от одного его толку действительно мало. Итд ИТП)
Yuri0128
09.02.2025 09:38Ну я юзаю не более 30% того, что было дадено, то есть большая часть - это просто инфомусор. И в том числе про работу триггера (статичское ОЗУ на них). И это при том, что я еще и проектировщик железа, но к уровню триггера я не опускаюсь.
Код Хаффмана применяю.
Yuri0128
09.02.2025 09:38Так и я о том. У меня с этим довольно удачно вышло. Обычно гораздо хуже. Пару лет вел практику в одном учебном заведении (по прямой специальности, уточнять не буду), так там даже у любознательных было порядка 10-15%.
vkni
09.02.2025 09:38С другой стороны, не очень ведь понятно, какие именно 10% будут из этого всего использованы.
vkni
09.02.2025 09:38То, что проходят в университетах про логику работы и вентили настолько далеко от настоящего современного процессора, что общего там только базовая логика.
Там ровно один курс пропущен. См. книгу Харриса и Харрис.
Кмк, для сквозного понимания работы компьютера (качественного), достаточно Хоровица/Хилла, Харриса/Харриса, потом курса по компиляторам, скажем Essentials of compilers и курса по ОС. Разумеется, там могут подтянуться какие-то ещё курсы (типа TAPL, SICP), но их вполне обозримое количество.
Итого, от транзисторов до верхнего уровня. Для понимания работы транзистора от школьной физики тоже нужен примерно курс.
То есть, вполне реально, если поставить такую цель, выпускать инженеров, понимающих все уровни ЭВМ. Другое дело, что этого почему-то не делают.
IUIUIUIUIUIUIUI
09.02.2025 09:38Утверждаю, что спектра от Харрис и Харрис до TAPL недостаточно, чтобы понимать все уровни ЭВМ, потому что Харрис и Харрис не объясняет квантмех, лежащий за транзисторами, которые в основе всех этих вентилей, а TAPL не объясняет логико-категориальные основания математики.
Без Ландафшица с одной стороны спектра и какого-нибудь «categorical logic and type theory» Якобса с другой нельзя быть хорошим программистом, ящетаю.
vkni
09.02.2025 09:38Утверждаю, что спектра от Харрис и Харрис до TAPL недостаточно, чтобы понимать все уровни ЭВМ
Я не призываю тут никого это всё изучать, поэтому не надо ёрничать. А про квантмех, лежащий за транзисторами я, извини за грубость, точно побольше вашего знаю.
Я о другом. Вокруг меня как-то все рассказывают, что компьютер - это вещь непостижимая сама в себе. Ну и знания стандартного выпускника какого-нибудь физического факультета при рассказе про компьютер напоминают известный мем про рисунок совы.
1. Вот кристаллическая решётка, вот дырки-электроны, вот канал MOSFET, так он управляется. Транзистор готов. Это достаточно хорошая модель, дальше там рыть не надо.
2. Из двух транзисторов мы делаем операционный усилитель, из усилителей мы получаем дискретную логику, из 4 логических элементов - D-trigger, дальше счётчик и сумматор.
3. ----------------------------
4. Рисунко ЭВМ из Фигурнова, язык ассемблера.5. ----------------------------
6. Язык Цэ.
7. ЯВУ высшего порядка.
Так вот, уровни 3 и 5 - это просто Харрис/Харрис и книжка по компиляторам/интерпретаторам.
Соответственно, объём знаний, достаточно цельно покрывающий работу компьютера, велик, но вполне проходим. Замечу, никакой агитации и пропаганды.
IUIUIUIUIUIUIUI
09.02.2025 09:38А про квантмех, лежащий за транзисторами я, извини за грубость, точно побольше вашего знаю.
Вполне возможно, особенно если говорить про транзисторную часть, а не логическую, например.
Хотя, впрочем, все релевантные дисциплины в Физтехе я сдал на отл или хор (от теормеха с введением в лагранжев и гамильтонов формализм через сам квантмех до какой-то ерунды по моделированию в том числе квантовомеханических процессов, по которой у меня был хор из-за того, что я задиристый засранец). Но да, это не моя специализация (и я приматом был), и уж точно не в моей активной памяти.
Соответственно, объём знаний, достаточно цельно покрывающий работу компьютера, велик, но вполне проходим.
Но не нужен. Потому что пока ты учишься рассчитывать фононы в кристаллических решетках и плазмоны-поляритоны на их границе (ой, надо топологию изучить, кстати, опять математика попёрла), Вася изучает паттерны, методологии разработки, рассуждения о литкод-алгоритмах на интервью вслух, командную работу и софт-скиллы, и нанимается на работу вместо тебя. А ты идёшь со своим пхд по квантам и требованием 5-7 лет опыта работы с этим вот всем в калифорнийский медстартап за смешные 50-70к в год, пока двухлетний выпускник буткампа идёт фронтендером кнопочки перекрашивать за 100-150.
Поэтому смотри, что выходит: у тебя есть куча дисциплин, освоение которых требует нетривиальных усилий, которые не приносят практически никакой пользы лично тебе, и альтернативные издержки которых ощутимо высоки. На обывательско-человеческом языке это называется «неподъёмная задача».
vkni
09.02.2025 09:38Но не нужен.
Это уже другой вопрос.
На обывательско-человеческом языке это называется «неподъёмная задача».
Я говорю про конкретно наше образование. А мне лично, получается, достаточно написать компилятор и немного поиграться с FPGA, параллельно читая Харрисов. И всё - гешефт закрыт, я в общих чертах понимаю всю ЭВМ насквозь.
пока двухлетний выпускник буткампа идёт фронтендером кнопочки перекрашивать за 100-150.
А если бы он пошёл работать валютной проституткой, то зашибал бы больше и раньше. Но мы ему давать советы тут, пожалуй, не будем...
IUIUIUIUIUIUIUI
09.02.2025 09:38Это уже другой вопрос.
Это ключевой вопрос, потому что разговор о реалистичности тех или иных сценариев развития всегда неявно подразумевают их оправданность.
А если бы он пошёл работать валютной проституткой, то зашибал бы больше и раньше. Но мы ему давать советы тут, пожалуй, не будем...
Проститутки ассоциируются с криминалом, не более. Говорят, в развитых странах с легализованной проституцией этой стигмы меньше.
Да и все мы занимаемся проституцией, продавая свои мозги, по большому счёту.
vkni
09.02.2025 09:38нельзя быть хорошим программистом, ящетаю.
Программистом чего? Вообще, то, что умеешь держать сразу много системных уровней, часто помогает в жизни. Естественно, при этом знания достаточно поверхностные, например, без Якобсов, но с Пирсами...
Я подозреваю, что вот всё это хорошо держать в голове при разработке всякой электроники, окрашенной в зелёный цвет. И для космоса.
IUIUIUIUIUIUIUI
09.02.2025 09:38Вообще, то, что умеешь держать сразу много системных уровней, часто помогает в жизни.
И это естественным образом прокачивается при работе обычным программистом ровно в том объёме, который обычным программистам и нужен.
разработке всякой электроники, окрашенной в зелёный цвет
Работа мечты!
vkni
09.02.2025 09:38естественным образом прокачивается при работе обычным программистом ровно в том объёме, который обычным программистам и нужен.
Ну нам-то какое дело до обычных программистов?
Работа мечты!
Люди разные.
IUIUIUIUIUIUIUI
09.02.2025 09:38Ну нам-то какое дело до обычных программистов?
Дело до того, что разговор с них начался, наверное? Вон какой исходный тезис был (самую важную часть выделил жирным):
Это абсолютно необходимо для программирования (не только на ассемблере) и оно обязательно входит в курс обучения в университете. Все кто заканчивал какое-то программирование этого проходили.
IUIUIUIUIUIUIUI
09.02.2025 09:38С хорошим таким успехом, очень небольшим количеством багов и прекрасной производительностью.
При этом, когда дело дошло до практики, после ваших деклараций, что код на ассемблере вполне хорош и легко поддерживаем, мы с вами попытались сравнить поддерживаемость кода на ассемблере и моих языках на примере написания парсеров. И вы отказались решать задачу, на которую мы оба согласились, и в которую я, в отличие от вас, таки вложил время и усилия. Вместо этого вы привели когда-то написанный код для какого-то другого проекта, который делает что-то отдалённо похожее, не более.
isumix
09.02.2025 09:38Как говорится: в чужой монастырь со своим уставом...
ahabreader
09.02.2025 09:38Для защиты прихожан от чужаков есть простой линусовский жест: "*YOU* are full of bullshit. $LangName is a horrible language". Но это не иноверцы, два креста носящие, Rust в ядро приглашён. Линус проблемы мягко обрисовывает как конфликт поколений: есть у них "old-time kernel developers", которые Rust не знают и знать не хотят (
а когда закончатся - вступайте в наследство).К тому же в этот раз могут надавить государство и корпорации. В старой истории с C++ у них интереса не было, а сейчас ОАО "Красная шляпа" и прочие могут напомнить, на чьей земле монастырь стоит.
Zhuikoff
09.02.2025 09:38Это что-то про Вавилонскую башню? Чтобы её разрушить, строителям нужно начать говорить на разных языках?
ihouser
09.02.2025 09:38Вавилонская башня это символ экономического успеха Вавилона и его падения. Слишком большой успех привлек много иностранцев. Вавилон неосилил ассимилировать эту массу. Разные неуправляемые нравы, разные языки очень осложнили жизнь и в конце концов привели к разрушению Вавилона.
Так что, самое главное тут - управляемость проекта.
IndyCar
09.02.2025 09:38даже не так,- чтобы начать её строить, надо привлечь дополнительную рабочую силу, а там пошло-поехало, и вот мы видим «бесполезную нетехническую ерунду»
AntonLarinLive
09.02.2025 09:38Увы, это удел всех проектов с гигантской кодовой базой и гигантским количеством инсталляций. Никто в реальности не будет их переписывать, какими бы благими намерениями это не было вызвано. Просто из-за лавинообразного нарастания сложности поддержки и дальнейшей разработки.
dv0ich
09.02.2025 09:38А могли бы просто взять С++.
Мне даже интересно, когда до них дойдёт, что С++ это неизбежность для ядра, невзирая на тупой хейт Линуса по отношению к крестам.
vanxant
09.02.2025 09:38А что такого дали бы плюсы именно в ядре? Учитывая, что stl и прочих библиотек там нет и не будет. И скорее всего не будет исключений.
Ну я навскидку назову виртуальные функции вместо явного использования указателей на функции и "ручной" реализации VPTR. Синтаксис указателей на функции трудно назвать приятным, но само по себе это погоды не делает.
И ещё RAII вместо goto exit_N (но оно требует исключений, так что вероятно нет).
Шаблоны просто не нужны, в ядре практически нет таких задач. Раскидистые иерархии классов с множественным наследованием — наворотить то можно, но зачем?.. А что тогда ещё?
ZirakZigil
09.02.2025 09:38но оно требует исключений
Лечится optional'ами и expected'ами, если я правильно понял, почему "требует".
vanxant
09.02.2025 09:38не, не лечится. Разве что костылится. См. мой коммент ниже.
ZirakZigil
09.02.2025 09:38возможно, в виде пачки вложенных if
Если всё завёрнуто в optional'ы, то эти if'ы будут неявными (в деструкторе у этих optional).
Ну т.е. да, это всё ещё проверки на каждый чих, но как минимум мы избавляемся от этого goto блока, и от потенциальных ошибок, что какой-то void * передали во free_resource1 вместо free_resource2.
Мы совершенно ничего не теряем, но приобретаем.
ahabreader
09.02.2025 09:38И ещё RAII вместо goto exit_N (но оно требует исключений, так что вероятно нет).
Основная идея RAII в освобождении ресурсов в ходе автоматического удаления объекта (поэтому, собственно, в названии идиомы нет ни освобождения, ни уничтожения...).
Почему отсутствие исключений не очень важно:
Не важно в деструкторе, потому что из него в любом случае не следует кидать исключения. Ещё RAII требует, чтобы освобождение ресурсов не могло сломаться, ядро Linux обычно тоже из этого исходит.
А что до acquisition & initialization, то придётся, например, удалить конструктор и собирать объект функцией, возвращающей std::optional (или как-нибудь погрязнее).
vanxant
09.02.2025 09:38RAII без конструкторов не имеет смысла. Замена конструкторов на возврат
std::optionalтолько добавит писанины, но не избавит вас отgoto(возможно, в виде пачки вложенныхif).Ну, например, вам нужно скопировать данные откуда-то куда-то. Для этого вам нужно выделить память под буфер и открыть два дескриптора. Потом, соответственно, вам надо всё это закрыть и освободить, при любом развитии событий. Если это у вас три вызова
new, то всё нормально, С++ за вами приберёт, если один из конструкторов выкинет скажемbad_alloc. А если безnew, то приветgoto.ahabreader
09.02.2025 09:38RAII без конструкторов не имеет смысла.
Атрибут cleanup (GNU C) считают за RAII. Его используют в systemd.
Если это у вас три вызова new, то всё нормально, С++ за вами приберёт
Если мы вручную вызвали new, то нам вручную и вызывать delete. RAII нет.
Если мы как угодно получили ресурс в конструкторе RAII-контейнера, то нам его и освобождать в деструкторе, фокус на new не нужен.
Замена исключений (в конструкторе) на std::optional (в функции, создающей объект) - это, вроде как, лишь замена одного способа обработки ошибок на другой. if'ы вместо try-catch.
vanxant
09.02.2025 09:38Зарапортовался. Вызов new разумеется спрятан в конструкторе локальной переменной, а соответствующий delete - в деструкторе.
ahabreader
09.02.2025 09:38К слову о том, что делает systemd.
В одном файле:
// ... _cleanup_(memstream_done) MemStream m = {}; FILE *tf = memstream_init(&m); if (!tf) return log_oom(); // ... (используем tf, m больше не упоминается) // _cleanup_ определён как // #define _cleanup_(x) __attribute__((__cleanup__(x)))В другом файле (а структура MemStream тут):
void memstream_done(MemStream *m) { assert(m); /* First, close file stream, as the buffer may be reallocated on close. */ safe_fclose(m->f); /* Then, free buffer. */ free(m->buf); }Разбросано по файлам, но
memstream_doneпереиспользуется около 40 раз.С RAII-на-std::optional было бы что-то в духе этого:
// ... std::optional<MemStream> m = MemStream::TryCreate(); // Вместо memstream_done - деструктор MemStream // memstream_init пусть будет статическим методом TryCreate if (!m) return log_oom(); // ... (используем m->f)
IUIUIUIUIUIUIUI
09.02.2025 09:38Замена конструкторов на возврат std::optional только добавит писанины, но не избавит вас от goto (возможно, в виде пачки вложенных if).
Зачем?
MaybeиEither… тьфу,optionalиexpected— это «линейные» монады, их можно разворачивать черезco_await. Вполне можно писать код в духеstd::optional<int> getCount(); template<typename T> std::optional<T*> allocateMem(int); std::optional<Result> doStuff() { const auto count = co_await getCount(); const auto mem = co_await allocateMem<int>(count); const auto objects = co_await initialize(mem, count); co_return doSomethingWith(objects); }
Kelbon
09.02.2025 09:38что stl и прочих библиотек там нет и не будет. И скорее всего не будет исключений.
stl это standard template library, для большей части из неё не нужно никаких исключений, выделения памяти и тд, ничего не мешает ей быть в ядре
RAII тоже не требует исключений, оно просто работает и с исключениями тоже ( в отличие от goto)
Факт в том, что нет никаких недостатков от перехода на С++ и стоимость крайне низкая, а вот преимуществ много - уверен, что в ядре очень много кода можно было бы избежать шаблонами или упростить constexpr, в конце концов иметь нормальные енамы вместо тех что с префиксами из-за того как работают сишные, плюс к тому С++ запрещает никому не нужны кривые конструкции из С, такие как typedef без определения типа
4p4
09.02.2025 09:38Проблема в том, что нельзя просто взять и договориться использовать только некоторый "полезный" сабсет с++, люди будут использовать всё что компилятор разрешит. Придётся возложить работу по копмлаенсу на людей, а это не работает.
Kelbon
09.02.2025 09:38с тем как использовать С договорились, как-то используют. Не вижу никаких проблем также сделать с С++, для начала просто переключить gcc в режим С++
AnimeSlave
09.02.2025 09:38На самом деле не договорились, а скорее запретили использовать нововведения. Типа когда-то начали с gnu89, и очень неохотно переходили на новые стандарты. Только в 2022 году перешли на gnu11. В языке C это позволяет не использовать не нужные вещи. В то время как в C++ всё иначе.
Сейчас не возможно заставить C++ программиста программировать на C++98. Это просто бессмыслено. Все самые важные изменения пришли в C++11, а они с собой несут очень много специфичного поведения, которые для стабильности ядра linux, могут иметь отрицательный эффект.
Проблема ещё, не возможно выделить в C++ какой-то особый набор правил типа только C с классами. Некоторые программисты например не знают, что семантика перемещения имеет свои особенности, и без костылей её не возможно применять. А костыли нужны. И часть таких костылей является частью стандартной библиотеки. А это значит, что нужно нести стандартную библиотеку языка C++ в ядро. Стандартная библиотека C++ имеет ряд особенностей, которые, опять же, могут отрицательно сказаться на стабильности работы ядра.
То есть, есть куча нюансов из-за которых просто так взять, и разрешить C++ в ядре нельзя
IUIUIUIUIUIUIUI
09.02.2025 09:38Все самые важные изменения пришли в C++11, а они с собой несут очень много специфичного поведения, которые для стабильности ядра linux, могут иметь отрицательный эффект.
Например?
Некоторые программисты например не знают, что семантика перемещения имеет свои особенности, и без костылей её не возможно применять. А костыли нужны. И часть таких костылей является частью стандартной библиотеки.
Например?
Ну, только чтобы это было вредно для ядра. Так-то костыли везде нужны, понятное дело.
А это значит, что нужно нести стандартную библиотеку языка C++ в ядро.
Только нужное для используемых вещей подмножество.
std::threadдля мув-семантики тащить не обязательно.То есть, есть куча нюансов из-за которых просто так взять, и разрешить C++ в ядре нельзя
Этим аргументом и заботой о нюансах можно парализовать любую работу и любые изменения.
AnimeSlave
09.02.2025 09:38Например?
Шаблонов вполне досточно. SFINAE.
Например?
Копирование данных при неправильно перемещении. Перемещение данных при неправильно копировании. Кейсы редкие, но не невозможные.
Только нужное для используемых вещей подмножество.
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте. Сомневаюсь, что на это пойдут, если до сих пор так не сделали. А я что-то не помню, чтобы для C запрещали использовать что-то из стандартной библиотеки.
IUIUIUIUIUIUIUI
09.02.2025 09:38Шаблонов вполне досточно. SFINAE.
Было в C++03. C++11 добавило expression sfinae, но это вопрос юзабельности и упрощает метапрограммирование.
Впрочем, как шаблоны и sfinae влияют на стабильность ядра linux?
Копирование данных при неправильно перемещении.
operator=(const Foo&) = delete; operator=(Foo&&) { ... }Перемещение данных при неправильно копировании.
Это надо как-то отдельно постараться ещё.
Как там с use-after-free дела, кстати?
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте.
Кто сказал?
Напомню, кстати, что ядро написано не на стандартном C, а на диалекте. Апеллировать к отсутствию каких-то ограничений в стандарте плюсов — это снова интеллектуальная нечестность.
А я что-то не помню, чтобы для C запрещали использовать что-то из стандартной библиотеки.
Что, даже
thrd_createможно в ядерном коде?AnimeSlave
09.02.2025 09:38Впрочем, как шаблоны и sfinae влияют на стабильность ядра linux?
А как sfinae работает? Всегда так как задумано?
operator=(const Foo&) = delete; operator=(Foo&&) { ... }А как это поможет когда нужно и то, и то?
Кто сказал?
Хотите сказать, что нет? Вы прям можете запретить не вызывать отдельные инклюды?
Что, даже thrd_create можно в ядерном коде?
А что, запрещено документально?
IUIUIUIUIUIUIUI
09.02.2025 09:38А как sfinae работает? Всегда так как задумано?
Это что за аргумент вообще такой? Какой мейнстримный ЯП всегда работает так, как задумано?
А как это поможет когда нужно и то, и то?
А как сишники сейчас справляются с тем, когда нужно и то, и то?
Кстати, на плюсах я могу сделать что-то в духе
// один раз, utility-класс template<typename T> struct ForceCopy { const T& src; explicit ForceCopy(const T& s) : src { s } {} }; // ... Foo(const Foo&) = delete; Foo(ForceCopy<Foo>) ... Foo(Foo&& other) ... operator=(const Foo&) = delete; operator=(ForceCopy<Foo>) { ... } operator=(Foo&&) { ... }и использовать как
Foo foo = makeFoo(); //doSmthWithCopy(foo); ниработаит doSmthWithCopy(ForceCopy { foo }); // работаит doSmthWithCopy(std::move(foo)); // работаит doSmthWithCopy(makeFoo()); // работаит doSmthWithCopy(Foo { ... }); // работаит //foo.bar(); линтер ругнётся на use-after-move— всё предельно явно, грепабельно и типобезопасно (насколько это может быть безопасно для языков C-семейства).
И линтер действительно ругнётся, например, clang-tidy:
note: Object 'foo' is moved 37 | doSmthWithFoo(std::move(foo)); | ^~~~~~~~~~~~~~ note: Method called on moved-from object 'foo' 39 | foo.bar(); | ^~~~~~~~~Хотите сказать, что нет? Вы прям можете запретить не вызывать отдельные инклюды?
Да, конечно. Например, не имея этих инклюдов в путях компилятора в процессе сборки.
А что, запрещено документально?
Лол. Lmao even. В который раз убеждаюсь, что самые ярые фанаты сишки нихрена не знают о C, а самые ярые фанаты штабильности в ядре нихрена не знают ни о конкретном обсуждаемом ядре. Кекспертиза уровня опеннета.
Читайте https://kernelnewbies.org/FAQ/LibraryFunctionsInKernel . Потом можете погрепать исходники ядра на предмет упомянутой функции. Хотя не, у вас же их под рукой нет, так что я сделаю это за вас:
10:55:43 деанон@deadzxt /usr/src/linux % grep -Rw thrd_create | wc -l 0знаете, что это значит?
AnimeSlave
09.02.2025 09:38Это что за аргумент вообще такой? Какой мейнстримный ЯП всегда работает так, как задумано?
C не просто так стал языком ядра, а C++ не стал. И шаблоны отчасти были тому причиной. У вас странная реакция. Сами задали выпрос. Если вещи очевидны, к чему тогда сам вопрос был.
А как сишники сейчас справляются с тем, когда нужно и то, и то?
Никак. В C нет семантики перемещения.
Да, конечно. Например, не имея этих инклюдов в путях компилятора в процессе сборки.
И вы можете запретить их добавлять? Не можете.
Читайте https://kernelnewbies.org/FAQ/LibraryFunctionsInKernel .
Вот это уже конструктивный диалог. А теперь вернёмся к моему сообщению выше:
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте.
Я об этом и написал. Для реализации на месте нужно будет ести все костыли стандартной библиотеки. Без костылей в виде
std::moveилиstd::forwardиз стандартной библиотеки семантика перемещения не работает. Помимо ни есть ещё целая куча вещей. Если смотреть на ситуацию с языком C++ со стороны, то отказ от него в ядре вполне оправдан
IUIUIUIUIUIUIUI
09.02.2025 09:38C не просто так стал языком ядра, а C++ не стал.
Например, по личным причинам — ну не нравится Торвальдсу язык, и всё тут. Или по легаси-причинам — просто потому, что в 91-м году с компиляторами и стандартом C++ было всё очень плохо.
И шаблоны отчасти были тому причиной.
Так в чём конкретно проблема со sfinae, можете сказать? Особенно чтоб в C++11 она усугубилась, как вы изначально говорили.
Сами задали выпрос. Если вещи очевидны, к чему тогда сам вопрос был.
Этот вопрос — риторический, и является ответом на ваш псевдоаргумент. Собственно, вопрос к этому ответу, и вы так и не пояснили, в чём конкретно проблемы.
Никак. В C нет семантики перемещения.
Всегда копируют, что ли? Ну вот заодно перемещать научатся. Видите, одни плюсы!
И вы можете запретить их добавлять? Не можете.
Не понял, почему не могу? Не принимаю патч, который добавляет что-то, точно так же, как не приму патч, который сегодня добавляет
thrd_create.Без костылей в виде std::move или std::forward из стандартной библиотеки семантика перемещения не работает.
Это вообще однострочники, их самому можно написать, в чём костыльность и в чём проблема?
Помимо ни есть ещё целая куча вещей.
Вы упорно избегаете конкретики, просто размахивая руками и высказывая общие тезисы.
ahabreader
09.02.2025 09:38Если с другой стороны посмотреть, то когда-то жила идея, что C++ сможет заменить C и почти все на него перейдут. И у Страуструпа, вроде как, жила.
А потом умерла. И уже первый стандарт C++ как бы хоронил идею, требуя поддержку исключений в freestanding-режиме ("bare metal", не hosted). Можно найти высказывания Страуструпа, что C++ в ядрах ОС следует использовать именно с исключениями и в Linux тоже, он ссылался на чей-то эксперимент.
ahabreader
09.02.2025 09:38просто взять и договориться использовать только некоторый "полезный" сабсет
Нет, с Си так и поступили. Он тоже много всякого позволяет, но договорились об определённом подмножестве.
Например: The Linux Kernel Is Now VLA (Variable-Length Array) Free
vanxant
09.02.2025 09:38стоимость крайне низкая
))) осталось переучить несколько тысяч программистов, большинство из которых железячники и в эти ваши ООП с паттернами, простите, проектирования, нормально не умеют.
Два вагона книжек "С++ за 21 день" кто оплатит?)
Kelbon
09.02.2025 09:38А зачем их переучивать, если то что уже работало не сломается? Если вы начинаете компилировать С код С++ компилятором, то ни-че-го не меняется в коде в 99% случаев
vanxant
09.02.2025 09:38а потом программист С открывает код коллеги на современных плюсах, в целях отладки например, видит нагромождение двоеточий и всех видов скобочек и в ужасе закрывает.
IUIUIUIUIUIUIUI
09.02.2025 09:38Учитывая, что stl и прочих библиотек там нет и не будет.
Чем какой-нибудь
any_ofилиfor_eachплох?И ещё RAII вместо goto exit_N (но оно требует исключений, так что вероятно нет).
Нет, early return тоже норм.
Шаблоны просто не нужны, в ядре практически нет таких задач.
А если найду всю эту замечательную макросню и
void*вместо нормальных типов?
AirLight
09.02.2025 09:38Звучит так, будто есть проблема интерфейсов и нет взаимозаменяемости компонентов. Я полагаю, что одни и те же компоненты должны быть легко заменяемыми реализацией на обоих языках. И вероятно, там не хватает покрытия тестами, чтобы сделать такие подмены безопасными.
TimurTukaev
09.02.2025 09:38Статья названа абсолютно некорректно и лид формирует ложные ожидания. Автор даже не представляется и не говорит, почему ее мнение по этому вопросу может быть значимым и полезным, так же как не говорит он и о том, что это просто ее компиляция и пересказ разных мнений. Так нельзя, это враньё. Selectelну вы чего? Вы же толковые технари, так почему такой кликбейт в свой блог регулярно допускаете? Так же нельзя. Планку держать надо, а не отусом или Максом ракатански становиться
sci_nov
09.02.2025 09:38Раз ядро так разраслось, то и поддержка двух языков это нормально, и, скорее всего, прогресс победит и некоторые олды - приверженцы С - оставят свои позиции, дав дорогу молодым растовцам.
Это нормально, когда большой проект поддерживает более одного языка. Это рабочий вариант. Да, в переходный момент будет тяжело, но постепенно всё устаканится.
Кто его знает, может третьим языком будет Python? Лет так через дцать... Не говорю что прям в ядре, но где-нибудь на окраине ядра, на периферии.
Yuri0128
09.02.2025 09:38приверженцы С - оставят свои позиции, дав дорогу молодым растовцам
вы думаете, что растовцы будут изучать Си? Ибо для переписывание придется это делать.
Это нормально, когда большой проект поддерживает более одного языка.
Это жопа в поддержке. Притом реальная.
Кто его знает, может третьим языком будет Python?
Не будет, он для других целей разрабатывался (в отличие от того-же Раста).
Не говорю что прям в ядре, но где-нибудь на окраине ядра, на периферии.
Ну юзерский интерфейс уже на нем пишут. Норм. На окраину ядра его - да ну нафиг.
sci_nov
09.02.2025 09:38Да, я думаю есть люди которые знают и С, и Раст.
AnimeSlave
09.02.2025 09:38Они даже в ядре linux есть среди мейнтейнеров.
sci_nov
09.02.2025 09:38Язык Си легче языка Раст, и видимо поэтому идея перевода на Раст прошла. Те, кто на ты с Растом, поймут конструкции языка Си. Разрабатывая ядро, программист должен понимать логику работы системы, а раз долгое время всё было на Си, то как бы это обязывает понимать Си.
rsashka
Во первых, вы забыли указать ссылку на первоисточник новости: https://www.opennet.ru/opennews/art.shtml?num=62685
Во вторых, вы либо по не знанию, либо намеренно исказили смысл и техническую суть проблемы:
В третьих, сам кризис:
После чего:
alan_dani
Внесу небольшую корректировку. Хелльвиг не сравнивал Rust с раковой опухолью. Оригинал его сообщения доступен по ссылке.
Т.е. он явно объяснил, что сравнивает с раковой опухолью процесс поддержки двух-язычной кодовой базы, а не Rust.
Приведу его другое сообщение относительно Rust:
Я не перевожу эти сообщения на русский язык, чтобы каждый сформировал свое личное мнение.
К позиции Хелльвига есть вопросы, но переводить её на эмоциональный уровень нет необходимости.
rsashka
Класс, я узнал новый термин "flameware" :-)
alan008
Он просто старый пердун и не хочет учить ничего нового )
IUIUIUIUIUIUIUI
Давайте почитаем вашу же ссылку ещё:
То есть, возникает абсолютно шизофреническая ситуация, когда Кристоф не хочет мейнтейнить код на расте сам, но при этом отказывается от предложения, чтобы растовские обвязки мейнтейнились их авторами, говоря, что дополнительные мейнтейнеры не нужны.
Ну, вернее, шизофреническая она, только если считать, что вся мотивация всех участников базара высказана ими же полно и без вранья. Шизофрения исчезает при вполне естественном и подтверждаемым опытом предположении, что мейнтейнер — это человек с непочиненным синдромом вахтёра, и ему хочется продолжать иметь полный и безраздельный контроль над МОЁ!!!
Теперь особенно смешно это читать. Это теперь какой-то другой Линус, не тот, который же финн?