LINUX.ORG.RU

Rust 1.10

 ,


0

4

Анонсирована очередная версия языка программирования Rust 1.10, разрабатываемого Mozilla совместно с сообществом.

Улучшения компилятора:

  • Добавлен новый тип крейта cdylib, предназначенный для экспорта C API. Основные отличия от dylib:
    • отсутствие метаданных;
    • разрешено LTO;
    • все библиотеки должны быть статически слинкованы;
    • экспортируются лишь те символы, которые помечены как extern. Например:
      pub fn foo() {} // не экспортируется
      #[no_mangle] pub extern fn bar() {} // экспортируется
    Для сравнения: «hello world» cdylib занимает 7.2КБ, а dylib - 2.4МБ.
  • Добавлена поддержка платформ i586-unknown-linux-gnu, i686-unknown-linux-musl, и armv7-linux-androideabi;
  • Снижено потребление памяти на ~100МБ при проверке типов;
  • Ускорена проверка T: Sized на 15%;
  • Улучшена кодогенерация при #[derive(Copy, Clone)].

Изменения в стандартной библиотеке:

Breaking changes!

  • AtomicBool теперь преобразуется в bool, а не isize. Демонстрация:
    use std::sync::atomic::AtomicBool;
    use std::mem::transmute;
    
    fn main() {
        let foo: bool = unsafe { transmute(AtomicBool::new(true)) };
    }
    
    На старых версиях компилятора будет ошибка;
  • time::Duration::new теперь будет паниковать при переполнении;
  • String::truncate теперь будет паниковать чуть меньше;
  • Небольшое изменение поведения макросов на этапе их парсинга: из :ty и :path следует :block;
  • Исправлен баг, связанный с гигиеной макросов. Следующий код будет валидным в устаревших версиях компилятора:
    fn main() {
        let x = true;
        macro_rules! foo { () => {
            let x = 0;
            macro_rules! bar { () => {x} }
            let _: bool = bar!();
            //^ `bar!()` использует первый `x` (который bool),
            //| а должен использовать второй `x` (который i32).
        }}
        foo! {};
    }
  • Переименование платформ:
    • arm-unknown-linux-gnueabi => arm-unknown-linux-gnu;
    • arm-unknown-linux-gnueabihf => arm-unknown-linux-gnu;
    • armv7-unknown-linux-gnueabihf => armv7-unknown-linux-gnu.
    Другими словами, изменены target_env, применяемые в conditional compilation.

Изменения в менеджере зависимостей Cargo:

  • Добавлен флаг --force, -f для подкоманды cargo install, предназначенной для загрузки исходных текстов из crates.io, их компиляции и установки в каталог ~/.cargo/bin. Это нововведение теперь позволит писать:
    cargo install FOO -f
    вместо:
    cargo uninstall FOO
    cargo install FOO
    Однако всё еще невозможно узнать, а требуется ли обновление вообще?
  • Диагностические сообщения теперь отправляются в stderr, а не в stdout;
  • С помощью флагов cargo doc --bin и cargo doc --lib можно выбрать: генерировать html документацию для проекта-приложения src/main.rs или проекта-библиотеки src/lib.rs;
  • В конфигурационном файле Cargo.toml, который можно встретить в корневом каталоге каждого проекта, теперь можно указать, каким образом макрос panic!() будет завершать приложение: unwind (по умолчанию) или abort;
  • Добавлен флаг cargo --explain FOO, поведение которого идентично rustc --explain FOO: показывает документацию по номеру ошибки;
  • В черный список имен крейтов добавлены ключевые слова раста, такие как fn, unsafe, let и прочее.

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



Проверено: tailgunner ()
Последнее исправление: cetjs2 (всего исправлений: 6)

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

Но нужно признать, что Rust не облегчает жизнь С/С++ программистам

Какие твои доказательства?

Ну это же очевидно. Как Rust может облегчать жизнь тем, кто им не пользуется? А вот почему не пользуется - отдельный вопрос. Конечно, во-первых потому-что Rust еще молодой и малоизвестный. Во-вторых - таки непривычный синтаксис. Но это дело времени и привычки. В-третьих, и как по мне главное, у него достаточно высокий порог вхождения. Если во всяких С++, Java, Go, Python и пр. можно начинать говнокодить копипастом, и многое делается интуитивно по подобию в других языках, то Rust тебе сходу скажет - RTFM! Это большой плюс для языка, но и большой минус для его продвижения.

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

(условно) один проект из тысячи в одном месте

В среднем - минимум один из сотни. Что-то слишком условно, аж на порядок.

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

