The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Четвёртая редакция патчей для ядра Linux с поддержкой языка Rust , opennews (?), 17-Янв-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


293. "Четвёртая редакция патчей для ядра Linux с поддержкой языка ..."  –1 +/
Сообщение от JMemail (?), 19-Янв-22, 23:54 
Вижу во всём этом кучу потенциального геморроя.

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

2. Геморрой социальный. Сообщество разработчиков Linux было единым, со своими идиомами программирования, с единым языком, с единой культурой, со своей философией (свобода там, все дела). А тут в эту культуру хотят впендюрить совершенно инородный элемент: nien! нельзя к памяти обращаться! Развивать один проект на двух разных языках - это просто гарантировать разрушительный для всего проекта конфликт между сторонниками радикальго разных (в данном случае) культур. Тут выше говорят о конкуренции, и о её благости. Да, конкуренция - это хорошо, но не внутрипроектная, а внешняя. Пусть на Rust делают Redox, а потом сравним результаты (нет, не сравним, конечно, потому что см. технические проблемы).

Получается, Google разрушает сообщество разработчиков ядра. Я не думаю, что менеджеры Google этого не понимают. Следовательно, это делается целенаправленно. Вопрос: зачем?

Ответить | Правка | Наверх | Cообщить модератору

294. "Четвёртая редакция патчей для ядра Linux с поддержкой языка ..."  +/
Сообщение от DyadyushkaAU (ok), 20-Янв-22, 02:03 
1. Танцы с бубнами есть, но не такие уж и извращённые. Двусвязный список сделать возможно. Проблема в том, что компилятор Раст очень щепетилен и не любит неопределённостей, а в двусвязном списке они присутствуют. Поэтому приходится прибегать к unsafe. Односвязный список можно реализовать без unsafe. В книге по Раст приводится пример.
Однако же вполне можно пользоваться готовым. https://docs.rs/intrusive-collections/latest/intrusive_colle.../

2. На начальных этапах Расту  отводится роль языка для написания драйверов. Так что сообщество разработчиков ядра, как было единым, так им и останется. А на чём там драйверы написаны - да какая разница?

> nien! нельзя к памяти обращаться

Это что за бред? Конечно, можно. Лучше безопасно. Но если очень хочется, можно и как в Сях - небезопасно. Разница в том, что при некорректной работе с памятью ошибку будет куда проще локализовать на Расте - достаточно пройтись по коду с метками unsafe.

> Получается, Google разрушает сообщество разработчиков ядра

Получается, ты начитался какой-то белиберды от хейтеров и теперь транслируешь их страхи, даже не пытаясь особо вникнуть в детали.
Гугл пытается оптимизировать свои расходы. Потому что если принять во внимание статистику, то количество ошибок некорректной работы с памятью приближается к 70% от общего количества ошибок - это очень много, такие ошибки часто критичные, на исправление тратится много времени и денег. Если Раст позволит сократить количество таких ошибок и время на их локализацию хотя бы вдвое - то это уже огромный жирный плюс.

Ответить | Правка | Наверх | Cообщить модератору

298. "Четвёртая редакция патчей для ядра Linux с поддержкой языка ..."  +/
Сообщение от JMemail (?), 21-Янв-22, 07:18 
1. И вот это вот вы называете не извращённым? https://github.com/Amanieu/intrusive-rs/blob/master/src/link...

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

И если бы мне хватало односвязных списков без циклов, я бы писал на чём-нибудь функциональном. Зачем вообще связываться с императивными языками, указателями и ссылками в таком случае?

2. Нет, не получается. Меня заставили писать на Rust текущий проект для микроконтроллера, и я уже этого Rust столько наелся, что спасибо, больше не надо. Больше всего раздражает, что технические решения принимают менеджеры, которые последний раз код писали лет 100 назад, которым к тому же надувают в уши всяких абстрактных культов о том, что мол строгая типизация спасает от ошибок. Да нифига она не спасает, и это научно установленный факт. От ошибок спасают неизменяемые структуры данных. Но, к сожалению, ядра операционок или вот микроконтроллеры они вообще целиком и полностью про изменяемые структуры данных, про взаимодействие с изменяемым миром, в котором куча переменных взаимосвязей.

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

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

Кстати, зелоты Haskell тоже в свой время кричали о том, что вот сейчас они возьмут и напишут операционную систему, безопасную и без утечек памяти. И что? И где? Тоже дошли примерно до уровня Redox и сдулись.

В прошлый раз жертвой такого надувательства стала Microsoft, которая только вот недавно избавилась от этого груза, выпнув Haskell-истов из своих лабораторий в Haskell Foundation и свободное плаванье. Хотя, теперь они умудрились присосаться к Epic Games, и будут сейчас изобретать ей язык Verse.

Впрочем, в эпоху постмодерна и деконструкции, кого интересует реальная наука и практика? Да, ведь? Главное громче всех кричать о том, что даже не сделано (как например в Haskell нет никакой категории Hask, зато про неё громче всех кричат). Про Rust даже не доказана теорема о продвижении, которая просто must have, если вы кричите о навороченной системе типов. И баги и ошибки Rust пропускает, есть много тому примеров, только они очень сложные и нетривиальные, и рождаются в попытках реализовать необходимое через барьеры ограничений, которые Rust ставит.

