создавать надёжное и эффективное программное обеспечение
async/await наконец-то в стабильной версии!
https://www.rust-lang.org
Вместо шапки: https://gist.github.com/TatriX/183c816f1346d418f969c4576c2b9b41
Предыдущий тред: >>1602965 (OP) (OP)
> async/await наконец-то в стабильной версии!
Ну и сколько этой новости уже месяцев?
татрикс, откуда ты знаешь про Haxe?
Как сделать, чтобы compile buffer не скроллился в самый низ?
>Не, я как раз с сишки пришёл, понимаю, что это быстрее, но думал что для раста это менее важно.
Тут такая фишка, что эта фукнция - часть stdlib раста, а stdlib должна быть самым быстрым ковбоем или не быть такой огромной.
Что за либа, аноны?
Отличная вещь, я на ней клиента для тинькова написал.
Сразу дам пару советов:
1. Сразу пиши свой луп.
loop{ siv.step() -> твоя логика -> siv.refresh() }
в лупе работай с элементами через siv.find_name("el_name")
он возвращает Option, т.к. элемент может быть неактивен
2. Изнутри коллбэков этот сотона ничего не может видеть, если нужна связь с внешним миров в коллбэке, оберни его в структуру и просунь через siv.set_user_data(your_struct)
советую, так как сам довольно долго проебался, пытаясь обойтись дефолтным лупом с коллбэками.
Сейчас говнякаю на реакте, но хочется потрогать раст.
Нативно интегрирую https://seed-rs.org/
Просто в расте самый большой подводный камень, о котором надо знать, это ownership model (по-русски будет криво звучать), реализация базовых структур тебе позволит с этим ближе познакомиться.
>>1667169
>Хотя хотелось бы сделать простую апишку.
Если ты про rest, то пока не стоит, там много делов, лучше если захочешь на кошках потренироваться напиши клиента для гофера/dns -> затем асинхронную версию, но не на async сгенерированных future, а чисто имплементацией трейта. Короче я считаю в веб лезть пока не стоит, слишком много там делов.
Начинал с c++ билдера когда-то давно, а кончил джавой, но попиливаю свой личный проектик на расте (правда в основном там используется либа на c).
>Какие технологии пробовал по мере роста скилла?
Мм, на перле пробовал форум писать.
>>1667221
Ну типо его там и сям большие уже немного используют, в мозилле вообще целый web gpu пилят на ржаном-гречневом.
fn fun() -> i32 {
return return return return return return!!!!!!!111;
}
1 вернёт. Тут даже в нынешней версии нет UB и всегда возвращается целочисленное значение, которое ближе к нулю. А вот 1E20 as usize (на всех поддерживаемых архитектурах) уже UB, хотя скоро и это поправят: https://github.com/rust-lang/rust/pull/71269
Очевидно, что все ретёрны кроме последнего не имеют смысла. Дальше мы видим кучу битовых not вместе с унарными минусами. Очевидно, что N - 1 будет выполнен после унарных минусов и битовых not, поэтому пока просто забудем об этом.
нот-нот 111 => 111
--- 111 => -111
!(-111) => бля, я тебе калькулятор штоле, считать two's complement в голове, когда это не -1?
----- => -(!(-111))
! => !(-(!(-111))
Короче, пошёл на хуй. Ебал я такой хуетой заниматься, у меня проекты есть, которыми надо заниматься.
Эта залупа называется yay
https://github.com/Jguer/yay
Сделойте уже пул, хуйнул как написано и всё работает.
(defun rustic-compilation-setup-buffer (buf dir mode &optional no-mode-line)
"Prepare BUF for compilation process."
(let ((inhibit-read-only t))
(with-current-buffer buf
(erase-buffer)
(setq default-directory dir)
(funcall mode)
(if (or compilation-auto-jump-to-first-error
(eq compilation-scroll-output 'first-error))
(set (make-local-variable 'compilation-auto-jump-to-next) t))
(unless no-mode-line
(setq mode-line-process
'((:propertize ":%s" face compilation-mode-line-run)
compilation-mode-line-errors)))
(force-mode-line-update)
(sit-for 0))))
з
х
Десктоп наш? Почалось?
https://tauri.studio/en
>>1672985
Раст без borowck ни нужен, ну правда есть ещё секси енумы, макросы, комбинаторы по типу map_err и прочее для ошибок.
inb4 ряяяя ансейф
use std::ptr;
let mut buf = [0; LOG_BUFFER_LEN];
let mut p = buf.as_mut_ptr();
let end = p.offset(LOG_BUFFER_LEN as isize);
let mut data: const c_char = ptr::null();
let mut flags: c_int = 0;
let mut n = 0;
if ERR_peek_error() == 0 {
return;
}
loop {
n = ERR_peek_error_line_data(
ptr::null_mut(),
ptr::null_mut(),
&mut data as mut const _,
&mut flags,
);
if (n == 0) {
break;
}
if (p == end.offset(-1)) {
ERR_get_error();
continue;
}
ptr::write(p, b' ');
p = p.offset(1);
ERR_error_string_n(n, p as mut _, 10);
while p != end && p != 0 {
p = p.offset(1);
}
if p != end && data != 0 && flags & ERR_TXT_STRING != 0 {
ptr::write(p, b':');
p = p.offset(1);
let len = {
let data_len = libc::strlen(data);
let left = end.offset_from(p);
if left <= 0 {
0
} else {
data_len.min(left as usize)
}
};
std::intrinsics::copy_nonoverlapping(data, p as *mut _, len);
p = p.offset(len as isize);
}
ERR_get_error();
}
1. Наконец-то можно i32 + &i32 и так далее. Урра!
2. Какого-то хуя перестал работать мой собственный impl Drop
вот было, всё работало, отрабатывало по Ctrl+C, а потом перестало. Шо за нах это может быть? С обновлением напрямую не связано, работало уже после апдейта на 1.43, а сегодня с утра перестало.
> Раст без borowck ни нужен, ну правда есть ещё секси енумы, макросы, комбинаторы по типу map_err и прочее для ошибок.
Речь не о крутых фичах, а о фичах которых раньше не было. Так-то солянки из идей разных ЯП были и до раста (да и сейчас появляются как грибы, благо есть LLVM, который берёт самую сложную работу - генерачию машинного кода - на себя).
Впрочем и со временами жизни раст немного обосрался. А конкретно при даункасте структуры в трейт время жизни стирается (превращается в 'static) и из трейта его никак выковырять невозможно - оно указывается отдельно синтаксисом (impl|dyn) Trait + 'lifetime [1], но функции внутри трейта время жизни самого трейта никак узнать не могут. Из-за этой багофичи до сих пор не могут сделать специализацию.
[1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4f838cf43498f87425639fffb7efb60f
>специализация
Наверное не понимаю, что такое специализация. Но разве это не оно?
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=284e4b4dee802e9c8a1d552ba4ba172f
Не совсем. Специализация относится к функциям, а не объектам. Ты можешь определить функцию по-умолчанию и специализировать в зависимости от того какие трейты имплементируют аргументы функции, а в твоём случае функция выбирается в зависимости от типа объекта, а не от того какие трейты он имплементирует. Вот пример - есть трейты Clone и Copy. Если объект определил трейт Clone, то значит он может быть скопирован, но для этого надо всегда вызывать функцию clone, которая может делать нетривиальные операции (например увеличивать счётчик в случае умных указателей). А если объект определяет трейт Copy, то значит он может быть скопирован побайтовым копированием памяти. Со специализацией можно сделать дефолтную функцию, которая будет принимать все объекты с трейтом Clone и более быструю специализированную для тех кто ещё определил трейт Copy, чтобы использовать побайтовое копирования для ускорения кода.
Проблема в том, что в изначальном варианте хотели позволить специализировать не только по типам, но и по времени жизни. Но как оказалось трейты совершенно не знают о том какое у них время жизни и потому в подобной специализации можно используя безопасные конструкции языка превратить ссылку &'a с произвольным временем жизни в &'static - со временем жизни равным времени жизни программы.
Сейчас хотят сделать упрощённую версию без возможности специализировать время жизни, но и там есть свои проблемы.
Пишем. Торгового бота для себя и приложение камеры для ведроида. В заначке ещё пара проектов.
>2 пик
И эти люди называют С++ уродливым
Спасибо, блядь, сам нашёл.
https://github.com/rust-lang/miri
>dvach-02.webm
>rust - нвероятно быстрый язык для системного программирования
Объясните ньюфаундленду, если так важна скорость, зачем использовать какой-то хипстерский язык, почему бы не использовать Си или, упаси господи, ассемблер?
> постоянного времени исполнения
И что ты под этим понимаешь? Жосткий риалтайм? Так наоборот с высокоуровневым языком проще будет, потому что к нему можно будет написать анализатор, который тебе сразу выдаст время выполнение в худшем случае. А если про то что нужно именно чёткое время выполнения каждой инструкции, то с современными процессами с конвейером и прочими оптимизациями ты быстро соснёшь (ну и в случае мк не забываем про прерывания, которые тоже могут въебать детерминизм времени выполнения куска кода). Тут справятся только FPGA (ну или ASIC, если нужно массовое производство).
> Так наоборот с высокоуровневым языком проще будет, потому что к нему можно будет написать анализатор, который тебе сразу выдаст время выполнение в худшем случае.
К любому языку нельзя такой написать, кроме частных случаев когда программа совершенно линейная и выполняется в изоляции. А с высокоуровневым языком у тебя происходит больше скрытых вещей и меньше возможности на них влиять.
> К любому языку нельзя такой написать
Можно. Для этого функциональщики и придумали такие понятия как "чистота" функций и прочее. В расте уже подобное тоже сделали: https://github.com/rtfm-rs/cortex-m-rtfm (с оговоркой, что это не чистый раст, а растоподобный язык, который макросами преобразуется в раст).
Нужна либа для удобных assert'ов в тестах. Конкретно моя проблема, сравниваю два небольших буффера, равны по длине, но хочется, чтобы сразу показывало первую позицию по несовпадению, ну и чтобы вообще был вагон удобных ассертов для людей, а то стандартного ассерта таки маловато возможно будет в будущем. Чего посоветуете?
Означает время жизни. Может быть либо генерик-параметром у структуры (может означать разное, но зачастую означает что структура имеет ссылку со временем жизни равным этому параметру) либо относится к ссылке и означает что ссылка имеет это самое время жизни. Во всех случаях когда ты используешь ссылки ты используешь и времена жизни, просто зачастую компилятор их может вывести самостоятельно и потому тебе не обязательно давать им имена (апостроф нужен чтобы отличить их от параметров-типов).
https://www.reddit.com/r/rust/comments/gezz84/buttplug_sex_toy_control_project/
>Buttplug is an open-source standards and software project for controlling intimate hardware, including sex toys, fucking machines, electrostim hardware, and more.
log::set_logger(&LOGGER).unwrap();
есть отдельный поток - напрямую из него логирование ок.
В потоке идёт работа с методами некой структуры, которая находится в другом файле - и вот оттуда с логированием облом. Причём если запускаю методы из основного потока, то всё логируется. Как их подружить?
> Речь про динамически подключаемые библиотеки
Не, для динамических библиотек все будет норм работать.
>>1681174
Вообще без кода непонятно, в чем проблема. Но про CursiveLogger могу сказать, что он странный очень, я тоже на странную хуету натыкался. Юзай лучше https://github.com/deinstapel/cursive-flexi-logger-view , там таки под капотом нормальный логгер. И юзай эту либу с мастера, там есть аналог toggle_debug_view из Cursive.
Разобрался, там у меня был не работали вызовы, которые debug, т.к. я сам же их и отфильтровал, чтобы не видеть пикрил хуеты. Только я протупил и думал про них, что они warn.
Тогда след вопрос - как подавить дебаг выхлоп курсива, но видеть свой?
Rust analyzer тоже прекрасно работает
>>1682849
Не думаю, что со стандартным логгером там получится. А для flexi-logger там работает такой же синтаксис, как и для env-logger (типа RUST_LOG="cursive=error,yourlib=debug", не уверен, что точно так должно выглядеть).
3ий месяц к ряду пилю разные пет-проджекты - хайлоад-веб-бекенд, блокчейн-аппликуху на Exonum'e, n64 - эмулятор.
Просто охуенно. Плюсы кажутся дикой парашей после раста.
Были бы еще конст-дженерики и фулл-тайм проект, вообще бы спермой потолок пробил.
Вообще, в плане работы. Я так понял, если хочешь устроиться куда - дрочи блокчейн ? Ибо из реальных вакансий я видел только блокчейн всё ну и пару а-ля хайлоад серверов.
По работе пишу на свифте, для души подрачиваю раст, что именно тебя интересует в сравнении?
>if let
Эээ, ну init statement в if-е даже в 17-е плюсы завезли, это уже просто максимальный мэйнстрим которые есть везде (даже в последней версии питона, лол).
>общий разраб
Один из десятков разрабов общий, ты хотел сказать?
>Как у них там с bc?
С чем?
Вообще, хуй знает что сравнивать, они максимально разные. Из реально общего — несколько кейвордов. Мемори менеджмент — в расте завуалированный, но ручной, в свифте полностью автоматизированный (разве что в отличие от языков с GC приходится следить за цикличными ссылками). Дженерики — в расте полностью компайл-тайм, в свифте они компайл-тайм только в совсем простых случаях, а в не очень простых — джава-стайл рантайм. Коллекции — в расте можешь писать свои и вообще ты ни к чему не привязан, в свифте у тебя есть 3 вшитых в рантайм (array/map/set), а дальше ты либо идёшь нахуй, либо ебёшься (написать тото же двусвязный список на свифте, который при этом не будет лагать/течь как тварь — нихуя не легче чем на расте без unsafe, вот уж реально сходство). Парадигма — раст функциональный, а свифт ООП с кучей фич из ФП (как и любой современный хайлевел язык). Система модулей — в расте какой-то пиздец с притензией на плюсовые неймспейсы, дрочево на 2 экрана в каждом файле, в свифте — "import Foundation" и ты импортировал половину системных фреймворков. IDE — в расте блокнот с автокомплитом, не умеющим в генерики и нормальный error recovering, а в свифте из коробки ахуенная, хоть и багованная, full featured IDE со всем, что только может быть нужно. Сферы применения — в расте байтоёбля с миллисекундами, в свифте — клиентские приложения, где жс жирноват, сборка мусора слишком недетерменированно себя ведёт, но надо писать бизнес-логику и UI чтобы не лагало.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0aab1b53434e354e0fc59088ababf3c5
Всё было зашибись, но потом я решил, что неплохо бы выводить в stdout в том, случае если в аргументах программы пользователь не указан путь к файлу на диске. Но тут возникла проблема из-за мономорфизации, как-нибудь можно построить тип с маркером, который бы указывал, что привязка идёт к AsRawFd?
А ещё можно пойти работать в buttplug.io и писать чудесные программы на расте.
>>1683378
Я не знаю, почему сразу не допёр сделать вот так
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=72b776d67842eaa5a8cc77be40b81507
Наверное трейты для меня до сих пор - эльфийские технологии.
> FdBio<'a, T: 'a>
А тут точно T: 'a нужен? Оно означает что время жизни внутренностей T (нарпимер если внутри T есть ссылка на что-то) должно быть больше или равен 'a. При том при имплементации трейта у тебя стоит where T: AsRawFd, что является сокращением для T: AsRawFd + 'static (т.е. тут T либо не должен иметь ссылок внутри, либо все ссылки должны быть 'static). Это ошибок не вызывает, потому что T: 'static удовлетворяет требованию структуры к T: 'a (потому что 'static больше или равен любому 'a), но что-то явно не так. Либо убери требование T: 'a в структуре, либо добавь where T: AsRawFd + 'a в имплементацию.
>те, кто готов отдать свою свободу (с/с++), чтобы приобрести немного временной безопасности (раст), не заслуживают ни свободы, ни безопасности
Ты ничего не теряешь, просто проверки, которые в плюсах
отсутствуют, нужно отключать стеной из ансейфа.
Только забыть сделать проверку можно, а вот написать
.unwrap_or_else(|| unsafe { unreachable_unchecked()}) случайно - нет.
Он очень хорош, как первый язык программирования, потому что
1. Системный, без GC, так что учит тому, как работает память. Это не нужно всяким математикам, которые только proof of concept рисуют, и веб-макакам, но для любого другого программиста - очень полезно.
2. Учит видеть UB. Это просто охуеть как полезно. Примерно так же полезно, как строгая типизация (которая опять в хуй не упёрлась математикам и веб-макакам, которым вообще похуй, что там у юзера упадёт).
3. Best practices из мира крестов на уровне синтаксиса, а не "посоны, блет, ну мы же вам в 20 стандарте рекомендовали эту срань записывать в комменты к функции, ну почему всем поебать на советы".
Раст плох, если ты не собираешься становиться программистом. Раст - это не язык для школьников, которые не хотят учиться этому ебаному программированию; ты должен чётко понимать, что ты учишь и зачем ты учишь, потому что учить эту срань ты будешь охуеть как долго.
>Implementations in Rust
Вы официально закшварены.
> 1. Системный, без GC,
А в чём проблема гарбаж коллекторов? Вроде норм же, тычешь им куда-то, он освобождает память, можно не бояться утечек памяти... Или это лишние циклы процессора использует? Я не знаю правда что такое эти ваши собиратели мусора.
> 2. Учит видеть UB. Это просто охуеть как полезно.
А другие - нет?
> Примерно так же полезно, как строгая типизация
А что это такое?
> 3. Best practices из мира крестов на уровне синтаксиса
Скажу честно, я в этом не разбираюсь.
А вроде бы всё то же самое есть в Сишечке, кроме синтаксиса...
>>1682516
Ну ладно :/
А в чем заключается сложность, желательно простым языком?
>>1682544
> Не, у тебя задача не та, тебе раст нахуй не нужон.
А какая у меня задача вообще? Научиться писать алгоритмы?
>>1682491-кун
>Научиться писать алгоритмы?
У тебя нет задачи их писать, твоя задача разобраться, чем ты хочешь вообще заниматься, то есть выбрать область, которая твоя, а для этого тебе раст не нужен. Если в итоге захочешь заниматься системным программированием, то изучай Си - lingua franca в мире программирования, а в раст закатывайся только тогда, когда сам уже для себя всё решишь, ну или если пойдёшь работать в buttplug.io мозиллу.
>А в чём проблема гарбаж коллекторов?
Они работают с памятью неявно.
>> 2. Учит видеть UB. Это просто охуеть как полезно.
>А другие - нет?
Нет, не учат (C, C++, lua, и ещё куче других языков тупо срать, будет UB в коде или нет).
>> Примерно так же полезно, как строгая типизация
>А что это такое?
Гугли.
>Скажу честно, я в этом не разбираюсь.
>А вроде бы всё то же самое есть в Сишечке, кроме синтаксиса...
Нет. Как минимум, у растосообщества есть нормальный Code of Conduct.
Если не разбираешься, то чего споришь? А если разбираешься и троллишь так, то пойди на хуй, пожалуйста.
А с вэбом почему, мне так проще вкатываться в язык, начиная с простых проектов.
let res = core::mul_mat_mat(&mat1, &mat2)?.to_mat()?;
На с++ это было бы что-то типа auto res=mat1*mat2;
Правильно ли я понимаю, что Result как универсальный вариант хэндлинга ошибок делает перегрузку оператора, который может возвращать ошибку, невозможной, и, как следствие, бесполезной для околоматематических задач?
>Правильно ли я понимаю, что Result как универсальный вариант хэндлинга ошибок делает перегрузку оператора, который может возвращать ошибку, невозможной, и, как следствие, бесполезной для околоматематических задач?
Можно сделать енам или структуру наподобие { Matrix, Result <> }
Я просто задаю вопросы
> Тока ECS не пугайся
Если шаришь, поясни, в чем его преимущество перед обычным ООП? Я вот пытался заюзать, и выглядит очень плохо. Вместо нормальных типизированных объектов мы храним каждый объект по кусочкам без какой-либо связи (только "entity id"-"component"), и тем самым теряем всю мощь системы типов.
Другой анон
Наоборот, когда пытаешь моделировать всю фигню через ООП, появляется миллион перекрестных ссылок. А вот когда у тебя есть, например, сущность "физический движок", то ему знать только то, что у него есть массив параллелепипедов, которые ему нужно обсчитывать. Лучше инкапсуляция, лучше использование кеша. Так все современные движки работают.
1. ОПП убивает производительность, потому что Data Driven Design - это про расчленение всего этого вот, чтобы каждый кусочек работал максимально эффективно, и данные не дублировались без надобности (к тому же, как только ты начинаешь писать "настоящий" ООП, у тебя сразу все объекты хуярятся через Box, что опять-таки убивает производительность).
2. В реальном мире как раз всё похоже на ECS, а не на OOP, поэтому писать в виде ECS всякие штуки, которые хотя бы частично моделируют реальный мир - проще. Да и эффективнее, потому что см. пункт 1.
3. Ты путаешь Object из OOP и систему типов. Система типов вовсе не про "захуярим всё вместе", она про типы. Тут хуй расскажешь, это надо на хаскеле показывать.
>>1685273
Ок, тогда как решается проблема "гарантировать, что я не проебал часть объекта"? Ведь мне ничего не мешает снести отдельный компонент, оставив остальные, принадлежащие конкретной entity? Ну и выбор всех компонентов для entity очевидно более тяжелый вычилсительно, чем получить объект.
> В реальном мире как раз всё похоже на ECS, а не на OOP
Очень спорно.Я бы сказал, что прямо противоположно.
> Ты путаешь Object из OOP и систему типов
Нет, не путаю. Может выразился несовсем корректно, это да. Я про то, что если брать подход "похожий на ООП", то у меня будет массив, например, NPC. Каждый NPC - инстанс вполне конкретного типа (в случае раста - структура), который может быть проверен компилятором. А в случае ECS мой NPC - это куча непонятно как связанных штук, корректность которых в компайлтайме не проверишь. Это реально похоже на реляционную БД, с потребностью в написании "запросов" или что-то типа ORM. То есть я, очевидно, не могу утверждать. что это менее быстро работает, но очевидно, что это хуево с точки зрения кода.
https://www.youtube.com/watch?v=aKLntZcp27M
>Ну и выбор всех компонентов для entity очевидно более тяжелый вычилсительно, чем получить объект.
А зачем? Если ты, например, считаешь урон от падения, то тебе нужно сделать запрос физическому движку и к хп персонажа. Ни анимация, ни моделька, ни данные с клавиатуры тебе не нужны. Да и доступ к массиву - это дешево.
>Ок, тогда как решается проблема "гарантировать, что я не проебал часть объекта"?
Ты можешь точно также забыть проинициализировать поле объекта и у тебя получится персонаж по умолчанию размером с Австралию и весом ноль.
В твоём случае это библиотека-биндинг плюсового opencv
>pub fn cv_operatorX_const_MatExprX_const_MatExprX(e1: const c_void, e2: const c_void) -> Result<*mut c_void>;
По-хорошему, должна быть "няшная" библиотека-обёрточка вокруг этой, которая внутри там паникует, когда надо, а когда нужно возвращает результат в виде определённых алг. типов.
>>1685410
Ну тип выше уже написал, что это это реляционная БД по сути, и твоё недо-ооп умещается в "колонке".
После Джавы Раст будет комфортнее в плане количества странной херни, которая может случиться в скомпиленной программе. Плюсы комфортнее в плане количества странной херни до компиляции.
По работе: плюсы менее денежные, чем Джава, и это не изменится, сиди в своём энтерпрайзе. А если Раст наконец-таки взлетит, то вакансии на 300кк в наносекунду появятся именно на нём.
>можешь точно также забыть проинициализировать поле объекта
В расте - не могу. А в ECS я могу не просто забыть проинициализировать, а полностью забыть добавить данные к объекту вообще.
> С ECS даже проще, программа сразу запаникует
Она должна отлавливать это в компайл тайм (чему ECS мешает полностью), а не в рантайме стрелять себе в голову.
> Ни анимация, ни моделька, ни данные с клавиатуры тебе не нужны
Ага, именно поэтому там уже в туториале получаются такие типы для получения данных:
type SystemData = (
WriteStorage<'s, Ball>,
WriteStorage<'s, Transform>,
WriteStorage<'s, UiText>,
Write<'s, ScoreBoard>,
ReadExpect<'s, ScoreText>,
);
Я боюсь представить высоту колонки, если будет реальный проект. Удобство как оно есть, несомненно.
Мой одноклассник читает лекции по Расту. Горжусь.
Плюсы конечно. Раст решает не существующую проблему, трудно учится, некрасивый, приходится много времени тратить на обход борроу чекера, нет обратной совместимости, трудно работать с системными концептами и быстро, эффективно их реализовывать. Язык пытается избавиться от сайд эффектов, но такова природа компьютера.
>Раст решает не существующую проблему
С точки зрения студентика с laba.cpp - несомненно.
>пытается избавиться от сайд эффектов, но такова природа компьютера
Долбоёбушка, смысл не в избавлении от сайд эффектов, а в контроле над ними и изоляции от чистого кода.
> трудно учится,
Ды-а.
https://softwaremaniacs.org/media/alenacpp/cppmap-2012.png
>в плюсы самая дорога, ага.
Я ничего не утверждаю, это вообще было про сложность со слов >>1687368
>Сколько там в полюсах занимает стороннюю либу подключить?
Почитать хэлп у компилятора (или один раз написать makefile/CmakeList.txt/Gyp) (есть вообще люди, которые в мс студиях и силайонах сидят), карго удобен, конечно, но тип ты сильно преувеличиваешь сложность, тем более если ты в каком-нибудь линуксе, где куча тулзов и внезапно тоже есть пакетный манагер, с которым ты изи таскаешь хедеры и либархивы - даже быстрее, чем с карго всё будет, если привыкши. Кстати про удобство карго, зонецил expand, вот где раст действительно сияет, такой-то тулинг 10/10.
> Почитать хэлп у компилятора
Не поможет с подключением либы, там лишь десятки тысяч специфичных флагов компиляции, которые тебе не нужны.
> один раз написать makefile/CmakeList.txt/Gyp
Ага, всего-то осилить еще один ебанутый язык и на нем написать билдскрипт, в котором ко всему нельзя ошибаться, иначе получишь непонятную ошибку при билде с которой хуй пойми что делать, если опыта нету.
> тем более если ты в каком-нибудь линуксе, где куча тулзов и внезапно тоже есть пакетный манагер
Не стандартизировано, следовательно скорее всего оно будет работать только на твоей машине (в лучшем случае на твоем дистрибутивенейм, в лучшем случае пару лет, потом ебля с версиями). Чтобы это решить можно взять конан, но там половину рецептов придется писать самому ручками на богомерзком питоне, ибо готовых пекеджей нет.
> ты сильно преувеличиваешь сложность
Нет, работа с зависимостями в С++ это полнейший ад, что бы ты не делал. Всё потому что ебанное легаси и отсутствие стандартов билда в языке со стандартом. (стандарта по факту у С++ кстати тоже нет, но это другая история...)
/ мимо сгоревший плюсовик /
> > тем более если ты в каком-нибудь линуксе, где куча тулзов и внезапно тоже есть пакетный манагер
> Не стандартизировано, следовательно скорее всего оно будет работать только на твоей машине (в лучшем случае на твоем дистрибутивенейм, в лучшем случае пару лет, потом ебля с версиями). Чтобы это решить можно взять конан, но там половину рецептов придется писать самому ручками на богомерзком питоне, ибо готовых пекеджей нет.
Еще есть nix, охуенная штука. Описываешь какие зависимости тебе нужны в nix файле, в дирректории проекта вводишь nix-shell и попадаешь в окружение с нужными пакетами.
https://nixos.org/nix/
мимо
Во первых, для базового использования достаточно написать файл уровня пикрл, где в массив просто передавать нужные зависимости.
Во вторых, язык не ебанутый, а функциональный и ленивый, прям как хаскель. Вот такие йобы можно с его помощью делать: https://blog.galowicz.de/2019/04/17/tutorial_nix_cpp_setup/
Думаю на него перейти и для растасам юзаю его для хаскеля, плюсы взял только как пример, ибо заебался для каждого проекта ждать пока карго скачает полгигабайта тех же самых зависимотей.
Backend meetup
Ruby, GO, Rust, Node.js, Python, Elixir
https://metaconf.net/backend-meetup-2020
> для базового использования
Не надо вообще нихуя уметь и думать.
> язык не ебанутый
> f = libname: libs: derivs: with pkgs.lib;
> concatMap (deriv:
> mapAttrsToList (libVers: lib:
> (deriv.override { "${libname}" = lib; }).overrideAttrs
> (old: { name = "${old.name}-${libVers}"; })
> ) libs
> ) derivs;
>
> overrides = [
> (f "stdenv" compilers)
> (f "poco" pocoLibs)
> (f "boost" boostLibs)
> ];
> in
> pkgs.lib.foldl (a: b: a // { "${b.name}" = b; }) {} (
> pkgs.lib.foldl (a: f: f a) originalDerivation overrides
> )
Тех, кто пишут на Си в шутку называют "сионистами".
Тех, кто пишет на Паскале называют "пасквилянтами".
А как называют тех, кто пишет на Расте?
type + &type
будет подсвечивать ошибкой? Совсем обленились, ёма.
https://github.com/intellij-rust/intellij-rust
PRs are welcome
the book, rustling или rust by example?
что посоветуете, если я уже что-то знаю о программировании в общем (функциональном в том числе), но не на расте
>Хочу стать великим в Расте. Что и как делать для этого?
Такое как-то получше можно сделать? Надо чтобы функции было похуй что жевать, указатель или валуе.
Во-первых, я бы заменил сигнатуру на
fn plus(a: impl Borrow<i32>, b: impl Borrow<i32>) -> i32 {
Т.е. использовать impl-трейты вместо генериков.
> Надо чтобы функции было похуй что жевать, указатель или валуе.
Зависит от того что ты собираешься с этим значением дальше делать. Недостаток трейта Borrow в том, что на выходе у тебя всегда будет ссылка (даже если передаётся значение) и будет очень проблематично сохранить входные параметры в какую-нибудь структуру. Для простых типов и так сойдёт, потому что их почти бесплатно можно скопировать, а вот для чего-то более сложного (например строки или массивы) лучше использовать Cow (принимать что-то вроде impl Into<Cow<'a, str>> для приёма любых видов строк), который плюс уже содержит имплементации полезных трейтов для строк/массивов и прочего.
Ах да, чуть не забыл. Если функция большая, то лучше всего всю работы выделить в отдельную функцию, чтобы компилятор не создавал четыре копии почти одной и той же большой функции. Т.е. сделать как-то так: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=baa30100332b874332cd1487df234785
> The Chromium project finds that around 70% of our serious security bugs are memory safety problems.
>>1699740
https://chromium-review.googlesource.com/c/chromium/src/+/1752927/
Всего-то уже и разрабы хрома активно ищут язык на замену плюсам, лол. Из альтернатив расту:
а) запилить форк ллвм, цланга, написать свой гц и запретить сырые указатели;
б) модернизировать процессоры (лол);
в) жс/жава/котлин (хз почему они в этот список попали, кекус конечно), свифт (который все же слишком хайлевел).
Растаны, хоть и страшно у вас такое даже спрашивать, но почему в прикреплённых примерах, основной поток блокируется после того, как все сообщения получены и потоки отработали? Если перед получением сообщения заджойнить все потоки, то всё нормально.
В доке написано, что iter.next() возвращает либо Some либо None. Но у меня он блокирует поток поле последнего Some и всё.
У тебя tx и 10 его клонов, итого 11. Сообщение ты отправляешь 10 раз, остаётся один (оригинальный) ненужный, его тебе и надо дропнуть. Между for воткни drop(tx).
"{a: 1, b: 2}". Хочу десериализовать её в структуру вида
struct MyStruct {
a: i32,
b: i32,
c: Instant
}
где в поле c буду пихать время десериализации Instant::now() - т.е. такое себе служебное поле только для меня, обратно сериализоваться оно тоже не будет. Можно такое провернуть?
Да. Делаешь имлементацию Default и метишь поле #[serde(skip)]
#[derive(Default, Deserialize, Serialize)]
struct MyStruct {
a: i32,
b: i32,
#[serde(skip)
c: Instant
}
Если не можешь всю структуру сделать Default, тогда установи чере макрос для поля функцию, откуда брать дефолтное значение.
В Хашкеллях, Питонах, Сисярпах и прочих Джавах есть буквально точно такие же средства, но почему-то претензии есть только к Расту. Причем, Ансейфом пользоваться даже проще, чем Джавовским JNI, потому что не надо думать ни о каком сборщике мусора и сейфпоинтах.
>Кстати да, я как жаба макака вообще с трудом представляю зачем могут unsafe блоки понадобиться. Это чисто игрушки сатаны для всяких додиков, которые конпеляторы пишут.
Немного поржал с игрушки сатаны (просто забавно звучит), мест много где он нужен, например, если у тебя используется ffi (там правда код прямой как рельсы), или, нопример, из очевидного запись в вектор без инициализации буфера, пины, тысячи мест так-то.
Ну и вся эта хрень в итоге не нужна, если ты пишешь клиента для рест-апишечки, например. Пины я, например, юзал лишь однажды - как раз с ffi, когда нужно было передавать контекст и получать коллбэк из сишного кода - часто ты проделываешь такое в жс, например?
Речь о том, что если ты юзаешь раст там, где обычно юзают жабу/питон/жс, то об ансейфе можно не вспоминать.
>Ну и вся эта хрень в итоге не нужна, если ты пишешь клиента для рест-апишечки, например.
Ну так и раст не нужен в этом случае, вообще раст и
>где обычно юзают жабу/питон/жс
попахивает хипстерской хуйней и buttplug.io, я к тому, что нормальные мужики на расте явно этим не занимаются.
https://docs.python.org/2/extending/extending.html
А теперь попробуй заснуть.
> если ты пишешь клиента
Потому что весь ансейф уже написан в библиотеках и зачастую его пользователям он не нужен. Исключение - неинициализированная память, для которой ансейф нужен как со стороны библиотеки, так и со стороны бинарника. Но тут уже что-то пытаются сделать: https://github.com/rust-lang/rfcs/pull/2930 после этого пулл-реквеста, ансейф нужен будет только библиотеке, а пользователь сможет использовать только безопасные функции.
А так ансейф зачастую используется для трёх вещей: (1) неинициализированная память, (2) ffi, (3) работа с указателями (у указателей нету времени жизни, но зато они могут указывать на освобождённую память, а потому нужно следить за ними самому).
Но вакансий мало
> C++ быстрее и безопаснее Rust, Yandex сделала замеры
>школьникам будет по 30
>лет через 25
судя по тому, как у тебя с математикой, предсказываешь ты тоже хуёво.
https://chromium-review.googlesource.com/c/chromium/src/+/1752927/
>Фишка в том, что в расте такой код "за забором". И я как-то считал, в СТД (в котором ужас-ужас сколько ансейфа) его значение порядка 0.1% от общей кодовой базы (считал очень грубо, по строчкам). Это значит, что у вас не миллион строк кода где можно "на секунду отвлечь/забыться", а тысяча. А теперь допустим что программист в среднем "забывает/отвлекается" раз на тысячу строк кода. В итоге в одной программе будет тысяча багов из-за этого, а в другой — один.
Что за унтеры там сидят? Уноси.
>он наверное и не в курсе, о чём там openssl.
Ну давай посмотрим на описание последней CVE
>Уязвимость CVE-2020-1967 представляет собой «ошибку сегментации» в функции SSL_check_chain. Серверные или клиентские приложения, вызывающие функцию SSL_check_chain () во время или после TLS-рукопожатия (версии 1.3), могут аварийно прекратить работу из-за разыменования нулевого указателя в результате неправильной обработки TLS-расширения «signature_algorithms_cert».
Так openssl — это про use after free?
Или из того что сразу приходит на ум — https://ru.wikipedia.org/wiki/Heartbleed
Так openssl — это про отсутствие проверки границ?
Поясни, про что же openssl. Ну не про корявый язык на котором написана же?
Самое смешное было смотреть на оправдание С/С++-идиотов, которые защищали дырки в своих языках. Линус так вообще откосплеил мэра лондона с его "UB это нормальная практика для разработчика на С и их не стоит бояться".
>>1710468
openssl - это две библиотеки crypto и ssl, первая - "швейцарских нож" от мира криптографии, вторая собственно сама реализация протоколов ssl разных версий от старых до самой последней. По поводу первой либы, значит, это огромный набор реализаций алгоритмов, которые все разом никому не нужны, что-то конкретное можно всегда найти в другом месте, даже в виде crate на расте. Вторую библиотеку тоже нет смысла переписывать, потому что там куча легаси + есть другие реализации, если тебя ssl из openssl не устроил, например, libressl, раз уж heartblead упомянули.
Пример из жизни, который работает, ring - небольшая по меркам монстра libcrypt библиотека, но её и webpki достаточно для реализации tls 1.3, ну и rustls как имплементация ssl.
То есть мало того, что переписать openssl на раст - непосильная задача, так она и не стоит вовсе.
Привет! Работа над TON Dark (Rocks) уже идет вовсю. Скоро будем запускать тестнет и распределять наши настоящие коины (много коинов!) среди членов команды. А ты все сидишь на сосаче. Ты не хочешь попасть на раздачу? Для этого надо вступить в нашу команду и сделать какой-то effort. Особенно сейчас в почете C++-челы, Rust-челы и прогеры с опытом работы под блокчейн.
tondarklead@protonmail.com
>Раз уж расто-тред, что там с либрой, ну и для справедливости с зеброй, зойчем кому-то нужен тон, если упомянутые работают (если работают)?
>либра
Лол. Во-первых, еще не работает, Цук сейчас пытается поулчить у США разрешение, во-вторых, сейчас бы отправлять сканы своих документов и проходить полный KYC-AML цикл, чтобы мне разрешили ВЛАДЕТЬ КРИПТОВАЛЮТОЙ. Это нормально вообще, зачем тогда крипта? Хотя это же создатель ФСБука, камон.
>еще не работает
Я имел в виду работоспособность самой программы, типо как тон полгода назад, когда там они свои конкурсы проводили, как я понял, он уже был готов. Либру довольно давно пилят, возможно она уже готова, я это имел в виду, а не запуск. Ну и зебра ещё есть. На них смотрели?
id: i32,
seks_list: Vec<Pizda>
}
struct Pizda{
id: i32,
zalupa: &Zalupa
}
Аноны, может кто объяснить как в данном случае правильно расставить лайфтайм спесифаеры? Вообще никак понять не могу. В залупе должен быть список пезд, залупа владеет и списком и каждой пиздой в нём. А в пизде ссылка на какую-то залупу.
> в данном случае правильно расставить лайфтайм спесифаеры
Никак.
https://rust-unofficial.github.io/too-many-lists/index.html это мне кажется может помочь разобраться
Вообще для указателей лучше всегда NonNull<T> использовать https://doc.rust-lang.org/std/ptr/struct.NonNull.html , либо Option<NonNull<T>> если возможно null-евое значение. Оба равны usize и являются zero-cost абстракциями и чуть безопасней сырых указателей.
Бля, ну что за кривое пердольное говно? Стоял stable-x86_64-pc-windows-msvc, решил накатить gnu, теперь вообще ничто не ставится.
rustup срёт ошибками, что нет нужных папок. Создаю руками, он пишет всё установлено, но по факту нихуя нет.
Пробовал standalone installers, но где в этом говне стандартная библиотека? Clion не хочет это говно принимать, хотя нужную папку указываю.
Ну пиздец. Причём в справке нихуя не написано, пишут ставить интерактивной залупой rustup-init и ни слова как заставить это говно работать.
>сидеть на виндовозе в 2к20.
https://github.com/rust-lang/rust-wiki-backup/blob/master/Using-Rust-on-Windows.md
Вообще, я бы посоветовал всё снести и обратно поставить заново всё, начиная с rustup.
Ну вот так оно даже скомпилируется
struct Zalupa<'a> {
id: i32,
seks_list: Vec<Pizda<'a>>
}
struct Pizda<'a> {
id: i32,
zalupa: &'a Zalupa<'a>
}
Только вот сконструировать что-то нормально не сможешь, да. Вместо ссылок надо юзать Rc/Weak, чтобы запилить циклическую зависимость.
> шиндопроблемы с файловой системой и переменными окружения
Но ведь это говно просто не работает. В этом (((безопасном))) пердософте написано что будут скачаны небходимые пакеты и установлены в такие-то папки, но ни первого, ни второго не происходит. Если бы были проблемы с вводом/выводом шинды, то должно быть исключение, но это говно просто нихуя не делает. Это не проблема шинды, что эти говнокодеры понаписали что-то в реестр и теперь нихуя не работает. Я бы понял если была хоть какая-то ошибка, но это говно пишет что всё ок и установлено. Сегодня я уже сгорел и даже не хочу пытаться вычищать это говно из системы. Алсо, удаление этого говна ничего не поменяло, надо чистить вилкой.
У меня есть подозрение что это говно не работает потому что я как-то полуавтоматически ставил всё это через VS Code, но это не отменяет того что делали всё это говноделы, неспособные в простейшее тестирование, т.к. это всё официально поддерживается.
>Алсо, удаление этого говна ничего не поменяло, надо чистить вилкой.
>ряяя это же не проблемы кривого дизайна шинды ряяяяяяя
>это всё официально поддерживается.
>опенсорс с баблом от некоммерческой организации
Эта "официальная поддержка" там от пары челиков, потративших на это своё время. Имхо — не стоило, с шиндой всегда так — ебли много, а потом ещё говнокодером назовут когда всё развалится.
Тащемта, ты сам долбоёб, который не захотел делать всё по инструкции, сделал всё по своему и всё поломал. Теперь ты пришёл сюда, даёшь 0 инфы и срёшь какую-то хуйню. Блять, ты же даже сам переустановить не можешь, о какой нормальности фс и прочей шиндохуйни вроде реестра ты говоришь?
Pin это аналог unique_ptr из c++.
Если не запинить Zalupa, то при муве Zalupa поинтер на нее поменяется, и все элементры внутри списка будут иметь референс(поинтер) на невалидную память.
Pin это позволяет избежать, т.е. память всегда хранится в одном месте.
В его случае если не запинить значение, то ты получишь ошибку лайфтаймов АРЯЯЯ!! НА РАСТЕ ЧТО-ТО ТАМ НЕЛЬЗЯ.
Есть еще вариант если у тебя Zalupa является 'static, в таком случае достаточно в самой Pizda брать &'static Zalupa.
core::ptr::unique::Unique — вот аналог твоего unique_ptr (Box — safe аналог, но не прямой).
Если бы Pin работал как Unique, у тебя бы вся память по пизде пошла, потому что Unique дропает свой контент, а Pin просто привязывает указатель.
Пин — это просто маркер, который позволяет полагаться на то, что Zalupa не сдвинется через эту &mut ссылку, но при этом ты всё ещё можешь получить мутабельный доступ к полям внутри через DerefMut.
> Пин — это просто маркер, который позволяет полагаться на то, что Zalupa не сдвинется через эту &mut ссылку, но при этом ты всё ещё можешь получить мутабельный доступ к полям внутри через DerefMut.
Ну да, так а что тогда ему нужно, чтобы Pizda к Zalupa нормально ссылалась?
Она есть, но с пометкой "не трожь, пидр".
https://doc.rust-lang.org/1.4.0/std/ptr/struct.Unique.html
В том случае именно надо сделать частью структуры Pizda, как-то так:
struct Pizda<'a>{
id: i32,
zalupa: Pin<&'a Zalupa<'a>>,
}
чтобы указать, что при создании этой структуры Zalupa уже должен быть "запиннен" где-то в памяти и его нельзя перемещать в другое место.
Попробовал bigdecimal, на первый взгляд ничего так, но нельзя указывать точность для операций. Например надо мне sqrt(2) с точностью 100 знаков, или деление, а там такое не предусмотрено.
1) Как CoC раст-коммунити к такому относится?
2) Если выгоришь — можно будет пойти работать на вебку.
Единственное что я смог нагуглить — https://docs.rs/num/0.2.1/num/
Если не то — либо писать самому, либо писать биндинги к сишным аналогам.
Аноны-растишки, поясните за оптимизацию исполняемого кода в rustc. Почему в rustc при opt-level=3 и опции использования расширений текущей архитектуры не используется ни одна инструкция из расширений, тогда как в gcc выходная программа чуть менее, чем полностью строится на AVX-расширениях? И есть ли вообще способ как-то собрать программу на Rust'е с этими расширениями?
Проблема а) в -ffast-math, который не хотят включать по причинам б) Лишние проверки, которые блочат векторизатор.
https://godbolt.org/z/ZQwyGJ
По умолчанию точно нет. Собственно, fast-math - это когда мы считаем, что флоаты ассоциативные и коммутативные. Это можно закостылить вручную, хотя, наверное, проще интринсиками.
https://godbolt.org/z/bPH2vr
Есть &[u8]. Там внутри записано ascii символами число. Допустим ['1', '2', '3']. Необходимо перегнать это дело в i32. Должно выйти 123.
Пока язык изучаю, поэтому придумать хорошее решение не в состоянии, может быть подскажете как без String::from_utf8(array).unwrap().parse::<i32>().unwrap() обойтись? Нашел from_str_radix, но оно принимает &str.
А чем from_utf8 и parse не устраивают? Выходит нормально, плюс не забывай что у раста мощный type inference, так что можно при вызове parse не указывать тип, если его можно вывести позже.
https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=250dd2ec5df3dc8b53f3a834ac33dd2c
>>1718166
> unsafe { std::mem::transmute(a) }
Для этого есть from_utf8_unchecked: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html
И да, str::from_utf8 не копирует строку. Он просто проверят все ли байты в массиве соответствуют utf8, а потом вызывает from_utf8_unchecked, который просто превращает ссылку &[u8] в ссылку &str. Если ты уверен что массив содержит корректные данные (например проверка уже была выполнена ранее), то можешь вызывать напрямую from_utf8_unchecked, чтоб не проверять массив лишний раз.
ты тредом ошиблась, тебе сюда >>1719888 (OP)
По факту добавили только две крупные фичи:
1) async/await теперь не требует Thread-Local Storage, а значит может работать в no_std и в целом быстрее и генерирует меньше кода (теперь может даже полностью оптимизироваться).
2) catch_unwind теперь имеет zero-cost есть код внутри него не выбрасывает панику.
Вот и всё. Остальное ещё в процессе.
> Рантайм для фьючей в стдлиб уже завезли
Сомневаюсь, что это туда вообще когда-нибудь завезут. Особенноу читывая, что помимо токио и асунк-сдт, уже есть особенно необычные рантаймы, например поверх io_uring у новых линуксов.
ой как воскрес быстро
https://habr.com/ru/post/506598/
> некоторые идеи стали насаждать в головы настолько агрессивное, безапелляционно и грубо.
Как они смеют оскорблять лучший в мире язык С++? Вообще охуели. Вон эксперты яндекса говорят что раст не нужен и С++ гораздо безопасней. А я яндексу больше верю, потому что я патриот.
https://docs.rs/specs/0.16.1/specs/
Берешь такой объект за шкирятник и потрошишь его нахуй.
Эти поля превращаешь каждое в массивы или иные коллекции.
Теперь объекта нет.
Есть сущность, которая раньше была объектом, а теперь стала просто типа тегом со списком поддерживаемых компонентов
Есть компоненты (которые бывшие поля и теперь ничего друг о друге не знают и тупо лежат в множественном числе в массивах и прочих колелекциях под капотом у ECS без прямого доступа к ним)
Есть системы - которые типа лямбда с циклом внутри итерирующаяся каждая только по своему компоненту и нихуя не знающая ни о сущностях ни о чужих компонентах.
Значит система должна на выходе высирать множество сообщений (например физическая система пробежала по всем пулям и объектам в мире и высрала список кто в кого попала, этот список сожрался геймплейной системой, которая пробежалась по хп атаке и проставила соответсвующие статусы/флагии передала системе анимации, которая передала список анимаций скелетов рендеру который уже нарисовал корчащихся трупов итд), которые должна схавать другая система.
Ну, строго говоря, specs — не совсем ECS. Но при этом, ECS как раз очень хорошо подходит для мультипоточности, потому что всё независимое. Лучше ECS подходят только выросшие прямо из CRDT системы, но там расширяемость страдает по сравнению с ECS. Мультипоточность — это вообще всегда боль, потому что менять расшаренные данные нельзя, а всегда хочется.
Группа1(оп11, оп12,..), группа2(оп21,оп22,..)
что нужно:
1. чтобы каждая из групп выполнилась асинхронно
2. чтобы выполнение группы 2 началось после того, как отработает группа 1
3. чтобы всё вместе это дело отработало внутри асинхронной неблокирующей таски
а то что-то сам я запутался - tokio, futures, async-std, куча тулз, рантаймов, пиздос. Вдруг кто уже проворачивал подобное.
Все еще оба моих аргумента вполне обоснованны.
Я понимаю, почему ecs может быть полезен в видеоиграх, но в целом довольно редко есть кейс, что надо менять прям одни и те же данные из разных потоков ОДНОВРЕМЕННО. И в итоге проще применять всякие мьютексы для конкретных случаев, чем тянуть для всей системы ecs и все ее минусы. Как минимум думая о рабочих проектах (среди них один - довольно хайлоад система с мягким реалтаймом; везде - многопоточность), ecs выглядит как бесполезная и даже откровенно мешающая хуйня. Шарить изменяемые данные между потоками плохо, но если совсем надо, то Arc<RwLock_>> и вперед.
>>1724479
Примерно так (я только не понял 3 пункт, но подозреваю, что тебе надо просто запустить из работающей async функции и забить на результат)
async fn some_func(....) -> ... {
... <some code>
// Вот тут ты просто запускаешь свой асинк и идешь дальше
tokio::spawn(async move || { futures::join_all(<your ops>).await; futures::join_all(<your ops>).await; })
... <some other code>
}
Чо тут происходит:
1. tokio::spawn запускает переданную ей асинхронную функцию на текущем рантайме. Можешь думать об этой функции как об аналоге thread::spawn, только на вход подается асинхронная функция;
2. async move || {...} это просто асинхронная безымянная функция, тут все просто;
3. futures::join_all(<your ops>).await; futures::join_all(<your ops>).await; - это как раз последовательный запуск групп;
4. futures::join_all просто запускает все переданные ей футуры одновременно и ждет завершения всех.
Хуево описал, но надеюсь будет понятно хоть немного.
Если вместо tokio юзать async-std, то там наверно есть аналог tokio::spawn, лень гуглить.
ну чо, как вам?
https://blog.tonari.no/why-we-love-rust?ref=twtr
мог бы и сам ссылку скинуть, каког хуя мне пришлось самому её искать?
но впринципе достаточно интересно было глазами пробежаться, спасибо
ах ну да, а нахуя эта залупа зеркальная нужна? обычных вебок уже недостаточно?
>группы
Почему именно группы?
>неблокирующей таски
Русский язык, не?
>а то что-то сам я запутался - tokio, futures, async-std, куча тулз, рантаймов, пиздос.
A { B_готов: bool }, B (первый набор задач), C (второй набор задач) реализуют std::future::Future
В poll у A, если B_готов, то опрашивается C, иначе B. Хуле тут сложного? По поводу рантаймов вопрос сложнее, про async-std я ничего не могу сказать, в токио есть оч простой способ ВАЙТИ, это если ты его используешь с фичей rt-core с сингл тредовый рантайм
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ba94d6fc181417417a4e274386722038
В билдере .basic_scheduler().
>>1726196
Можно коротко про что там? Быстро бегать глазами не люблю, а если что-то интересное, то можно и почитать аккуратно.
Планируете ли сами переименовывать? Или тут все гитлеры?
>Можно коротко про что там? Быстро бегать глазами не люблю, а если что-то интересное, то можно и почитать аккуратно.
Сам сильно не вчитывался
кратко: кампания начала пользоваться растом, рассказали как к этому пришли, с чем столкнулись, плюсы минусы и тд
ничего полезного
> Ну, он же написал, что не будет объяснять причин своего поступка и всё такое.
Интересно все участвующие в этой рассылке тоже были провёрнуты африканскими братушками? https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/
И СЕО гитхаба тоже: https://twitter.com/natfriedman/status/1271253144442253312?s=19
"Африканские братушки" - это демократы и стоящие за ними рептилоиды из wall street , которые должны ухуярить промышленников-васпов.
Тут многие не понимают, что вот эти все каминаутники на самом деле понимают ЧЬЯ повесточка и держат нос по ветру и за кого на самом деле вписываются.
И они прекрасно понимают что мрии про Make America Great Again на фоне стремительно превращающихся в детроит промышленных городов и бесплатной рабочей силы в странах третьего мира с перспективой замены их роботами - это примерно чуть менее чем нихуя фейспалмово чем мрии во возрождении СССР 2.0.
По этому они вписываются за повесточку сильных, у которых план унасекомить васпов-промышленников через черный расизм.
И стало интересно и правда все настолько плохо в реальных проектах, что приходится держать 2 копии проекта, одну компилируешь, другую кодишь в данный момент?
У меня-то пока хеловорлды которые собираются за секунды, интересно реальное положение дел.
>с перспективой замены их роботами
Тут не все так однозначно
https://www.vedomosti.ru/business/news/2019/11/11/815970-adidas
https://vc.ru/tech/132226-sboi-na-konveyere-i-ezhegodnoe-obnovlenie-pochemu-apple-otkazalas-ot-avtomatizacii-proizvodstva-v-polzu-ruchnogo-truda
> И стало интересно и правда все настолько плохо в реальных проектах, что приходится держать 2 копии проекта, одну компилируешь, другую кодишь в данный момент?
Со включённым lto, даже мелкие проекты могут компилироваться пару минут.
>>1726510
> но это вроде как решалось через новый линкер
Ещё не решилось. cranelift не интегрирован в стабильный раст. Можно закостылить в ночнушке, но никто ничего не гарантирует, там даже тесты не проводятся.
Да, раст довольно медленно собирается. Но особых проблем нет, особенно при кодинге. У меня рабочий проект уже под 50к строк кода, разбитых на множество крейтов, и rust-analyzer хорошо работает, не тормозит процесс (только при запуске немного тупит, пока анализирует проект). Вообще >>1726510 анон прав, тебе нафиг не нужен compile (rust-analyzer его не делает, например), если тебе не надо что-то запускать.
Я пару раз менял структуру крейтов, чтобы было быстрее запускать тесты в отдельных крейтах, ну и не перекомпиливать вообще все из-за изменения в одном крейте. Но в целом это не такая большая проблема, и вряд ли вылезет на небольших проектах.
Почитал статейку, ну короч там хуй знает вообще о чём идёт речь по факту камеры с драйверами под линь и хуйня для браузера, шта? С одной стороны я не понял, вообще при чём тут джабаскрипт и web изначально, во-вторых, webrtc - это же хуйня, которая тунелится в http и, заворачивается в tls => по сути всё по цене tls. Зачем там были пляски вокруг webrtc? Зачем тут вообще некий web + нет нихуя исходников, чтобы понять о чём вообще речь. Из нового для себя открыл structopt, хотя он и не нужен. Там момент был
>A week of struggling with WebRTC’s nearly 750,000 LoC behemoth of a codebase revealed just how painful a single small change could be — how hard it was to test, and feel truly safe, with the code you were dealing with.
Ну потом решили "переписать" на раст
>webrtc-audio-processing is a good example. The benefits it provides (clear audio with no vocal echoes or feedback) are huge and porting it to Rust in the near-term is not likely (it's around 80k lines of C and C++ code).
Но 80к уже внебюджета + чел не шарит в C или плюсах судя по всему, наверное единственная причина, почему они там раст выбрали.
Чёт хуй знает, такая себе статья. Единственное, что подметил положительного, японские тянки худенькие, а не кабанихи и их много в разраб-конторе.
1. Проповедуется "институциональный расизм". В США 90% белых +- согласно с тем, что чёрному парню из гетто труднее устроится, т.к. в гетто плохая школа, после которой его не возьмут в хороший колледж, а после в MIT
2. Но чтобы работать программистом, не нужно оканчивать хороший колледж - в этой сфере полно самоучек.
3. Профессия престижная, выучиться можно сидя дома за компом. Почему же нет нигеров-программистов? Нам, белым, как-то неудобно получать такие бабки, когда бедные нигеры там курят крэк в подворотне и стреляют друг в дружку - вдруг каким-то боком мы, программеры, тоже расисты, сами того не замечая?
4. Всё ясно: нигеры боятся слова master в гите! Вот ща переименуем, тогда-то чёрные братишки перестанут бояться программировать и раскроют всему миру свой интеллектуальный потанцевал.
>Аноны, я, кажется, понял причины особого градуса СЖВ истерии в среде западных программеров
Смешно но нет.
Главная причина - банкиры и прочие рептилоиды с wall street и их борьба с васпами - владельцами производящей промышленности.
Равно как нет пыни а есть кооператив озеро из бывших шпионов и мусоров, так и нет трампа а есть всякие форды-шморды и прочие крайслеры-хуяйслеры на пару с боенгами-хуёингами.
Поясняющий ролик:
https://www.youtube.com/watch?v=rStL7niR7gs
Вся суть в воспитании. Если нигера воспитывает белая мать, может выйти толк - тот же Обама.
Если воспитывают нигеры, которым "все должны", вырастает дженерик нигга.
Вот только интересно - есть тенденция к скатыванию, или раз вставший на путь истинный нигга будет и детей своих и внуков воспитывать приличными людьми.
Вот только что доделал свой пет-проект:
> Finished release [optimized] target(s) in 1m 36s
Маленькая программка, которая скачивает с антизапрета и рублэклиста список заблокированных доменов/айпи и на их основе генерирует dnsmasq/ipset фильтры для автоматического обхода блокировки средствами iptables. Самое смешное, что самая сложная часть - это поиск доменов второго уровня для группирования, если доменов третьего уровня слишком много. Я заморочился и сделал правильный поиск доменов первого уровня, используя список https://publicsuffix.org/list/ и написав парсер, который преобразует его в идеальный хэш-мап (т.е. без коллизий) на 10722 строк кода, с помощью которого и производится поиск доменов.
Это автосгенерированный код уровня пикрилейтед. Короче в пять раз он станет, только если доменов поубирают. Первая версия и так была в 16000 строк и собиралась 6 минут (потому что домены разбивались по частям в разные хэш-мапы и всего было несколько сотен хэшмапов, но во второй версии всё объединил в одну), это уже после оптимизации.
https://github.com/sfackler/rust-phf
Вся суть в том, что все данные известны на момент создания хэш-карты, а потому можно на ихз основе сгенерировать идеальную хэш-функцию без коллизий. Недостаток в том, что чем больше данных тем дольше генерируется хэш-функция.
Да, там создаётся массив с дополнительными данными для расчёта в случае коллизий. Но он не увеличивается бесконечно. Там больше упор на рандомную генерацию данных для хэш-функции пока все данные внутри карты не будут идеально хэшироваться. Потому генерация карты и занимает много времени (правда будет заметно при >1000000 элементах, моя с ~10000 даже в дебаг-билде генерируется моментально).
Это не хуета, это глобализация и отмазки. Просто если сказать что китайцы/индусы/пакистанцы стоят дешевле роботов — это будет неполиткорректно.
Вообще, после коронакризиса как раз таки предсказывают уменьшение этой самой глобализации, и роботизация точно будет расти. Всё какие нибудь же ахуевшие американцы это не среднеазиаты, работающие за чашку риса, и оезко роботы перестанут быть «неточными».
Трудности перевода
>Typical problems that arose include how Apple's use of glue required precision the machinery couldn't reliably match. And the tiny screws needed required the automation to correctly pick and position them but that same automation couldn't detect problems the way a human hand could.
https://appleinsider.com/articles/20/06/04/how-apple-learned-automation-cant-match-human-skill
Я так понимаю роботы иногда тоже промахиваются, но человек может понять что он не туда клея жахнул и исправить. А робота надо еще этому учить.
Потому что хэшмап быстрее, не? Там около 11000 элементов внутри и без коллизий время почти всегда одинаково (хотя скорость вычисления ключа и зависит немного от его длины). К тому же конкретно phf и создаёт статический вектор, а после вычисления хэша у тебя получается индекс в котором находится пара ключ/значение. Т.е. вся суть в том, что хэшмап полностью создаётся во время кодогенерации (а у меня она генерируется отдельной утилитой) и фактически хранится в бинарнике в готовом для использования виде и инициализировать перед использованием её никак не надо.
>opencl
На вулкане есть вычислительные шейдеры, которые должны работать на любых девайсах, поддерживающих вулкан - лучше юзай их. С OpenCL, например, на мобилах туго, а на десктопе куда давит. Да и сама концепция OpenCL немного устарела. AMD, вон, пилит HIP - аналог куды. Правда, тоже для плюсов-онли.
Для раста есть потуги в виде https://github.com/MaikKlein/rlsl https://github.com/gfx-rs/rspirv - когда-нибудь сможем полноценно ебошить для GPU прямо на расте.
Основные критерии проекта, благодаря которому берут на работу:
1.Работа с вебом.
2. Многопоточность.
3. Асинхронность.
4. Пользуется популярностью у других/приносит прибыль создателю.
Плюсом будут - графический интерфейс, работа с базой данных, кросплатформенность, версия для мобильных устройств.
Самый легкий способ идеи для проекта - спиздить уже существующую и изменить её с упором на что то конкретное. Например, есть библиотека, которая охватывает множество юзкейсов, ты создаешь её копию, которая охватывает только часто используемые юзкейсы, улучшаешь либо функционал в этом направлении, либо производительность/ресурсоемкость. Называешь её lightweight оригинальная либа нейм, описываешь достоинства и радуешься звездочкам на гитхабе.
Без асинхронности всё гуд, работает. Как только меняю вызов любой функции на асинхронный, ругается на пикрил. Хуле ему надо? Я чего-то невозможного хочу? Пиздос.
Ну тебе же написали, что какая-то из ожидаемых тобой Future не является Send. Покажи код, хуле, так сложно сказать.
>>1733277
Забей вообще. Сейчас, если ищут именно раст разработчика с опытом, никто особо не будет смотреть на твой гитхаб (ну то есть будут, но его отсутствие совсем не критично). Слишком мало кандидатов, чтобы еще и выкидывать тех, у кого нема гитхаба. У нас вон вакансия на раст разработчика закрывается уже хуй знает сколько месяцев.
Если после жабы накачу раст, я офигею писать бизнес логику на этом языке? Будет так же больно как на С++ или терпимо?
Ебать проще... Проще... Проще...
thread 'main' panicked at 'dispatch dropped without returning error', /home/vasya/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/macros.rs:13:23
Ну какой-то код из либы, которую ты юзаешь, запаниковал. Судя по гуглу это что-то из hyper'а.
>>1733808
>>1733803
Невероятно, откуда вы все лезете. Открою секрет: вы ВООБЩЕ на любом языке можете дернуть системный exit и прибить любой процесс вне зависимости от гарантий языка. И я уж молчу про то, что сделать плохой дизайн либы/приложения можно тоже на любом языке (кроме C++ - там ты просто не дойдешь до дизайна, пока будешь ебаться с языком).
Кому не лень, перечислите недостатки раста, можно субъективно? Чисто ради того, чтобы иметь картину об языке. Плюсы и так можно услышать, а вот о недостатков - это интереснее узнать.
Штош, поехали:
1. Недостаточно "взрослые" либы. Те либы, которые ты, например, юзаешь сейчас для проекта, через год будут совсем другими. Или вообще часть будет заброшена. Или изьята (особенно криптография).
2. Долгая компиляция.
3. Отсутсвие стабильного ABI. Очень мешает созданию растовых динамических либ (есть крейт abi_stable, но это жуткий костыль).
4. Борроу чекер иногда не способен обработать корректный код (проблема решается, NLL очень сильно улучшил ситуацию, polonius сделает прям вообще хоршо, когда будет готов).
5. Лично меня очень сильно раздражают orphan rules. Я понимаю, почему они введены, но было бы неплохо иметь возможность обходить эти правила в bin крейтах, ибо такой крейт уже никуда не будет реэкспортироваться (то есть он что-то типа final же).
6. Нет нормальной возможности указывать кастомные аллокаторы для разных контейнеров (вроде как над этим думают).
6.5 В целом есть некоторые претензии к стандартной либе, но они постепенно решаются.
Ну это вот что прям я бы назвал минусы. Так еще бы отметил слабоватый вывод типов, отсутствие HKT (да даже GATы хуй появятся видимо), да и наверно все.
Но при всех минусах юзать раст приятнее, чем другие языки, ИМХО.
>>1734340
Ну так ты юзай нормальный редактор/ide, а не идею. Есть великолепный rust-analyzer, зависимость есть, брат жив.
1. cargo. Это просто манна небесная в плане упрапвления проектом (сборка и зависимости) после всего, что я юзал ранее (Python - pip/venv/pipenv, C++ - ебать нахуй make/cmake/зависимости из жопы, Java/C# - вообще неюзабельны без ide для новичка). cargo, будучи довольно простым в использовании, покроет примерно 90% потребностей проекта любой сложности.С build.rs - 99%. И никаких монструозных Makefile, pom.xml, стремных requirements.txt + env/bin/activate. Может есть и у других языков подобное cargo (точно есть), но я их не юзал.
2. Сам язык удобный. Один только pattern matching делает вещи куда удобнее. Не зря его пытаются в питон даже затащить (да, я знаю что в каком-нибудь хаскеле это есть хуй знает сколько лет). Ну и в целом многие вещи, заимствованные из функциональщины очень удобны.
3. МАКРОСЫ.
4. За счет большого количества либ (хоть иногда и сомнительного качества) + хорошей выразительности языка можно юзать легко вместо питона для скриптинга (я так и делаю иногда, особенно если сходу знаю, что мне знакомы нужные либы). А с evcxr можно даже юзать в REPLе (хоть и тормозит немного).
5. Там, где я его юзаю по работе, требуется производительность, поэтому аналогом мог бы быть только C или C++, и лучше уж Rust.
Ну вот как-то все вышеперечисленное и приводит меня к тому, что мне оч нравится использовать Rust (хотя я и питон юзаю, и что-то еще тыкаю иногда).
Хз, можно ли к идее подключать произвольный language server. Но вот если сравнивать именно плагин intellij-rust и rust-analyzer, то я бы сказал что rust-analyzer лучше, потому что он а). Не привязан к редактору (берешь любой совместимый с lsp редактор - работает). б). В него вкладывается больше усилий со стороны коммюнити, так как он не завязан на идею. в). Ну его пилит matklad, который раньше в jetbrains пилил собственно intellij-rust. г). itellij-rust очень гейский и например отладчик есть только в платных ide (idea ultimate или clion).
Я тут намешал как технических так и "идейных" аргументов, но короче я бы сказал, что если тебе не нужна прям idea, то лучше перелезть на связку vscode + rust-analyzer (в моем случае это емакс, а не vscode). Но это вкусовщина, разумеется, на работе вон все в разных средах пишут (главное не быть пидором и не добавлять папку .idea/ в гит репозиторий).
Ну мне раст вообще кажется более читаемым (я с ним таки 90% времени работаю), то есть 15/10. Сложный код на питоне (с большой вложенностью) вообще не могу нормально читать без подобной фигни https://github.com/antonj/Highlight-Indentation-for-Emacs/ . Ну и наличие типов в коде очень сильно помогает его читать (и давайте будем честными, в питоне очень редко код с type hint'ами).
Ну и вообще тебе будет проще читать то, с чем ты больше работаешь (хоть ассемлбер), так что такой себе вопрос.
>интересный баг
Этот интересный баг - всего лишь отсутствие доки у функции. Задержался курсором, получил пикрил. rls на этом же месте показывает {unknown}. То есть, вроде бы это и проблема vscode тоже.
>>1734642
>что-то лишнее реэкспортится
Ага, #[macro_use] перед "extern crate tokio";
Пидарасы, могли бы обозвать tokio_test.
Ctrl+. в дефолтных биндингах. Но вообще там экшн есть Quick fix. То, что там написано no quick fixes available - очередные баги.
>>1734651
пикрил. Большинство Vsknob'ом пользуется. Мне тоже "приходится" им пользоваться, потому что эмакс слишком сильно лагает на моей машине, а что-то другое настраивать нет ни времени, ни сил.
Я не шучу, если что, по поводу эмакса. Elip сам по себе медленный. А тут ещё и вдобавок медленный gc и только один поток. Ну, может, голый он не лагает. А font-lock-mode(подсветка синтаксиса) уже заставляет фризить при скролле. По фичам то эмакс вообще топ, но с кучей пэкэджей он будет только раздражать своими лагами, если ты ,конечно, не на мейнфрейме его запускаешь.
Алсо, про вим. С coc.nvim оно выглядит так: нажимаешь хоткей или вручную вызываешь CocFix, стоя курсором на нужном месте, снизу открывается окно(пикрил), где выбираешь что нужно
Я мимокрокодил, но что там не так с макросами? Я вроде недавно только читал, что завезли в clion экспанды для макросов. Хз, правда, как оно сравнимо с trace_macro, но всё же это по идее должно быть лучше, чем сидеть на листочке их разворачивать, как раньше.
Напомните почему Rust медленнее си? Где то читал, или смотрел видео доклад, там было что то толи про LLVM, то ли про неудачный дизайн ABI с оверхедом ассесблера, не могу найти. Интересуют подвижки в этом плане.
Но медленнее сишарпа
https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext
А вообще там в С++ какой-то годный бд драйвер завезли
https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=query
просто хейтеры не умеют делать бенчмарки
Проводились норм бенчи - раст ебал кресты в рот в 9 тестах из 10. Раст - будущее. Апогей компьютерных технологий, который сумел нивелировать на 99% ошибки памяти, не прикручивая при этом GC. Ассемблер был заменен сишкой, сишка заменяется растом потихоньку. Мир системного программирования тоже меняется, пора оставить UB, висячие указатели и переполнения в прошлом, 2к20 год уже как никак.
>Но медленнее сишарпа
На 0.3%
Дожили, блять.
>>1737308
>Может быть те бенчи которые видел, как раз не правильные и подкрученные?
Самые релевантные бенчи — это, кто бы что бы не говорил, benchmarksgame, т.к. есть конкретные алгоритмы с конкретными ботлнеками и всё прозрачно. Тот же techempower — хуйня из под коня, ей богу. Что там вообще сравнивается? Кто напишет сервер поддерживающий меньшую часть http или не сующий в заголовки лишние 2 байта и это используется как аргумент в спорох о языках? Лол.
>benchmarksgame
Помню в свое время как раз к ним были какие-то претензии и люди кричали не воспринимать те тесты за объективные.
Не хочу холиварить, мне на самом деле даже все равно и ничего плохого языку я не желаю. Просто не переношу фанбоев, которые манипулируют фактами со словами "раст быстрее сишки" или начинают кидаться сомнительными, но удобными тестами.
Не думаю что результаты techempower.com дадут какую-то математическую точную истину. Нет, они показывают много интересных вещей, которые не видно за манипуляцией.
Да раст быстрый, это факт. Но блин хватит уже этого фанатизма в профессии.
>Тенденции к скатывания не может быть
Запросто. Допустим, некий нигга из хорошей семьи вдруг решит стать гэнгста (книжек обчитается, рэпа обслушается, проникнется романтикой). Внезапно, на него, такого крутого гэнгста, западут с десяток нигресс из приличных семей - что-то у них щёлкнет унутре от его лихости. В итоге имеем 1 ниггу в тюрячке и 10 мамаш одиночек, воспитывающих гэнгста-деток - и всё по-новой.
пикрил
https://github.com/telegram-rs/telegram-bot/blob/master/lib/examples/simple.rs
Приходит сообщение, формируем ответ, отправляем. Но мне надо чтобы программа сформировала ответ без входящего сообщения, по списку зарегистрированных пользователей, как это сделать? Я не понимаю как мне самому создать структуру message, возможно ли её как-то сохранить в файл и загружать при запуске программы? Или как вообще это делается?
Касаемо написания программ в макоси рекомендуют вместо системного аллокатора всегда использовать jemalloc или другой кастомный: системный там лютое говнище и из-за него программы иногда работают в разы медленней чем на других системах.
А в целом всё одинаково - вс код и раст-анализер работают везде.