..Переписал, не благодари))

ты так говоришь, будто кто-то собирался тебя благодарить.

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

Как Rust может облегчать жизнь тем, кто им не пользуется?

Легко! Вот пишешь на С++, потом смотришь на раст и душа радуется, что может быть лучше.

Если во всяких С++, Java, Go, Python и пр. можно начинать говнокодить копипастом

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

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

Наверное. Хотя относительно «размеров» минуса можно поспорить. Мне всё-таки кажется, что достаточное ядро сообщества можно собрать среди опытных программистов, то есть, среди тех, кто «готов к сложностям», да и благодаря опыту разобраться им будет проще. Язык всё-таки не скриптовый, чтобы обещать любому, что он сможет писать после чтения двух страничного мануала. И если сумеет хоть небольшую нишу занять, то дальше будет проще в плане продвижения.

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

Ну это же очевидно.

Ага, только не то что ты написал. Язык молодой. Ломают совместимость в минорщине. Когда (и если) они это перестанут делать, его можно начинать использовать.

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

Этот пример показывает только отсутствие тернарного оператора. Что впрочем действительно странно.

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

В среднем - минимум один из сотни.

Статистику покажешь? Я припоминаю, что была информация с crates.io: 96% проектов не пришлось чинить при переходе с 1.0 до 1.5. Так может даже лучше получится, ведь я говорил о поломках между каждой новой версией. Правда более свежие данные искать лень, но если они есть, то с удовольствием посмотрю. А на результаты опроса не уверен, что есть смысл сильно ориентироваться.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от AUX
fn fac_recur(n: i32) ->i32 {
    if n <= 1 { 1 }
    else { n * fac_recur(n-1) }
}

И? На плюсах сильно лучше будет? Даже если с тернарным оператором в одну строку записать, то разница не велика:

if n <= 1 { 1 } else { n * fac_recur(n-1) }
return n <= 1 ? 1 : n * fac_recur(n-1);
Причём, как по мне, лучше иметь в языке одну конструкцию, чем две «почти одинаковых». И это реально главная претензия?

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

Легко! Вот пишешь на С++, потом смотришь на раст и душа радуется, что может быть лучше.

Это скорее должно вгонять в депрессию :)

Вот как раз в плюсах говнокодить копипастом опасно

А это отдельная история про то, откуда берутся плюсохейтеры.

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

Что впрочем действительно странно.

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

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

А это не важно. Важно, что изменение логики работы. Значит кого будет ломать. Там не все баги компилятора.

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

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

В чем именно?

А нет, почти признался:

FreeBSD сдала позиции именно из-за активного продвижения Linux

Вот только причины какие-то левые:

Если бы не было одного только RedHat, или в 1993 году FreeBSD уже существовал хотя бы пару лет, многое могло бы быть иначе.

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

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

(1...n).fold(1, Mul::mul)

Тогда уж:

fn fac(n: i32) -> i32 {
    (1...n).product()
}
Esper
()
Ответ на: комментарий от anonymous

Это скорее должно вгонять в депрессию :)

Если честно, то я не хейтер С++ и поэтому пишу на нём без мучений. Но на новые языки посмотреть всегда интересно, тем более, что лучшие вещи понемногу переходят и в «мейнстрим».

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

А на результаты опроса не уверен, что есть смысл сильно ориентироваться.

А я не уверен, что нет смысла ориентироваться.

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

Да

Ну тогда я за раст спокоен, если к нему есть только такие претензии.

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

А я не уверен, что нет смысла ориентироваться.

По остальным пунктам значит возражений нет. (:

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

DarkEld3r ★★★★★
()

все чудесатее и чудесатее
прийдется переучиваться

kto_tama ★★★★★
()

Это какой уже по счёту убийца С++? Плюсокапец то скоро или нет?

Breaking changes!

Во дела, я уж хотел предложить на нем ядро переписывать, а тут такое.

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

Там не все баги компилятора.

Ну да, там ещё пример с `transmute` (хотя его использование — гарантированное ССЗБ).
Разработчики перед изменением проверяют, сломает ли оно что-то на crates.io или нет.

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

Это скорее должно вгонять в депрессию :)

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

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

причины какие-то левые
или в 1993 году FreeBSD уже существовал хотя бы пару лет

Не про FreeBSD, но сам Торвальдс не считает подобные причины левыми:

«If 386BSD had been available when I started on Linux, Linux would probably never had happened.» (c).

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

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

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

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

Так можно и до лиспа докатиться.

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

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

