The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

В ядро Linux 6.8 намечено включение первого сетевого драйвера на языке Rust, opennews (??), 18-Дек-23, (0) [смотреть все]

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


120. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  –3 +/–
Сообщение от Витюшка (?), 18-Дек-23, 16:31 
Нет, проблема именно с базовой системой владения, borrow checker и т.п. Rust очень тупой язык, и корректный и валидный (но сложный) код просто не понимает.

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

Rust говорит "я ничего не понимаю, что ты там написал, я тупой, ДОКАЖИ мне что это корректно". И часто сделать это из-за самого же Rust просто невозможно (именно доказать корректность для borrow checker Rust).

И все забивают и пишут unsafe на unsafe, или глобальный аллокатор, потому что объект в BumpAllocator привязан в времени жизни аллокатора (массива) и объяснить компилятору что код корректный не получается. Ну, как я понял из их описания.

Это КАТАСТРОФА.

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

124. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +1 +/–
Сообщение от фнон (?), 18-Дек-23, 16:47 
> Нет, проблема именно с базовой системой владения, borrow checker и т.п.
> Например когда несколько указателей из разных потоков владеют хитрым образов куском памяти.

Судя по описанию несколько потоков просто имеет кусок памяти, а потом где-то случается гонка и CVEшки поимеют юзера.

> И часто сделать это из-за самого же Rust просто невозможно (именно доказать корректность для borrow checker Rust).

Тут 2 варианта: ты не смог или невозможно вообще.
Если второе - то на дыряшке эта конструкция и так будет небезопасна, а мы почитаем про очередную "уязвимость с повышением привилегий".
Если первое - то не страшно, возможно ты просто неосилятор или не смог поменять парадигму программинга.
А то попривыкают писать uint32_t x = (*(struct foo *)NULL)->x
и ARM приходится бросать безусловный HardFault, потому что по другому подобные гении не учатся.

> И все забивают и пишут unsafe на unsafe, или глобальный аллокатор

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

> Это КАТАСТРОФА.

Для Витюшка, возможно. Для linux, android, aws, windows и индутрии в целом - нет.
Возможно разница в ресурсах и опыте.

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

243. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  –1 +/–
Сообщение от Витюшка (?), 18-Дек-23, 23:17 
Ниже ответил
Ответить | Правка | Наверх | Cообщить модератору

125. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +6 +/–
Сообщение от Анонин (?), 18-Дек-23, 16:48 
> Rust говорит "я ничего не понимаю, что ты там написал, я тупой, ДОКАЖИ мне что это корректно".

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

> Ну, как я понял из их описания.

Т.е. ты раст не знаешь, ты на нем не пишешь, но что-то "понял" и несешь свет знания на опеннет?
Ну, не то чтобы я удивлен... Ты еще в предыдущей теме ими блистал.

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

155. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  –3 +/–
Сообщение от Витюшка (?), 18-Дек-23, 17:58 
Что значит я Rust не знаю? И что именно я должен знать в Rust чтобы вести дискуссии?

Или я должен верить в magic великого компилятора Rust, который не позволяет ошибкам случиться прямо в compile time?)

А вот Andy Pavlo другого мнения;) У него студенты спрашивали уже насчёт Rust. Типа...а как же Rust? Разве он не безопасно работает с памятью? Откуда дедлоки и утечки памяти и все race condition берутся? Это же Rust 😆

Ты ручками, ОЧЕНЬ аккуратно, должен лочить и анлочить мьютексы, согласно протоколу синхронизации. Rust никаких существенных преимуществ не даёт.

Это уже как религия, как секта скорее всего. Свидетели безопасного Rust.

Если бы всё было именно так - я бы сам лично на него бы уже пересел, как минимум в pet project. Я его оценивал...то не умеет, это не умеет, с многопоточностью работать не умеет (ссылки на ячейку памяти а разных потоках, где всё абсолютно корректно и валидно, но Rust этого не понимает).

У Rust куууча недостатков по сравнению с Zig, лень перечислять.Например его exception при unwrap - а это hidden control flow. В Zig ошибки возвращаются только как возвращаемое значение. Ты всегда знаешь что никакого exception не будет, их и нету а языке. Никаких неявных деструкторов, defer. Никаких неявных аллокаций памяти. Ты всегда знаешь выделяет функция память или нет по сигнатуре. Никаких ошибок с alignment, в отличие от Rust. В Zig они встроены в систему типов и ты не сможешь больший alignment присвоить меньшему. Нууу и так далее.

Я в чём-то не прав? Можешь оспорить или опровергнуть мои слова?

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

164. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Анонимусс (?), 18-Дек-23, 18:26 
> А вот Andy Pavlo другого мнения;)

Ты уже вторую тему газифицируешь без пруфов.
Тебе что так сложно скопировать ссылку и написать "вот тут умный чел написал то-то"?

> Ты ручками, ОЧЕНЬ аккуратно, должен лочить и анлочить мьютексы, согласно протоколу синхронизации. Rust никаких существенных преимуществ не даёт.

Спасибо, насмотрелись уже на "аккуратных", вот только memory ошибки как были 30+ лет, так до сих пор делаются.

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

Даааа! Конечно "коректно и валидно", и одновременное можно одну память менять, я так 100 раз делал! Звучит почти как в СИшке... а точно.

> Например его exception при unwrap - а это hidden control flow

Не уверен, что это слишком большая проблема. В каком случае это приводит к ошибке?

> Никаких неявных деструкторов, defer

С каких это пор defer это плохо?

> Никаких ошибок с alignment, в отличие от Rust. В Zig они встроены в систему типов

Сколько накладных рассходов нам это стоит в Зиге?

> Я в чём-то не прав? Можешь оспорить или опровергнуть мои слова?

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

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

170. Скрыто модератором  +/–
Сообщение от Витюшка (?), 18-Дек-23, 18:32 
Ответить | Правка | Наверх | Cообщить модератору

177. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 18-Дек-23, 18:44 
Как тут цитаты вставлять?)

Ниже я написал пример "многих указателей" на структуру данных. Можешь ткнуть меня носом в race condition, в ошибки, а то я покусился на святое. И сейчас окажется что ошибок нет 😆

Всё верно, можно 100 раз менять память безопасно, ты правильно понял.

Это очень большая проблема. У тебя критичный код, который никогда не должен падать, может всегда, в любой момент упасть 😆 Это приводит к необратимым последствиям. Но, видимо в Rust "и таааак сойдёт" ✊ В С++ это называется exception safety.

