LINUX.ORG.RU

Требуется помощь в тестировании Rust 2018

 


2

4

В июле этого года начались обсуждения вокруг Rust 2018. Вкратце, запускается цикл долгосрочных этапов, называемых «Выпусками», вокруг которых, в рамках обычных 6-недельных циклов разработки, будут сосредоточены все улучшения и работы: в библиотеках, инструментах и документации Rust. Новые выпуски будут выходить примерно раз в три года: Rust 1.0 был выпуском «Rust 2015», а предстоящий Rust 1.31 будет выпуском «Rust 2018». Каждому выпуску посвящён свой предмет: в Rust 2015 — это была стабильность, в Rust 2018 — это продуктивность.

Rust 2018 уже тестируется некоторое время, и всё выглядит довольно неплохо. До следующей стабильной версии Rust 1.31 ещё есть 6 недель, в связи с чем, разработчики просят попробовать бета-версию.

Есть два способа попробовать Rust 2018: обновить текущий проект, или начать новый. Подробная информация есть в руководстве по выпуску, ниже же приведена быстрая и упрощенная версия.

Разработчики просят сообщать им о всех проблемах, которые возникнут у вас во время тестирования.

Прежде всего, вам надо установить бета-версию Rust из соответствующего канала:

$ rustup install beta

Чтобы использовать бета-версию, вы должны добавить +beta к командам rustc или cargo:

$ rustc +beta --version
$ cargo +beta build

Это позволит вам оставаться на стабильной версии, используя бету только для экспериментов.

Новый проект Rust 2018 начинается следующим образом:

$ cargo +beta new my-sample-project

При этом в файле Cargo.toml добавляется новая опция edition = "2018" (отсутствие данной опции равнозначно наличию опции edition = "2015"):

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

[dependencies]

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

Для начала надо запустить:

$ cargo fix --edition  

Это проверит ваш код и автоматически исправит любые проблемы, которые получится; для тех, что не получилось, в консоли будет напечатано соответствующее предупреждение - для них вам надо обновить код вручную. Каждый раз, исправляя код, запускайте cargo fix --edition, пока у вас не останется предупреждений. В конце, вы получите код, который будет совместим как c Rust 2015, так и с Rust 2018. После, вам остаётся только обновить файл Cargo.toml и добавить туда строчку edition = "2018":

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

[dependencies]

и запустить cargo +beta build

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

★★★★★

Проверено: jollheef ()

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

компилятор сам кордамп свой в багтрекер слать будет?

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

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

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

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

Нормальный синтаксис. Ну, может, плотноват слегка и непривычен поначалу. А теперь, после Rust, я на Java-подобный код смотреть не могу: кажется, что это не программа, а скучное многабуквенное описание. Чтобы распарсить, приходится еще и звуковой центр в мозге напрягать. А Rust-иерогливы сразу мапятся на образы языковых конструкций в памяти.

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

Если jvm уже есть в проекте (ну типа андроид), то добавляется совсем мелочь. Иначе можно посмотреть в сторону kotlin native, хотя моё мнение заключается в том, что котлин - язык, спроектированный для jvm, запускать его под другие платформы есть смысл только если хочется пошарить код между платформами. Они работают над этим, но еще рановато. Так же само раст нет смысла запускать в веб, если для этого нет веских причин.

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

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

Синтаксис у успешных языков программирования целесообразен и приспособлен к их назначению. Поэтому чтобы оценить его, надо немного поизучать язык. Это относится и к Rust, и к Java.

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

Ну сравнили котлету с гавном. Rust - попытка создать молодежный, удобный и надежный язык, в чем-то успешная, Java - очередной С++ с выпиленными сложными и опасными фишками. Да, выбирать между rust и kotlin следует исходя из требований к производительности, а не по красоте, но мы же пока про синтаксис говорим.

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

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

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

Оба описания неправильные, так как не учитывают, что было добавлено.

