LINUX.ORG.RU

Rust 1.9

 


0

3

Анонсирована очередная версия языка программирования Rust 1.9, разрабатываемого Mozilla совместно с сообществом. Примечательно то, что с момента релиза первого стабильного выпуска прошел 1 год.

Основные изменения:

  • Стабилизирован модуль std::panic, позволяющий перехватывать раскрутку стека. Соответствующие функции рекомендуется применять только в исключительных ситуациях, но никак не для эмуляции механизма try-catch.
  • Стабилизированы методы настройки TCP и UDP соединений; расширены возможности OsString, BTreeSet и HashSet; char может быть получен из UTF-16 последовательности; стабилизирована функция copy_from_slice(); появилась возможность работы с волатильными переменными с помощью read_volatile и write_volatile; сырые указатели обрели .as_ref() и .as_mut(), которые возвращают Option<&T>, где null будет представлен как None; в libcore для всех типов реализован Debug.
  • Разработчикам библиотек доступен атрибут #[deprecated], разрешающий компилятору слать предупреждения при использовании устаревшего API.
  • Специализация уже используется в ночном релизе и будет доступна в стабильном 1.11 через 3 месяца, но оптимизация .to_owned() и .to_string() таки попала в текущий стабильный выпуск.
  • Расширен список поддерживаемых платформ: mips-unknown-linux-musl, mipsel-unknown-linux-musl, i586-pc-windows-msvc.
  • Ускорено время компиляции монады с одинаковыми функциями.

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

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

Для кросс-компиляции подготовлен инструмент rustup, обеспечивающий тривиальное взаимодействие с каналами сборок компилятора (stable, beta, nightly), стандартными библиотеками и их документацией к различным операционным системам, а также обновление всего этого зоопарка одной командой.

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