defer как раз очень круто и правильно, как и нужно делать, а бросание исключений при unwrap() нет.

Я тебе более скажу - zig более безопасный чем Rust, он отловит большинство ошибок, которые Rust отловить не может, в runtime. Потому что при Debug автоматически включает AddressSanitizer, аллокаторы с выявлением memory leaks, и тд. Те любые выходы за границы массива, утечки памяти, двойное освобождение памяти и многое другое.

Нисколько накладных ресурсов. Это проверяется в compile-time системой типов.

Я на Rust вообще не пытаюсь писать никак 😆

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

198. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от фнон (?), 18-Дек-23, 19:41 
> Как тут цитаты вставлять?)

Просто копируешь и добавляешь >
У нас тут не очень продвинутая комментировалка. (Или идешь на форум, там можно цитировать, но вообще все сообщение)

> Всё верно, можно 100 раз менять память безопасно, ты правильно понял.

Ну так с помощь mutex в раст можно сделать тоже самое, не понимаю в чем у тебя трудности.
А просить код я, естественно не буду, на форуме анонимов)

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

Значит тебе не ядро линукс нужно, а какое-то seL4.

> В С++ это называется exception safety.

Но я ядре плюсов нету, ладно ты бы сказал в СИ оно есть. Вон в хаскеле есть монады, а в расте тоже нету.
Будет нужно, напишут RFC и добавят в спарк. Пока у всех нормально работает (кроме тебя и еще нескольких)

> а бросание исключений при unwrap() нет.

Просто делаешь правило для линтера что unwrap() запрещен.
И делай свой проект без unwrap.
Я читал разные статьи как NEVER Use `unwrap()` in Production, так и Using unwrap() in Rust is Okay. Так что feel free в своем проекте делать то что считаешь нужным.

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

210. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 18-Дек-23, 20:06 
> Ну так с помощь mutex...

Point в том что Rust не даёт безопасную работу с памятью. Или то что он даёт совершенно недостаточно для чего то сложнее hello world. А вот жизнь усложняет значительно, как и загрязняет синтаксис. На это, кстати, много жалуются реальные разработчики чего-то серьезного на Rust.

> Просто делаешь правило для линтера

ВСЁ тоже самое можно сделать на С++. Написать правильно линтера, добавить move семантику к типу, добавить exception safety в кусок кода и так далее.

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

Всё это можно сделать, так в чём преимущество Rust?

> Но я ядре плюсов нету

Я пришёл набросить!)))

Я считаю что Rust безусловно лучше С и даже С++ для ядра Linux. Но Zig безусловно лучше (и значительно) чем Rust для того же ядра.

> Значит тебе не ядро линукс

Представляю как я прихожу и говорю что для нашей базы данных нужен seL4, а не Linux :))

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

215. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +1 +/–
Сообщение от Аноним (178), 18-Дек-23, 20:14 
> Point в том что Rust не даёт безопасную работу с памятью. Или то что он даёт совершенно недостаточно для чего то сложнее hello world

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

Ну, или покрутят пальцем у виска...

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

220. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  –1 +/–
Сообщение от Витюшка (?), 18-Дек-23, 20:26 
Сотни тысяч... точнее 20 миллионов человек пишет на JavaScript НУ И ЧТО?

Или "Чел, так расскажи это миллионам людей в индустрии - будет сенсация!" что JavaScript это г...но написанное за 2 недели на коленке?)))

А если 100 миллионов на Rust будут писать, он от этого станет лучше или безопаснее?)))

Раньше 30% всей мировой разработки было на С++. Не помешало выпустить С++11 и кардинально улучшить язык.

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

222. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (-), 18-Дек-23, 20:30 
> Раньше 30% всей мировой разработки было на С++. Не помешало выпустить С++11 и кардинально улучшить язык.

Т.е раст высечен в камне? И добавить туда RFC нельзя?
Точно так же есть Edition в который добавляют ломающее апи.

ps погугли когда ядро перешло с С99

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

226. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (178), 18-Дек-23, 20:38 
> НУ И ЧТО?

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

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

237. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 18-Дек-23, 21:43 
Ничего я не извиваюсь. Вот когда добавят безопасную работу с памятью, вот тогда и приходи, когда твоё RFC добавят.

Пока ни один язык её не добавил. Частично эту проблему решили managed языки типа Java. Но там а) память теперь течёт б) это только для простых случаев, написать многопоточный код это тебе никак не помогает.

А это основное и самое сложное. Отследить ссылки я и сам могу.

И в Rust никакой безопасной работы нет. Тот же С++ (современный), только сбоку. Принципиальной разницы нет. Ну, пока мне её никто не показал, стесняются, наверное.

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

241. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (178), 18-Дек-23, 22:57 
Ну так я ж говорю: ты сообщи ребятам, юзающим Раст, о своих открытиях: что в нем нет безопасной работы с памятью, что это "С++, только сбоку"... Люди должны знать правду! Ты разве не видишь, что это глобальный заговор? На тебя единственного вся надежда, Витюшка - спаси индустрию!
Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

217. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (217), 18-Дек-23, 20:16 
> Всё это можно сделать, так в чём преимущество Rust?

В том что сделать-то может и можно.
А тут оно уже сделано и работает в ядре.

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

223. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 18-Дек-23, 20:31 
Минуту назад ты говорил что нужно добавлять линтер чтобы не вызывать unwrap() и вообще "это не нужно" для exception safety, и бери другое ядро.
Ответить | Правка | Наверх | Cообщить модератору

221. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +1 +/–
Сообщение от фнон (?), 18-Дек-23, 20:27 
> Я считаю что Rust безусловно лучше С и даже С++ для ядра
> Linux. Но Zig безусловно лучше (и значительно) чем Rust для того же ядра.

Я про зиг уже писал. Это по сути СИшка в смысле недостатков (управление памятью), затом модно-молодежно.
Ну и добавили очень странные "улучшения" аргументируя "no hidden control flow" и приводя в пример
Examples of hidden control flow:
    C++, D, and Rust have operator overloading, so the + operator might call a function.
    C++, D, and Go have throw/catch exceptions, so foo() might throw an exception, and prevent bar() from being called.

Но дефер все таки вернули, наверное это уже не хидденфлоу) Причем errdefer тоже. (Интеренсо как оно будет работать с правилом "so foo() might throw an exception, and prevent bar() from being called")
Думаю у них цели/ценности меняются так же часто, как у некоторых генералов число ПИ.

