LINUX.ORG.RU

Rust 1.31.0 (2018)

 , rust2018


5

10

Команда Rust объявила о выходе новой стабильной версии Rust 1.31.0, который ознаменует собой также выход новой редакции «Rust 2018». Rust — это язык программирования, который позволяет каждому создавать надежное и эффективное программное обеспечение.

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

rustup update stable

Если у вас ещё не установлен Rust, то это можно сделать, загрузив с сайта утилиту rustup.

Что нового в Rust 1.31.0

Rust 2018

Данный релиз ознаменует собой выпуск редакции Rust 2018. Впервые Rust 2018 был упомянут в марте, затем в июле: прочтите их, чтобы понимать для чего нужен Rust 2018. Также, есть статья на сайте Mozilla Hacks.

Вкратце, Rust 2018 это возможность представить всю работу за последние три года в виде цельного пакета. Кроме возможностей языка, сюда входят:

  • Инструментарий (поддержка IDE, rustfmt, Clippy)
  • Документация
  • Работа различных рабочих групп
  • Новый веб-сайт

Для обозначения редакций Rust был представлен ключ edition в Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
authors = ["Your Name <you@example.com>"]
edition = "2018"

[dependencies]

Значение 2018 означает, что используется редакция Rust 2018; отсутствие ключа или значение 2015 означает использование редакции Rust 2015.

Важно отметить, что каждый пакет может быть в редакциях 2015 или 2018, и они без проблем могут работать вместе. Проект под редакцией 2018 может использовать зависимости 2015, а проект 2015 использовать зависимости 2018. Это гарантирует целостность экосистемы, сохраняя совместимость существующего кода. Кроме того, существует возможность автоматической миграции кода с редакции Rust 2015 на Rust 2018 при помощи cargo fix.

Non-lexical lifetimes (NLL; Нелексические времена жизни)

В 2018 появились нелексические времена жизни, что на простом языке означает, что проверщик заимствований (borrow checker) стал умнее и теперь не отклоняет правильный код. Например:

fn main() {
    let mut x = 5;

    let y = &x;

    let z = &mut x;
}

В старых версиях этот код выдаст ошибку компиляции:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
6 | }
  | - immutable borrow ends here

из-за того, что время жизни действует внутри лексического блока; то есть, заимствование будет удерживаться за y, пока y не покинет пределы main, несмотря на то, что y больше не используется. Сегодня этот код скомпилируется правильно.

Другой пример:

fn main() {
    let mut x = 5;
    let y = &x;
    let z = &mut x;
    
    println!("y: {}", y);
}

Старый Rust выдаст следующую ошибку:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
...
8 | }
  | - immutable borrow ends here

В Rust 2018 вывод ошибки стал лучше:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:13
  |
4 |     let y = &x;
  |             -- immutable borrow occurs here
5 |     let z = &mut x;
  |             ^^^^^^ mutable borrow occurs here
6 |     
7 |     println!("y: {}", y);
  |                       - borrow later used here

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

Пока эти возможности доступны в Rust 2018, но в будущем планируется портировать их на Rust 2015.

Изменения в системе модулей

Редакция Rust 2018 привносит некоторые изменения в работу с путями, что в конечном итоге привело к упрощению системы модулей.

Вкратце:

  • extern crate больше не требуется практически во всех случаях.
  • Макросы теперь можно импортировать при помощи use вместо атрибута #[macro_use].
  • Абсолютные пути начинаются с названия пакета, где ключевое слово crate ссылается на текущий пакет.
  • foo.rs и поддиректория foo/ могут сосуществовать вместе; mod.rs больше не нужен при размещении подмодулей в поддиректории.

Полную информацию можно прочесть в руководстве.

Упрощенные правила синтаксиса времени жизни

В обеих редакциях представлены новые правила синтаксиса времени жизни для блоков impl и определениях функций. Следующий код:

impl<'a> Reader for BufReader<'a> {
    // methods go here
}
теперь может быть написан таким образом:
impl Reader for BufReader<'_> {
    // methods go here
}

'_ подсказывает, что BufReader берёт параметр, но больше нет необходимости именовать его.

В структурах времена жизни всё ещё должны быть определены, но теперь без лишнего кода:

// Rust 2015
struct Ref<'a, T: 'a> {
    field: &'a T
}

// Rust 2018
struct Ref<'a, T> {
    field: &'a T
}
: 'a добавляется автоматически. При желании, можно продолжать использовать явное определение.

