LINUX.ORG.RU

Вышел Rust 1.20

 


2

7

Команда разработчиков Rust с удовольствием объявляет о выходе новой стабильной версии Rust: 1.20.0.

Rust — это язык программирования, ориентированный на безопасность, скорость и параллелизм.

Если у вас установлена предыдущая версия Rust, то для обновления до Rust 1.20 достаточно выполнить следующую команду:

rustup update stable

(Прим. пер. - иногда предварительно нужно выполнить rustup self update)

Если Rust ещё не установлен, то вы можете установить его скачав rustup с соответствующей страницы на нашем сайте. Также вы можете посмотреть полный список изменений в Rust 1.20.0 на GitHub.

Что нового в стабильной версии Rust 1.20.0

В предыдущих версиях Rust вы уже могли определять «ассоциированные функции» для трейтов, структур и типов-сумм:

struct Struct;

impl Struct {
    fn foo() {
        println!("foo - это ассоциированная функция структуры Struct");
    }
}

fn main() {
    Struct::foo();
}

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

В Rust 1.20 добавлена возможность использовать «ассоциированные константы»:

struct Struct;

impl Struct {
    const ID: u32 = 0;
}

fn main() {
    println!("ID структуры Struct: {}", Struct::ID);
}
Здесь константа ID ассоциирована со структурой Struct. Как и функции, ассоциированные константы могут быть определены для трейтов и типов-сумм.

Использование ассоциированных констант в трейтах предоставляет дополнительные возможности. Ассоциированная константа в трейте используется также, как и ассоциированный тип: её можно определить, не присваивая ей значение. Значение константы будет указано при реализации трейта:

trait Trait {
    const ID: u32;
}

struct Struct;

impl Trait for Struct {
    const ID: u32 = 5;
}

fn main() {
    println!("{}", Struct::ID);
}
В предыдущих релизах Rust при реализации трейта, представляющего числа с плавающей точкой, приходилось писать такой код:
trait Float {
    fn nan() -> Self;
    fn infinity() -> Self;
    ...
}
Это немного неудобно, но, что более важно, такие функции невозможно использовать для определения констант. Из-за этого приходилось вводить дополнительные константы:
mod f32 {
    const NAN: f32 = 0.0f32 / 0.0f32;
    const INFINITY: f32 = 1.0f32 / 0.0f32;

    impl Float for f32 {
        fn nan() -> Self {
            f32::NAN
        }
        fn infinity() -> Self {
            f32::INFINITY
        }
    }
}
Ассоциированные константы позволяют реализовать всё это намного проще. Трейт будет выглядеть таким образом:
trait Float {
    const NAN: Self;
    const INFINITY: Self;
    ...
}
А его реализация станет намного проще и расшит возможности использования трейта:
mod f32 {
    impl Float for f32 {
        const NAN: f32 = 0.0f32 / 0.0f32;
        const INFINITY: f32 = 1.0f32 / 0.0f32;
    }
}
Ассоциированные константы были предложены три года назад в RFC 195. И мы наконец смогли их реализовать! Этот RFC содержал все виды ассоциированных элементов, не только константы. Некоторые из них мы смогли реализовать быстрее чем другие. Мы много работаем над улучшением поддержки работы с константными выражениями, чтобы увеличить возможности Rust в области мета-программирования во время компиляции. В будущем в этой области появятся дополнительные возможности.

Кроме того, мы исправили ошибку при работе с макросом include! в тестах документации: пути к файлам определялись относительно рабочего каталога, а не каталога, в котором находится файл кода.

Стабилизация библиотек

В этом релизе не произошло значительных изменений в стандартных библиотеках. Внесено несколько полезных улучшений и продолжается работа по стабилизации API.

Макро unimplemented! теперь принимает параметр, в котором можно указать причину отсутствия реализации.

Добавлена поддержка Unicode 10.0.0.

Функции min и max были переписаны на Rust, и больше не используют cmath.