В общем сейчас это просто забавный пример СИшки, но чуть поприятнее.

> Представляю как я прихожу и говорю что для нашей базы данных нужен seL4, а не Linux :))

И? Тебя же не уволят?
Если твоя супер база работает на обычном ядре ликукса - то это консумерская штука и никакой супер надежности для нее скорее всего не нужно, все равно ядро настолько дырявое, что софт может быть и попроще.

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

233. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 18-Дек-23, 21:35 
> Я про зиг уже писал. Это по сути СИшка

Так, видимо ты не понимаешь что такое defer.

Ты пишешь сразу же

mutex.lock()
defer mutex.unlock()

И компилятор автоматически везде вставляет mutex.unlock() перед ЛЮБЫМ выходом из функции. Где бы ты и как потом ни выходил.

Согласись, надо быть тупым чтобы не вставить на следующей строке unlock. Тебе не нужно по всем return бегать. Это делает компилятор автоматически.

errdefer сделает тоже самое везде, но только для ошибки. И обычный errdefer ты вызываешь в 99% случаев. Однако, если надо, ты можешь прописать значительно более хитрые и продвинутые условия. В Rust этого сделать нельзя, в С++ тоже.

Конструкторы и деструкторы это ужасные костыли.

А что если ты не хочешь вставлять unlock() и тебе не нужно "очищать ресурс"? Например, зачем тебе обнулять память, если она будет перезаписана потом? В С++ и Rust ты этого сделать не можешь.

Какие-то пустые бредовые деструкторы вызываются всегда. Это совсем не бесплатно, делать все эти вызовы. Тем более рекурсивно!

> Но дефер все таки вернули

Потому что ты явно пишешь errdefer mutex.unlock(). Ты видишь этот вызов, ты видишь что ты делаешь и как очищаешь. Это явно. Прямо в функции. Даже в язык С есть proposal добавить defer.

Более того, ты можешь делать больше чем "деструктор", например пометить объект удалённым в массиве индексов. С деструктором это невозможно. Или вызывать "очищение" только при определённом условии или при определенной ошибке.

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

Я опять же писал что Zig БЕЗОПАСНЕЕ чем Rust. Многие ошибки, если не большинство, в compile time невозможно отловить никогда. В Zig есть все автоматические проверки безопасности. Выхода за границы массива, безопасность выравнивания типов данных (в Rust нет), разные аллокаторы (в Rust нет) и мноооого чего ещё, я сам всё не знаю.

Он БОЛЕЕ кроссплатформенный чем Rust. Он БЫСТРЕЕ чем Rust. Он компилируется быстрее. У него лучшая интероперабельность с С и С++. Он гораздо более продвинутый в низкоуровневых возможностях.

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

291. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (-), 19-Дек-23, 13:53 
> Так, видимо ты не понимаешь что такое defer.

Ты написал целую кучу про дефер, но так и не сказал это "hidden control flow" или нет.

> Конструкторы и деструкторы это ужасные костыли.

Ого! да у нас тут гуру, ты не стесняйся продолжай что еще является костылями?

> А что если ты не хочешь вставлять unlock() и тебе не нужно "очищать ресурс"?
> Например, зачем тебе обнулять память, если она будет перезаписана потом?

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

> Я опять же писал что Zig БЕЗОПАСНЕЕ чем Rust.

Очень голословное утверждение особенно на фоне того что разрабы ЗИГа сами пишут "not fully safe".
Зато капсом, так наверное более убедительно.

> Многие ошибки, если не большинство, в compile time невозможно отловить никогда.

Хм... ну так начнем с ошибок которые можно словить, а потом может что-то придумаем.

> В Zig есть все автоматические проверки безопасности. Выхода за границы массива, безопасность выравнивания типов данных (в Rust нет), разные аллокаторы (в Rust нет)...
> Выхода за границы массива

// Slices have bounds checking and are therefore protected
// against this kind of undefined behavior. This is one reason
// we prefer slices to pointers.
В Раст слайсы тоже есть. Более того By default, accesses to container types such as slices and vectors involve bounds checks in Rust.
Это еще раз показывают качество твоих знаний про Раст.

А что в Зиге с массивами?
https://ziglang.org/documentation/0.1.1/#undef-index-out-of-...
At runtime crashes with the message index out of bounds and a stack trace.
Т.е таки крешится... А ты рассказывал "как же в расте программа крешится? А не должна"
И в чем тут преимущество?

> разные аллокаторы (в Rust нет)

А насколько это необходимо? Насколько это влияет на безопасность?
Примеры пожалуйста.

Я уже молчу что в нем есть целая статья UB ziglang.org/documentation/0.1.1/#undefined-behavior
Где наверное больше половины заканчиваются
When a safety check fails, Zig crashes
А секции
Invalid Enum Cast TODO
Incorrect Pointer Alignment TODO
Memory TODO
Сразу видно уровень качества разработки, у нас будет креш по памяти, но ты об этом не узнаешь)

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

308. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 19-Дек-23, 16:47 
Я смотрю ты очень избирательно читаешь или не понимаешь написанного.

Это типичные проблемы junior программистов и фанатиков.

Расскажи мне, где ты увидел что

> Это еще раз показывают качество твоих знаний про Раст.

Я говорил что проверок выхода за границы нет в Rust?

> Ты написал целую кучу про дефер, но так и не сказал это "hidden control flow" или нет.

Это не hidden control flow.

> Ого! да у нас тут гуру, ты не стесняйся продолжай что еще является костылями?

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

Например, не вызывать деструктор на объекте после std::move(val). Понимаю, такому наверное не учили.

> Такая необходимость возникает в очень редких задачах типа БД.

Это возникает в любом высокопроизводительной задаче, HPC, браузерные движки, базы данных, и тд. Если ты гоняешь json-чики на Rust (или С++), то конечно обновляй всё подряд, что нужно и не нужно 😆

> Для обычной разработки память должна обнуляться чтобы потому bufferoverflow

Откуда у тебя там buffer overflow возникнет?) Это надо быть рукожопом. Меняешь size на 0, массив логически пустой. Индексы при вставки тоже проверять нужно. Вот такие рукожопы потом и говнокодят, что на С++, что на Rust.

Я смотрю и Rust особо от рукожопов не спасает 😆

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