const fn

Существует несколько способов определения функций в Rust: регулярная функция с fn, небезопасная функция с unsafe fn, внешняя функция с extern fn. В этом релизе появился ещё один способ: const fn, который выглядит следующим образом:

const fn foo(x: i32) -> i32 {
    x + 1
}
Функции const fn могут вызываться как регулярные функции, но вычисляются во время компиляции, а не во время выполнения. Для стабильной работы, они должны иметь детерминированный результат и в настоящее время ограничены следующим минимальным набором операций:

  • Арифметические операторы и операторы сравнения с целыми числами
  • Все логические операторы, кроме && и ||
  • Построение массивов, структур, перечислений и кортежей
  • Вызов других функций const fn
  • Задание индекса массивам и срезам
  • Доступ к полям структур и кортежей
  • Чтение из констант
  • & и * на ссылках
  • Приведение типов, за исключением необработанных указателей на целые числа

В будущем данный набор будет расширяться, подробную информацию можно посмотреть здесь.

Новые инструменты

Наряду с Cargo, Rustdoc, и Rustup, которые являются ключевыми инструментами с версии 1.0, редакция 2018 представляет новое поколение инструментов: Clippy, Rustfmt, и поддержку IDE.

Clippy является статическим анализатором кода в Rust, достиг версии 1.0 и теперь доступен в стабильной версии Rust. Установку можно произвести следующим образом: rustup component add clippy, запуск: cargo clippy.

Rustfmt является инструментом для автоматического форматирования кода Rust в соответствии с официальной стилистикой Rust. В этом релизе он достиг версии 1.0 и, начиная с этой версии, гарантируется обратная совместимость для Rustfmt: отформатированный сегодня код останется неизменным в будущем (только с опциями использованными по-умолчанию), и несёт практическую ценность при использовании с системами непрерывной интеграции (CI; cargo fmt --check). Установить Rustfmt можно следующим образом: rustup component add rustfmt, использовать: cargo fmt.

Поддержка IDE - одна из наиболее востребованных возможностей в Rust. Работы над поддержкой IDE ещё не закончены, но на данный момент уже существуют несколько высококачественных опций:

Tool lints

В Rust 1.30 были стабилизированы атрибуты инструментов, такие как #[rustfmt::skip]. В Rust 1.31 стабилизированы «анализаторы инструментов» («tool lints») наподобие #[allow(clippy::bool_comparison)], у них появилось своё пространство имён и теперь ясно к какому инструменту они относятся. Старые проверки Clippy теперь можно писать следующим образом, вам больше не нужен атрибут cfg_attr:

// old
#![cfg_attr(clippy, bool_comparison)]

// new
#![allow(clippy::bool_comparison)]

Документация

В этом году Rustdoc увидел ряд улучшений, также полностью было переписано руководство по Rust.

Рабочие группы

В этом году было объявлено о создании четырёх рабочих групп в следующих областях:

  • Сетевые сервисы
  • Приложения командной строки
  • WebAssembly
  • Встраиваемые устройства

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

  • Группа сетевых сервисов работает над интерфейсом Futures и async/await, который уже будет доступен в скором времени.
  • Группа командной строки работает над библиотеками и документацией для создания ещё лучших приложений для командной строки.
  • Группа WebAssembly выпустила огромное количество инструментария для использования Rust с wasm.
  • Группа встраиваемых устройств добилась поддержки разработки ARM на стабильной версии Rust.

Новый сайт

Основной сайт получил новый дизайн.

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

Добавлено множество реализаций From:

  • u8 теперь реализует From<NonZeroU8>, то же самое для других числовых типов и их NonZero-эквивалентов
  • Option<&T> реализует From<&Option<T>>, аналогично для &mut

Были стабилизированы следующие функции:

  • slice::align_to и её изменяемый аналог
  • slice::chunks_exact и её изменяемый и r аналоги (такие как slice::rchunks_exact_mut) во всех комбинациях

Подробный список изменений можно посмотреть здесь.

Cargo

Cargo теперь загружает пакеты параллельно, используя HTTP/2. В связи с тем, что extern crate практически больше не требуется, было бы неудобно использовать пакет через extern crate foo as bar; Это можно сделать в Cargo.toml следующим образом:

[dependencies]
baz = { version = "0.1", package = "foo" }

или

[dependencies.baz]
version = "0.1"
package = "foo"

В примере выше, пакет foo теперь может быть использован через baz.