Внедрена защита от уязвимости Stack Clash. Основные изменения: stack probes и отключение дополнительных ручных проверок для стека основного потока. Для включения защиты достаточно скомпилировать проект в Rust 1.20, изменения в коде не требуются.

В стандартную библиотеку добавлены три новые функции сортировки: slice::sort_unstable_by_key, slice::sort_unstable_by и slice::sort_unstable. Как вы заметили, все три содержат «unstable» в названиях. Стабильность — это свойство алгоритма сортировки, которое требуется не всегда, но раньше в стандартной библиотеке не было алгоритмов нестабильной сортировки. Теперь доступны обе возможности! Для демонстрации разницы между этими видами сортировки рассмотрим список:

rust
crate
package
cargo
Список, отсортированный алгоритмом стабильной сортировки только по первой букве, должен выглядеть таким образом:
crate
cargo
package
rust
То есть, если в исходном списке слово crate предшествовало слову cargo, то и в отсортированном списке оно должно стоять первым. Алгоритм нестабильной сортировки тоже может выдать такой результат, но допускается и вариант с измененной последовательностью:
cargo
crate
package
rust
Как вы понимаете, меньшее количество ограничений часто позволяет создать более быстрый алгоритм. Если вам не важна стабильность сортировки, нестабильная сортировка может оказаться быстрее, чем стабильный вариант. Как обычно, лучше попробовать оба варианта и сравнить их скорость. Эти функции сортировки были добавлены в RFC 1884. По ссылке вы можете узнать больше подробностей, включая результаты бенчмарков.

Также были стабилизированы следующие API:

и некоторые другие.

Возможности cargo

Этот релиз внес полезные улучшения в менеджер пакетов cargo. Первое и самое важное: токен аутентификации для crates.io хранился в ~/.cargo/config. Обычно маска доступа для файлов конфигурации устанавливается в 644, то есть чтение разрешено всем. Но в этом файле хранится секретный токен. Мы переместили токен в отдельный файл ~/.cargo/credentials, таким образом для него может быть установлен доступ 600, и он будет скрыт от других пользователей системы.

Если вы использовали пакеты Cargo, создающие дополнительные исполняемые файлы, вы знаете, что их исходный код хранится в src/bin. Но иногда вам может понадобиться создать несколько дополнительных исполняемых файлов, требующих много кода. В этом случае код может храниться в файлах src/bin/client.rs и src/bin/server.rs и все субмодули этих файлов попадут в один каталог, что неудобно и создает путаницу. Теперь мы используем соглашение, что такие файлы как src/bin/server/main.rs и src/bin/client/main.rs также используются для создания дополнительных исполняемых файлов. Это позволяет удобнее разграничить код.

>>> Подробности

★★★

Проверено: Shaman007 ()
Последнее исправление: red75prim (всего исправлений: 3)

Ответ на: комментарий от makoven

Только Go. Со всеми из него вытекающими

Го божественен, не бухти. Конечно в рамках своей ниши.

anonymous
()
Ответ на: комментарий от makoven

Время покажет.

Ну и да, поясню: речь не про то, что Rust не пригоден к использованию в embedded, а про то, что в этой нише:

a) у Rust-а уже есть серьезная конкуренция,

b) использование Rust-а там, скорее всего, будет сильно отличаться от использования Rust-а в Servo и FireFox-е.

Все это сделает проникновение Rust-а в embedded, на мой взгляд, не быстрым процессом.

eao197 ★★★★★
()
Ответ на: комментарий от mersinvald

Фибоначчи на итераторах? В смысле на обычном наборе типа range/map/flatmap/filter/fold? Я вот так сходу не представляю.

khrundel ★★★★
()
Ответ на: комментарий от makoven

Может и льщу. Я всегда думал (а точнее где-то вычитал), что бэкенд на плюсах в 20-100 раз менее прожорлив фреймворка на динамическом языке

