LINUX.ORG.RU

Релиз языка программирования Rust 1.39

 ,


1

8

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

Что нового в версии 1.39:

  • стабилизирован новый синтаксис асинхронного программирования, основанный на функции «async», блоке async move { … } и операторе «.await»;
  • разрешено указание атрибутов при определении параметров функций, замыканий и указателей на функции. Поддерживаются атрибуты условной компиляции (cfg, cfg_attr), управляющие диагностикой через lint и вспомогательные атрибуты вызова макросов;
  • стабилизирован «#feature(bind_by_move_pattern_guards)», который позволяет использовать переменные с типом привязки «by-move» в шаблонах;
  • предупреждения о проблемах при проверке заимствования переменных c использованием NLL переведены в разряд фатальных ошибок;
  • в пакетный менеджер cargo добавлена возможность использования расширения «.toml» для файлов конфигурации.

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

>>> Источник

★★★★★

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

Предлагаю внести изменение в движок ЛОРа. Есть есть тег «программирование», а количество комментариев превысило 800 в первый же день, то заменить все комментарии на Fffuuu Rage Guy. Потому что почти любая тема про Rust, шарп, Java или JavaScript - такая.

ZenitharChampion ★★★★★
()

Местная цпп-порватка знатно бомбит от раста. И это хорошо :) Просто потому что асинхронщина в убогом цпп настолько кривая, что ее никто не использует. Либо пишут все сами, но тогда у нас возникает сферический цпп_даун всгда_пишу_без_ошибок.

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

кроме, наверное, единственного исключения: python-tk

Нет, там точно так же нужно менять виджеты в главном потоке. Инфа 100%.

Queue и tk.after как раз и придуманы для того чтобы дополнительные потоки могли общаться с GUI потоком и слать сообщения какой виджет нужно изменить….

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

кроме, наверное, единственного исключения: python-tk

Нет, там точно так же нужно менять виджеты в главном потоке. Инфа 100%.

Нифига. В python-tk можно легко менять гуй в другом потоке:

from Tkinter import Tk, Label
import threading, time

def another_thread():
    for i in range(5):
        time.sleep(1)
        label['text'] += ' ho'
    label.quit()

root = Tk()
label = Label(root, text='Hello')
label.pack()

threading.Thread(target = another_thread).start()
root.mainloop()
И это python 2.7, а не какая-то супер-новая фича.

Пусть GTK/Qt-шники завидуют!

anonymous
()

мультипарадигмальный

Брррр… Раньше на ЛОРе писали «мультипарадигменный», а оказалось, это ещё не дно…

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

Ещё раз, точно так же я могу написать и в Qt, и в Java Swing, и это даже будет работать на первый взгляд, но это баг. Точно такой же как и в python tkinter.

Вот тип даже отдельный проект создал, чтобы вызывать tk функции не из главного потока:

https://github.com/abarnert/mttkinter

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

Вот ещё что нашёл:

https://bugs.python.org/issue11077

https://stackoverflow.com/questions/54237067/how-to-make-tkinter-gui-thread-safe

https://stackoverflow.com/questions/13753545/tkinter-freeze-on-grid-remove/13753865#13753865

Судя по ссылкам нет единого мнения, thread-safe tkinter или нет…

Тут тоже ничего не написано: https://docs.python.org/3/library/tkinter.html