Но я так понял тут у нас Rust эксперт, который в массив с обычными данными ещё и пароли записывает 😆😆😆

Вот ты и расписался в своей абсолютной некомпетентности. Ты как говнокодил на языке Н, так и на Rust продолжаешь говнокодить 😆

И как мы видим никакой Rust тебе не помог, ошибки твои не выловил, по рукам не дал. Зато "безопасно". От дураков защиты нет.

> Хм... ну так начнем с ошибок которые можно словить, а потом может что-то придумаем.

Это умеет делать одинаково хорошо и С++. И zig.

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

> Очень голословное утверждение особенно на фоне того что разрабы ЗИГа сами пишут "not fully safe".

Зато капсом, так наверное более убедительно.

Я достаточно привёл аргументов. И доказал убедительно с фактами. Понимаю, неприятно их признавать.

Твой фанатизм затмил тебе глаза, ты как сектант теперь.

Конечно Zig не полностью безопасный язык. Там есть сырые указатели. Как и в Rust, но он у тебя полностью безопасный 😆😆😆 Самому то не смешно?)))

> А насколько это необходимо? Насколько это влияет на безопасность?

Примеры пожалуйста.

Кастомный аллокатор в 30-60 раз быстрее обычного глобального, потому что он потокобезопасный, у него куча внутренних структур и локов.

Это нужно там где 1. важна скорость 2. важны гарантии - микроконтроллеры, любое критичное ПО на Linux. 3. ты можешь какому-то коду давать специальные аллокаторы

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

> When a safety check fails, Zig crashes

Там где программа в состоянии, где больше ничего нельзя сделать. Например выход за границы массива. Вместо того чтобы потихому прочитать невалидные данные он упадёт. Это и есть безопасность.

> Сразу видно уровень качества разработки, у нас будет креш по памяти, но ты об этом не узнаешь)
> Memory TODO

Ну зачем ты так нагло и некрасиво врёшь? Я специально посмотрел документации master и 0.11. Там ничего такого нет. Все TODO - это в основном добавить документацию.

Как это не узнаешь? А все те проверки это что по твоему?) А выход за границы массива, а memory leak sanitizer???


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

182. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (-), 18-Дек-23, 18:54 
> Или я должен верить в magic великого компилятора Rust

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

> Ты ручками, ОЧЕНЬ аккуратно, должен лочить и анлочить мьютексы, согласно протоколу синхронизации. Rust никаких существенных преимуществ не даёт.

Падажди? А разве в сишке ты не должен "ОЧЕНЬ аккуратно лочить и анлочить мьютексы"?
Наверное должен... но кто ж тебе запретит просто фигачить данные с каких попало потоков вообще без мьютексов!

Раст тебя заставит хотя бы Arc<Mutex> использовать.
При этом rust prevents data races, но logical races and deadlocks are still possible.
Дедлоки легко сделать в любом языке. Что в си, что в расте, что в питоне.
Я не знаю ни одного языка который гарантировал бы их отсутствие. Это скорее ближе к формальной верификации, а не к языку.

И встречный вопрос - раз для раста это проблема, а зиг круче раста, то зиг 146% поборол дедлоки и другие проблемы многопоточного кода? Правда ведь?))

> А вот Andy Pavlo другого мнения;)

Это очень существенно. А Линус противоположного мнения мнению Andy. Теперь будет схватка двух йокодзун?

> У Rust куууча недостатков по сравнению с Zig, лень перечислять.
> лень перечислять.

Прям не сомневался в этом)))

> Никаких неявных деструкторов, defer.

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

> Ты всегда знаешь выделяет функция память или нет по сигнатуре.

Полезная штука, не спорю.

> Нууу и так далее.

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

> Я в чём-то не прав?

Ты считаешь это недостатками, а я считаю недостатком мнимую "простоту" Зига.
Потому что получается та же сишка, только в профиль. Еще и написанная... ну скажем так, непонятно кем с крайне сомнительными перспективами.

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

242. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 18-Дек-23, 23:16 
> Там компилятор гарантирует выполнения некоторого количества просто элементарных правил

В этом и проблема! Ничего он не гарантирует!

Если бы он говорил "этот код некорректный!", следуй этим правилам - это было бы одно. А он говорит "я ни ... не понимаю что ты написал, пиши как я сказал" и просто ОТБРАСЫВАЕТ корректный валидный безопасный код 😆 Это бреееед, ребята 🤠

Это не то что ожидаешь от СИСТЕМНОГО языка программирования.

Те он тупо слабенький и не понимает что ты пишешь. Это как если бы компилятор говорил что "многопоточная программа" небезопасна, пиши в один поток!

А почему бы и нет, а действительно супербезопасно!

> типа не меняй переменную с двух разных мест просто так

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

И когда я пишу базу данных, я делаю вещи посложнее чем "отслеживание ссылок" на несколько порядков 😆 Если бы был простоое переключение safe / unsafe вопросов бы не было. Там вообще всё начинает разваливаться, какие-то pin, transmute ещё какая-то бредятина появляется.

> И встречный вопрос - раз для раста это проблема, а зиг круче раста, то зиг 146% поборол дедлоки и другие проблемы многопоточного кода? Правда ведь?))

Ты не понял мой point. Zig - это системный язык программирования, он тебе позволяет легко сделать всё что угодно, но ЯВНО. И максимально удобно и безопасно там, где это оправдано.

Какой смысл усложнять очень сильно язык и при этом не решить основные и главные проблемы "безопасной работы памяти"?) Ты сравни код Zig и Rust на досуге. Zig читается как песня, он ПОНЯТЕН. Он делает то, что ты ожидаешь от языка и что видишь в коде.

При этом Zig БОЛЕЕ безопасный при работе с памятью. Он отлавливает всё что возможно отловить существующими средствами вообще без изменений языка.

Например, ты просто передаешь std.testing.allocator (специальный аллокатор, который отлавливает утечки памяти, аналог Valgrind) в структуру и ВСЕ вызовы всей программы будут использовать этот аллокатор. Или передаешь его только в нужный кусок кода. Неплохо иметь "Valgrind" из коробки в языке, согласись? Который вызывается одной строчкой.

Это отлавливает 99.99% ошибок с памятью на этапе первых запусков программы (даже на тестах). В runtime, ведь в compile time можно выловить только очень ограниченное количество ошибок, и все они банальные (простые).

Я несколько месяцев (когда не знал как собирать сложное приложение с их билд системой, незрелая она была тогда) писал приложение только на тестах и этом аллокаторе))) Собрал - заработало сразу.

Твой "безопасный Rust" так умеет?) Нет) Только не говори что "и таааак сойдёт" или "не очень то и нужно было". В Rust любая функция может неявно вызвать глобальный аллокатор. А может вызвать переданный как параметр (если есть такая опция), а может и тот и другой.

Ещё он включает многие санитайзеры проекта LLVM. Это, конечно, не формальная верификация, но уже очень сильно.

А планирует задействовать вообще все санитайзеры которые там есть, но руки не дошли. В том числе и ThreadSanitaizer. Это гораздо круче чем все твои проверки в Rust.

Вот их документации Zig что он УЖЕ умеет:

Reaching Unreachable Code
Index out of Bounds
Cast Negative Number to Unsigned Integer (пофиксили в Rust в 2015)
Cast Truncates Data
Integer Overflow
Exact Left Shift Overflow
Exact Right Shift Overflow
Division by Zero
Remainder Division by Zero
Exact Division Remainder
Attempt to Unwrap Null
Attempt to Unwrap Error
Invalid Error Code
Invalid Enum Cast
Invalid Error Set Cast
Incorrect Pointer Alignment (!!!) (а Rust схавает и не подавится и привет Segmentation Fault в лучшем случае, в худшем "безопасное" перезаписыаание области памяти)
Wrong Union Field Access
Out of Bounds Float to Integer Cast (!!! Читаем - https://stackoverflow.com/questions/61144957/what-happens-wh...

In Rust 1.44 and earlier, if you use as to cast a floating-point number to an integer type and the floating-point number does not fit¹ in the target type, the result is an undefined value², and most things that you can do with it cause undefined behavior !!!

Очень "безопасно" для языка версии 1.44. Сравни с версией Zig 0.11 😆)

Pointer Cast Invalid Null (В zig есть null safety, чего дарт не мог получить вплоть до версии Dart 3.0 - указатели НЕ МОГУТ быть нулевыми)

Многие проверки СРАЗУ делаются и в compile time (условия которые можно проверить во время компиляции), и в runtime!

Твой "безопасный" Rust так умеет?

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

Нет, выше я писал. Это делает КОМПИЛЯТОР. Это в С ты должен во всех return освободить всю память и ничего не забыть и помнить кто где аллоцировано, а что ещё нет.

Ты должен написать только defer allocator.free(memory) И ВСЁ. Компилятор сам вызовет освобождение памяти ВО всех точках выхода из функции!

А как в Rust НЕ вызывать деструктор? Например у меня есть память, я туда пишу и знаю что если я возвращаю ошибку, дальше в коде она полностью будет перезаписана другими данными! Мне не нужно её тут обнулять (в других местах нужно).

А, нельзя?)))

> Но вот почему-то ни один сишник еще не справился с такой элементарной задачей

Потому что в С ты должен освобождать ресурсы во всех разных сложных точках выхода из функции.

И там могут быть сложные условия - array1 уже выделился, array2 тоже, а на array3 память выделить не получилось - освобождаем array1 и array2. А в других случаях нужно освобождать только array1 (валимся на выделении array2) и так далее.

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

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

Ответил выше. Ни за какие пределы ты не выйдешь никуда.

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

276. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +1 +/–
Сообщение от freecoder (ok), 19-Дек-23, 09:55 
> А как в Rust НЕ вызывать деструктор?

Используй mem::forget.

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

207. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +1 +/–
Сообщение от Аноним (178), 18-Дек-23, 19:54 
> Например его exception при unwrap - а это hidden control flow. В Zig ошибки возвращаются только как возвращаемое значение.

Ты не поверишь, но в Rust ошибки тоже возвращаются только как возвращаемое значение. Но ты даже не удосужился почитать, что такое unwrap и кинулся воевать против Раста.

Чел, ради бога, не разводи цирк. Твой уровень знания Раста все уже и так увидели в соседней новости о спутнике.

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

218. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  –1 +/–
Сообщение от Витюшка (?), 18-Дек-23, 20:20 
https://doc.rust-lang.org/rust-by-example/error/option_unwra...

Читаем)

Далее идём сюда https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...

и читаем

> When code panics, there’s no way to recover.

Ты смотришь в книгу и что там видишь? Даже не понимаешь смысл того что процитировал.

Ну, unwrap() на None ошибку вернёт? Не вижу возврата ошибки что там должно быть Some(x) 😆 Не очень похоже на безопасный язык.

Вот в Zig все, любые ошибки возвращаются, ну если ты не вызовешь os.abort() или os.exit() явно.

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

225. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +1 +/–
Сообщение от Аноним (-), 18-Дек-23, 20:38 
> Ну, unwrap() на None ошибку вернёт? Не вижу возврата ошибки что там
> должно быть Some(x) 😆 Не очень похоже на безопасный язык.

Ты несешь какую-то чушь /_-
Если приложене упало - то пусть падает.
Лучше out-of-service чем получение рута.

> Вот в Zig все, любые ошибки возвращаются, ну если ты не вызовешь os.abort() или os.exit() явно.

И что же делать если программа пришла в состояние невозможное из которого исправить ничего нельзя?

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

256. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 19-Дек-23, 01:26 
> И что же делать если программа пришла в состояние невозможное из которого исправить ничего нельзя

В каком состоянии программа и что делать при "невозможном" состоянии решать... наверное программе, а не какой-то там библиотеке?

В этом весь point. А тебе тихонечко вызовут unwrap() на None 😆

Про panic() из самого (конечного) приложения естественно вопросов и претензий нет. Конечно такие состояния возможны.

В Zig есть ключевое слово unreachable. Те "никогда никогда это условие не будет выполнено".

Таааак подожди...
https://doc.rust-lang.org/stable/std/alloc/struct.Global.html
А это что ещё за хрень???

В самом безопасном языке в мире можно вызвать new_uninit() которая вернёт неинициализированную переменную??? И функция даже не помечена как unsafe?

Это такая безопасность у Rust?)

Я на такую хрень натыкаюсь в Rust постоянно. Везде есть небезопасные методы которую всю эту безопасность ставят раком 😆

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

Но при этом можно создать неинициализированную переменную???

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

266. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (266), 19-Дек-23, 05:59 
Так new_uninit() возвращает MaybeUninit<T>, для которого assume_init() как раз unsafe.
И да, rust защищает от программистов-идиотов, которые даже читать не умеют.
Ответить | Правка | Наверх | Cообщить модератору

293. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (-), 19-Дек-23, 14:07 
> В каком состоянии программа и что делать при "невозможном" состоянии решать... наверное программе, а не какой-то там библиотеке?

Твоя библиотека на Ziz получает что-то из этого списка в рантайме
https://ziglang.org/documentation/0.1.1/#undefined-behavior
например Cast Negative Number to Unsigned Integer и что она делает?
Она безусловно крашится!
At runtime crashes with the message attempt to cast negative value to unsigned integer and a stack trace.

Как программа на том же Zig будет обрабатывать такой случай? Ну "все ж ошибки обрабатываются" и прочие сказки венского леса.
Здаётся мне "это фиаско, братан!"

> В самом безопасном языке в мире можно вызвать new_uninit() которая вернёт неинициализированную переменную??? И функция даже не помечена как unsafe?

Кажется слово MaybeUninit тебе вообще ничего не говорит? /_-
Ты бы хоть доку читал дальше заголовка.

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

231. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (178), 18-Дек-23, 20:59 
> Далее идём сюда https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...

А предыдущую главу с говорящим названием "Recoverable Errors with Result" ты решил тактично пропустить? А зря: в ней есть раздел "Shortcuts for Panic on Error: unwrap and expect" в котором ты бы мог наконец-то узнать, что такое unwrap() (собственно, ответ уже в названии).

https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...

> Не вижу возврата ошибки что там должно быть Some(x) 😆

Потому что ты читаешь о Option а не Result, не?

А "These cases can either be explicitly handled via match or implicitly with unwrap" мы тактично пропустили, да?

Что ж, Витюшка наконец-то открыл документацию Раста - уже прогресс...

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

258. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 19-Дек-23, 01:53 
Ты как-то плаваешь в Rust, друг мой.
> ты решил тактично пропустить...

А что там обсуждать? Мы говорим о panic(), который вызывается при unwrap(). При чём тут обычные возвращаемые значения из функции?

Вот вызываю я функцию библиотеки, она откуда-то получает option. Вызывает на нём unwrap() и я получаю панику. При том сама функция естественно может возвращать Option (но в других случаях).

Я конечно бы обработал возвращаемое значение, только панику не обработать. Или я не прав?

Тоже самое касается Result. unwrap() на Result это паника при Err().

И почему в таком супер безопасном языке, где защищаются именно от программиста дурака, который и с указателями и индексами не может справиться, можно просто взять и вызвать unwrap() и кинуть панику? Притом случайно, непреднамеренно.

Вот они аргументы (кого-то выше) "но есть же unwrap_or()" меня умиляют.

Да, есть. Это типа "Пиши просто сразу безопасно", из такого разряда? Так и в С можно писать сразу безопасно и проверять указатель на NULL везде.

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

Вот эти аргументы "но это же не пройдёт код ревью!" думаю понимаешь что очень слабые. В С++ тоже не пройдет 😆

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

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

306. Скрыто модератором  +/–
Сообщение от Аноним (-), 19-Дек-23, 16:32 
Ответить | Правка | Наверх | Cообщить модератору

133. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (133), 18-Дек-23, 17:10 
Это всё потому что ты и такие как ты неосиляторы пытаетесь на расте писать в стиле Си. Архитектуру приложения надо другой делать, "не Сишной". Потому что "сишные архитектуры" и приводят к "сишным проблемам". Причем раст тебе позволит писать и в сишной манере, но тогда, конечно, как ты тут упомянул, всё будет измазано в ансейф. И ошибки вернутся старые, но виноват у тебя окажется раст.
Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

135. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (135), 18-Дек-23, 17:14 
> Например когда несколько указателей из разных потоков владеют хитрым образов куском памяти.

Точняк... А потом случается рэйс кондишн и вот мы уже читаем очередную новость про очередное CVE, а опеннет-иксперды вроде тебя под такой новостью пишут в комментах (в очередной раз), что и на сях можно писать безопасно (только свой "безопасный" код длинее хэлло_ворлда никогда не показывают).
Сорян, но ты не умнее борроу чекера и тех, кто его писал. Так оказывается в 100 случаях из 100. И если он с тебя требует доказать, что там корректно, значит ты написал так, что у тебя там потенциально некорректно: ты как писал свой сявый код с потенциальными UB, так и на расте его продолжаешь пытаться писать. А оно тебя по руках (кривым не из плеч растущим) лупит, да.
Некоторые не выдерживают того, что им себе в ногу стрелять не дают и убегают назад дальше CVE и прочие use-after-free плодить, некоторые - начинают пистаь более безопасный код. Не потому, что раст весь из себя какой-то такой волшебный, а потому, что не даёт писать твои любимые потенциальные CVE. Просто заставляет пистаь код лучше либо прямо объявлять с помощью unsafe секции, где ты будешь гуанокодить. И их потом хорошо видно.

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

151. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  –1 +/–
Сообщение от scriptkiddis (?), 18-Дек-23, 17:52 
Но и как правильно такое переписать на твоем святом, ты тоже не сказал.
Ответить | Правка | Наверх | Cообщить модератору

167. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  –1 +/–
Сообщение от Витюшка (?), 18-Дек-23, 18:28 
Такое это какое? Вопрос мне? Корректность зависит от самого алгоритма и других метаданных.

Например у каждого потока может быть указатель на массив в который он пишет. Параллельно. Но эти сегменты (array[x], array[y]) никогда не пересекаются. Это может быть ring buffer.

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

Теперь возможно что поток прочитает недозаписанные данные другого потока. Это решается с помощью read-write mutex для каждого сегмента.

Напишите мне эти проверки с помощью borrow checker на Rust? 😆

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

214. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (178), 18-Дек-23, 20:09 
> Проблема в том что я в 100 раз умнее borrow checker. Это только васяны с hello world на Rust рассказывают о том как там всё безопасно.

Ну, кто бы сомневался. Чел, у тебя тяжелая форма Даннинга-Крюгера.

Давай, продолжай рассказывать захватывающие истории о своих воображаемых хэллоуворлдах на Zig, который и до версии 1.0 не дозрел и не используется никем в индустрии.

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

219. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Анонин (?), 18-Дек-23, 20:21 
> Но эти сегменты (array[x], array[y]) никогда не пересекаются.