Менее. Но разрыв между C++ и Java на server-side гораздо менее драматичный (за счет прогрева JVM и jit-а). Если руки у Java-разработчиков нормальные и они не налепили паттерн и паттерне просто так, потому, что «так правильно».

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

pftBest ★★★★
()
Ответ на: комментарий от pftBest

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

Да в каком-то из Rust-срачей уже обсуждалась split_at_mut, которую нельзя сделать иначе, кроме как с unsafe внутрях. Кому-то же она потребовалась (например, для quick sort-а).

В программировании real-time систем запросто можно столкнуться ситуацией, когда есть один общий вектор (например, очередь запросов на обработку) доступ к которому нужно иметь из независимо работающих объектов (нитей, например). И гарантии безопасности обспечиваются средой исполнения (например, среда гарантирует, что активен может быть только один из них, с наивысшим приоритетом). Получится, что каждому объекту нужна своя мутабельная ссылка, без плясок с бубном в ран-тайме вокруг lock-ов и unwind-ов.

eao197 ★★★★★
()
Ответ на: комментарий от AntonyRF

но я ещё не видел ни одного исходника в настоящем проекте на Ада

Мухаха! Кто же пустит деревенского дурачка из третьего мира к настоящим проектам.

anonymous
()
Ответ на: комментарий от eao197

В программировании real-time систем запросто можно столкнуться ситуацией, когда есть один общий вектор (например, очередь запросов на обработку) доступ к которому нужно иметь из независимо работающих объектов

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

anonymous
()
Ответ на: комментарий от AntonyRF

Вы всегда так реагируете, когда вам фичу объясняют на примере однострочника? Йилд вещь полезная, позволяет очень просто писать генераторы с зависимостью от предыдущих элементов. Фибонача - это просто примитивнейший пример.

khrundel ★★★★
()
Ответ на: комментарий от eao197

Но разрыв между C++ и Java на server-side гораздо менее драматичный

Поэтому я и сказал «высоконагруженные сетевые сервисы», где и двукратный разрыв может быть драматичен

makoven ★★★★★
()
Ответ на: комментарий от anonymous

А я и не спорю. Но на языке без гц и рантайма все-равно можно выжать больше из сервера

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

Поэтому я и сказал «высоконагруженные сетевые сервисы», где и двукратный разрыв может быть драматичен

Ну вот я бы рассматривал для Rust-а нишу тех сетевых сервисов, где нужна и производительность, и безопасность одновременно. Только вот за счет того, что безопасность бесплатно не дается и для поступающих из-вне данных обеспечивается проверками в run-time, то разрыв между Rust-овым кодом и хардкорным C или C++ все равно будет.

Другое дело, что там, где важна безопасность, цена этого разрыва будет более чем приемлемой.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

По вашему embedded — это только микроконтроллеры? Вот посмотрите здесь, слайд №7. Это относится к embedded или нет?

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

AntonyRF ★★★★
()
Ответ на: комментарий от AntonyRF

но Ада у в пределах СНГ от этого популярнее не стала.

А что, здесь обсуждаются перспективы Rust-а только на просторах СНГ?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

Нет. Идеология Раста в том, что на один объект может существовать множество ссылок реад-онли и только одна мутабельная ссылка в одной зоне видимости. И это хорошо.

Но опять же, это не мешает писать в safe rust на микроконтроллерах

AntonyRF ★★★★
()
Ответ на: комментарий от anonymous

Мухаха! Кто же пустит деревенского дурачка из третьего мира к настоящим проектам.

Звучит обидно, особенно когда правда родился в деревне =)

AntonyRF ★★★★
()
Ответ на: комментарий от khrundel

Вы всегда так реагируете, когда вам фичу объясняют на примере однострочника?

Не совсем, просто есть более полезные вещи в rfc раста, почему именно йилд?! Вам, конечно, спасибо за объяснение

AntonyRF ★★★★
()
Ответ на: комментарий от eao197

доступ к которому нужно иметь из независимо работающих объектов (нитей, например)

Arc, Mutex?

Получится, что каждому объекту нужна своя мутабельная ссылка, без плясок с бубном в ран-тайме вокруг lock-ов и unwind-ов.

Типаж clone в помощь

AntonyRF ★★★★
()
Ответ на: комментарий от AntonyRF

Я так понимаю, сделали за компанию с корутинами

khrundel ★★★★
()

Проблема раста в том, что он не подходит для обучения ни под каким соусом. Сравните реализацию двусвязного списка на расте и на паскале или с. Или дерева. тут раст еще более упорт чем александреску с его 2-3 этажными шаблонами.

anonymous
()
Ответ на: комментарий от AntonyRF

Рад за вас, но если в «гондурасе» перестанут спонсировать разработку Rust-а, в РФ ее никто развивать не будет. Даже в рамках импортозамещения.

Так что чем больше Rust будут использовать «там», тем лучше и проще его будет использовать «здесь».

eao197 ★★★★★
()
Ответ на: комментарий от RazrFalcon

Серьезно? Я как на 2 курсе RB дерево написал на том самом паскале, так для меня на чем угодно его написать теперь не проблема. B никакой боли.

anonymous
()

Пацаны, а вы чего в рабочее время базарите? Это говорит о аудитории любителей Rust'a. Или ждёте пока вакансии запилят на вашем любимчике? :3

anonymous
()
Ответ на: комментарий от anonymous

Пацаны, а вы чего в рабочее время базарите? Это говорит о аудитории любителей Rust'a.

Затралил. Но вообще-то любители Rust базарят не между собой, а с его критиками. Видимо, с ними тоже не всё ладно.

Virtuos86 ★★★★★
()
Ответ на: комментарий от anonymous

Деревья бывают разные. Суть в его производительности.

Вот на расте приходится использовать Rc и Week, что не шибко удобно.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Ёлы-палы, это здесь каким боком? Сталь стынет в котлах, пока ты на ЛОР пишешь

anonymous
()
Ответ на: комментарий от RazrFalcon

причем тут производительность? Это дело дальнейшей оптимизации. Разговор то за обучение принципам. Смысл в том, что студенту важно понять принцип, например сбалансированного дерева, или списка. Во всех этих Rc<> и прочих Weak он просто потеряется и пошлёт всё нах. Не говоря уже о более высоких материях.

(Это, кста, касается и опытных тел уже. Программист он, сука, ленив. если программист не ленив, то он не сможет писать правильный и гладкий код. А ленивая жопа пошлет раст уже после первого факапа с борроу чекером)

А вот если понять принцип, то потом все эти Rc Box Cell будут просто эстетическое неудобство доставлять.

anonymous
()
Ответ на: комментарий от anonymous

Пацаны, а вы чего в рабочее время базарите?

Они на переменках. Можно еще физру прогулять и побазарить за мировое господство ржавого.

anonymous
()
Ответ на: комментарий от anonymous

При чём тут обучение? Я про GC говорил.

Умение реализовывать hashtable в виде блоксхемы - это конечно прекрасно, но в реальном жизни всё в 100500 раз сложнее.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Дерево без GC вообще боль.

О боже, ну и ламье собралось вокруг ржавчины.

anonymous
()
Ответ на: комментарий от RazrFalcon

Потому что разговор зашел за то, что раст не годен для обучения. Ты сказал, что деревья это «ад и вообще сложна!», я сказал, что деревья это норм, если понять принцип. А принцип постигается засчет удобного и выразительного инструмента, коим раст не является.

Умение реализовывать hashtable в виде блоксхемы

мля причем тут хештейбл, что ты, нах, несешь?

anonymous
()
Ответ на: комментарий от eao197

[...] доступ к которому нужно иметь из независимо работающих объектов (нитей, например). И гарантии безопасности обспечиваются средой исполнения [...]

Нити - это что? Fibers? В этом случае несложно создать безопасную zero-cost абстракцию для работы с расшаренными ресурсами.

На вскидку:

