Согласен с вами, что язык - это просто инструмент, и он не может быть всегда универсальным. Пример, который вы привели, мне очень нравится, потому что он подтверждает это.
Если говорить про RTOS и МК, то тут не вижу смысла использования Rust. Си позволяет тут выстроить более тонкую настройку.
Переписывать всю фазу DXE и все драйвера не предлагаю, это что-то на безумном. Можно, как идея, новые драйвера пробовать писать изначально на нем. Если буду пробовать, то постараюсь поделиться опытом с сообществом.
Вообще идея переписывания ради переписывания мне не очень близка, но в этом правиле могут быть исключения. Допустим, бывают такие случаи, когда нужно переделать под проект драйвер, и эти изменения могут копиться как снежный ком: в начале понемногу, а потом через полгода понимаешь, что под лавиной из твоего кода похоронены старые исходники драйвера. В этот момент можно, если есть возможность и желание, подумать, как это всё причесать, чтобы и читаемость улучшить, и архитектуру подправить, и вспомнить про тех счастливчиков, которые будут всё это поддерживать в дальнейшем. И тут, как мне видится, Rust — хороший инструмент.
Из минусов: кушает больше памяти, высокий порог, работает медленнее. Это может быть критично, если говорить про МК, но если про использование в BIOS, тут это не так заметно.
Пару слов про аллоцирование. Может показаться, что 232 вызова — это немного, но тут главная проблема - с какой частотой происходят вызовы? Отвечу на свой вопрос: часто, очень часто. Память выделяется и при получении handler-ов, и при работе со строками, может происходить просто аллоцирование через функцию. И по опыту, ты можешь это всё держать в голове, и в описании функций это указано, но просто в силу человеческого фактора можно случайно такое пропустить из-за объема. И это по большому счету работа, которую можно оптимизировать, и Rust как раз это делает. Мелочь, а может для кого-то и нет, но приятно. Позволяет подумать о чем-то более важном. Квалифицированный программист - это хорошо, но мы же говорим про язык, а это просто инструмент. И всегда хорошо иметь под рукой классный инструмент, который имеет предохранители от "брака", но язык позволяет эти предохранители отключать. В крайнем случае можно разные участки работ делать разными инструментами.
Вопрос вроде бы и простой, но ответ получается объёмный. Лично моё мнение, на данный момент, полностью вытеснить Си невозможно просто в силу объёма кода, написанного на нём. Сейчас можно частично написать или переписать лишь какие-то элементы, например, Dxe-драйвера, утилиты, работающие в шелле, попадался мне как-то даже загрузчик на Rust. Если говорить о чем-то более раннем, инициализация стека, памяти, железа — тут сложнее, но думаю возможно.
Про сам язык, попробовав для себя отметил, опять же в сравнении, как разработчик, что язык даёт более удобные инструменты для работы с динамической памятью, забирает всю работу с освобождением на себя. Очень частая проблема связана с утечкой памяти, так как ты можешь это упустить или забыть просто в силу частоты появления такого события. Да, это не критично, утекают килобайты, до мегабайтов редко доходит, но всё равно неприятно.
Еще мне понравилась в языке тема с обработками результатов работы - Result. Это убирает из кода “простыни” с обработкой выхлопа из функций, позволяя сосредоточиться на главном функционале, а не на бесконечном количестве if-в с обработкой статуса.
И можно привести еще примеры с прикормкой из языка, от которой я балдею. Опять же, для себя я решил, что пока пробую rust только для написания утилит, и на данный момент мне всё нравится
Мем сложный, можно даже сказать ребус, требующий пояснения. Если гуглить что-то по слову UEFI, забыв переключить при этом раскладку с родной кириллицы, то можно получить вместо желаемого гору картинок с краской
Согласен с вами, что язык - это просто инструмент, и он не может быть всегда универсальным. Пример, который вы привели, мне очень нравится, потому что он подтверждает это.
Если говорить про RTOS и МК, то тут не вижу смысла использования Rust. Си позволяет тут выстроить более тонкую настройку.
Переписывать всю фазу DXE и все драйвера не предлагаю, это что-то на безумном. Можно, как идея, новые драйвера пробовать писать изначально на нем. Если буду пробовать, то постараюсь поделиться опытом с сообществом.
Вообще идея переписывания ради переписывания мне не очень близка, но в этом правиле могут быть исключения. Допустим, бывают такие случаи, когда нужно переделать под проект драйвер, и эти изменения могут копиться как снежный ком: в начале понемногу, а потом через полгода понимаешь, что под лавиной из твоего кода похоронены старые исходники драйвера. В этот момент можно, если есть возможность и желание, подумать, как это всё причесать, чтобы и читаемость улучшить, и архитектуру подправить, и вспомнить про тех счастливчиков, которые будут всё это поддерживать в дальнейшем. И тут, как мне видится, Rust — хороший инструмент.
Из минусов: кушает больше памяти, высокий порог, работает медленнее. Это может быть критично, если говорить про МК, но если про использование в BIOS, тут это не так заметно.
Пару слов про аллоцирование. Может показаться, что 232 вызова — это немного, но тут главная проблема - с какой частотой происходят вызовы? Отвечу на свой вопрос: часто, очень часто. Память выделяется и при получении handler-ов, и при работе со строками, может происходить просто аллоцирование через функцию. И по опыту, ты можешь это всё держать в голове, и в описании функций это указано, но просто в силу человеческого фактора можно случайно такое пропустить из-за объема. И это по большому счету работа, которую можно оптимизировать, и Rust как раз это делает. Мелочь, а может для кого-то и нет, но приятно. Позволяет подумать о чем-то более важном.
Квалифицированный программист - это хорошо, но мы же говорим про язык, а это просто инструмент. И всегда хорошо иметь под рукой классный инструмент, который имеет предохранители от "брака", но язык позволяет эти предохранители отключать. В крайнем случае можно разные участки работ делать разными инструментами.
Вопрос вроде бы и простой, но ответ получается объёмный. Лично моё мнение, на данный момент, полностью вытеснить Си невозможно просто в силу объёма кода, написанного на нём. Сейчас можно частично написать или переписать лишь какие-то элементы, например, Dxe-драйвера, утилиты, работающие в шелле, попадался мне как-то даже загрузчик на Rust. Если говорить о чем-то более раннем, инициализация стека, памяти, железа — тут сложнее, но думаю возможно.
Про сам язык, попробовав для себя отметил, опять же в сравнении, как разработчик, что язык даёт более удобные инструменты для работы с динамической памятью, забирает всю работу с освобождением на себя. Очень частая проблема связана с утечкой памяти, так как ты можешь это упустить или забыть просто в силу частоты появления такого события. Да, это не критично, утекают килобайты, до мегабайтов редко доходит, но всё равно неприятно.
Еще мне понравилась в языке тема с обработками результатов работы - Result. Это убирает из кода “простыни” с обработкой выхлопа из функций, позволяя сосредоточиться на главном функционале, а не на бесконечном количестве if-в с обработкой статуса.
И можно привести еще примеры с прикормкой из языка, от которой я балдею. Опять же, для себя я решил, что пока пробую rust только для написания утилит, и на данный момент мне всё нравится
Мем сложный, можно даже сказать ребус, требующий пояснения. Если гуглить что-то по слову UEFI, забыв переключить при этом раскладку с родной кириллицы, то можно получить вместо желаемого гору картинок с краской