Подробный список изменений можно посмотреть здесь.

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

★★★★★

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

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

Все просто — у тебя разработчики неправильные.

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

Тогда и нечего говорить про «мы сейчас мир защитим».

Окей, я не буду этого говорить.

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

Не ожидал от тебя, честно.

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

Не ожидал от тебя, честно.

Это была ирония по поводу приписанных мне слов. Ты правильно не ожидал.

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

Я понимаю, что вы не следите за тем, что происходит в прочих языках. Если вам интересно, то посмотрите доклад Херба Саттера (председателя комитета стандартизации С++) про безопасность памяти в С++, существующие наработки и изменения в будущих редакциях языка: https://youtu.be/80BZxujhY38?t=1099

Кастательно

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

Вы же понимаете, что ваш посыл тут лжив? Вы в курсе как на крупных проектах организована сборка программ, обеспечение проверки контроля качества и прочее? Если нет, я вам расскажу упрощая: используются билд машины, которые настраиваются таким образом, чтоб прогнать полный набор инструментов для отлова всех возможных ошибок и прогона всех возможных анализаторов. Автоматически выполняются юнит тесты, smoke тесты и прочее. Если того требуют non-functional requirements, прогоняются фазификаторы. За частую после всего этого можно быть 100% уверенным, что все с кодом хорошо. При этом зависимости тоже собираются из исходного кода и на них прогоняется полный набор тех же проверок. То что делает Раст по умолчанию — малая доля всех тех проверок и всего того тестирования, которое выполняется на нормальных коммерческих проектах.

Конечно, сам набор тестов и утилит сильно зависит от специфики проекта и компании рарзработчика. Например, в игровой индустрии всем будет плевать на устойчивость программы к сбоям. Если игра крешанет, то никто не помрет от этого. А вот быстродействию выделяется очень много внимания. В медицинской сфере важно как быстродействие (жесткие системы реального времени) так и отказоустойчивость. Соответственно, тулинг разный там и там.

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

Fortunately, the Linux kernel provides us with a function to “reset” the currently applied LSM:

void​ reset_security_ops​(void)
{
  ​ ​security_ops​ ​=​ ​&default_security_ops;
}

This essentially kills the active LSM and disables all its hooks - with one function call

Милота.

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

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

Shadow stacks provide more protection for return addresses than stack canaries, which rely on the secrecy of the canary value and are vulnerable to non-contiguous write attacks.[4] Shadow stacks themselves can be protected with guard pages[5] or with information hiding, such that an attacker would also need to locate the shadow stack to overwrite a return address stored there.

Что ещё знаете?

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

Когда псевдо Растовики начнут читать доку по языку?

Those superpowers include the ability to:

* Dereference a raw pointer
* Call an unsafe function or method
* Access or modify a mutable static variable
* Implement an unsafe trait

Dereference a raw pointer - причина того, что С++ не безопасный, не? Call an unsafe function or method - т.е. такой метод, который может выполнить в принципе любую из перечисленных 4-х операций, т.е. тоже по транзитивности не безопасный. Читаем далее:

People are fallible, and mistakes will happen, but by requiring these four unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block.

О боже, как «that any errors related to memory safety must be within an unsafe block»? Он же безопасный.

Я не надеюсь, что вы поймете абсурдность своих утверждений.

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

Интересно, не встречал такое.

Тогда о чем с тобой говорить, если ты не в теме происходящего в ИБ?

Судя по описанию с вики не панацея

Панацеи не существует в принципе. Для любого языка, для любой технологии.

Тем не менее — описание с вики совсем не о том, о чем я говорил. Ты знаешь значение слова «аппаратный»?

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

То что делает Раст по умолчанию — малая доля всех тех проверок и всего того тестирования, которое выполняется на нормальных коммерческих проектах.

Эмм. Аналогов borrowck для С/С++ не существует, так что это не малая часть, а дополнительная часть.

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

Существует в экспериментальной ветке Clang-а. Я кидал уже видео https://youtu.be/80BZxujhY38?t=1099

До borrowchecker-a Rust-a, на мой взгляд, еще далеко. Но это шаг в верном направлении. Кроме того используются уже сейчас всякие аннотации а-ля nullable и прочее, что позволяет отловить некоторые другие ошибки.

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

Я понимаю, что вы не следите за тем, что происходит в прочих языках.

Отучайтесь говорить за собеседника.

За частую после всего этого можно быть 100% уверенным, что все с кодом хорошо.
Вы же понимаете, что ваш посыл тут лжив?

