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

Растишишку

Хипстота драная.

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

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

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

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

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

кроме, наверное, единственного исключения: 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()

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

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

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

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

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

https://github.com/abarnert/mttkinter

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

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 в главном потоке…

https://codebabes.com/

обнажённые в полный рост

4.2. :(

Самый топовый язык на сегодня.

Особенно если посмотреть по количеству вакансий.

Так там же по списку курсов, грубо говоря, hello worldы. Или это не полный список курсов?)

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

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

Годная альтернатива

http://codedicks.com/

Почему?

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

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

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

Казалось бы придумали язык лучше, чем 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

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

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

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

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

но это баг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

верхуай залогинься

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

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

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

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

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

а сейчас где? на винде? )) тогда дерзай, останавливать не буду

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

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

и

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

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

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

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

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

А что тут комментировать? Открываем растовский файл и читаем первые 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

хитрые растишки, не стали ковыряться в шлаке, а просто сгенерели биндинги тулзой
а ещё есть такое https://c2rust.com/ https://github.com/immunant/c2rust/

А что тут комментировать? Открываем растовский файл и читаем первые 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 наследования реализации.

По ссылке не ходил, но всё равно фу.

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

А обоснования где? В википедии указаны даты релизов обоих языков. И сегодня разница между этими датами не такая уж и большая. Иначе приводи обоснования почему это не показатель и что является показателем. На 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.

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

Синдром утёнка. Тут пол лора таких.

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

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

Ну тут только в морг.

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

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

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

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

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

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

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

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

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

Так и есть

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

https://t.me/rust_async

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

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

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

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

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

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