Проверено: Falcon-peregrinus ()
Последнее исправление: shaiZaigh (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

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

мой код все равно будет чище, будет жрать меньше памяти и быстрее работать

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

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

Типичный разговор с макаками выглядит так

Давай пруфец ТИПИЧНОГО разговора.

Что касается Rust, то он таки позволяет отсрелить себе ногу

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

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

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

Выпустить приемлемую версию. Что бы не надо было срочно выгрызать что-либо.

Так и так вроде ж. В 1.10 депрекейтнут, в 2.0 выкинут.

Это еще бабушка надвое сказала. Постоянно что-то ломают в минорщине. Ну и для продакшена увеличение минорной версии не должно приводить к сообщениям об использовании устаревшего. Ибо маркетинг.

Смысл? У данного решении я вижу 2 недостатка: отсутствие флажка депрекейтед на интервале 1.10-2.0 приведёт к увеличению количества кода, использующего этот устаревший метод, а необходимость ждать 2 мажорных релиза до удаления откладывает плюшки от избавления от кривого API на несколько лет. Достоинств же вообще нет. Собственно, ради чего ждать мажорного релиза перед депрекейшеном? Чтоб у кого-то ворнинги при компиляции не выскочили?

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

Ээ... вообще-то нет. Все эти минорные/мажорные версии как раз и есть условность, пусть и удобная. Первичен как раз срок поддержки. Атрибут депрекейтед - это предупреждение о необходимости избавиться от этой зависимости, соответственно важно именно своевременность предупреждения, возможность подготовиться к исчезновению фичи.

А вот и нет. Условностями они не являются. Разработчик не ДОЛЖЕН следить за изменениями в языке. Ибо начал разрабатывать один. Продолжил другой. Поддерживает третий. И никто не знает какие фичи языка использовали. Когда в минорщине появляется предупреждение о устаревании просто забъют на него до перехода на версию 2. Тогда и будут разбираться.

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

Никак не противоречит идее с аппаратом Елизарова.

Зато противоречит идеи «кровавого тырпрайса».

Что касается Rust, то он таки позволяет отсрелить себе ногу

А не противоречит ли это идее «аппарата Елизарова»? Ещё о «сверхманевренности» чего-то расскажешь?

Бесполезный спор, впрочем.

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

Там отключаемый GC, так что заработает.

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

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

Это понятно. Я имел ввиду классическую трансляцию.

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

Дык я не про GC, а про работу с кучей, там где ее нет. Контейнеры не перепишут же.

PS: со встраиваемыми системами знаком посредственно - могу ошибаться.

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

А не противоречит ли это идее «аппарата Елизарова»?

Ну, аппарат Елизарова то же можно поломать.

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

Вот почему создатели Раста выбрали в качестве промежуточного представления не С/C++, а LLVM IR???

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

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

Почему не заработает? GC можно отключить, памяти не хватит? это не аргумент. Единственное чем архитектуры отличаются между собой это шириной int и endianness. И то и другое можно указать в настройках nim.

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

Если тебе очень нужна куча то ее можно сделать вручную на любой платформе. см реализацию из newlib

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

Дык я не про GC, а про работу с кучей, там где ее нет. Контейнеры не перепишут же.

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

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

Вот почему создатели Раста выбрали в качестве промежуточного представления не С/C++, а LLVM IR???

Выше гибкость и производительность компиляции?

Вон, сейчас они заканчивают MIR. Можно будет во что угодно транслировать. Только зачем?

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

Rust превращается в безопасный C++

Не превращается.

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

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

Вон, сейчас они заканчивают MIR. Можно будет во что угодно транслировать. Только зачем?

Ну прикинь:

1.Есть, наппример, z80 или 51микроконтроллер, для которого есть только sdcc, LLVM нет...
2.Есть такой замечательный Раст, которым можно транслировать в Си из этого самого МИРа...
3.Есть мартышки (например студенты или более взрослые быдлокодеры), 
которые не умеют во встраиваемые системы, а надо. Таким можно только нижние уровни дров писать 
(линейный императивный код без логики, или с очень ограниченным ее количеством).
4.Даем им Раст.
5.Они начинают писать не только нижние но и средние уровни (нулевой указатель-то не разыменуют уже).
6.??????
7.ФИРМВАРЬ!!!

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

то это несколько сомнительное преимущество.

Я отвечал на «мало чем отличается», а не на «какие преимущества».

вырвиглазный синтаксис

Вполне на уровне плюсов. Где-то лучше, где-то хуже.

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

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

(К счастью) я мало что знаю о маркетинге, зато знаю, что в минорных версиях компиляторов (даже компиляторов, а не языка! впрочем, для раста это пока одно и то же) могут появляться новые баги. И ничего с этим не сделать. Так что разводить панику из-за предупреждений как-то странно, на мой взгляд.

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

Разработчик не ДОЛЖЕН следить за изменениями в языке
Когда в минорщине появляется предупреждение о устаревании просто забъют на него до перехода на версию 2. Тогда и будут разбираться.

Как хорошо, что у меня другой опыт. По крайней мере, сейчас.

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

Наш 14-летний друг заявил, что Nim более переносимый, но не предъявил списка поддерживаемых архиьектур. У Rust он по крайней мере есть.

Откопай (если сможешь) список поддерживаемых архитектур для языка C и получишь список архитектур на которых можно запускать программы на nim.

И в чем вообще заключается «официальная поддержка» архитектуры для языка, который не генерирует машинный код? Это тоже самое как спросить у Java программиста, для какой архитектуры он компилирует свой код. Ответ: для всех, потому что джава будет работать везде где есть джава машина. Так и nim, будет работать везде где есть компилятор C.

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

Так и nim, будет работать везде где есть компилятор C.

Лапша маркетолухов.

Завтра окажется, что твоя архитектура не умеет в double и приехали. Ну или умеет, но непозволительно тормозит. И придётся подкручивать/переписывать свой «переносимый» код под неё.

Я не говорю, что в других языках это проще, чем в C. Но вот эти рассказы, что С работает везде - попахивает фанатизмом. Особенно с учетом наличия 100500 компиляторов, которые работают от немного, до сильно, по разному.

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

Откопай (если сможешь) список поддерживаемых архитектур для языка C и получишь список архитектур на которых можно запускать программы на nim.

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

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

Хотя с другой стороны, если человек пишет что-то вроде:

    if(beginnum!=0xFFFFFFFF)
    {
        while(begin!=end)
        {
            DWORD num;
            DWORD middle=(begin+end)/2;
            if(!ArcRead(middle,&Arc))return(false);
            num=Arc.NumRecord;
            if((num>beginnum)&&(num!=0xFFFFFFFF))
            {
                begin=middle;
                if(end!=begin)if(end-begin==1)
                    {
                        if(!ARC_ReadRecord(end,&Arc))return(false);
                        num=Arc.NumRecord;
                        if((num<beginnum)||(num==0xFFFFFFFF))end=begin;
                        if((num>beginnum)&&(num!=0xFFFFFFFF))begin=end;
/*И так далее*/

То Раст ему не очень то поможет...

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

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

Ес-но, в том числе и для С, и для С++, и для Rust это так, но если ее не реализовать на, например, Win32, то и заявлять о поддержке этой платформы нет смысла.

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

Я не говорил что код не потребует изменений, это ведь не джава. Нету float и double - не используй их в коде на nim и он не будет использовать их в коде на C. В этом и отличие от rust, где твоя архитектура должна во-первых поддерживаться LLVM а во-вторых самим компилятором rust.

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

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

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

Все различия должны покрываться стандартом

Ага. Знаем мы эти стандарты. Любой стандарт не реализован везде одинакового. Меня наоборот радует, что у раст один компилятор и от самих авторов. А то боль переноса проекта с gcc на msvs - это просто сказка. И это самые популярные компиляторы. Про остальные вообще молчу.

Нету float и double - не используй их в коде на nim

То есть сразу выбрасываем всю стандартную библиотеку? Вон в раст пилят libcore, в котором даже float не будет.

твоя архитектура должна во-первых поддерживаться LLVM

С этим проблем нет:

% llc --version
LLVM (http://llvm.org/):
  LLVM version 3.5.0
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: core-avx-i

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_be - AArch64 (big endian)
    arm        - ARM
    arm64      - AArch64 (little endian)
    arm64_be   - AArch64 (big endian)
    armeb      - ARM (big endian)
    cpp        - C++ backend
    hexagon    - Hexagon
    mips       - Mips
    mips64     - Mips64 [experimental]
    mips64el   - Mips64el [experimental]
    mipsel     - Mipsel
    msp430     - MSP430 [experimental]
    nvptx      - NVIDIA PTX 32-bit
    nvptx64    - NVIDIA PTX 64-bit
    ppc32      - PowerPC 32
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    r600       - AMD GPUs HD2XXX-HD6XXX
    sparc      - Sparc
    sparcv9    - Sparc V9
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
    xcore      - XCore

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

Коментарий ниочем. Какая мне разница какие архитектуры поддерживает LLVM если о них не знает rustc? Спор был о том какой язык более переносимый rust или nim и на данный момент ответ nim.

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

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

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

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

Но она при правильном подходе всегда не помешает и даже поможет в большинстве случаев.

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

Спор был о том какой язык более переносимый

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

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

Я отвечал на «мало чем отличается», а не на «какие преимущества».

Ok. Тогда просто поясню свою позицию по поводу обязательности проверки кодов возврата.

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

let _ = do_some_operation();
чем вот так:
do_some_operation();
а потом обнаруживать, что do_some_operation(), оказывается-то, возвращает какое-то важное значение, которое нужно было бы хорошо проверять. Грубо говоря, бывает, что кусок кода просто откуда-то к себе переносишь (из документации, например, или со stackoverflow) и не всегда точно знаешь все делали работы скопированного кода.

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

Вот, например, исключения позволяют записать что-то вроде:

auto r = postprocess(process(preprocess(take_data())));
А вот если каждая из этих функций возвращает Result<StageResult,Error>, то придется эту цепочки записывать несколько иначе и выразительность кода будет потеряна.

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

исключения позволяют записать что-то вроде

Быдлокод в кубе! Это еще хуже чем цепочки методов.

Одна строка - одно действие.

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

Ну так можно делать проект на нескольких языках:

HAL на С\С++, а дальше - высокоуровневый код на высокоуровневом языке.

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

Зачем писать много букаф, если можно сэкономить время\буквы\деньги?

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

Откопай (если сможешь) список поддерживаемых архитектур для языка C и получишь список архитектур на которых можно запускать программы на nim.

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

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

В заявлении core team «мы ожидаем, что сгенерированный компилятором код будет транслироваться и работать на $ARCH». Заявление core team, не анонимных экспертов ЛОР и не фанатов языка, узнавших о его существовании 17 часов назад.

тоже самое как спросить у Java программиста, для какой архитектуры он компилирует свой код. Ответ: для всех

Неверно. Он компилирует свой код для Java-машины.

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

У вас, кроме оскорблений

Просто для протокола: «быдлокод» - это такое же оскорбление, как и «если мозгов хватит». Так что либо не начинай, либо не ной.

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

Сужу на основании ваших высказываний о том, как вы программируете, что считаете приемлемым, а что ниасилили нет.

Eiffel далеко не так прост, как может показаться. Там нормальное ООП во все поля, а практика показывает, что в ООП умеют не только лишь все. Плюс в Eiffel-е есть исключения, хотя они и сильно не такие, как исключения в C++ или паники в Rust-е. Плюс Design-By-Contract, который выражается не только в пред- и постусловиях, но и в инвариантах (особенно в инвариантах циклов).

Ну а т.к. вы в C++ные исключения не можете, да и OOM для вас повод крешить все приложение, то высоки шансы, что планка Eiffel-я для вас окажется слишком высокой.

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

А вот если каждая из этих функций возвращает Result<StageResult,Error>, то придется эту цепочки записывать несколько иначе и выразительность кода будет потеряна.

Совершенно потеряна.

let r = postprocess(process(preprocess(take_data()?)?)?)?;

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

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

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

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

Но мне, это ничего не говорит о вас, как о программисте. Не считая фанатизма.

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

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

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

В других случаях альтернативные механизмы информирования об ошибках (будь то коды возврата (пусть даже в виде АлгТД) или errno, или panic-и) оказываются хуже. И, кроме того, эти механизмы плохо дружат с перегрузкой операторов, например.

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

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

В этом смысле идея Swift'а с опциональной последовательностью кажется лучше. Там лишь один раз нужно ? ставить.

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

Зашибись.

Уродливо же. Жаль, что приняли в такой форме.

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

Разный - это одна возвращает Result, а другая - SomethingFunny? Это не нужно.

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

А вот если каждая из этих функций возвращает Result<StageResult,Error>, то придется эту цепочки записывать несколько иначе и выразительность кода будет потеряна.

Ну да. Хотя если нас устроит просто вернуть Error, то вариант с .? не так уж сильно теряет в выразительности.

В целом я понимаю, что везде свои плюсы и минусы и исключения «однозначным злом» не считаю.

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