Количество дыр показывает обратное.

нормальных коммерческих проектах

Список в студию.

В медицинской сфере важно как быстродействие

google: как взломали кардиостимулятор за 5 мин

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

google: как взломали кардиостимулятор за 5 мин

Они подменили прошивку же. Будь она написана на Rust, это ничего не изменило бы.

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

Класс, использующий unsafe, нужно написать и протестировать один раз и забыть. В плюсах сделать тупую опечатку и искать её неделю можно абсолютно в любой строчке.

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

В токио там отдельный нестабильный бранч пока.

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

Ну, например, синтаксис описания структур такое себе. Эти бесконечные String::from() и прочие Box<>. Часто это пытаются обойти макросами, но вот незадачка, IDE не умеет их подсвечивать.

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

Отучайтесь говорить за собеседника.

Я выразил свое представление о вас, а не говорил от вашего имени. Учитесь читать написанное.

Количество дыр показывает обратное.

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

google: как взломали кардиостимулятор за 5 мин

Вообще не интересно. Я же не утверждал, что такого нет? Я утверждал, что зависит все от корпоративной и инженерной культуры.

Список в студию.

Тот список, на который я мог бы сослаться, покрыт NDA. И я не собираюсь встречному-поперечному распространяться о нем. То, что находится в публичном доступе, на пример, можете поискать самостоятельно вот тут: https://www.jpl.nasa.gov/ JPL были первыми в сфере инженерии, кто стал применять теперь довольно популярные статические анализаторы, фазификаторы, санитайзеры и прочие. Они же (NASA) спонсировали Сyclone, на который возлагали большие надежды.

Встречное предложение: завезите в студию крупный, сложный, реально использующийся продукт, написанный на Расте. Тогда и поговорим.

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

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

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

А вот и виляния пошли. Скучно с вами.

завезите в студию крупный, сложный, реально использующийся продукт, написанный на языке, который вышел три года назад

fixed

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

Не уверен на счет вашего опыта, мой показывает что большинство ошибок совершается в логике, а не на уровне «опечаток». В борьбе с такими ошибками компилятор может помочь только на уровне системы типов. Но логику всей программы он проверить не может. Хотя были попытки использовать автоматизированное доказательство теорем для решения этой проблемы. Например, компания Microsoft, однажды реализовала ОС Singulatrity на С#, которая была безопасна со всех сторон. Для обеспечения безопасности как раз и использовалось автоматизированное доказательство теорем. В производство наработки пошли в виде специальных расширений к языку и статических анализаторов, которые сейчас активно используются внутри самой корпорации. Некоторые наработки были добавлены и во внутреннюю реализацию С/С++ в виде несовместимых со стандартом расширений (да МС не использует студию для компиляции Оффтопика, а специальный компилятор).

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

Тогда о чем с тобой говорить, если ты не в теме происходящего в ИБ?

На бложики не подписан, да :( О прорывах в механизмах безопасности в XXI веке, разумеется

Тем не менее — описание с вики совсем не о том, о чем я говорил. Ты знаешь значение слова «аппаратный»?

О том. В статье упоминается, что в 2016 Intel выпустила спецификацию по hardware реализации шедоу стека. На каком железе он симплеменчен мне найти не удалось :(

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

Заметьте, что «нормальных коммерческих». Таких мало на общем фоне, а в особенности на фоне открытого софта.

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

Ну вы же голословно утверждаете о его превосходстве по всем фронтам. Ваше утверждение должно быть основано на фактах, а не быть просто жу-жу?

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

О том.

Нет.

На бложики не подписан, да :(

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

Разговор о «а я вот прочитал на Википедии» — это на двач лучше. Там обычно обсуждения такого уровня.

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

О том.

Нет.

На бложики не подписан, да :(

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

Разговор о «а я вот прочитал на Википедии» — это на двач лучше. Там обычно обсуждения такого уровня.

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

Я-то? Пруфца бы. Пока что я слышу лишь визги фанбоев Растишки с криками «вы всё врёти».

fixed

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

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

... чтоб постить на бложики

Только тогда можно говорить с человеком о чем-то.

Прямо на бложике!

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

Ну да =) Рад, что вы заметили. Прочитайте тред вверх.

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

А вот утверждение про ненужность С и С++ — абсурдны. Вот ваш resvg использует Qt-овый бэкэнд. И предоставляет С API. Были бы те 2 языка ненужны и был бы Раст самодостаточен, вы бы такой фигней не страдали бы.

А про пресловутую безопасность я мозел уже на языке натер: ее можно достичь в любом языке. Проблема в том, что начинающий С++ программист без поддержки старшего коллеги в С++ наворотит делов. А про Раст, как бы его не пиарили, нет еще статистических данных и нормальной базы кода, чтоб говорить о 100% безопасности. Вы сами признали, что у языка рожденного в 2015 (?) не может таких данных просто физически быть.

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

завезите в студию крупный, сложный, реально использующийся продукт, написанный на Расте

Как мерять «крупность, сложность»?

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

Вы серьезно? Самая простая метрика: кило-линии кода. Другая но тоже простая: кол-во комитов и количество комитеров. Потом еще количество мажорных релизов (т.к. каждый такой релиз свидетельствует об эволюции продукта). Кол-во минорных релизов и патчей - показатель поддержки.

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

Как мерять «крупность, сложность»?

Вы серьезно? Самая простая метрика: кило-линии кода.

Это «крупность». Со скольки kLOC начинается «крупный»?

Другая но тоже простая: кол-во комитов и количество комитеров.

Тот же вопрос - со скольки начинается «крупный»?

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

Ну вот вам пример самого известного и крупного проекта, причем не на С++, а на С, который довольно-таки memory-safe: https://www.kernel.org/

Далее: https://www.chromium.org/ и закончим игровой индустрией: https://github.com/EpicGames/UnrealEngine

Можете взять еще V8. Хотя бы что-нибудь из написанного на Расте сравниться с этими проектами?

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

Между «крупностью» и «сложностью» прямая связь. Код сложен обычно не потому, что он делает запредельные вещи, а потому что этих вещей слишком много и кода слишком много и редко кто знает всю систему и весь код в целом.

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

А вот утверждение про ненужность С и С++ — абсурдны.

Конечно. Но начинать новые проекты на C/C++, если это не суровый энтерпрайз, - как минимум странно.

был бы Раст самодостаточен

Наличие либ не имеет ни какого отношения к самому языку.

чтоб говорить о 100% безопасности

Никто и не говорит.

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

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

Вон в лисе уже пол ляма строк на расте.

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

Но начинать новые проекты на C/C++, если это не суровый энтерпрайз, - как минимум странно.

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

Мне кажется, что мы говорим тут о разных вещах. Вы, поправьте если я не прав, подходите с точки зрения независимого разработчика из среды open source. Я же вам рассказываю как на Раст смотрят корпорации и продуктовые компании. К стати, чистые стартапы сейчас иногда выбирают Раст, на сколько мне известно.

В корпоративном мире, обычно, сперва идентифицируют проблему, потом ищут как ее решить. Т.е. Раст если и завозят, то под соусом таким: Раст решит нам такие-то проблемы. Поэтому, его не завозят на новый проект, а потихоньку добавляют в существующий.

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

Вопрос не бредовый. Меряют яблоки к яблокам. Вы же меряете Раст по отношению к другим языкам?

В лисе на Расте написаны только СSS стили, которые туда с Servo перекочевали. При этом они у меня пару раз крешанули на OS X. И они заметно замедлили время старта лисы, когда впервые вышли в релиз.

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

Вообще, меня вся эта дискуссия утомила. Всем хорошего дня, г-да.

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

который довольно-таки memory-safe: https://www.kernel.org/

После приведенного выше линка на взлом Bluetooth, это особенно смешная шутка.

Хотя бы что-нибудь из написанного на Расте сравниться с этими проектами?

Сравниться может Servo, тупо потому, что его начали писать задолго до официального релиза Rust. Но он не подходит по критерию «реальной используемости». Так что если ты не согласен на меньшее - значит, проектов, удовлетворяющих твоим критериям, пока нет.

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

«утёк» - вышел из области видимости без явного вызова close()

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

Я чёрным по белому написать «энтерпрайз», а вы опять накатали простыню.

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

суровый энтерпрайз

Суровый энтерпрайз на плюсах не писали практически никогда - там кобол/abap/одинэс/жаба/решетка во все поля (в примерном порядке развития отрасли). Энтерпрайз - это область коммерческого софтостроения, задача которой баблишко и с ним связанное подсчитывать и софт там пишут в основном люди, которые хорошо знают как баблишко считать, а как правильно программировать не очень.

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

И пишется на крестах по одной-единственной причине - быстродействие и вытекающего из него UX.

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

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

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