struct SharedMemoryWrapper<T> { ... }
impl<T> AsMut<T> for SharedMemoryWrapper<T> { ... }
fn yield(_: SharedMemoryWrapper<T>) -> SharedMemoryWrapper<T> { ... }
Между yield'ами можем свободно работать с &mut T. Получение &mut T из *mut T, который будет во внутренностях SharedMemoryWrapper - zero-cost.

Threads? Как тогда рантайм собирается гарантировать, что выполнение не будет передано другому потоку в середине функции, считающей что она единолично распоряжается расшаренной памятью?

red75prim ★★★
() автор топика
Ответ на: комментарий от red75prim

Нити - это что?

Что угодно.

На вскидку:

И зачем весь этот огород, если вы все равно будете использовать unsafe?

Впрочем, это риторический вопрос. Растоманы на него отвечают тем, что unsafe будет только в отдельных местах и бла-бла-бла. Поживем, увидим.

Как тогда рантайм собирается гарантировать, что выполнение не будет передано другому потоку в середине функции, считающей что она единолично распоряжается расшаренной памятью?

Вопрос выдает человека, который никогда не слышал про ОС реального времени и про важность приоритетов в них :)

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Проблема раста в том, что он не подходит для обучения ни под каким соусом.

Зачем его использовать для обучения? Для этого есть более другие инструменты.

Igor_FF
()
Ответ на: комментарий от eao197

И зачем весь этот огород, если вы все равно будете использовать unsafe?

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

Вопрос выдает человека, который никогда не слышал про ОС реального времени

Хорошо, слушаю эксперта. Как рантайм может гарантировать, что высокоприоритетный тред (или тред с гарантированным временем выполнения) не прервет низкоприоритетный тред, работающий с расшаренной памятью, и не создаст data race?

red75prim ★★★
() автор топика
Последнее исправление: red75prim (всего исправлений: 1)
Ответ на: комментарий от red75prim

Единственный unsafe, относящийся к совместному доступу к расшаренной области памяти, будет внутри AsMut. И его безопасность будет гарантировать рантайм.

Хорошо, послушаю эксперта. Как он это будет гарантировать?

Как рантайм может гарантировать, что высокоприоритетный тред (или тред с гарантированным временем выполнения) не прервет низкоприоритетный тред, работающий с расшаренной памятью, и не создаст data race?

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

Это все уже на совести разработчика. Использование мутексов здесь чревато порождением проблемы инверсии приоритетов.

eao197 ★★★★★
()
Ответ на: комментарий от O02eg

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

И пока это единственное его достоинство. Остальное настолько криво... :(

Нужен НОМАЛЬНЫЙ язык с таким механизмом. Может кто запилит? Ж:-)

anonymous
()
Ответ на: комментарий от mersinvald

Че-ж плюсовики то тогда первыми плюются от раста?)

Плюсовики разные бывают.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Virtuos86

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

Как бы для некоторых вещей надо залезать в Qt и править. Это, оказывается, довольно легко. ООП, однако. Которого в rust не завезли.

anonymous
()
Ответ на: комментарий от eao197

Хорошо, послушаю эксперта. Как он это будет гарантировать?

Fibers - это по определению кооперативная многозадачность. Единственная точка перехода к другому fiber - yield. Сигнатура yield, которую я написал выше, гарантирует, что на момент вызова yield на расшаренные данные нет мутабельных ссылок.

То есть когда другой fiber получает управление, он может безопасно преобразовать указатель на расшаренные данные в мутабельную ссылку, одновременно заимствуя SharedMemoryWrapper, что не позволит вызвать yield, пока эта ссылка существует.

Это все уже на совести разработчика. Использование мутексов здесь чревато порождением проблемы инверсии приоритетов.

То есть не

[...] гарантии безопасности обспечиваются средой исполнения [...]

a, среда исполнения реализует какую-то scheduling policy, при которой невозможно использование мутексов.