А кто или что это гарантирует не в раст, а напр. в си или зиге или с++?
Оно так просто потому что "мамой клянусь, никогда не пересекаются!" А если вдруг таки пересекутся, то что?))

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

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

260. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 19-Дек-23, 02:30 
Ну ты циклы писать умеешь? А if else писать умеешь? И кто гарантирует что ты их корректно и правильно написал?

Rust это умеет делать???

Что же Rust вас от этого не защищает? Вы же несмышленые, вдруг напортачите?

Или ты думаешь что если ты отнимешь вместо прибавления от банковского счёта, то ничего страшного?

> Оно так просто потому что "мамой клянусь, никогда не пересекаются!" А если вдруг таки пересекутся, то что?))

Потому что ты каждому потоку выделяешь индекс в массиве и выделяешь массив с количеством потоков.

Да, сложно. Нужно num_threads() * kbytes!

> А если вдруг таки пересекутся, то что

А вдруг true false перепутал, а вдруг if else не в состоянии правильно написать?

Смотрю сильные серьезные аргументы начали заканчиваться.

Остались "великий и могучий borrow checker" которого нужно слушать, а я дурак 😆

И какая-то иррациональная вера что кто-то (например Rust) будет за вас писать (и гарантировать) корректный код 😆

> Только не забудь написать коммент с обоснованием почему оно так

Так (условный ты) ты же дурак? Откуда у тебя обоснования "почему оно так", если ты даже за указателями уследить не можешь? Как ты докажешь корректность кода, если надеешься на компилятор, что он тебе магически должен гарантировать непересечение массивов и чего-то там ещё?

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

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

307. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Аноним (-), 19-Дек-23, 16:36 
> Смотрю сильные серьезные аргументы начали заканчиваться.

Аргумент "я выдумал задачу, а она в парадигму раст не влазит" - это не серьезный аргумент.

> а я дурак 😆

Тут я с тобой соглашусь.

> unsafe будут писать дяди из С++ и С. Которые знают как работают компьютеры, знают алгоритмы и знают как выжать из компьютера максимум.

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

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

159. Скрыто модератором  –1 +/–
Сообщение от Витюшка (?), 18-Дек-23, 18:10 
Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

143. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +1 +/–
Сообщение от Аноним (178), 18-Дек-23, 17:38 
> Например когда несколько указателей из разных потоков владеют хитрым образов куском памяти.

Чего? Несколько указателей владеют одним куском памяти? И Раст, сволочь, не дает тебе писать такую дичь, я правильно понял?

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

163. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 18-Дек-23, 18:19 
Совершенно верно. Это внутрянка безопасной структуры данных, например concurrent hashmap или любой многопоточной параллельной структуры данных.

Я сам проверяю все инварианты и корректность кода. Там может быть несколько разных сегментов памяти (массивов). А на выходе ты получаешь абсолютно безопасную корректную структуру данных.


Rust умеет это делать? Умеет проверять инварианты за меня?

Ну и что что он сделает "безопасным" доступ к одному массиву??? Это же не сделает код безопасным и потокобезопасным? Если, например, другой поток запишет в это время в другой массив или захватит на нём lock (deadlock)?

Странно что нужно объяснять такие вещи защитникам Rust.

И теперь чтобы написать что-то сложнее hello world, нужно писать кучу boilerplate, unsafe и так далее. Я лучше тогда JavaScript возьму. Будет безопаснее)

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

173. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Анонимусс (?), 18-Дек-23, 18:35 
> Совершенно верно. Это внутрянка безопасной структуры данных, например concurrent hashmap или любой многопоточной параллельной структуры данных.
> Я сам проверяю все инварианты и корректность кода. Там может быть несколько разных сегментов памяти (массивов).

Ну так написал "я сделяль свой велосипед, он работает корректно, мамой клянусь"

> А на выходе ты получаешь абсолютно безопасную корректную структуру данных

Громкие слова, очень громкие для кого-то, кто считает гарантии компилятора магией.
Более того Arc<T> + Mutex<T> и RwLock<T> должны позволить реализовать твою хотелку.

> И теперь чтобы написать что-то сложнее hello world, нужно писать кучу boilerplate, unsafe и так далее. Я лучше тогда JavaScript возьму. Будет безопаснее)

Внезапно, я с тобой соглашусь, лучше пиши на JS. Там можно не только память пердолить со всех сторон одновременно, но даже к строке прибавлять инт.

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

183. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 18-Дек-23, 18:55 
Представь себе, велосипеды пишут потому что никаких "готовых" структур данных нет.

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

Или авторы MySQL, PostgreSQL и MSSQL это васяны со своими велосипедами? 😆😆😆

Конечно для твоего hello world подойдёт и то что в стандартной библиотеке 😆

Нет, Arc<T> + Mutex<T> и RwLock<T> НИКАК не помогут. Они защищают только один объект/структуру, считай одно поле структуры.

А...ты предлагаешь лочить всю высокоуровневую структуру данных? Ну, такой ***код не пройдет 😆 Ты сейчас сделал из многопоточной однопоточную программу где все +- ждут друг друга 😆

Например это индекс базы данных. Те ч должен залочить ВЕСЬ индекс для одной операции?

Я ожидал большего от фанатиков Rust.

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

209. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от фнон (?), 18-Дек-23, 20:02 
> Например у каждого потока может быть указатель на массив в который он пишет. Параллельно. Но эти сегменты (array[x], array[y]) никогда не пересекаются. Это может быть ring buffer.
> Но при этом каждый поток может читать данные других потоков.
> Теперь возможно что поток прочитает недозаписанные данные другого потока. Это решается с помощью read-write mutex для каждого сегмента.

Ладно, возможно у тебя очень специфическая задача. Сколько таких в ядре линукса?
Нужно ли отказываться от дополнительного языка если на нем сложно/невозможно сделать такую конструкцию?

> Например тебе нужна хэш-таблица с поддержкой диска. Пишешь свою родненькую. Там пишут все лучшие величайшие программисты мира (поднимаю ставки троллинга 😆), во всех базах данных свои структуры данных, даже свои мьютексы.
> Или авторы MySQL, PostgreSQL и MSSQL это васяны со своими велосипедами?

Парирую троллинг пруфами)

выполнения кода при обработке в СУБД SQLite определённым образом оформленных SQL-конструкций https://www.opennet.ru/opennews/art.shtml?num=52084

Критическая root-уязвимость в MySQL https://www.opennet.ru/opennews/art.shtml?num=45127

> Я ожидал большего от фанатиков Rust.

Вот только фанатиком тут выглядишь ты.
У тебя есть супер "особенная" задача. Которая судя по описанию, мало кому нужна за пределами баз данных. И ты "мая задачка не решается языком! плак плак! Раст плохой"

Причем в качестве альтернативы приводишь Зиг на сайте которого прямо пишут https://ziglang.org/learn/overview/
Please note that Zig is not a fully safe language
Multithreading safety and race detection are areas of active research.
Более того говорят что operator overloading это плохо... ну удачи им в большом проекте)
In order to accomplish this, Zig programmers must manage their own memory, and must handle memory allocation failure.

А дефер-то оказывается есть? А как же "no hidden control flow"! Неужели они пошли против своих принципов.
In addition to A fresh take on error handling, Zig provides defer and errdefer to make all resource management - not only memory - simple and easily verifiable.

Т.е писать ты будещь в СИ стиле, память менеджить ручками (привет ошибки), только сменится интаксиc языка. Ну и нафиг менять шило (СИ) на мыло (Зиг) ?
Думаю мейнтейнары ядра тоже так подумали.

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

250. "В ядро Linux 6.8 намечено включение первого сетевого драйвер..."  +/–
Сообщение от Витюшка (?), 19-Дек-23, 00:49 
> А дефер-то оказывается есть? А как же "no hidden control flow"!

Мы про одно и тоже говорим? Кажется я уже выше подробно отвечал, возможно не тебе.

В defer нет hidden control flow. Я описал выше почему. Ты его видишь в функции, он ЯВНЫЙ. А деструкторы неявные. И пока ты туда не заглянешь - не узнаешь что и как они там освобождают.

Более того постоянно приходится туда смотреть чтобы понять что именно там он освобождает. А ещё может выкинуть exception в С++. Ну в Rust, который содран с С++, всё +- также должно быть.

> Парирую троллинг пруфами)

Я там выше накидал пруфов как в безопасном языке в стабильной версии 1.44 можно сделать

let i: i8 = -1
let k: u8 = i

И получить "переполнение" или как там правильно это назвать. Настолько он безопасный) Тихо, незаметно, без ошибок.

> Т.е писать ты будещь в СИ стиле..

Выше я ОЧЕНЬ подробно написал насколько Zig безопасный, сколько гарантий и проверок он даёт (больше чем Rust) и что он БЕЗОПАСНЕЕ чем Rust.

Добавлю ещё const по умолчанию для всех параметров функций и переменных.

Он в сотни раз безопаснее С. Но при этом более низкоуровневый чем С! Или все эти проверки для тебя "тоже самое что и С"?)

Память ты ВСЕГДА менеджишь ручками в Rust и C++, просто неявно, это не managed языки.

И очень-очень плохо 😆 По простому это говнокод и костыли.

> Думаю мейнтейнары ядра тоже так подумали

Те в ядре норм что какой-то там деструктор будет рекурсивно (!) вызываться хрен знает когда, когда его даже не просили об этом?) Это там где есть обработчики прерывания и очень важен максимальный перформанс и надёжность?

Или мне нужно освободить страницу памяти КАК МОЖНО быстрее, я пишу page.Drop(), а потом деструктор всё равно вызывается, хотя он нахрен не нужен 😆 И внутри у меня стоит if (flag) { free() } чтобы он второй раз не освободил память 😆

Это из реальной жизни. Все эти "абстракции" типа "итераторы", "конструкторы/деструкторы", перегрузка операторов, перегрузка функций, шаблонные функции и весь template код всё это лютое #@&!.

Это лютейший over engineering. Для 2000х Rust был бы неплох.

У Zig это всё сделано значительно лучше. Даже типа строка нет. Потому что никаких строк нет нигде. Есть просто набор байт и их интерпретация (кодировка). Справится любая библиотека. Нет "методов", есть только функции с "сахаром" в виде объект.функция().

> Please note that Zig is not a fully safe language

Покажи мне ХОТЬ ОДИН в мире безопасный (по-настоящему) язык программирования. Знаю 20 языков программирования, и ни одного безопасного.

> Multithreading safety and race detection are areas of active research

Аналогично. Это active research не только в языке, а вообще в мире в индустрии. Или где-то решена эта проблема?

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

Lock-free алгоритмы даже в научных статьях неправильные, некорректные, с ошибками (не моё мнение, эксперта
)😆 Как говорится, welcome to real world, из однопоточного джаваскрипт-манямирка.

Вообще ты должен бы это всё знать, хотя бы на уровне "active research".

Это не значит что в языке не работают мьютексы или атомики. Это значит долгое вдумчивое ВГЛЯДЫВАНИЕ в код. И никакой Rust тебе не поможет. Или лови месяцами ошибку на тестах.

Это касается любого языка программирования где есть потоки.

> Более того говорят что operator overloading это плохо...

Ядро Linux - 40 миллионов строчек кода.

Ну-ка, расскажи мне про перегрузку операторов и на что ты там перезагружаешь операцию + ? Как-то не смог найти применение в жизни этой "фичи".

Вот складываешь ты int + int и всё хорошо, а потом тебе прилетает строка в шаблонную функцию и ты сравниваешь две гигабайтные строки 😆 Надёжно, быстро, безопасно 😆

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

В Zig ты пишешь функцию, которая принимает аргумент anytype. И проверяешь этот тип как хочешь. И вызываешь для int +, для строк concat, и ничего для остального.

Во время компиляции будут сгенериррваны супероптимизированные функции под эту задачу. Одна работает только с int (как пример), вторая только со string.

Это как если бы ты руками эти две функции написал.

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

Попробуй на Rust такое написать 😆

У С++ многие вещи только только появились, if constexpr и так далее

> In order to accomplish this, Zig programmers must manage their own memory, and must handle memory allocation failure.

А что, если у тебя памяти нет, Rust тебе как-то поможет? Или ошибки выделения памяти уже в Rust обрабатывать не нужно?)

> Нужно ли отказываться от ...

Я считаю что у Rust была хорошая задумка, а реализация полное ...

Будут лучше языки для ядра. Но Rust займёт его место, а зоопарка Торвальдс не допустит - остальные на помойку.

Если это не так, то в целом я ничего против не имею. Я так, набросил чтобы поспорить и поболтать, прокрастинация такая.

Но Zig для ядра лучше подходит.

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

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

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




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

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