:(

Продолжу писать с Queue и обработчиком GUI в tk.after в главном потоке…

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

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

anonymous
()

А я не понимаю почему rust так уязвляет сишников и плюсовиков. Казалось бы придумали язык лучше, чем C++, так это же, во-первых, прекрасно, а, во-вторых, естественно — прогресс не стоит на месте. Так нет же, ворчат, недовольны чем-то. Почему?

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

так он не лучше.

Тогда вопрос «почему?» возникает с новой силой.

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

Казалось бы придумали язык лучше, чем C++,

Просто сравни, например,

https://github.com/gtk-rs/gtk/blob/master/src/auto/combo_box.rs

и

https://github.com/GNOME/gtkmm/blob/mainline/gtk/src/combobox.ccg

То, что лучше «на бумаге», на практике может представлять лютый п%ц.

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

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

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

Ещё раз, точно так же я могу написать и в Qt, и в Java Swing, и это даже будет работать на первый взгляд

Не, обычно, если сделать так из другого потока, то получишь ошибку. А вот вот именно в python-tk так можно.

но это баг.

И в чём тут баг? Предложи пример кода, который будет выдавать ошибку, падать или ещё как-то некорректно работать из-за многопоточности. В смысле, откуда ты знаешь, что python-tk нельзя использовать из других потоков?

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

По поводу костылей - чини методичку. Корутины со стеком были всегда. Юзаются они ещё проще - никаких мусорных кейвордов. Костыли - это кейворды.

У тебя кресты головного мозга.

Видишь ли, если что-то сделано в C++, то ты можешь не глядя предполагать, что сделано через жопу. Такова судьбина крестов, они от начала до конца являются дизайнерской катастрофой. С одной стороны они хотят быть кроссплатформенным ассемблером, с другой - чем-то настолько же высокоуровневым, как какой-нибудь хаскель. Вот взять работу с параметрами функций, в этом моменте кресты более абстрагированы от железа чем Java. В последней программист, передавая что-то сложное в функцию или принимая что-то сложное в качестве параметра, должен понимать что такое указатель, в крестах это необязательно, добрый дядя Страуструп позаботился, чтоб начинающий программист не заморачивался разницей между параметром типа int и std::string. Из-за этой дури потом 15 лет каждый фреймвёрк колхозил собственную реализацию COW-строк, а разработчики языка занимались церебральным сексом с р-валуе ссылками и std::move. Корутины из той же серии, давайте сделаем чтоб работало не глядя, без всяких этих ваших кейвордов, а насколько это оправдано, насколько эффективно - плевать, чего-нибудь наколхозим.

Сабж, с другой стороны, делают люди умные. Когда-то давно они хотели запилить зелёные потоки, они даже работали в альфе, но потом люди посмотрели, подумали, да и выкинули нахрен эти потоки, типа давайте сделаем вменяемый низкоуровневый язык, а для удобной асинхронщины чего-нибудь придумаем. Вот, сейчас придумали. Оно не работает путём копипаста синхронного исходника внутрь асинк-функции, но зато сделано по-человечески.

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

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

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

У тебя кресты головного мозга. … итд

По-моему вы плохо понимаете о чём говорите.

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

Любой программист с++ прекрасно понимает когда можно/нужно использовать тот или иной вариант.

cawa
()

Hello, World’ы на Rust, ToDo LIST на Node.js, бложики на Ruby, нормальное ПО - на C# и Java, нормально, так устроен мир.

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

Раньше на ЛОРе писали «мультипарадигменный», а оказалось, это ещё не дно…

Научите, как правильно

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

А я не понимаю почему rust так уязвляет сишников и плюсовиков.

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

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

Напомните причины малого количества вакансий.

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

Возраст ЯП сопоставим с ГОшкой.

у go сегодня юбилей https://blog.golang.org/10years
и за этим яп стоит богатейшая корпорация гугл, в то время как основателю раста приходится полный рабочий день разрабатывать swift, чтобы заработать денег на проживание

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

Сдаётся мне там не проблема языка.
Раст не гарантирует от говнокода.

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

Жуть! Пусть те, кто говорит, что руст лучше, прокомментируют.

ЭТО ДРУГОЕ! И вообще, C++ негров линчует.

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

Жуть! Пусть те, кто говорит, что руст лучше, прокомментируют.

А что тут комментировать? Открываем растовский файл и читаем первые 3 строчки

// This file was generated by gir (https://github.com/gtk-rs/gir)
// from gir-files (https://github.com/gtk-rs/gir-files)
// DO NOT EDIT
Marvel
()
Ответ на: комментарий от Marvel

А что тут комментировать? Открываем растовский файл и читаем первые 3 строчки

А.... Ну тогда ты точно сможешь упростить такое:

    fn connect_format_entry_text<F: Fn(&Self, &str) -> String + 'static>(
        &self,
        f: F,
    ) -> SignalHandlerId {
        unsafe extern "C" fn format_entry_text_trampoline<P, F: Fn(&P, &str) -> String + 'static>(
            this: *mut gtk_sys::GtkComboBox,
            path: *mut libc::c_char,
            f: glib_sys::gpointer,
        ) -> *mut libc::c_char
        where
            P: IsA<ComboBox>,
        {
            let f: &F = &*(f as *const F);
            f(
                &ComboBox::from_glib_borrow(this).unsafe_cast(),
                &GString::from_glib_borrow(path),
            )
            .to_glib_full()
        }
        unsafe {
            let f: Box_<F> = Box_::new(f);
            connect_raw(
                self.as_ptr() as *mut _,
                b"format-entry-text\0".as_ptr() as *const _,
                Some(transmute(format_entry_text_trampoline::<Self, F> as usize)),
                Box_::into_raw(f),
            )
        }
    }