Язык много чего «должен». Быть простым в плане изучения и использования и т.д. И не всё можно совместить. Как по мне, то от отдельного тернарного оператора пользы нет. Да, в некоторых случаях мы можем сэкономить аж пару символов (в примере выше - три), но в других случаях мы вынуждены сами скобки расставлять и тогда никакого выигрыша нет. Могу только порадоваться, что в этом моменте моё мнение и мнение разработчиков раста совпало.

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

Наследование когда впилят?

Вангую, что никогда.

Новая парадигма: наследование вредно!

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

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

Во-первых не пару, даже в примере выше ты специально добавил return, чтоб разница была меньше, но это неправильно т.к. сравнивать надо было именно выражения. Во-вторых дело не в символах, а в читабельности. Конструкция if/else внутри выражения - ужасна. И это объективно.

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

но это неправильно т.к. сравнивать надо было именно выражения.

С какой стати? Выше был пример функции, вот её тело и сравнивал.

Конструкция if/else внутри выражения - ужасна. И это объективно.

Ничуть.

Тем более, что если не стараться всё в одну строчку запихнуть, то мне однозначно больше вариант с if/else больше нравится. Особенно, если хочется иметь вложенные условия.

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

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

С какой стати? Выше был пример функции, вот её тело и сравнивал.
Тем более, что если не стараться всё в одну строчку запихнуть, то мне однозначно больше вариант с if/else больше нравится. Особенно, если хочется иметь вложенные условия.

Ок, напиши аналог:

let rowHeight = contentHeight + (hasHeader ? 50 : 20)
anonymous
()
Ответ на: комментарий от anonymous

Конструкция if/else внутри выражения - ужасна.

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

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

Зато имеем выигрыш в плане единообразия.

Я уже упоминал лисп, у него очень «популярный» синтаксис.

И учитывая как ты за символы зацепился, кажется, что других аргументов нет

Еще раз повторяю, символы меня не интересуют, меня интересует удобное чтение.

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

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

Тебе тоже задача записать выражение выше.

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

let rowHeight = contentHeight + (hasHeader ? 50 : 20)

let rowHeight = contentHeight + (if hasHeader {50} else {20});

В чем ужас - в непреодолимом синдроме утенка?

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

В чем ужас - в непреодолимом синдроме утенка?

В твоем случае - да. Ты же не пользуешься Rust, только мастурбируешь на него. Я хотя бы привел пример на Swift, который понемногу использую. И где, кстати, твоя запись тоже валидна, но не обязательна. А ты можешь считать, конечно, что раз тебе нельзя - то так и надо, а все просто не понимают.

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

В чем ужас - в непреодолимом синдроме утенка?

В твоем случае - да

А, ну окей.

Ты же не пользуешься Rust, только мастурбируешь на него

Меньше думай о мастурбации и больше - о вопросах, которые тебе задавали.

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

Я уже упоминал лисп, у него очень «популярный» синтаксис.

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

Еще раз повторяю, символы меня не интересуют, меня интересует удобное чтение.

Но ты продолжаешь считать это объективным фактором?.. Думаешь лисперы - это какой-то особый вид у которого генетическая склонность к скобкам? С++, Haskell, (любой) лисп - читаются очень по разному. И если иметь опыт только с каким-то одним языком, то все непохожие будут казаться чем-то диким и неестественным. Всё это вопрос привычки.

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

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

И?

И это один из моментов, почему людям не нравится код на Rust. Тут нет тернарного оператора, тут self надо всегда писать, там unwrap, тут match (вместо того как в Swift сделали), там T::new, тут Some, там нет перегрузки функций и даже с new надо писать:

color::new(s.color.red, s.color.green, s.color.blue, s.color.alpha)

И т.д. И в итоге код становится говном. И все аргументы защитников Rust - нам и так сойдет, это все не нужно.

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

Что, сам ниасилил придумать название переменным?

Что, уже научился гуглить? Рад за твой прогресс.

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

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

Взять Swift - у него синтаксис почти один в один с Rust. А читается он на порядок лучше. Значит дело не только в опыте, но и в умении сделать язык удобным.

anonymous
()

А нормальная IDE уже есть? С нормальной навигацией по коду. Или все еще надо плясать с бубном вокруг Sublime и плагинов?

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

Значит дело не только в опыте, но и в умении сделать язык удобным.

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

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

А нормальная IDE уже есть?

Тут практически никто из адептов Rust на нем не пишет. Так что просто смотри оф. доку, там есть варианты:

https://www.rust-lang.org/ides.html

П.С. tailgunner, иди лучше на Rust пробуй писать, тут все было нормально без тебя, это у тебя климакс крышу сносит.

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