В Java были добавлены возможности, нужные для сложных серверных приложений. А именно, использование JVM и одиночного наследования с интерфейсами. Дурачки из числа программирующих на C++ восприняли это как упрощение по сравнению с множественные наследование в C++. На самом деле это средство создавать приложения из компонентов (связанных иниерфейсами). В C++ можно применить вместо этого абстрактные виртуальные классы Но только для своих компонентов. А всякая сложная программа включает и чужие, и такие казалось бы бОльшие возможности наследования в С++ не позволяют добиться разнообразия в связывания компонентов.

В результате Java вытеснил C++ в той области, для которой пр5дназначен.

Для программирования на основе компонент оказались полезны модули - файлы кода, которые описывают связи между другими файлами кода. Поэтому они были задним числом добавлены в Fortran, в Java (начиная с JDK 9), в Rust существуют с самого начала, а в C++ их нет.

В общем, я такое явление нкоднократно наблюдал: тупой плюсобыдлокодер воспринимает сложность C++ как преимущество, а себя считает программистом высокой квалификации только от того, что освоил его (даже если не знает ничего другого).

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

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

Rust слишком напряжный. Он для своей ниши, куда мало кто попрет. Я он сомневаюсь, стоит ли на нем писать даже игровой движек. Думаю для большинства лучше всего было бы написать что-то вроде swift, взять лучшее от Java/C#/*ml и сделать его нативно исполняемым и с доступом к низкому уровню. Ну и забавно бы попробовать взять наработки раста про scope и ненавязчиво добавить в более user-friendly язык, так чтоб они там не мешались под ногами. Типа опциональный ownership и GC по дефолту.

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

Rust слишком напряжный.

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

Ну и у нас в России почему-то все больны страхом принятия нововведений. Не принятие НТП - это реальная проблема.

По Rust есть только вопрос в том, что библиотек для RAD пока не хватает, но он уже выстрелил как язык. А после Rust 2018 станет более умным и читаемым, гуглить хотя бы про NLL.

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

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

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

либо не понимает чего же я хочу, либо не разрешает мне делать то, что на самом деле абсолютно безопасно

Если компилятор не может быть уверен на 100%, что ты что-то делаешь безопасно, то он перестрахуется. Но со временем компилятор становиться умнее и таких мест становиться меньше.

А раст могли бы написать нормально...

Его до сих пор пишут так то, не всё сразу

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

А раст могли бы написать нормально...

Ну напишите что ли нормально.

В хаскеле например больше всего бесит требование тотальности, когда программист обязуется

Меня в Haskell ничего не бесит. Я им не пользуюсь и уверен, что не буду ввиду его ненужности. Но возможно, ваша претензия несправедлива(если авторы Haskell разбираются в нём лучше, чем вы). Однако неправильно обсуждать Haskell в теме про Rust - сходства между ними очень мало.

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

Однако неправильно обсуждать Haskell в теме про Rust - сходства между ними очень мало.

Ну вообще-то расту многое досталось от haskell/sml, сколь сильно не отличались бы они по модели исполнения.

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

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

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

Потом, когда шеф дал добро на проект, хуяк-хуяк и в продакшон, надо херачить новые фичи, закрывать баги, «эээ... надо бы добавить типы...» - «чё? так клиентам и сказать, в релизе 10.0 добавлены декларации типов? ха-ха, бля, иди фичи пили».

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

MyPy

Первый раз слышу. У них же вроде был какойто другой проект статической компиляции питона. + Cython тоже про это. + Perl6 вроде должен был так уметь и даже лиспы пробовали подобное вводить. asmjs можно приплести, .. тысячи их короче. Только поздновато рыпаются, поезд мейнстрима уже ту-ту.

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

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

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

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

Потому что, или система типов должна полностью описывать проблемную область

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

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

Рассуждение длинное, это хорошо. Но ни о чём. Это не так хорошо.

В Rust есть базовые типы и возможность образовывать новые типы. Что ещё надо? Из вашего рассуждения непонятно.

Partisan ()