А еще убрать огромное кол-во кода из-за отсутcтвия в Rust наследования реализации.

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

Ага, если бы. Нет.

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

По поводу асинхронщины на сишке десятки лет назад. Может я напишу бред, но хочу высказаться. Давным-давно можно сделать printf(«Hello World.»);. Вроде банальщина. Но если смотреть «под капот». printf - запись массива байт в stdout, который имеет интерфейс файла (и может как раз являться файлом). Значит, вся работа с stdin, stdout, stderr сводится к «прочитать файл, записать в файл». В самом банальном случае файлы хранятся не в астрале, а на конкретном железе, а именно hdd (про ssd пока умолчим, ибо они не были мейнстримом 30 лет назад, а контекст как раз про сишку десятки лет назад). Работа с hdd идёт через файловую систему, которая в свою очередь работает с драйвером диска. Надеюсь всем известно, что оперативная память быстрее hdd? Так вот, printf, который по сути запись в файл, сводится к «послать сообщение драйверу запиши этот массив байт в этот файл, await ответа от драйвера, что он выполнил задачу или выбросил одну из возможных ошибок, и после эвэйта возвращать управление вызывающему коду». И да, вместо зависания на ожидании ответа от драйвера выполняется другой код (зависит от шедулера). Это справедливо для любой ОС, написанной на си, которая не встаёт раком (не зависает намертво) при каждом копировании любого файла. Да даже редокс, которая работает без самого распоследнего раста и не виснет от каждой io операции эти проблемы давным-давно как-то решили. (Моё предположение, не утверждение).

Это получается, что ЛЮБОЙ хелловорлд на любом ЯП вызывает условный printf, который «под капотом» асинхронно общается с драйвером медленного hdd и после эвэйта возвращается в условную main.

Очень важно заметить, что await там на уровне семантики, а не синтаксиса или названий функций. Чтобы не блеять типа «я сделал Ctrl+F по сишным исходникам и не нашёл await, значит нет на сишке нормальной асинхронщины».

Вроде как этот примитивный функционал был ещё в самых первых юниксах. Значит, на си решили море прикладных проблем, в том числе семантику async-await ещё ДО ТОГО, как сишка распространилась за пределы AT&T.

arturianec100
()

Судя по бомбажу у адептов няшной сишечки - хороший язык.

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

Любой программист с++ прекрасно понимает когда можно/нужно использовать тот или иной вариант.

И прекрасно понимает, что это всё нужно держать в голове. Иначе получим лишние (дорогие) копирования, use-after-free, use-after-move, etc. В rust копирование всегда явное, а жизнь ссылки проверяется на этапе компиляции.

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

Придумал аксиому - сам поверил.

А я не понимаю почему rust так уязвляет сишников и плюсовиков.

Нас не уязвляет сам язык. Нас раздражаюи идиоты, которые кричат на каждом углу «c - говно», «c++ - говно», «используйте rust вместо них» и т.п.

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

Нас раздражаюи идиоты, которые кричат на каждом углу «c - говно», «c++ - говно»

Почему сразу идиоты? C/C++ действительно говно. Или у вас есть аргументы использовать 40-летний шлак?

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

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

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

отдельный синтаксис для асинхронщины

Не очень понимаю что ты хотел спросить.. Отдельный синтаксис для «зелёных нитей» а если ты хочешь чтоб ОС решела вопросы потоков то просто делаешь tread::spawn

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

async-await лапша должна в state machine разворачиваться

Так и есть

У русских растоманов даже отдельный чат, посвящённый обсуждению вопросов по асинхронному фреймворку Tokio и библиотеке futures

https://t.me/rust_async

Тут 200+ человек, В общем русском раст чате на данный момент 1600 человек

incker
()

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

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

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

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

Сам туда иди. Только и делаешь заявления на пару слов без единого обоснования.

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

Ну на самом деле там из зелёных нитей был mio, потом tokio.. теперь выкатили async-std.. и по идее есть и другие реализации зелёных нитей. Просто официальная вот только выкатилась.. хотя tokio уже прижилось у всех.

Я понял, ты придраться к слову «новый» Ну как бы его не было)) поэтому новый

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