И что можно ответить на вопрос: «Как использовать стандартную библиотеку, если стандартную библиотеку использовать нельзя?»? Делать что-то подходящее под задачу, естественно. И Раст тут дает больше возможностей чем C.

red75prim ★★★
() автор топика
Ответ на: комментарий от red75prim

Fibers - это по определению кооперативная многозадачность. Единственная точка перехода к другому fiber - yield. Сигнатура yield, которую я написал выше, гарантирует, что на момент вызова yield на расшаренные данные нет мутабельных ссылок.

То есть когда другой fiber получает управление, он может безопасно преобразовать указатель на расшаренные данные в мутабельную ссылку, одновременно заимствуя SharedMemoryWrapper, что не позволит вызвать yield, пока эта ссылка существует.

Ну т.е. вы начинаете проектировать задачу из того, что вам позволяет сделать Rust, а не из того, что нужно для самой задачи. Возможна в safe Rust всего одна мутабельная ссылка — значит давайте приседать так, чтобы у нас был SharedMemoryWrapper и yield.

Нужно это в прикладной области или не нужно — пофигу. Главное, чтобы компилятор был доволен.

Именно поэтому многие на Rust смотрят с опаской.

a, среда исполнения реализует какую-то scheduling policy, при которой невозможно использование мутексов.

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

Нужно ли эти гарантии выражать в коде посредством SharedMemoryWrapper, да еще так, чтобы был доволен компилятор, а не разработчик — большой вопрос.

И Раст тут дает больше возможностей чем C.

Речь шла не о том, что дает Rust. А о том, что unsafe Rust-а здесь будет больше, чем при использовании Rust-а вне мира embedded.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Вам не угодишь, мало unsafe - плохо, приходится всякие абстракции вводить. Много unsafe - плохо, ничем не отличается от С.

В Расте несколько мутабельных ссылок на одно значение - UB, поскольку их уникальность гарантируется языком. Как в С++ гарантируется то, что ссылка не может быть null. Даже если процессор будет аппаратно проверять ссылки, это не сделает программу, использующую нулевые ссылки, корректной. Если нужен алиасинг, есть UnsafeCell и другие инструменты.

red75prim ★★★
() автор топика
Ответ на: комментарий от eao197

Нужно это в прикладной области или не нужно — пофигу.

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

Иначе можно назвать стандарты кодирования софта для авионики и автомобилестроения бесполезной хренью, потому что они заставляют «проектировать задачу из того, что заставляет делать стандарт, а не из того, что нужно для самой задачи».

anonymous
()
Ответ на: комментарий от anonymous

Иначе можно назвать стандарты кодирования софта для авионики и автомобилестроения бесполезной хренью, потому что они заставляют «проектировать задачу из того, что заставляет делать стандарт, а не из того, что нужно для самой задачи».

Зачастую это так и есть. В какой-то момент кто-то, где-то решил, что так правильно. Исследований никаких не проводилось. Просто экспертное мнение. Как и большинство решений, решения о стандартах кодирования проталкивались корпорациями, что бы убрать конкурентов. И вот те решения, тогда принятые, сейчас, спустя десятилетия, приходиться выполнять. Но такова работа.

anonymous
()
Ответ на: комментарий от red75prim

Вам не угодишь, мало unsafe - плохо, приходится всякие абстракции вводить. Много unsafe - плохо, ничем не отличается от С.

Вы, видимо, не поняли исходный поинт. Мое мнение состояло в том, что в эмбеддеде в Rust-е будет больше unsafe, чем в обычных областях. Следовательно, выгод от использования Rust-а там будет меньше.

Так что если стоит вопрос лучше ли брать Rust для нового проекта повторяющего функциональность какого-нибудь BIND9 или sshd, то тут ответ однозначный: уж лучше Rust, чем C. И, может быть, чем C++.

Тогда как для эмбеддеда уже не так все однозначно. Тем более, что в эмбеддеде и C, и C++, и Ada уже давно. А Rust-а там нет вообще.

eao197 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.