Для избегания ошибок с памятью у Google есть Go. Если Google не устраивает Linux, они могут просто взять Rust и написать на нём своё ядро (ха-ха-ха, конечно, см. пример Redox), вот будет настоящая конкуренция. Типа, смотрите, мы написали ядро на Rust и оно лучше Linux. Зачем в Linux-то тащить весь этот маразм? Нет, ну реально, в Linux владение ссылками постоянно переходит от одних структур данных к другим, структуры данных постоянно перемещаются для оптимизации, на Rust с этим работать - полная дикость. Так зачем? Ради хайпа, политических и социальных плюшек?

Ответить | Правка | Наверх | Cообщить модератору

307. "Четвёртая редакция патчей для ядра Linux с поддержкой языка ..."  +/
Сообщение от DyadyushkaAU (ok), 25-Янв-22, 02:04 
> 1. И вот это вот вы называете не извращённым? https://github.com/Amanieu/intrusive-rs/blob/master/src/link...

Хотелось бы большей конкретики. ИМХО, код как код.

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

Но я ведь объяснил причину. Повторюсь. Если имеем дело с неопределённостями, причём сложными, то или обмазываемся Option, Box, Rc, Arc и т.д. (сложный синтаксис, да), либо сразу пишем unsafe. Вполне себе нормальный подход. Хотите ходить быстро (тяп-ляп, как в Си) по граблям без гарантий компилятора - ок, вот вам инструмент. Хотите гарантий компилятора при работе с динамичными и местами неопределёнными структурами - чешите репу. На Си или Плюсах, если бы вы захотели гарантий, вам бы пришлось действовать точно так же, только репу чесать ещё сильнее и дольше. Поэтому я не понимаю, чем вы недовольны.

> В ядрах операционок требуются гораздо более сложные конструкции
> с уймой перекрёстных ссылок.

Например? Кроме файловой системы в голову больше ничего особо и не приходит. Вы её имели ввиду? Или что-то ещё?

> И что, Rust мне предлагает для каждой такой структуры писать такую нахлобучку из unsafe-кода?

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

> И этот код нетривиальный, в нём легко накосячить и сложно косяк найти.

Гораздо проще, чем в C. Потому что куски unsafe изолированы друг от друга. Опять же странно, что вам нравится копаться в одной сплошной куче unsafe-кода, нежели в отдельных изолированных кусочках.

> И если бы мне хватало односвязных списков без циклов, я бы писал
> на чём-нибудь функциональном. Зачем вообще связываться с императивными языками, указателями
> и ссылками в таком случае?

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

> строгая типизация спасает от ошибок. Да нифига она не спасает, и это
> научно установленный факт.

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

> От ошибок спасают неизменяемые структуры данных.

С ними, понятное дело, куда проще иметь дело. Логических ошибок будет действительно гораздо меньше. Но причём здесь логические ошибки до ошибок приведения типов?

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

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

> И что? И где? Тоже дошли примерно до уровня Redox

А что с Redox не так? Разработка затихла? Или какие конкретно претензии?

> Про Rust даже не доказана теорема о
> продвижении, которая просто must have, если вы кричите о навороченной системе
> типов.

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

> И баги и ошибки Rust пропускает, есть много тому примеров

Ещё раз. Rust не страхует от всех возможных ошибок. Только от определённого класса: некорректное приведение типов, некорректная работа с памятью.

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

Там, где много неопределённости - так и есть. Но в каких языках по-другому? Конкурентное программирование да ещё с динамическими общими структурами - одна из самых сложных областей в программировании. На других языках, подозреваю, то, что в Rust можно сделать хоть с какими-то гарантиями, сделать невозможно от слова "совсем". Встречалась статья, где один мужик оптимизировал софт на крупной международной бирже. За полгода ему удалось сделать то, что не удалось сделать коллективу плюсовиков за несколько лет. Главная причина - сложность многопоточного программирования в плюсах. Мужик писал на F#, где, по-видимому, с этим дела обстоят намного проще.

> Зачем в Linux-то тащить весь этот маразм?

Может потому, что это не маразм в глазах программистов Google, MS, Huawei, Amazon, Mozilla и кучи других более мелких спонсоров?


Ответить | Правка | Наверх | Cообщить модератору

301. "Четвёртая редакция патчей для ядра Linux с поддержкой языка ..."  +/
Сообщение от Аноним (-), 21-Янв-22, 18:46 
>А на чём там драйверы написаны - да какая разница?

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

Ответить | Правка | К родителю #294 | Наверх | Cообщить модератору

303. "Четвёртая редакция патчей для ядра Linux с поддержкой языка ..."  +/
Сообщение от Аноним (-), 21-Янв-22, 19:01 
>Геморрой социальный. Сообщество разработчиков Linux было единым, со своими идиомами программирования, с единым языком, с единой культурой, со своей философией (свобода там, все дела). А тут в эту культуру хотят впендюрить совершенно инородный элемент

А ты посмотри на состав раст фаундейшена и заодно вспомни, сколько внутри растосферы sjw на зарплате у MS.

Ответить | Правка | К родителю #293 | Наверх | Cообщить модератору

304. "Четвёртая редакция патчей для ядра Linux с поддержкой языка ..."  +/
Сообщение от Аноним (-), 21-Янв-22, 19:28 
> А ты посмотри на состав раст фаундейшена и заодно вспомни, сколько внутри
> растосферы sjw на зарплате у MS.

На состав линукс фаундейшена давно смотрел?


Ответить | Правка | Наверх | Cообщить модератору

305. "Четвёртая редакция патчей для ядра Linux с поддержкой языка ..."  +/
Сообщение от Аноним (305), 21-Янв-22, 21:56 
Так потому я и жду слаку 15, потихонечку изучая ситуацию с другими unix-подобными ОС, от заразы пекарня уже очищена давно. По большей части.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру