Rust не производительнее C - я скидывал ссылку на сравнение в реальной задаче, и не безопасный - его система типов unsound и допускает ошибки и утечки памяти. Кроме того, любой мало мальски нетривиальный алгоритм требует использования unsafe для работы со структурами данных. Если бы Rust позволял писать работу со сложными структурами в safe, вопросов бы к нему не было, всё было бы супер. Но не позволяет же. Ковырни любую библиотечную структуру данных - там врутри unsafe код. А с учётом того, что система типов Rust некорректна (правда, мы не знаем, она математически некорректна, или это косяки реализации, но тем не менее, в текущем состоянии она допускает утечки памяти), unsafe для любой нетривиальной структуры данных - это вдвойне неприятно. Не понятно, где произойдёт выстрел в ногу.
Ладно бы это было только в недрах операционки, но, ведь, в unsafe возникает необходимость просто в обычном пользовательском коде.
Вы сами давали ссылку на реализацию очереди на Rust, которая длинее в 20 раз, чем реализация на С - это громоздкость. Если не нравится C, то можно взять Go (теперь мне не нравится, ну, да ладно). Тоже будет короткая простая реализация без урезанной функциональности. И производительность у Go вполне на уровне. Rust без unsafe от Go сильно оторваться не может:
Я пришёл в Python после Haskell. Ничего не сломалось, в безумную обезьяну, которая пытается передать строки вместо чисел я не превратился. Что я делал не так?
Если бы все ездили только по правилам, аварийность была бы гораздо выше. Иногда приходится совершать запрещённые манёвры, чтобы избегать столкновений. В крупных городах приходится делать это довольно часто.
При движении на мотоцикле, так и вообще правила соблюдать небезопасно. Например, гораздо безопаснее двигаться в междурядье, а не по полосам движения, чтобы быть заметным в зеркалах заднего вида автомобилей.
Кроме того, аналогия плохая. Правила - для людей, а не для машин. Это как code style, а не как borrow checker. И правила довольно часто пересматривают, чтобы адаптироваться к новым реалиям. Про borrow checker такого не скажешь, адаптивностью он не отличается.
Кроме Rust есть множество безопасных языков программирования, которые позволяют работать со сложными структурами данных без необходимости пересекать границу unsafe. Тем, кому нужна безопасность, идут в эти языки, и пишут большую часть кода на них, оставляя только небольшие чувствительные к производительности участки для реализации на языках с более слабыми гарантиями безопасности. Но это небольшие участки кода, нет никакого смысла использовать для них такой громоздкий язык, как Rust, в котором они были бы, всё равно, реализованы unsafe.
В экосистеме C, если и делают обобщённые структуры данных, то не через void*, а через макросы -- жаба же давит указатель лишний раз разыменовывать. Но такая потребность возникает редко, потому что на Си обычно пишут узкоспециализированные утилиты и библиотеки, в которых нет особого простора для обобщений.
Антропологи уже лет 100, если не дольше, определяют расы по строению скелетов - по остеометрическим признакам. Учёные, проводившие исследование, не в курсе?
Да, он сложный. Это сложный код, который не решает тривиальную задачу. В операционке гораздо гораздо всё сложнее со структурами данных. Соответственно, код будет распухать, скорость разработки будет падать, функциональность будет страдать. Производиельность тоже, потому что это всё нифига не бесплатно. Можете сравнить ассемблер реализации на Rust и аналогичной реализации на Си. Не, конечно, если цель сделать разработку Linux более дорогой и недоступной широкому кругу любителей, а сам код более ресурсоёмким, то верной дорогой идёте, товарищи! Только вот будет ли такой Linux Linux-ом? Надеюсь, будет создан какой-нибудь stainless fork.
Да что же любители Rust такие поверхностные-то? Там прямым текстом в коде написано, что нельзя пройти по списку без его разрушения. Нельзя взять элемент из середины. Да и читал я этот блог, когда пытался что-нибудь более или менее работоспособное на Rust написать.
Если было бы важно, дизайнили бы Rust иначе. Вопросы представления структур данных и алгоритмов при разработке явно не на первом месте были.
И это, в принципе, ok. Это имеет право на существование. Это интересно. Если бы не эта вся агрессивная pr-компания по пропихиванию Rust во все места... Довели бы до ума Redox, написали бы manual: классические алгоритмы и структуры данных на Rust - было бы хорошо, люди бы потянулись. Может быть, надо сначала научиться нормально, не через хэши, кучу Фибонначи реализовывать, и только потом уже в ядро лезть?
Но, ведь, нет. Нам втирают без каких либо достоверных обоснований, что это better C. Но по исходникам Redox и Servo видно, насколько better: Rust - очередная итерация "the worse the better".
Не правда. На практике unsafe используется даже в коде тестов, потому что без unsafe не триггернуть некоторые поведения. И смотреть надо не на то, сколько по объёму этот unsafe занимает, а на какой код он влияет, и там уже будет точно не 1%. В Rust могут быть крайне мозголомные утечки даже без unsafe, а с unsafe можно нарушать любые гарантии.
В Си, мы знаем, что можем снести себе ногу, и работаем осторожно, структурируем программы так, чтобы минимизировать риски. В Rust вы можете просто не знать об ошибке: компилятор съел код, и точка, вы верите, что всё хорошо. Народ, ведь, именно так и программирует: не через дизайн системы, а через затыкание компилятора. Смотрите на кучу unwarp повсеместно во всём коде на Rust. Это существенно снижает качество ПО, а не повышает.
Ещё раз повторю свой вопрос: покажите safe-реализацию очереди на Rust. Вопрос не об абстрактной полноте, а о совершенно конкретных алгоритмах и структурах данных.
Я, конечно, понимаю, что теоретикам от терий типов безразлично, будет очередь O(1) или O(n), но на практике, особенно при программировании ядра OS, это чертовски важно
Да, да, конечно. Именно NIH-синдром. И у каждой компании собственный компилятор Си... Не поэтому людям Rust не заходит, совсем не поэтому. Ещё раз повторю: нельзя на safe Rust закодировать некоторые алгоритмы. А дальше вопрос: зачем на Rust переходить, если будет, всё равно, unsafe? Просто, потому что модно, что ли?
А что делать? Ждать, когда эти десятки тысяч либ перепишут на Rust? Так, ведь, никогда не перепишут. Проблема Rust в том, что он просто не позволяет реализовывать некоторые алгоритмы в safe-режиме. А менять unsafe C на unsafe Rust не особо экономически оправдано. Поэтому, да, проще взять и проверить критически важные библиотеки на C. Собственно, все так и делают, кому безопасность важна.
Rust не производительнее C - я скидывал ссылку на сравнение в реальной задаче, и не безопасный - его система типов unsound и допускает ошибки и утечки памяти. Кроме того, любой мало мальски нетривиальный алгоритм требует использования unsafe для работы со структурами данных. Если бы Rust позволял писать работу со сложными структурами в safe, вопросов бы к нему не было, всё было бы супер. Но не позволяет же. Ковырни любую библиотечную структуру данных - там врутри unsafe код. А с учётом того, что система типов Rust некорректна (правда, мы не знаем, она математически некорректна, или это косяки реализации, но тем не менее, в текущем состоянии она допускает утечки памяти), unsafe для любой нетривиальной структуры данных - это вдвойне неприятно. Не понятно, где произойдёт выстрел в ногу.
Ладно бы это было только в недрах операционки, но, ведь, в unsafe возникает необходимость просто в обычном пользовательском коде.
Вы сами давали ссылку на реализацию очереди на Rust, которая длинее в 20 раз, чем реализация на С - это громоздкость. Если не нравится C, то можно взять Go (теперь мне не нравится, ну, да ладно). Тоже будет короткая простая реализация без урезанной функциональности. И производительность у Go вполне на уровне. Rust без unsafe от Go сильно оторваться не может:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-go.html
Так зачем при прочих равных мне выбирать более сложный язык программирования? Чтобы что?
OS можно написать хоть на Lisp, хоть на JavaScript, хоть на Haskell. Примеров множество. Вы хотя бы гуглите, прежде чем ложные заявления делать.
Я пришёл в Python после Haskell. Ничего не сломалось, в безумную обезьяну, которая пытается передать строки вместо чисел я не превратился. Что я делал не так?
Если бы все ездили только по правилам, аварийность была бы гораздо выше. Иногда приходится совершать запрещённые манёвры, чтобы избегать столкновений. В крупных городах приходится делать это довольно часто.
При движении на мотоцикле, так и вообще правила соблюдать небезопасно. Например, гораздо безопаснее двигаться в междурядье, а не по полосам движения, чтобы быть заметным в зеркалах заднего вида автомобилей.
Кроме того, аналогия плохая. Правила - для людей, а не для машин. Это как code style, а не как borrow checker. И правила довольно часто пересматривают, чтобы адаптироваться к новым реалиям. Про borrow checker такого не скажешь, адаптивностью он не отличается.
Кроме Rust есть множество безопасных языков программирования, которые позволяют работать со сложными структурами данных без необходимости пересекать границу unsafe. Тем, кому нужна безопасность, идут в эти языки, и пишут большую часть кода на них, оставляя только небольшие чувствительные к производительности участки для реализации на языках с более слабыми гарантиями безопасности. Но это небольшие участки кода, нет никакого смысла использовать для них такой громоздкий язык, как Rust, в котором они были бы, всё равно, реализованы unsafe.
Какая практика? Можно подробнее?
В экосистеме C, если и делают обобщённые структуры данных, то не через void*, а через макросы -- жаба же давит указатель лишний раз разыменовывать. Но такая потребность возникает редко, потому что на Си обычно пишут узкоспециализированные утилиты и библиотеки, в которых нет особого простора для обобщений.
Антропологи уже лет 100, если не дольше, определяют расы по строению скелетов - по остеометрическим признакам. Учёные, проводившие исследование, не в курсе?
Компиляторы давно умеют анализировать псевдонимы, и хорошо их видят. Кроме того, есть restrict, если компилятору нет доверия.
Не очень понятно, откуда в рассуждениях взялся void со звёздочкой.
https://codilime.com/blog/rust-vs-c-safety-and-performance-in-low-level-network-programming/
Да, он сложный. Это сложный код, который не решает тривиальную задачу. В операционке гораздо гораздо всё сложнее со структурами данных. Соответственно, код будет распухать, скорость разработки будет падать, функциональность будет страдать. Производиельность тоже, потому что это всё нифига не бесплатно. Можете сравнить ассемблер реализации на Rust и аналогичной реализации на Си. Не, конечно, если цель сделать разработку Linux более дорогой и недоступной широкому кругу любителей, а сам код более ресурсоёмким, то верной дорогой идёте, товарищи! Только вот будет ли такой Linux Linux-ом? Надеюсь, будет создан какой-нибудь stainless fork.
Да что же любители Rust такие поверхностные-то? Там прямым текстом в коде написано, что нельзя пройти по списку без его разрушения. Нельзя взять элемент из середины. Да и читал я этот блог, когда пытался что-нибудь более или менее работоспособное на Rust написать.
Если было бы важно, дизайнили бы Rust иначе. Вопросы представления структур данных и алгоритмов при разработке явно не на первом месте были.
И это, в принципе, ok. Это имеет право на существование. Это интересно. Если бы не эта вся агрессивная pr-компания по пропихиванию Rust во все места... Довели бы до ума Redox, написали бы manual: классические алгоритмы и структуры данных на Rust - было бы хорошо, люди бы потянулись. Может быть, надо сначала научиться нормально, не через хэши, кучу Фибонначи реализовывать, и только потом уже в ядро лезть?
Но, ведь, нет. Нам втирают без каких либо достоверных обоснований, что это better C. Но по исходникам Redox и Servo видно, насколько better: Rust - очередная итерация "the worse the better".
Смешной анекдот - это реализация Redox.
А реализация операций? С нетерпением жду.
Не правда. На практике unsafe используется даже в коде тестов, потому что без unsafe не триггернуть некоторые поведения. И смотреть надо не на то, сколько по объёму этот unsafe занимает, а на какой код он влияет, и там уже будет точно не 1%. В Rust могут быть крайне мозголомные утечки даже без unsafe, а с unsafe можно нарушать любые гарантии.
В Си, мы знаем, что можем снести себе ногу, и работаем осторожно, структурируем программы так, чтобы минимизировать риски. В Rust вы можете просто не знать об ошибке: компилятор съел код, и точка, вы верите, что всё хорошо. Народ, ведь, именно так и программирует: не через дизайн системы, а через затыкание компилятора. Смотрите на кучу unwarp повсеместно во всём коде на Rust. Это существенно снижает качество ПО, а не повышает.
Так как раз ОСы на нём писать крайне неудобно. В этом-то весь цимес. Он слишком ограничивает.
Ещё раз повторю свой вопрос: покажите safe-реализацию очереди на Rust. Вопрос не об абстрактной полноте, а о совершенно конкретных алгоритмах и структурах данных.
Я, конечно, понимаю, что теоретикам от терий типов безразлично, будет очередь O(1) или O(n), но на практике, особенно при программировании ядра OS, это чертовски важно
Да, да, конечно. Именно NIH-синдром. И у каждой компании собственный компилятор Си... Не поэтому людям Rust не заходит, совсем не поэтому. Ещё раз повторю: нельзя на safe Rust закодировать некоторые алгоритмы. А дальше вопрос: зачем на Rust переходить, если будет, всё равно, unsafe? Просто, потому что модно, что ли?
А что делать? Ждать, когда эти десятки тысяч либ перепишут на Rust? Так, ведь, никогда не перепишут. Проблема Rust в том, что он просто не позволяет реализовывать некоторые алгоритмы в safe-режиме. А менять unsafe C на unsafe Rust не особо экономически оправдано. Поэтому, да, проще взять и проверить критически важные библиотеки на C. Собственно, все так и делают, кому безопасность важна.
Типа, не смогли сделать Redox, поэтому пришли в Linux? Опасные ребята...