Rust — язык, позволяющий каждомусоздавать надёжное и эффективное программное обеспечение async/await наконец-то в стабильной версии!https://www.rust-lang.orgВместо шапки: https://gist.github.com/TatriX/183c816f1346d418f969c4576c2b9b41Предыдущий тред: >>1539530 (OP)
>>1602417 →такое дело: vulkano как раз генерит шейдер из процедурного макроса, т.е. код шейдера должен быть известен ещё до конпеляции. А я хочу через темплейт нагенерить 100500 вариантов шейдеров и матчилку для их разруливания. Короч, решил заюзать markup + build.rs - пожелайте удачи, в-обсчем.
>>1603001Просто у вас токсики-нацисты в сообществе. Последний случай с веб-сервером на расте и его выпиливанием с гитхаба весьма показательный пример для желающих вкатиться в ваше говно.
>>1603220Ну так сишка сложная, там потратишь на разработку намного больше времени. А питон любая школьница осилит и решит прикладную задачу в десятки раз быстрее.
>>1603223Словарь в питоне есть из коробки. В сях хеш-таблицу придётся реализовывать с нуля, либо брать либы.
>>1603097По опыту - совсем не подходит только для GUI (почти все фреймворки - говно, обвязки над qt/gtk - ещё хуже, да и как-то в целом язык, как кажется, не очень помогает), фронтенд (тащемта профитов мало, придется компилить в васм, ну нахуй, проще взять TS).Ещё (довольно узкий) кейс - система плагинов в виде динамических библиотек. Если хочешь DLL с растовым интерфейсом (трейты/трейт объекты/не С типы данных), то соснешь хуйцов, так как супер сложно обеспечить совместимость потом будет.В остальном для всего подходит, а с excvr можно даже как repl юзать.
>>1603047Есть Askama, как раз компилит шаблоны в compile-time. Для рантайма есть Tera. Оба по сути варианты Jinja2.Сам сейчас на работе юзаю Askama, очень неплохая штука. Не уверен, насколько она подойдёт для шейдеров, но раз ты упомянул mako, то наверно тебе сойдёт.
Как так выходит, что молодой язык созданный хипстерами даёт пасасать в половине случаев сишке, компилятор для который уже несколько десятилетий полируется суровыми асамблерными дедамиhttps://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
>>1604129А в некоторых не даёт. Удивительно, да?Есть мнение, что по перформансу оба языка находятся у предела для высокоуровневых языков. А перегибы в ту или иную сторону - лишь следствие особенностей реализации оптимизаторов.
>>1604069Было бы круто, но даже если все двачеры знающие Раст соберутся, путного ничего не выйдет. Слишком сложно.
>>1604062Запили поддержку 16-бит png для image и/или 12/16-бит жипега для него же. Вообще, под раст худо-бедно либы есть, но многие из них страдают дефицитом функциональности.
А где посмотреть бенчмарки раста?Я тут подумал, что широко известные ничего не показывают, кроме знаний авторов о железе и внутренностях раста.А такой, который бы показал перфоманс идиоматического кода на расте (без строчки unsafe), плюсов, джавы etc.
Пиздец. Обычный клиент Postgres не работает, если программа использует async.Причем падает с Runtime ошибкой>Cannot start a runtime from within a runtime.Ну заебись.Пошел переписывать на tokio-postgres
>>1606350Ну как бы да, синхронный клиент это обёртка над асинхронным (https://github.com/sfackler/rust-postgres/blob/master/postgres/src/client.rs#L35), и ей нужен свой рантайм. Но вопрос - а нахуя тебе синхронный клиент в асинхронном коде, а? Ты решил специально усложнить жизнь?
>>1602965 (OP)На удаленках выгорел и по итогу нет ни одного проекта нормального проекта для портфолио как и самого портфолиоВ реале идти устраиваться не вариантГде найти силы?? морально хочу начать сосать писюны и сидеть на каком-нибудь винте или герыче нет сил
>>1608386>На удаленках выгорел>Где найти силы?? Знакомые симптомы. Меняй режим работы. Сразу говорю мотвация, накачивания себя и прочие психологические штучки тут не помогают.Что мне помогло:- Никакого кода после 9-00: Код выходит говно, усталость накапливается, мораль падает.- Я полностью отказался от кофе в пользу яблок. Кофе дает бодрость не бесплатно, а в долг и требует потом проценты. От яблок тот же эффект, но больше пользы.- Я встаю в 6:00 каждый день , но это по желанию.- Ходять в качалку я не стал, купил гирю на 16. Мне достаточно в день делать 1 упражнеие - 10х10 махов гирей. Мышцы перестали атрофироваться и осанка несколько исправлась. Плюс вернулся аппетит.
>>1608428>Никакого кода после 9-00утра или вечера?>в пользу яблокмне помело помогает, которое фрукт. Адово бодрит>купил гирюя тоже себя нагружаю, чтобы ночью спать. Если физически не утомляюсь, ночью не сплю. Только надо подгадывать, чтобы ночью спать, а во время работы - нет.не тот анон, но тоже удалёнщик. хуячу приложение камеры на расте.
Вдогонку: кого бессонница не мучает - попробуйте пить зелёный чай. Я развожу из концентрата (взял на ебее за недорого), бодрит по-доброму - т.е. руки не трясутся, как от кофе. Но меня бодрит настолько, что я ложусь на 2 часа позже, чем следовало бы.
>>1608747>>Никакого кода после 9-00>утра или вечера?Вечера, понятное дело. Я за ~15 лет работы в IT видел много примеров "ночного" кода. Собственного, вендорсокого, кода джуниоров, синьеров, тим лидов.Что весь этот код объединяло - он всегда был говно.
>the maintainer of a popular Rust library (Actix Web), under heavy criticism (some might call it hate), decided to stop maintaining it and quit open source development.
>>1605892>А где посмотреть бенчмарки раста?Это немного странный вопрос, потому что сам раст позволяет тебе писать код сколь угодно близкий к железу. Может быть ты хочешь посмотреть производительность stdlib?Или может ты хочешь узнать как быстро работают программы написанные для синтетических задач? Тогда вот: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.htmlИли для конкретных реальных задач: https://blog.burntsushi.net/ripgrep/ https://github.com/serde-rs/json-benchmark https://github.com/tafia/quick-xml>Я тут подумал, что широко известные ничего не показывают, кроме знаний авторов о железе и внутренностях раста.Если ты хочешь делать бенчмарк на любом языке для любой задачи, тебе обязательно придется знать железо и внутренности языка. (в случае с Си этих "внутренностей" намного меньше чем в других языках, и вопрос ближе к железу)>А такой, который бы показал перфоманс идиоматического кода на расте (без строчки unsafe), плюсов, джавы etc.Я думаю вот это очень полезно: http://cliffle.com/p/dangerust/
>>1609490Я вот никогда во внутренности актикса не заглядывал, но вот вспыхнул скандал, и я солидарен, что там по, ансейф ансейфом погоняет.И как бы оно может упасть в любой момент, никакие гарантии, за что я полюбил Раст не работают.
>>1609637Там ансейф в одной функции, которая, вообще-то, тоже должна быть ансейф, и из-за этого кажется, что его мало.
>>1610207Это не самое смешное. Там до сих пор в лежит в исходниках аналог UnsafeCell, только где все функции помечены как безопасные. https://github.com/actix/actix-net/blob/master/actix-service/src/cell.rs
>>1610830Одно дело, когда у тебя в ансейфе 22 = 4, а другое, когда 2x = 4, где х - а хуй его знает, скорее всего тоже 2.У меня, кстати, в приложухе джля ведроида полно подобных ансейф преобразований, без которых никак, ибо коллбэки. Приходится в RefCell оборачивать и пикрил хуетой пользоваться (кстати, мож кто знает - есть ли подобное в стандартной либе?)
>>1611131> пикрил хуетой пользоватьсяМожет лучше RWLock возьмёшь из крейта parking_lot? Методы try_read_for и try_write_for. RefCell как бы не предназначен для многопоточных приложений.
>>1611528>try_write_forНашёл в другом крейте https://docs.rs/lock_api/0.3.3/lock_api/struct.RwLock.htmlспасибо, попробую. Хотя можно и мой костыль под дефолтный RWLock переписать - его тоже нагуглил.
>>1611712Это и есть parking_lot, точнее его дочерний крейт (в самом parking_lot'е стоит алиас type RwLock<T> = lock_api::RwLock<RawRwLock, T>;). Напрямую lock_api использовать не надо.https://docs.rs/parking_lot/0.10.0/src/parking_lot/rwlock.rs.html#89
>>1611712> Хотя можно и мой костыль под дефолтный RWLock переписать - его тоже нагуглил.Твой костыль очень хуёв в плане производительности и задержки. Мало того что идёт переключение контекста каждый раз при засыпании треда, так и при освобождении ресурса функция может возвратить результат не сразу. RwLock со встроенными таймаутами в разы лучше. В std поддержки таймаутов в RwLock'е нету, но если захочешь добавить в любом случае будешь изобретать похожий велосипед. Лучше возьми готовое.
>>1611769Ах, да. Чуть не забыл. У тебя напрочь отсутствует fairness. Что значит если непрерывно идёт много читателей, то поток на запись просто может быть навсегда заблокирован.
>>1611769Спасибо, боярин, и правда пошустрее стало (вроде). Не то, чтобы оно особо тормозило, но на обработке очереди 4 тыка по 5 raw снимков в серии ощутимо лагало - сейчас немного лагает.
Сап, есть такая задача. Надо будет из json-ов, xml-ев или любого другого формата данных извлекать допустим что-то подобное:{"componentName" : "position","value1" : "i32","value2" : "i32","value3" : "i32"}Далее мы должны создать по образу и подобию блять структуру статического размера, а потом грамотно уложить её в массив, чтобы его не распидорасило по всему heap'у.Если бы это делалось сразу в коде, то ничего сложного, просто объявляем структуру с полями value1..3 и всё. Но проблема в том что я не знаю как это сделать всё в рантайме. То есть мне надо в рантайме создавать типы определённых компонентов, и потом соотвественно эти компоненты заполнять. Там будут лежать только фиксированные по размеру инты всякие, или же ссылки которые ведут уже в кучу (но они относительно не так часто будут использоваться).Надеюсь я понятно пояснил.
>>1612499Ну я думал над чем-то подобным, но мне показалось что мой пример какой-то всратый и потенциально проблемный. Что можно просто взять, объявить одну структуру допустим, которой мы просто укажем внутреннему массиву размер исходя из того сколько в этом типе все совокупно байт будет (ну допустим на 3 i32 у нас уходит 96 байт.), а также создадим "дешифровку" этих байтов (Передаётся коду который будет работать с определённым типом компонентов). Потом создадим экземпляр как ты сказал хэшмап или чего-нибудь пошустее (динамический массив тут норм будет.) и запихивать уже эти экземпляры.У меня тут просто возникает вопрос, как это всё дело будет укладываться в памяти, потому что с этими компонентами будет очень много тяжёлых операций, и это может обосрать всю производительность. В идеале конечно чтобы было вот так как на пикрелейтеде. Ну то есть чтобы они прямо вот так штабелями нахуячены были прямо в памяти. L1 кэш, все дела...Извините за такие ебанутые вопросы, просто я совершенно не знаю во что там и как Раст превращает процессы укладки данных в памяти. Алсо ХэшМэпы не шибко медленные?
>>1612537Такой структуры в расте по-моему нету. Есть только tagged enum, но там каждый элемент будет иметь размер самого большого элемента. Нужно городить самому с ансейфами, вот кое-что сделал (только не гарантирую, что всё сделал правильно и там нет UB): https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0797858ab4cc20d8a42cc8669b81d2d9Новый размер массива вычисляется так:let new_size = self.bytes_size + size * 3;т.е. берётся размер добавляемого элемента и умножается на 3. Можно изменить по своему вкусу.Но есть несколько недостатков:1) Из-за отсутствия стабильного const-модификатора, приходится при каждом вызове вычислять Layout::new для TypeId и usize. Можно исправить с помощью lazy_static.2) Раст не гарантирует отсутствие коллизий для TypeId (что на самом деле пиздец тот ещё). Можно вместо него использовать свои хеши, вычисляемые в компил-тайме и в которых гарантированно отсутствуют коллизии.3) Из-за отсутствия стабильных unsized rvalue, в таком контейнере лучше не хранить элементы с деструктором. Либо он будет вызван сразу после добавления в контейнер, либо не будет вызван никогда (как сейчас). Не решается никак, лол. Впрочем даже с unsized rvalues если не выполнить итерацию по всем объектам, то деструктор не-итерированных объектов не будет вызван (по идее решается стабильным ABI и апкастом в трейты, но такого даже в планах нету).
>>1612693Ну спасибо, буду разбираться. Вообще я просто хочу попытаться создать годную реализацию ECS с возможностью создания систем и компонентов в рантайме.https://en.wikipedia.org/wiki/Entity_component_systemВ общем подумаю ещё как это можно без ансейфа сделать хитро. Кстати не вдуплил зачем он на 3 умножается.
>>1612537Ещё можешь через кодогенерацию нагенерить все возможные типы, задать для них хранилища в главной структуре и матчилки в методах для складирования/извлечения.Т.е., берёшь какой-нить темплейтный движок, пишешь кодогенератор, присобачиваешь это всё к build.rs и вперде.
>>1612810Ну и идея конечно. А можно просто создать одну структуру, внутрь засунуть ей просто массив байтовый, или может другой метод хранения нетипизированной информации, (допустим у нас будет 256 байт максимум для каждого компонента), а уже потом в него кастить инты всякие, или ссылки допустим превращать в байты. Но вопрос встанет - какие вообще будут расходы на чтение и редактирование по сути своеобразных POD из этой структуры.>>1612804Ебическая сила какие они быстрые. Но опять же если туда не прикрутить внятную возможность именно в рантайме новые типы создавать (я все данные, большинство систем подцеплять думаю их луа и жсонов каких-нибудь), при этом не городить еботню какую-то, то эти либы в пролёте.>>1612803Ну извини, не умею внятно объяснять другим людям наверное.
>>1612794> Кстати не вдуплил зачем он на 3 умножается.Просто так. Чтобы не вызывать realloc при каждом добавлении элемента. Я ж сказал, что тюнить надо под задачу. Тут в отличии от стандартного Vec'a нельзя предсказать размер последующих данных.>>1612818> именно в рантайме новые типы создаватьТакого в расте не будет. Максимум будет как работа с нетипизированными данными функциями уровня `read_u32(&mut self, is_be: bool) -> Option<u32>` и проверочкой после каждого чтения. Разве что в расте можно обойтись без копирования данных, оставляя в структуре ссылки на слайсы с байтами. А вообще мне кажется ты что-то делаешь не так. Неужели нельзя каждый компонент описать до компиляции и всю ёблю с десериализацией оставить тому же serde?
>>1612886Возможно всё-таки придётся создать все компоненты непосредственно самим кодом, оставив просто фичу-возможность с помощью жсонов использовать какие-нибудь заранее слепленные-шаблонные компоненты, которые уже просто своими заплоняешь данными и вписываешь ему id. Нда, вроде задача не то чтобы сложная, в голове-то блядь решение представить можно, а язык не позволит такие кульбиты вытворять. Вот так пиздос конечно. Но всё равно спасибо аз помощь.>нельзя предсказать размер последующих данных.НУ вообще предполагалось что типы копонентов инициализируются 1 раз (под инициализацией понимается сборка самих полей, считка того сколько получилось памяти, сохранение где нибудь инструкций как это расшифровать, и собственно создание самого vec под этот тип компонента), и после инициализации они по-сути свой размер и поля право менять и имеют.
>>1612905Тебя просто сложно понять. Ты хочешь жсоном декларативно описывать компоненты, так? Но что ты с ними собираешься делать? Как-то их преобразовывать? А описание преобразования тоже будешь описывать в жсон-файле с компонентом? Тебе тогда тут целый интерпретатор твоего жсона надо будет делать. И раст тут не при чём, ты ни в каком языке подобное не сделаешь, чтоб работать с незнамо какими данными.> собственно создание самого vec под этот тип компонентаТак у тебя в массиве будет храниться один тип компонента. Я-то думал ты в массиве хочешь хранить разные компоненты и потому нагородил свой костыль, который позволяет складировать в себя разные типы (сохраняя их в TLV-виде), а потом их динамически преобразовывать при чтении обратно.
>>1612818> именно в рантайме новые типы создаватьВ чем сложность? Все компоненты заранее известны, собрать произвольную энтити на основе жсона нет никаких проблем.
>Тебя просто сложно понять.Да я сейчас со стороны посмотрел и подумал что я и правда какой-то поток сознания вывалил. Следующий раз постараюсь более последовательно задачу расписывать.>>1612921>о что ты с ними собираешься делать? Как-то их преобразовывать?Только создавать экземпляры типа и помещать в массив.>Так у тебя в массиве будет храниться один тип компонента.Да, для каждого типа будет создавать отдельный vec. То есть внутри этого массива они будут одинаковы. Давай опрпобую ещё раз.Есть тип компонента, он допустим магическим образом определяется в рантайме, и для этого типа также создаётся vec-массив. Для каждого типа компонента массив свой.После того как тип компонента создан, его поля изменять нельзя, а можно менять только значения этих полей.>>1612933В том то и дело что я намерился создать расширяемый за счёт скриптовых языков и таблиц данных (LuaJit, Json, TOML) движок. То есть возможно создавать компоненты и системы в рантайме.
>>1612921Он хочет, чтобы оно у него хранилось ровно разложенным по полочкам. Вот только размер полочек, как и размер хранимых данных ему заранее неизвестен. Вот, он думает, ща как создаст структуру в рантайме с в рантайме вычесленным размером, как начнёт её складировать в заранее отведённый вектор (?), так благодать на него и польётся.Т.е, его вопрос больше про оптимизацию. Чисто технически, полагаю, у него отработало и что-то вроде того, что на пике.Даже подозреваю, что решение его задачи всё-таки есть в каком-то крейте.
>>1612956Не совсем так конечно, подразумевается что эти структуры будут не векторы хранить со стандартными а сами будут в векторе, и хранить эти типы как обычно. Ну видимо я и правда идиотскую задачу задал не знаю.>заранее отведённый векторИмеется ввиду что для каждого вида компонента свой будет вектор. и создаваться он будет как раз на инициализации видов компонентов создаваться и определяться.
>>1612947> Только создавать экземпляры типа и помещать в массив.Ты не можешь создавать экземпляр того, что не существует на момент компиляции. Что мешает сохранять чисто данные? Создай хэш-карту HashMap<TypeTag, Vec<u8>> и в массив сохраняй в виде `длина,данные`. Где длина - фиксированный размер в байтах, а данные - непосредственно байты. А преобразование туда/сюда уже делай на уровне FFI хоть на расте, хоть на луе.
>>1612972> в виде `длина,данные`Впрочем если длина фиксирована, то её можно и не сохранять в массиве, а хранить непосредственно в тэге. Т.е. в массиве будут чисто данные друг за дружкой, а вот сами поля данных уже можно упаковать через TLV (тип,длина,данные), тип и данные будут идти через FFI языку и там уже преобразовываться в нужную структуру.
>>1612972Во! Действительно годное решение, наконец-то. Нижайший поклон. К слову, а поиск в этих хэшмапах и преобразования туда/сюда, много ли с них накладных расходов будет? Потому что чтение этих компонентов нужно будет делать быстро-быстро блядь.
>>1612982Ну если совсем беспокоишься о производительности, то можно вместо хэш-мапа использовать тот же вектор (или массив фиксированного размера) просто создать глобальный счётчик и при создании новых данных добавлять в глобальный вектор данных новый пустой вектор с компонентами (который и будет по адресу счётчика) и сохранять счётчик в самом теге, который и использовать для нахождения данных. Создания нового компонента станет медленней, а вот доступ быстрее.
>>1612985>доступ быстрееДоступ это процесс чтения/записи?Если да - то так и следует сделать.>>1612987Это вообще пустяк, они создаваться будут только на запуске программы, а вот читаться/записываться сами компоненты будут очень часто.
>>1612985И да, вектор в этом плане скорее всего совсем не подойдёт, ведь его придётся упаковывать в RwLock, плюс он может реаллоцировать а значит создание нового типа будет тормозить чтение любого компонента.
>>1612990Ну опять же, если типы будут создаваться только в 1 момент программы (на запуске), будет ли это проблемой? Сначала создали типы компонентов, потом заполнили экземплянами этих типов, а потом ебись оно всё в рот.Тогда и реаллокации не будет, я правильно понимаю?
>>1612989> они создаваться будут только на запуске программыТогда вектор будет идеален, да. Доступ фактически будет только O(1) на поиск контейнера типов. А как ты собираешься доставать данные? По индексу? Будешь ли ты их удалять? Преобразование в основном упирается в порядок байтов. Впрочем если луа использует машинный endianness, то для преобразования четырёх u8 в u32 достаточно вызвать mem::transmute (который вообще ничего не делает в рантайме) и просто сказать расту что это ссылка не на четыре байта, а на один u32.
>>1612998> А как ты собираешься доставать данные?И, кстати, что насчёт многопоточности? Я бы задумывался об оптимизации фрагментации памяти уже после оптимизации доступа из разных потоков. Потому что первое увеличит потребление памяти, а второе уже может дать значительные лаги.
>>1612998>А как ты собираешься доставать данные?По индексу, да. >Будешь ли ты их удалять?Буду, ну из можно просто освобождать если что, допустим создав в менеджере вектор свободных индексов.>Преобразование в основном упирается в порядок байтов.Тут будет только преобразование байтов в их формат который и имела информация до превращения в байты. А, ну ещё адреса указателей или что-то подобное. ПОтому что нужно будет в компоненты ещё строки пихать, или массивы (допустим компонент storage, который хранит массив id ентити.)
>>1615227Не совсем. У tagged union все типы должны быть известны на момент компиляции, в TLV-формате можно хранить типы, создаваемые в рантайме.
Человеки, есть ли у кого какая-нибудь краткая памятка (желательно инфографическая, тобишь картинкой) по всем основным аспектам языка?Я нигде сам не нашёл, поэтому спросил тут, может кто видел-знает. Если такой вообще не ведётся, наверное придётся делать самому
>>1617716Просто я в обучении часто люблю диаграммки простые составлять, как бы деконструировать по небольшим и легко понимаемым-запоминаемым примитивам одну тему. Предполагаю что подобного врятли можно найти в Rust, поэтому думаю - может и самому попробовать составить. Там будет всё по темам и зависимостям. Допустим Операторы и выражения, Типы данных и функции, визуальное отображение того как зависимость можно работать, краткое описание основных STD и прочие вещи. Эта памятка не будет на полноту информации претендовать, но я считаю что для того чтобы что-то быстро вспомнить или просто систематизировать начинающим инфу будет самое то. Но я пока сам только изучаю, поэтому мне интересно что вы скажете и чего добавите. Через некоторое время как мне инфы или идей накидают (или не накидают, кто знает) я начну делать её.
Ржавичи, куПочему раст не взлетает? И когда взлетит по-вашему? ЯП-то годный в плане концепции. Представьте себе мир без уязвимостей на низком уровне - это же просто охуенно. Бтв, даже если в ансейфе есть переполнение, его очень трудно эксплуатировать, так как лэйаут памяти программы не позволяет это сделать также, как в прогах, написанных на си и крестах. На мой взгляд, через лет 10-15 весь лоу лвл будет порабощен растом, целый пласт низкоуровневой безопасности канет в небытие и станет частью истории. Ну а Си и кресты уйдут на заслуженный отдых, языки явно несовременные и свое они уже отжили.
>>1618100Клянусь всем чем можно, что я не троллю. Но я не понимаю почему эти языки нельзя считать несовременными? Они держут высокий рейтинг в TIOBE только по одной причине - на этих япах написано ОХУЕТЬ как много легаси программ. Просто О Х У Е Т Ь как много. Но эти языки имеют проблемы, причем серьезные. Кресты набрали кучу стандартов и сейчас в мире есть только несколько людей, которые реально могут сказать, что они ЗНАЮТ кресты. И это разработчики известных компилятором для крестов. Все. Остальные кресты не знают, их НИКТО не знает. Си - вообще отдельная история. Этот язык - сама по себе уязвимость.Почему раст, имея бинарную неуявимость (хорошо отдебаженный код на расте практически невозможно взломать, только если будут логические ошибки, которые найти ОЧЕНЬ трудно, ошибки работы с памятью, которые детектятся санитайзерами и фаззерами, идут лесом), не может заменить их в нише лоу левела? Напишут пару ОС на расте, они наберут популярность и все.
>>1618121Имхо люто играет синдром утёнка. Но при этом востребованность всё таки формируют бизнез компании, а им пока что далеко не всем есть что в расте ловить. Годных либ раз-два и обчёлся, а те что есть написаны с использованием того же ансейфа (ну не могут люди просто так изменить своё мышление и перейти с байтоёбства на более общие архитектурные решения или методы)Конечно это только моё мнение, самому интересно как чзцк будет развиваться.Но опять же не стоит забывать про его сложность. Я вот только сейчас вкатываюсь и понимаю что материалов которые бы конкретно и поэтапно подавали инфу нету. Тех двух книжечек явно недостаточно потому что я читаю и у меня глаза на лоб лезут нахуй от того как автор вроде рассказывал сначала про типы данных а потом залез в макросы и модули при этом ничего не пояснив, мол смотри читатель блядь как я умею. Понятное дело что там одно за другое цепляется, но блять, без нормального разделения и структурирования такой язык как раст проглотить будет ебейше тяжело.>>1617849Тут я к слову описал что хочу сделать. Думаю такой метод подачи не только мне зайдет.
>>1618192Можно сразу начать с того чтобы описать основой синтаксис и как и почему блять скобочки точечки эти нахуй выставляются, почему где то используются круглые, а где то <>. И всё это без описания самой std поначалу. Чтобы какая-нибудь хуйня типо Box<[Option<mut Container>]> не погружала неофитов с тантрум, а была вполне хотя бы относительно понятна что тут с чем пытается что сделать.
>>1618204О, благодарю! Вот из этого можно памяток наделать. Хотя возможно всё равно придётся как-то систематизировать всё это дело
>>1618198ide используй. Там оно подсвечивается и автовыводится.Вообще, скобочки и точечки не самое сложное в расте. Я, например, долго привыкал к тому, что нельзя просто взять и вернуть указатель (&), даже если ты сам результат получил уже в виде указателя. А потом, чё-т, раз и привык.
>>1618230Ну ты смотри на сложность которая вызывается от привычки (индивидуальная для каждого) и сложность которая вызывается от самой комплексности какой-либо вещи. Если в Расте очень много пересечения функционала и возможностей (как собственно и должно быть не спорю, но на понимание языка это влияет сильно), то это дико замедляет процесс понимания, потому что башка на плечах не в состоянии всё это дело грамотно распутать и разбить на удобоваримые кусочки-концепции. И вот тут у меня взорвалась жопа. Сейчас пока разберусь сам насколько смогу, потом надо реально подумать над тем как это всё дело переварить и высрать в виде понятном.
>>1618245Поставь ide и сразу пиши, не еби мозг. Я поначалу пытался через vim с одной только подсветкой его освоить - знатно охуевал. Потом накатил-таки идейку и процесс пошёл.Подозреваю, что и ты также мучаешься.
>>1618263Что сразу "не еби мозг"? Будто тебе лишний раз боязно разобраться более фундаментально в том что ты делаешь (или просто дед который не чует муки нюфань уже). VS Code вместе с дебаггером ЛЛВМ я давно установил уже, но я хочу сразу заложить базу понимания какбе.
>>1618192>Тех двух книжечек явно недостаточно потому что я читаю и у меня глаза на лоб лезут нахуй от того как автор вроде рассказывал сначала про типы данных а потом залез в макросы и модули при этом ничего не пояснив, мол смотри читатель блядь как я умею.Два чаю. Чуть не обосрался, пока не понял, как работает хендлинг ошибок с помощью комбинаторов в rust-by-example. Энивей, после 3 лет пердолинга в плюсах, лично для меня раст - это охуеннейший язык.
Вкатываюсь в раст после многих лет байтоебства на Си, по большей части работа с пердоликсомИзучаю книгу Программирование на языке Rust от O'ReillyБудут советы, кроме очевидного, что раст не нужен и денег мне не принесет. Я для развития как личности
>>1618337Вообще как я понял основная суть Раста в том, что он пытается занять нишу крестов, но при этом сам подход к разработке ПО довольно сильно отличается от плюсов, это надо понимать. Потому что я уверен что первое время (а может и второе) раст смогут осилить только как раз крестовики, и притащут туда свои знания и методы работы, превратя код в клубок ансейфа и попыток в наследование лол. Я конечно сам пока в процессе постижения, но уже явно видно что у Раста другой путь решения задач. Часто придётся пересматривать саму постановку задачи и методы её выполнения, чем начинать писать костыльный и небезопасный код, что по привычке C/С++ очень даже поощрял (неопределённым поведением, ага.)
>>1618558Если хочешь писать нормальный код на Rust, идею байтоёбства желательно погасить, потому что она будет постоянно подталкивать тебя на нарушение правил, и весь основной сок безопасности в Rust просто будет невилирован
>>1618573>раст смогут осилить только как раз крестовикида лан те, я вон, кресты не смог (не захотел) осилить, сразу на раст полез.А те крестовики, которые идут в раст, они, как раз, стараются быть святее Папы Римского, из-за комплекса новообращённых. Как нигеры в Африке головы друг другу режут, доказывая, что ислам/христиантсво самая миролюбивая из религий, так и растовики затравят кого угодно за лишний ансейф (не путать с ансейфами в ffi коде и всякой лоу-лвл работе с железом - они не лишние).
>>1618596Ну не знаю, сдаётся мне и те и те там есть в примерно схожих пропорциях. Одни травят других.Я вот лично вообще никакие языки не знал, Сначала кресты пытался осилить, вроде начало получаться но потом дропнул потому что пришлось заниматься другими вещами. Потом вернулся но уже на Го, мне он показался минималистичным и прямо то что надо, только потом просёк насколько он медленный по сравнению с крестами и пошёл дальше искать. Вот нашёл Раст, вроде всё устраивает.
>>1618596> затравят кого угодно за лишний ансейфОдна из проблем это популярность актикса. То есть раст позиционирует себя сейфовым, при это одна из самых популярных либ не особо сейф. Отсюда и предъявы.
>>1618601Ну вот и ЧТД, потому что толковые программисты которым было интересно двигать Раст и имеющие опыт написания серъёзного ПО работающем на низком уровне, скорее всего вышли-то из крестовиков, а там у них выдрачивать байты из компа это привычка, потому без ансейфов им очень неудобно. Ну как бы блядь, не скажу что это плохо, это наиболее вероятный и логичный исход скажем так. Конечно исправить его можно только собрав группу матёрых спецов по Расту (вопрос откуда таких наколдовать) которые бы сделали тот же самый велосипед, но уже без ансейфа. Выглядит как аутизм и какая-то ебанутая игра политическая.
>>1618601https://github.com/actix/actix/search?q=unsafe&unscoped_q=unsafeХотя так посмотришь, вроде не шибко много-то его. Или может я чего-то недогоняю
>>1618607Именно, что там ансейф был использован в том месте, где без него вполне можно обойтись. Даже так: на базе ансейфа был сделан костыль, чтобы "обмануть" конпелятор.Я вот сейчас vulkano использую и периодически в него заглядываю - дак там чем глубже в код, тем толще ансейфы - а иначе в работе с железом (не совсем, но железо накладывает долю неопределённости) никак.
>>1618623Кстати интересно знать сколько эта обётрка отжирает по перфомансу. от нативного вулкана.тоже програть игрульечку хочеш?
>>1618646Не, у меня больше по машинному зрению и вычислительным шейдерам интересы.игрульку вот прям на вулкане с нуля - я бы не стал. Оно вроде и заманчиво, а на деле пуд соли съешь и 1000 раз пожалеешь, что не взял готовый движок. Лучше сосредоточиться на сюжете/графоне/геймплее.
>>1618655Ну смотря конечно какую игру делать. У меня как-то давно загорелось в жопе сделать рогалик где бы механики всякие и симулятивность сука ух бляя. Я полтора года носил эту идею в голове думал ну блять тяжело наверное такое воплощать сука! Временами выливал свои мысли и решения геймплейные алгоритмические о том как те или иные вещи лучше делать, но пиздец, идея до сих пор не отпала, дерёт сука голову и всё, ну я подумал ну хуй с ним будем делать блядь. Вот сейчас учу. решил движок с нуля писать (ну може какие либы подтяну типо bearLib) потому что мне нужен ECS с возможностью рантайм компонентов, мне как раз выше аноны помогали с этим.
Быстрый вопрос. У вас в расте есть аналог parameter pack крестов или какой-нибудь другой способ определять список типов?
>>1618674>parameter packне знаю, что за зверь, но по звучанию похоже на trait в расте. Или объясни подробнее.
>>16186071) Ты не там ищешь. Нужно искать втрепе actix-net: https://github.com/actix/actix-net/search?q=unsafe&unscoped_q=unsafe2) Ансейфов там мало, потому что они используются в фундаментальных типах, которые потом используются везде. Например вот эта функция нужна чтобы ебать borrow checker в рот: https://github.com/actix/actix-net/blob/631cb86947cb2a3d2ccce2db59cf8e6d6fc23680/actix-utils/src/cell.rs#L40 и помечена она как безопасная (сам тип является аналогом UnsafeCell из стандартной библиотеки, только где все unsafe-функции помечены как безопасные), хотя может вызывать UB.
>>1618868> вот эта функцияУпс, ошибся. На одну ниже: https://github.com/actix/actix-net/blob/631cb86947cb2a3d2ccce2db59cf8e6d6fc23680/actix-utils/src/cell.rs#L45
>>1618871> pub(crate) unsafe fn get_mut_unsafe(&self) -> &mut T {Хм, хотя её уже пометили как ансейф (последний раз когда смотрел она была безопасной). Вот что значит уход говнодела. Сразу качество софта повышается.
>>1618874Ну бля, почему сразу говнодела. Без него актикса вообще не было бы, хуёво конечно что он такой UB код высрал, но его всяко теперь можно исправить без особых заморочей чем всё писать с нуля.
>>1618700https://en.cppreference.com/w/cpp/language/parameter_packЯ думал в раст перекатываются только бывшие крестовики, которых заебал бардак.
>>1619837>>1619837Мне го не понравился. Отсутствие дженериков после динамического языка причем даже в нем есть их подобие и кривое ООП отбивают все желание.
>>1619863Можно. Берёшь какую-нибудь regex либу и пишешь. В std работы с регексами нет, только со строками.
>>1619882Не какую-нибудь, а вполне себе оффициальную: https://github.com/rust-lang/regexПравда если он начнёт использовать мега-фичи регулярных выражений, вроде lookahead и lookbehind, то тогда уже придётся переходить на биндинги для PCRE.
>>1619898>мега-фичи>lookahead и lookbehindДожились, это стало мегафичей. обычная и нужная вещь, особенно когда у тебя есть свое экранирование по бэкслешуТеперь все что не реализовано превращается в "ненужно" как у гоферов?
>>1619876> и кривое ООПВ расте ООП вообще нет. С одной стороны мне после жавы (где ООП в основном используется в виде "один класс наследует интерфейсы") неудобств не предоставило, но с другой из-за отсутствия GAT [1] и отсутствию impl Trait [2] в ассоциативных типах (вторая фича по сути не даёт функциям из трейтов возвращать анонимные объекты, соответствующие какому-то трейту, а первая не даёт вместо со второй фичей возвращать трейт, который хоть как-то зависит от входных параметров) очень неудобно. В жяве я привык всегда возвращать интерфейс, а какой класс там на самом деле его имплементирует - скрывать, а в расте пока это невозможно.Надеюсь обе эти фичи в этом году завершат. Они обе необходимы для нормальных асинхронных функций в трейтах (потому что там та же проблема - возврат анонимных типов, о которых вызывающему будет известно только что они имплементируют трейт Future).[1]: https://github.com/rust-lang/rust/issues/44265[2]: https://github.com/rust-lang/rust/issues/63063
>>1619908> Теперь все что не реализовано превращается в "ненужно" как у гоферов?Я честно не знаю реализовано оно в го или нет. В крейте regex но точно не реализовано, потому и предупредил.
>>1619909Есть Box<dyn Yoba>. Просто жава тебе не рассказывает про цену возвращения интерфейсов, а раст прямо в ебло запихивает боксами.
>>1619948Я в курсе. Но я и перешёл на раст потому что хочу перформанса (в том числе ценой меньших аллокаций и работой напрямую с объектами без vtable). Насчёт dyn я в курсе. Например я его использую в одной рекурсивной функции. Сначала пытался использовать impl, но раст выдал мега-ошибку, потому что сам тип тоже рекурсивный и после 128 (по-моему) инстанциаций там была ошибка с гигантским Type<..., Type<..., Type, ..., ...>>>. Но и всё равно обошлось без Box - просто передавал ссылку &mut dyn Type.
>>1619672Как я понял, это аналог args/*kwargs гвидона. Есть RFC https://github.com/rust-lang/rfcs/issues/376А пока вот так: https://doc.rust-lang.org/rust-by-example/macros/variadics.html
>>1619837>го1. Пока что ниша го куда уже, чем потенциально у раста, хотя в этой самой нише он (го) довольно прочно закрепился. Раст также широк, как гвидон, и даже чуть шире (для машобчика только биндингов маловато)2. Периодически проплывают новости об отказе от го в пользу раста, но не наоборот (может я не те новости читаю)
>>1620080https://www.reddit.com/r/godot/comments/f07564/kotlin_gdnative/?utm_source=share&utm_medium=web2x
>>1620189>Kotlin GDNative bindingsСпасибо конечно но нах оно когда я про Rust GDNative bindings прашиваю
>>1620048>Есть RFC https://github.com/rust-lang/rfcs/issues/376>2014>https://github.com/rust-lang/rfcs/pull/2775>This RFC introduce variadic tuples, and API to handle tuples with an arbitrary arity.>2019Понятно.
>>1619909> GAT > в этом году завершатЯ искренне завидую твоему оптимизму IIRC его же там взялся делать только один чувак, который потом сказал "ну нахуй". Хорошо бы хоть const generics запилили.
Изучал всякие интересные хуёвины по типу Option<> и Box<>.Немного невдуплил зачем нужен Box<> вообще. Понятное дело что Option<> решает важную проблему (которую зачем-то намеренно создали), но не понятно нахуя бокс. вроде как любые структуры, массивы и векторы и так выделяются в куче.
>>1622019Box - это умный указатель, который не может быть скопирован. В основном используется там где ссылки использовать невозможно (например из-за отсутствия GAT и unsized rvalues) либо чтоб не нагромождать структуры шаблонным временем жизни и вместоstruct A<'a> {b: &'a B,}написать просто struct A {b: Box<B>,}>>1622024> Не все.Массивы наоборот всегда выделяются на стеке. Чтобы заставить раст выделить массив в куче как раз и надо использовать Box. И с этим у раста есть проблемы, потому что он вместо того чтобы сразу сделать массив в памяти, сначала делает массив на стеке и потом копирует его в память: https://github.com/rust-lang/rust/issues/53827 Особенно весело выглядит с MaybeUninit, когда со стека в память копируются неинициализированные данные, а стабильного способа создать неинициализированный массив в памяти до сих пор нет: https://github.com/rust-lang/rust/issues/63291
>>1622024Да, хуйню сморозил точно, но всё ещё не понятно нахуя это дело выделять в боксы. Это допустим нужно для того чтобы со всякими структурами играться? ну инициализировать сразу походу пихать их в коробки и в массив, кортеж или хуй пойми куда. Не доходит что-то.
>>1622033Вот, спасибо за пояснения, но пока не совсем понял что такоеGAT и unsized rvalues до конца. Это как-то связано с теми данными и переменными которые во время компиляции устанавливаются?
>>1622033>Массивы наоборот всегда выделяются на стеке.Интересно насколько это на самом деле больная проблема. Просто мне кажется что обычно когда мы ходим выделить массив в куче, то там лучше применить просто вектор сразу чтобы лишний раз не ограничиваться. Хотя могу ошибаться.
>>1622033> а стабильного способа создать неинициализированный массив в памятиНу хотя я конечно приврал. Можно напрямую использовать аллокаторhttps://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5b115ddabc5b0f6eb5f12817a345672e
>>1622035Unsized rvalues нужны чтобы можно было на стеке создавать переменные неизвестные на момент компиляции размера (ну и так же передавать их в функции и возвращать). Например dyn Trait - это переменная с неизвестным размером, потому что неизвестно какого размера будет структура, имплементирующаа trait и какого размера будет vtable. Потому dyn Trait можно передавать в (и возвращать из) функций только в виде ссылки (&dyn Trait) или внутри указателя (Box<dyn Trait> или (A)rc<dyn Trait>). Тоже самое касается слайсов - массивов, где количество элементов вычисляется в рантайме.GAT нужны чтобы внутри трейта можно было создать генерики, которые будут зависеть не только от шаблонных параметров самого трейта, но и от параметров функции где они используются. Например чтобы функции из трейта могли возвращать структуры с шаблонным временем жизни, как здесь: https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=14b4218a38b94f3b4cbf45d8d8a8c464 Сейчас нужно использовать умный указатель для этого: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=37029a81774effb1c091546d564c98d3
>>1622042>>1622044Неинициализированные массивы всегда будут ансейф. Даже массив [u8; X] без инициализации - ансейф (хотя его использование не может быть UB, поскольку любое значение корректно для u8). Такова позиция разработчиков раста.
>>1622069Ну более мене вдуплил насколько могу, спасибо>>1622072Ну что делать, свыкаться только. Но мы же можешь проинициализировать массив структур допустим через Option<MyStrcuct> как None, а потом уже запихать в него в рантайме что надо или просто в другом куске кода?
>>1622075> Но мы же можешь проинициализировать массив структур допустим через Option<MyStrcuct> как None, а потом уже запихать в него в рантайме что надо или просто в другом куске кода? Для этого есть MaybeUninit: https://doc.rust-lang.org/std/mem/union.MaybeUninit.html но опять таки функция assume_init является небезопасной, потому что компилятор никак не сможет проверить ты точно всё инициализировал правильно или нет.
>>1622078Да уж, с растом приходится от души так перепахивать свои подходы к написанию программ. Ну может оно и к лучшему, раз от этого более безопасный код получается.
>>1622080Впрочем ты можешь использовать Option для инициализации, но у него есть пара недостатков:1) Он может занимать больше места, потому что должен хранить в памяти ещё и состоянии - инициализирована переменная или нет.2) Доступ не нему будет всегда медленней, потому что при каждом запросе ко внутренней переменной он будет проверять инициализирована она или нет.
>>1622072>хотя его использование не может быть UB, поскольку любое значение корректно для u8Значение неинициалированного u8 - это undefined, оно не корректно. С т.з. ЛЛВМ.
Ух ебать. Там корутины в эмбеддед завели: https://ferrous-systems.com/blog/async-on-embedded/Теперь (в 99% случаев) не надо ебаться с прерываниями, синхронизацией и прочим говном. Можно просто все прерывания оборачивать в асинхронную функцию и работать как с сихнронными методами. Жалко что для работы в стабильной версии надо ждать пока https://github.com/rust-lang/rust/pull/69033 дойдёт до нее. Если успеют запушить в версию 1.43, то через пару месяцев будет в стабильной. Иначе ещё пол-года ждать.
Салют, ржавые. На связи крестовик, пишущий крипту на работе. Стоит ли пробовать раст? Что сложного будет? Говорите порог вхождения высокий, что именно сложное?Я попробовал чуток, мне понравилось что есть карго и нормальная поддержка модулей.Какие подводные короч?
>>1623221Представь, что ты всю жизнь дрочишь себе рукой. Дрочишь, дрочишь, уже привык, даже не кончаешь через пару секунд. И вдруг у тебя появляется девушка! Приходится переучиваться, учиться двигать бёдрами, а не рукой, туда-сюда, хуяк-хуяк. И охуеть как сложно, и ТНН, и хочется просто взять всё опять в свои руки.Вот такие же подводные и в расте. Он охуенный, но твоей фирме не нужны твои дети, потому что она не хочет оплачивать тебе отпуск.Ну и заебёшься всё расписывать, потому что раст не может тебе превратить i32 в usize, когда ты пытаешься достать что-то из массива через индекс. Это круто, примерно как TypeScript по сравнению с жаваскриптом, но макаки часто не могут осилить TS.
>>1623381> И вдруг у тебя появляется девушка!И у этой девушки одна сиська. Не то чтобы мешает основному действу, но неприятно, особенно когда пытаешься что-то помять рукой в этом месте, а там ничего нет. А родители девушки уже который год кормят обещаниями, что скоро пришьют и вторую и она станет полноценной.
>>1623401Да не, сисек у неё две (системный же язык, можно что угодно написать, надо только немного хуй поднять и через ногу плюнуть). Вот нос с горбинкой и размер у сисек всего первый, но обещают скоро исправить операцией.
>>1623404>системный же язык, можно что угодно написать, надо только немного хуй поднять и через ногу плюнутьТо есть сиська как бы есть, но ее нужно пришивать своими руками
>>1623404Как миниум из-за отсутствия const generic там нельзя написать кучу абстракций (попробуй например передай в println! массив с более чем 32 элементами). Ну и плюс мегаубогий трейт Read, который используется повсеместно и в который нельзя передать неинициализированные данные без UB. Даже стандартная библиотека признаёт что использует UB (да и все кто хоть как-то заботится о перформансе так делают). Слава богу асинхронную версию Read уже пишут специально затачивая под неинициализированные массивы.
>>1623381Лол, а чем этот сладкий хлебушек от майкрософтов лучше? Зачем кушать хлебушек, если можно на чистом жиэс писать? Никогда не понимал эти тайпскрипты, пурскрипты, кофескрипты...
>>1623530Конкретно тайпскрипт лучше за счёт строгой типизации. Позволяет часть ошибок вывести из рантайма в компил-тайм, ну и в целом крупные проекты легче делать со строгой типизацией (особенно если есть проблемы с тщательным документированием каждого метода и написанием тестов).
>>1623221> Стоит ли пробовать раст?Однозначно стоит. Даже если не подсядешь, вынесешь для себя что-то полезное назад в плюсы.> Что сложного будет? Говорите порог вхождения высокий, что именно сложное?It depends. Смотря что ты уже умеешь/знаешь. Думаю после плюсов будет очень хотеться обмазаться указателями, а нельзя. Субъективно для меня было самыми сложными вещами (по нарастающей) - лайфтаймы, различие между (fn, Fn, FnOnce, FnMut), HRTB, ну и процедурные макросы.Вообще самая большая проблема - надо начать думать немного по-другому, и строить программы немного по-другому. Но это справедливо при переходе на любой другой язык почти. Первое время будет бомбить как у анона выше> потому что раст не может тебе превратить i32 в usizeно потом ты поймешь, что это абсолютно разумные ограничения.Ну и не хватает иногда каких-нибудь возхможностей языка, приходится ждать, пока сделают/стабилизируют. Но думаю тебе не привыкать, C(++) изменения лет по 10 делают.
>>1623572Так я и не говорил, что неразумные, я эти ограничения сравнил с TS vs JS, если ты не заметил. Но не все макаки могут в TS, как я уже говорил.
>>1623530>эти тайпскрипты, пурскрипты, кофескрипты...Тайпскрипт - это жс со статическими типами.Пурскрипт - это язык вроде Haskell, только трнаслируется в жс. В отличие от Elm, там есть монады и вся остальная дрочь, но на нём никто не пишет, потому что сложна. Кофескрипт - это был такой синтаксис сахар, придуманный рубистами, потому что обычный жс для них был недостаточно гибок и эстетичен. Не актуален начиная с выхода ES6.Инбифо: сорта говна
>>1623572> Fn, FnOnce, FnMutС этой хуйнёй больше всего бесит, что сейчас в расте они являются МАГИЕЙ и по сути встроенными вариадик генериками в языке. Отсюда вытекает то, что эти трейты невозможно имплементировать в свою структуру - только использовать синтаксис замыканий.
>>1623976Как я пригорел с этой хуйни, изучая комбинаторы раста - просто пиздец. До последнего не хотел гуглить, но все же. Единственное, с чего жопа на марс улетела за всё время изучения языка, наверное.
>>1624212Как делаю я:1. Кодишь на языке, как если бы это был Си, только с хитрым борроу-чекером2. Постепенно начинаешь осваивать фичи, про которые что-то слышал, но боялся применять на этапе 1. Трейты, дженерики, лайфтаймы.3. Постепенно начинаешь осваивать фичи, про которые что-то слышал, но боялся применять на этапе 2. Замыкания, dyn трейты, процедурные макросы...N. Постепенно начинаешь осваивать фичи, про которые что-то слышал, но боялся применять на этапе N-1.как делаешь ты, и многие другие аноны: выучить ВЕСЬ язык, прочитав БОЛЬШУЮ, сука, книжку.Бля, ну хуй знает, кто из нас прав, может быть даже я не прав. Но мой путь полегше будет.
>>1624256Жопа начинает гореть примерно на втором шаге когда начинаешь натыкаться на сообщения компилятора, что эта фича экспериментальна и вообще идите нахуй.
>>1622873У LLVM только чтение неинициализированных данных - UB. В расте даже ссылку брать нельзя - сразу UB (можно брать указатель). А трейт Read ничего кроме ссылок не принимает. При том есть те, кто такое поведение защищает и считает, что обнуление памяти перед использованием массива должно быть обязательным (как в языках уровня жявы), а все кто не согласны могут не использовать std.
>>1624812>, а все кто не согласны могут не использовать std.Или как все нормальные люди использовать вот эти функции, которые как раз предназначены для лоу левел пердолинга.https://doc.rust-lang.org/std/ptr/fn.write.htmlhttps://doc.rust-lang.org/std/ptr/fn.read.html
>>1624983Ты нихуя не понял о чём речь. Есть стандартный трейт для чтения данных: https://doc.rust-lang.org/std/io/trait.Read.htmlИ вот функция непосредственно для чтения:> fn read(&mut self, buf: &mut [u8]) -> Result<usize>Переменную buf без UB можно передать только предварительно инициализировав, потому что передаётся не указатель, а ссылка. И этот трейт Read является одобренным STD для блокированного чтения вообще всего.
>>1625258И что самое смешное сама std использует UB с этим трейтом для более быстрого чтения: >>1623410Но им можно, они ж разработчики компилятора. А всем остальным - низзя. Не для скорости раст создавался, как вы не можете понят.
Если угасающая Мозилла продастся Микрософту, то что будет с растом? Сможет ли Микрософт серьёзно нагадить расту после покупки Мозиллы? Или сообщество раста настолько сильное, что сможет развивать без разрабов на зарплате?
>>1625394Микрософт уже свой аналог раста (только лучше) разрабатывает: https://github.com/microsoft/veronaБез сопливых обойдутся.
>>1625396Ну вот под этим предлогом могут "обосновать" покупку Мозиллы, типа "нам ваш опыт раста пригодится".
>>1625434Да там и так из раста потихоньку утекают умы. Вон недавно алекс кринтон ушёл. Правда куда ушёл - неизвестно.
>>1625459>шутишь про два фреймворка за год на жс>переписываешь проект под каждый мейнстримовый язык раз в пару лет
>>1625394Почему именно микрософт?У них и так пачка мертвых технологий во всё больше загнивающей экосистеме
>>1625394>Мозилла продастся МикрософтуЕсть новость, где почитать? Мозилла, вообще-т, НКО, совсем продаться она не может.Алсо, у раста уже набралась критическая масса заинтересованных компаний и без мозиллы - можно будет забацать отдельный фаундейшн с донатами.
>>1625962Совсем недавно, когда новые архитектуры устройств выходили чаще, чем опенсорсеры успевали писать для них драйвера, у альтернативных осей не было шансов. Но сейчас, когда закон Мура больше не действует и время жизни архитектур увеличилось (тот же GCN вона сколько протянул) и будет дальше расти - кто знает, вдруг взлетит.
>>1625937> и чем же? Там лучше курсором было выделено. И очевидно он лучше тем, что сделали его ОНИ сами.
>>1626574Когда собираешь топовый комп, а выходящая через полгода игруля указывает его спеки как минимальные - вот это действует. А то, что сейчас, это кошачьи слёзы. Даже эти изменения 14->12->7 нм далеко не те, что раньше. До 3х нм доползут, а дальше жизни вообще не будет. Ещё 3d компоновкой пугают, но сразу проблемы с охладом, сводящие на нет полученные преимущества.
>>1626752Ну, то, что макакены нынче не думают о перформансе от слова совсем (см всякую хуйню вроде пабга или говнину из шапки, у которых графика 2012-го (ебаный кризис 3 в 2013 выглядел в 40 раз лучше) и требования как у ебаного космолёта даже по меркам 2020) — это, конечно, показатель.Да и не факт что до 3 нм доползут хотя бы лет через 5, даже 7 нм уже трудно окупить, всё же зависит от окупаемости инвестиций в конце концов.
>>1626989Опять макаки какую-то сраную магию хотят, блет.macro_rules! kek { ($float:expr, $code:tt) => {{ if $float.is_nan() { panic!("it' fucking NaN!") } else { $code($float) } }}}
Есть ещё вариант сделатьstruct Yoba { inner: f32 }impl Yoba {fn new(f: f32) -> Self { Self { inner: f } }fn mut(&mut self, f: f32) {if f.is_nan() { panic!() }*self.inner = f;}Поскольку Assign операция не оверлоадится, только так можно, всё время используя .mut().
Есть прога test1.rs https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=460eeee90939808deb1177ad4886ec98Если её запустить без аргументов, то она закономерно падает в панике, но при этом компилятор не показывает номер строки с ошибкой. Вместо этого показывает номер строки в одном из модулей растовской библиотеки(libcore/slice/mod.rs), но это не то. Как заставить компилятор показывать ошибочную строку именно в test1.rs?
>>1627061Нужно установить переменную окружения RUST_BACKTRACE в 1 и компилировать с panic = "unwind" в cargo.toml (но он так делает по-умолчанию). Там на 17 месте и будет main> 17: playground::main> at src/main.rs:6
>>1627062Ах да, если компилируешь в релизном режиме нужно установить в cargo.toml парметр debug = 1 (можно 2, но тогда код будет медленней, а 1 достаточно для бэктрейсов). Ну и на винде pdb-файлик он не копирует c exe-шником - надо ручками брать из каталога deps.
>>1627063Спасибо.Лишь с RUST_BACKTRACE=1 и panic=unwind не выводилось, а вот с debug получилось. Точнее с debuginforustc -C debuginfo=1 test1.rs
>>1627066Ну у меня в cargo.toml есть специальное указание для генерации информации для отладки в релизном режиме:[profile.release]panic = "unwind"lto = truedebug = 1Я её использую для логирования паники с этим крейтом: https://crates.io/crates/log-panics (там устанавливать RUST_BACKTRACE уже не нужно, потому что код записывают всю информацию в лог-файл в любом случае).
Как это заебало. Вот неужели нельзя как-то запросто указать, что U != T, чтобы дефолтная автоимплементация шла лесом?Сука, аж бесит.
>>1627960Очевидно же, что хочет преобразовывать Pet<A> в Pet<B> при помощи трейта From. Но конпелятор жалуется, что преобразование из Pet<A> в Pet<A> уже определено в std и потому его имплементация трейта недействительна.
>>1627963Вот именно. Я хочу преобразование для разных дженерик типов, о которых известно только то, что они именно что разные. Но известно только мне, я не могу донести это конпелятору, который жалуется, что у него уже есть определение для одинаковых типов и зачем, мол, ещё одно.
>>1604129Я помню первые тесты, раст болтался где-то между джавой и с++. Не буду хейтить, может и правда допилили и все там внутри стало шустро. Но больше выглядит как подгонка под все эти недо-тесты.
Есть несколько вопросов по расту, не охота с головой в него погружаться поэтому более общая картина.1) Насколько раст хорошо подходит для прикладных приложений. Это скорее будет похоже на разработку на С++ или будет уже какой-то уровень JAVA?2) Какие основные преимущества языка?3) Какие фатальные недостатки?
>>1628240Поясню, есть возможность выбрать язык под проект, раст выглядит таким универсальным языком с перспективами, хочется знать общую картину по языку.
>>16282401. Ближе к жабе в плане того, что есть инфраструктура либ и зависимостей и безопасная работа с памятью, а трейты похожи на интерфейсы. Даже лучше жабы в том плане, что нет сюрпризов в виде неожиданных null.2. Сахарный, безопасный, быстрый.3. Сложноват для начинашек, нельзя вот так просто взять и сразу начать писать большую приложуху, каждому разработчику придётся съесть свой пуд соли.
>>1628240>не охота с головой в него погружатьсяТогда я бы не советовалВсё-таки основные фишки языка слишком специфичны и требуют отдельного осиляторства >Это скорее будет похоже на разработку на С++ или будет уже какой-то уровень JAVAБлиже к жабе
А есть тут те, кто свалил с Go на Rust? Вы наверняка переписали свои проекты. И насколько (в среднем) изменилось количество строк кода? Хорошо ли заметен прирост производительности?
И участвуете ли в разработке системщины, или всё ещё барахтаетесь в тех нишах, для которых пригодны языки с GC?
>>1628351Лично я на расте из серьёзного написал (точнее переписал с C#) только специальный сервер, который общается с устройством через COM и передаёт данные дальше через GRPC. Разница только во времени запуска программы и потреблении памяти (с C# было около 160Мб, на расте 1.4Мб, лол).
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=33170bf169071d25bd0ffce3356fba4cПонимаю, что ничего не понимаю, но помогите мне рализовать такую простенькую макакофабрику. Переписываю один свой старый проект, где очень нужно что-то похожее на то, что я попытался изобразить.Или это незаконно вообще -- делать фабрику dyn Trait?
>>16284111) Тут> struct Factory<T: Animal + FromString + ?Sized> {можно оставить простоstruct Factory<T: ?Sized> {в расте в определении структуры параметры нужно уточнять только в том случае, если это необходимо. В твоём случае необходимости в Animal и FromString нет.2) Тут> impl<T: Animal + FromString + ?Sized> Factory<T> {нужно убрать FromString. Он в имплементации не используется и потому может быть спокойно удалёнimpl<T: Animal + ?Sized> Factory<T> {После этих исправлений код компилируется и работает.
>>1628411> Понимаю, что ничего не понимаюИ да, код не компилировался потому что у тебя две ошибки:1) dyn может использоваться только с одним трейтом, а ты требовал, чтобы параметр T имплементировал два трейта: Animal и FromString. В теории этом можно решить определив трейт Animal так:trait Animal: FromString { fn say(&self) -> String;}тогда каждая структура имплементирующая Animal должна будет имплементировать и FromString. но тут возникает вторая проблема:2)trait FromString { fn from_string(s: String) -> Self;}> fn from_string(s: String) -> Self;Такая функция (где нет параметра self) не может использоваться в dyn-трейтах. Можно "исправить" заставив функцию быть невидимой в них:trait FromString { fn from_string(s: String) -> Self where Self: Sized;}тогда Animal может быть зависим от FromString и быть использован в dyn-трейтах. Но такой код уже начинает попахивать. Да и самой фабрике FromString как бы не нужен.Впрочем ей и Animal не нужен (тогда зачем вообще там параметр T?). Почему бы просто не сделать> impl<T: ?Sized> Factory<T> {?
>>1628454Анон, спасибо большое, что нашел время на разбор моей дрисни! Я, в общем, хотел просто описать контракты, чтобы во время компиляции все упало, если структура не реализует FromString (в реальности там будет json::Value, и из него будут браться данные для инициализации структуры) и не реализует Animal. Но я вообще не в том месте решил городить ограничения, фабрике вообще должно поебать, как оно там все будет реализовано. Великолепно меня Раст пнул за непонимание того, что я хочу на самом деле сделать.Написал чуть более обобщенно. Не очень понимаю, как все же далее ограничить в фабрике регистрацию только тех dyn Trait, для которых будет реализован FromString. Этот трейт важен, так как, как я уже выше говорил, на самом деле там из JSON данные разгребаться будут, это такой конструктор, и без подобной фабрики мне не решить задачу.>>1628467Спасибо и тебе, дружище! Сейчас экспериментировал и самостоятельно дошел до всего, что ты расписал, и примерно начал ситуацию понимать. Есть надежда, что я не совсем идиот.> trait Animal: FromString {Я тоже подумал, что это что-то не совсем адекватное, хоть и полностью решает вопрос с жестким контрактом на этапе компиляции.Поэтому буду искать другое решение, но пока не сильно понимаю, в какую сторону идти. Насколько понимаю, я не могу от dyn Trait требовать реализации какого-нибудь интерфейса трейта.
>>1628484Ты хочешь динамику, которая тебе всё обработает в рантайме. Но дело в том, что все этиtrait Yoba и fn foo(a: YobaType) -> Yobatypeработают только на этапе конпеляции. Чтобы разграничить структуры в рантайме, надо навешивать им флаги. Если у тебя там всё просто, то эти флаги элементарно енумом можно сделать:enum Flagged<D: Data> {Foo(D),Bar(D),}fn try_pet(d: Flagged) -> Option<> {match d {Foo(data) => pet(data.into_animal()),Bar(data) => None, // It's bot animal!}}
>>1628625У меня порт с ECMAScript-языка (AS 3.0).> Если у тебя там всё простоСмотря что имеешь в виду. Структур там ну сотни, наверное. Попытаюсь объяснить, с чем вообще имею дело.Есть JSON-сопля примерно такого содержания: https://pastebin.com/WMc001ShВ `actions` описана декларативно игровая логика, и у нас тут в каждом действии могут быть десятки разновидностей Requirement, Amount (вместо числа 30 мог быть сложный объект для расчета скидки при покупке) и прочее такое. Прикладываю примерные иллюстрации того, как все выглядело в оригинале.В рамках изучения Rust пытаюсь реализовать что-то похожее, но пока хуйню делаю какую-то.
ozon обезумел (?) и продал пикрил за 1678р, хотя обычно зарубежные издания продаются у них по 5-7 тысяч рублей ( не знаю уж кто их покупает за такую цену, видимо мутанты какие-то ). Получилось даже дешевле, чем с amazon'а ( тем более с сегодняшним-то курсом доллара, ололо ). Похоже был единственный экземпляр и после моего заказа эта позиция стала более не доступна.Кто-нибудь на ozon'е с таким еще сталкивался? Что это, просто они что-то перепутали, либо ж иногда годнота все же у них продается без запредельной наценки?
>>1627963>>1627984Незнаю уж что вам там очевидно.По факту он хочет Pet<T> -> Pet<T>Потому что если компилятор ничего не знает о A/B, то A = B = T
>>1628839>Потому что если компилятор ничего не знает о A/B, то A = B = Tну, вот ты, умный, расскажи, как донести до конпелятора, что я имплементирую для A != B, чтобы он шёл лесом со своей имплементацией для A = B
>>1628905Каким образом компилятор по твоему должен отличить тип A от типа B, если о них ничего неизвестно?
>>1628916>если о них ничего неизвестно?Как же неизвестно, когда известно, что А точно не В. Я даже готов сообщить об этом конпелятору. Куда писать, в какое окошко?Суть: у нас есть собаки, физически одинаковые (на уровне структуры), но есть дикие и домашние. Дикие имплементируют кусание, домашние - нет. Вот хочу я превращать диких в домашних со скоростью света - так как различий в структуре нет, мне нужно только копировать данные, ничего не меняя.https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=12cf296b2e20689c94aa73920c5a10ccпроблема в том, что речь не о собаках и не о всего лишь 2х типах, там их несколько больше. Я, конечно, могу заимплементить для каждого случая, но бля, зачем, почему, какого хуя - если все они одинаковые?
>>1628884#![feature(specialization)]Разве нет?Ну илиstruct Foo<A>(A);impl<A> Deref for Foo<A> {type Target = A;...}impl<A> DerefMut for Foo<A> {...}impl<A> Trait_1 for Foo<A> {fn yoba(self) { (self).yoba() }}struct Bar<B>(B);impl Deref for Bar ... { ... }impl DerefMut for Bar ... { ... }impl<B> Trait_2 for Bar<B> {fn other_yoba(self) { (self).other_yoba() }}
>>1628944Блин, забыл, что двач звёздочки жрёт. Короче, делаешь тип-обёртку под каждый трейт, имплементишь дерефы для обёртки и имплементишь сам трейт для обёртки через дереф. Там, конечно, надо написать<A:Trait_1>в паре мест, но вообще всё просто. Задерефить не забудь, там вроде видно, в каком месте звёздочки стоят.
>>1628943Т.к. ты не показываешь как ты хочешь это использовать, то вот, держи: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6f62e5c8fcb846343ad393ed44936ae2
>>1628964Просто хуёришь обёртку с <T> генериком. Потом под этот генерик подставляешь любую нужную структуру, которая может в impl Trait, потом через Deref имплементишь Trait для обёртки, и вуаля, ты можешь использовать трейт как структуру.
>>1628984Ты дурак? Он хочет донести trait solver'у, что хочет имплементировать From для всех T и U кроме T = U. Deref работает уровнем ниже. И сейчас это сделать попросту невозможно и даже в планах нет разрешать при проверке трейтов что-то кроме X = Y.
>>1629002Я думаю, что надо понять, что он хочет на самом деле. Потому что вероятно, есть более подходящие варианты достичь результата.
>>1628984В твоём примере есть Dog, который может конвертироваться в Pet(Dog) и Wild(Dog). А вот чтобы Pet(Dog) <-> Wild(Dog) - такое можно? А Pet(Poodle(Dog)) <-> Wild(Dog) ? Как я понимаю, нужно конвертить Any(Dog) -> Dog, но что-то не вдуплю с разбегу, как это.спать пора, видать Нужно именно это, так как эти сущности должны сперва кусаться каждый по-своему, а уж потом превращаться одно в другое.
>>1629007Это блядские генерики. Просто делаешьimpl<A> Foo<A> {fn get(self) -> A {self.0}и пишешьlet foo = Foo(...);let bar = Bar(foo.get());
>>1629007Если ты хочешь контролировать фичи вкладывая типы в друг в друга, наверное как-то так: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b5a5337a290a8998914bdb1db8acfc2f
РЕШИЛ ВКАТИТЬСЯ В РАСТ@ПОЛОВИНА ЛИБ - "ЭТО АЛЬФОВЕРСИЯ, НЕ ТРОЖЬТЕ!"@ДРУГАЯ ПОЛОВИНА - БИНДИНГИ К ЦЭПЭПЭ
>>1629118Как тебе не стыдно. Ты забыл про самое важное:БЕЗОПАСНАЯ БИБЛИОТЕКА НА БЕЗОПАСНОМ ЯЗЫКЕ@2145 UNSAFE-БЛОКОВ
>>16294411) Небогатый пул либ, в проде этот яп соснет хуйца в виду отсутствия большого количества либ для решения самых разных проблем, а писать либы с нуля - прерогатива далеко не всех прогеров. Хуяк-хуяк и продакшн не получится, а бизнес этого требует.2) Есть кресты и си с огромной базой, огромным кол-вом специалистов. Раст как бы пытается быть безопасной версией оных, но это отличие недостаточно для того, чтобы все поголовно перешли с крестов и си на раст.3) Эзотерический синтаксис, не самый простой язык в общем (хоть кресты все равно сложнее, офк). В виду того, что это системный яп, он требует имплементации низкоуровневого дрочева по типу зацикленных связынх списков, которые нельзя заимплементить без ансейфа, который нивелирует всю мякотку безопасности раста. В итоге получается, что серьезный системный софт, написанный на расте, требует использования ансейфа во многих моментах, что убивает весь смысл раста как замену си и крестам. А шило на мыло никто менять не хочет, раст без безопасности - ненужная хуета, так как есть кресты и си с огромной инфраструктурой и тонной спецов. Да и весь легаси тоже надо как-то поддерживать.
>>1629479>раст без безопасности - ненужная хуетаНу это же вроде как редкие случае, узкие подконтрольные места? Есть ли смысл все в абсолют возводить?Проведу аналогию с null и тем как сейчас стали бороться с этим в управляемых языках (котлин, шарп, тайпскрипт...). В общем, смысл в том что вся эта борьба минимизирует проблемы с null, но полностью не решает. Так же остается класс задач, где null нужен.Почему и тут раст должен прям полностью быть safe (или прям это у них фанатичная позиция на этом)?
>>1629126>>1629118БИБЛИОТЕКА ДЛЯ ТРУ-ФП ЯЗЫКА@БИНДИНГИ К СИШНЫМ ЛИБАМВас никто не ограничивает в выборе путей для профессионального развития. Вы же не сотрете свои высеры в старых тредах, если вдруг Раст или Хаскель победят в мире разработки ПО лет через двадцать. Зачем срать тогда? Берите из разных технологий, языков, фреймворков и паттернов лучшее, срывайте лучшие из плодов человеческой мысли.
>>1629562ансейф ансейфу рознь. Одно дело, когда ты делаешь что-то вроде transmute и в том, что внутри валидные данные, ты мамой клянёшься.А другое, когда ты наябываешь борроучекер, со словами "ну не, тот поток точно записать ничего не успеет" - а потом оно успевает в продакшене.>>1629562>класс задач, где null нуженВ той же жабе есть и Optional, и null. Почему они не могут во всех вызовах, где может быть возвращён null, обернуть результат в Optional? Дык, не нужен им null, а просто легаси же. Вот пусть и ебутся с null, пока не закопают вместе с языком. В расте этого изначально нет, и слава б-гу. Хотя со временем свой груз легаси-"фич" наверняка образуется.
>>1629603>Хотя со временем свой груз легаси-"фич" наверняка образуется.Порядок дропа. Уже превратили в стейбл фичу из-за легаси.
>>1629603> А другое, когда ты наябываешь борроучекерНу ты в абсолютно любом языке можешь выстрелить себе в ногу, тут уже только от тебя зависит. Вообще за такие ансейфы в приличном обществе пиздят, и возможно даже ногами. Для защиты от подобного как раз и есть код-ревью или опенсорс.Все таки без ансейфа язык был бы совершенно бесполезным (ты бы даже в консоль нихуя не напечатал, да).>>1629607Поясни плиз
>>1629655struct Yoba {a: Foo,b: Bar,}let y = Yoba::new();drop(y);Порядок дропа чётко определён в расте. Вроде бы сперва падает b, потом a, но это неточно, потому что я давно об этом читал. Но порядок точно определён.
>>1629656>>1629655https://github.com/rust-lang/rfcs/blob/master/text/1857-stabilize-drop-order.mdhttps://github.com/rust-lang/rfcs/issues/744#issuecomment-77851208
>>1629656>>1629661Понятно. Теперь непонятно, нахуя вообще полагаться на порядок дропа полей структуры? В чем смысл? Когда такое может пригодиться?
>>1629697Ну, скажем, ты повешал на дроп коллбэк и тебе кровь из носа важна очерёдность исполнения этих коллбэков.
>>1629118Раст уже обогнал по количеству библиотек перспективные языки типа Nim и D, которые появились раньше.
>>1629994>DС D вообще смешная история была: на нём изначально был написана первая версия OpenMW, но потом коммьюнити решило, что ну его нах, и переписали на крестах. С растом пока чаще случается наоборот - на нём переписывают с крестов.
>>1630070Там оправдывали тем, что на расте мало программистов, которые будут поддерживать продукт. Их можно понять.
>>1628776>>1628849это другая книга. Читаю её сейчас, впринципе она лучше раст бука только тем что там информация в более полном виде (500 стр.)
>>1629867Короче выглядит пока как то, что нужно знатно упороться, чтобы сделать такое. Но при этом я совершенно за, чтобы поведение было четко определено все таки.
>>1630173Они там субд и модули для машинного обучения разрабатывают, так что до веб макакинга еще далеко.
Если go - примитивный, то почему до сих пор нет транспайлера go-to-rust?Для миграции на rust было бы удобно, заодно и библиотек прибавилось бы.
>>1633917Потому что Go -- язык с GC, и напрямую код под концепции владения не переделать? Потому что все interface{} станут unsafe {}? Потому что на хуй не нужно низкосортный (как минимум с точки зрения языка с поддержкой обобщений) код переносить куда бы то ни было вообще, ведь архитектурных и композиционных различий там будет миллиард?
>>1634469https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2b7d08649c1fc0d024e1af8baff0c3cf
>>1634487Если элементы Copy, то уже сейчас можно использовать https://doc.rust-lang.org/std/primitive.slice.html#method.copy_from_sliceВ теории можно правую часть забирать и элементы перемещать (а все объекты в расте можно перемещать), но без ручного ансейфа это не сделать, а в виде функции не добавить, потому что unsized rvalues не стабильны (а они нужны чтобы функция могла принимать непосредственно слайс, а не ссылку на него).
>>1634494С вектором всё понятно, он гибкий. А я хочу именно массив, для, типа, скорости.Суть https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=10ab13f92246ec0d69de4c6343692e48the size for values of type `[usize]` cannot be known at compilation timeно конпелятор явно пиздит, так как цикл я задаю той же константой, что и размер массива. Т.е., там всё просчитывается, другое дело, что разрабы конпелятора до этого надеюсь, пока не добрались.Прост матчи со слайсами приделали - вот я и подумал, что тут как-бы похожая задача, даже попроще.
>>1634502 -> >>1634493>>1634502Бля, со слайсам заработалоhttps://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5448442ce184030741a1682ca2d121ab>>1634505Не, ну почему нельзя напрямую заебошить через "=", чтобы как в лучших домах?
>>1634508> Бля, со слайсам заработалоПотому что массив автоматом может превращаться в слайс.> Arrays coerce to slices ([T]), so a slice method may be called on an array. Indeed, this provides most of the API for working with arrays.
>>1634505> Ты померил, надеюсь не от жопы?Ну как минимум массив (если не использовать Box) выделяется на стеке, а вектор всегда в куче. Так что если элементов мало и их количество известно, то использовать вектор нет смысла. Другой вопрос, что без константных генериков использовать массивы с более чем 32 элементами очень сложно, потому что для них отсутствуют куча трейтов.
>>1634508> Не, ну почему нельзя напрямую заебошить через "=", чтобы как в лучших домах?1) Наверняка это значительно усложнит парсер. Сейчас в расте даже избавляться от ебанутого синтаксиса вызова генерик функций (yoba::<u32>()) не хотят (конкретно, избавится от этих :: перед списком типов).2) Слишком много магии, а этого расторазрабы очень не любят. Вместо того чтобы вводить новый синтаксис, можно это решить функциейfn move_from_slice(&mut self, src: [T])но чтобы эта функция заработала нужны unsized rvalues. Пока что можешь использовать unsafe-аналог: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e5e2c0dcb4120f3d6f187c30132deb6a
>>1634552> Пока что можешь использовать unsafe-аналогНу и можно вынести в макрос для реюза: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cb4b20f60bdc6c4d82c0538abc2ddf63Единственный недостаток: будут странные ошибки или потенциальные ub если скормить макросу не слайсы.
>>1634569Хотя ManuallyDrop тут лучше подходит: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1d0f7e04db2955d310d41570a5707772
>>1634552>>1634569да лан, меня и слайсы устраивают, в-принципе. Вот только жопно, что размеры только в рантайме чекаютсяmy_array[i5..(i+1)5].clone_from_slice([i, i+1, i+2, i+3, i+4, i+5].as_ref());
>>1634582Там не в слайсах дело, а в том, что элементы слайсов должны иметь трейт Copy (то есть должны быть тривиально копируемы).> что размеры только в рантайме чекаютсяТут да. Чтобы чекать в компил-тайме нужны константные генерики, которых до сих пор нет.
>>1634582> clone_from_slicecopy_from_slice будет быстрее (он тупо копирует кусок памяти, а clone копирует по-элементноб вызывая у каждого функцию clone).
>>1637635Потому что в рантайме никаких проверок нет. Все процедуры влияющие на безопасность (borrow checker например) происходят только при компиляции. Дальше код такой же как и на C. Ещё есть что-то связанное с нулевой стоимостью абсстракций таких как обобщённые типы. Где просто под каждый возможный тип при запуске программы резервируется функция реализующая этот тип. Это очень быстро работает в рантайме.
>>1637635Он не такой же быстрый. Кидаешь в godbolt две идентичные проги на C и раст и смотришь на сгенерированный ассембли. Там случае с алиасингом разве что оптимизируются llvm лучше
>>1637651А зачем вообще нужны динамические сборщики мусора, как в Java и C#, если можно делать как в Расте, собирая мусор при компиляции?
>>1637690Чтобы программисты не рыдали, пытаясь писать графовые структуры. И да, раст никакой мусор при компиляции не собирает, он просто контроллирует времена жизни
>>1637695Каким образом? В расте же не нужно вручную освобождать память, за тебя это делает компилятор.
>>1637701Компилятор это не бесплатно делает, а ограничивает действия которые может сделать программист, а это как раз таки и усложняет разработку. конечно смотря разработку чего
>>1637690>А зачем вообще нужны динамические сборщики мусора, как в Java и C#, если можно делать как в Расте, собирая мусор при компиляции?Отличный вопрос! Для того чтобы знать ответ, нужно раскопать несколько вещей.borrowck это не сборщик мусора, это механизм, который позволяет проверять на этапе компиляции что ссылки не "живут" дольше того на что они ссылаются. Освобождение ресурсов происходит автоматически по концу скоупа в котором живет переменная (есть исключения вида move semantics и std::mem::forget).borrowck не решает все возможные задачи по организации ресурсов, и не подходит для всех задач. Если ты попытаешься написать двусвязный список на расте, то столкнешься с огромным количеством веселья. https://rust-unofficial.github.io/too-many-lists/ . Почему так? Потому что в с двусвязном списке крайне сложно гарантировать что все указатели нормальные И время жизни известно на этапе компиляции. Приходится использовать более сложные структуры данных, такие как Rc, rc::Weak, арена+индексы.Так же, довольно сложно эффективно выразить в рамках borrowck такие структуру данных как граф и деревья со ссылками к родителям. И такие структуры данных очень часто используются во всяких UI. Есть разные решения, но они все идут в обход borrowck -- чаще всего используются или сырые указатели (что unsafe), Rc/Arc или арена+индексы. Сборщики мусора же идеально подходят для задачи "я хочу иметь ссылки во все стороны и не заботиться о памяти".Еще хочу добавить что в расте технически возможно использовать сборщик мусора в виде библиотеки, таким образом можно совместить сборку мусора для структур которые этого требуют и borrowck для структур которые этого не требуют. Большинство программ этого не делают и в этом не нуждаются.
>>1639204> Если ты попытаешься написать двусвязный список на расте, то столкнешься с огромным количеством веселья.Это было до появления Pin. Сейчас можно даже написать безопасный intrusive двусвязный список, который вообще не будет выделять память, а вся информация для списка (ссылка на следующий и предыдущий элементы) будет храниться непосредственно внутри элементах списка (потому что Pin будет гарантировать, что ссылки не сдохнут и элементы никуда не переместятся). Мегакрутая вещь, потому что позволяет обойтись без аллоцирования памяти внутри асинхронных алгоритмов (поскольку можно делать списки, хранящие внутри себя Future без выделения памяти).
>>1639215Я мимокрокодил, но можно поподробнее? Я из пинов трогал только Box::pin и вообще без понятия, как там список будет выглядеть
>>1639228Pin в отличии от простых ссылок помимо гарантии о том что объект не умрёт, даёт и гарантию, что объект не будет перемещён. Но, однако, ссылки всё так же остаются ссылками, а значит тебе придётся ебаться с лайфтаймами, если хочешь писать чисто безопасный код. А учитывая, что зачастую возможностей раста не хватает для адекватной работы со структурами с лайфтаймами (например из-за отсутствия GAT), то многие предпочитают по старинке использовать unsafe.>>1639956Он настраивается если тебе что-то не нравится: https://github.com/rust-lang/rustfmt/blob/master/Configurations.mdЯ лично использую дефолтный пресет.
>>1643644Ещё есть вакансия на руби, где в требованиях (или пожеланиях, не помню) указан опыт программирования на расте.
>>1643589Не, прост вакуха интересная.Кто-нибудь апплаился уже нан неё?Я дотнето-питоно-энтерпразо-блядь, мне не по чину, а тут такие-то требования и задачи, аж ухх.
Получить значение из хэшмэп в нормальном языке:m := scores["Yellow"]В расте:let m = scores[&"Yellow".to_string()];
Где найти актуальную справку по всем allow-параметрам?А то вот это уже не работает https://stackoverflow.com/questions/25877285/how-to-disable-unused-code-warnings-in-rust
>>1644415Что то ты или тупой, или пиздишь https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=176f7470b3b04e60f72b6cd4241bb7b2
>>1644937https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=bcb5c7f07d3e0f6956f833606a499481
Насколько русский растбук отстает в развитии актуальности? С английским нет проблем, но я не люблю на иностранных языках читать.
>>1645015Ну ты ведь только доказал, что сделал хуйню, и естественно компилятор не может за тебя понять, как ее интерпретировать. У тебя там в ключе хуйня в виде &String (хорошо, если один уровень ссылок). Так что ССЗБ, да.
>>1645015.iter создает интератор по &'life0 &'static str, вместо &'static str. так, что, тебе нужен into_iter который превратит массив в полноценный итераторhttps://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3648212cada0270fbc4e10f0ea06b157
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4da3f95df076b4fd0d07bdb72d30f9bfПочему if со сравнением ссылок срабатывает? Всегда автоматически разыменовывает что ли? Какие ещё операторы так делают? Где про это подробнее почитать в официальной документации?
>>1646258Это не в конструкциях дело, а в том, что Rust автоматом дереференсит объекты для вызова методов. Для сравнения у нас есть трейт std::cmp::Ord, и для сравнения a и b вызывается Ord::cmp(a, b). Тут-то и происходит дереференс.В Rust Reference расписано подробнее: https://doc.rust-lang.org/reference/expressions/method-call-expr.htmlЕсли очень хочется сравнить ссылки, обратись к ptr:eq.
>>1646353Спасибо. Странно, что для такого строгого языка как rust сделали при сравнениях неявный автодереференс. То ли дело https://play.golang.org/p/TSjp4-HumQc
>>1648013Ты представляешь, как будешь вызывать функции для Arc<Mutex<Box<T>>>? (T).do_something().> для такого строгого языка как rustСтрогость — она вообще не об этом. Тут все строго, но в безопасных моментах может быть неявно. Если неявно и однозначно не получается, копилятор ругается. В автодереференсе подводных нет.> То ли делоВ Go нет перегрузки операторов и сравнения не реализованы для ссылочных типов. Сравнения там вообще только для примитивов есть, поэтому никаких сюрпризов, это часть их подхода ко всему.В то же время, посмотри на пример пикрелейтед. Методы для структуры вызываются независимо от того, как они объявлены (rect там просто является индикатором сайд-эффектов при вызове метода) и независимо от того, по структуре r ты его вызываешь или по ссылке на нее rp. Тут тоже автодереференс работает во всю, ты просто ищешь его в том единственном месте, где в Go его нет по принципиальным причинам.
>>1648039Забыл, что звездочки съедает парсер.> (T).do_something()(✱✱✱T).do_something().> (rect там просто является индикатором сайд-эффектов при вызове метода)✱rect
Анон, поясни за AtomicPtr.Что-то я не пойму, а что если один из потоков уже вовсю юзает к нему доступ - что будет со вторым? Никакого Result или Option там нет, возвращается сразу указатель. Или оно само ждёт?
>>1648728>а не сам указатель.Имееется в виду данные на которые указатель указывает.Пример реализации стекаhttp://aturon.github.io/tech/2015/08/27/epoch/
>>1648750Нет, смотри:AtomicPtr - это просто кучка байтов, которые могут использоваться как адрес.И когда ты изменяешь эту конкретную кучку байтов, зовущуюся AtomicPtr, она изменяется атомарно. Данные по этому указателю обычные и изменяются обычно, а не атомарно (кроме случаев, когда твой указатель указывает на другой атомик, но это другая история).>>1648573Никто ничего не ждёт. Хочешь атомарный доступ к данным по указателю - юзай Mutex или RwLock (или ^const AtomicUsize, если указатель нужен, а не ссылка, как &AtomicUsize, если тебе надо хранить маленькую цифру, а не большой слайс).
>>1654602Ну, смари:1. У тебя прописан лайфтайм для функции, то ты и возвращаешь с энтим лайфтаймом. Но это может быть немного муторно.2. Ты передал в функцию вектор и возвращаешь указатель на элемент этого вектора. Годится не для каждого случая.3. Возвращаешь с &'static - но это немного некошерно, как я понимаю, так можно сделать утечку. (более опытные аноны пусть поправят)4. Самое лучшее - стараться писать так, чтобы функция возвращала прям-таки сам объект. То есть, создавала какие-то новые данные и их возвращала. Тогда никаких вопросов к ней не будет.
>>1654957Если дереференсить по полученной ссылке, то может и будет. А если ты создал объект, то никакого перемещения в памяти не будет.
>>1655129Да не, в расте стандартную либу ещё читать можно. Про всё говорить не могу, но некоторые вещи точно.
>>1655129В расте как раз никакого ада и никаких препроцессоров, только макросы иногда странные, но в стдлибе все макросы простые если не по коду, то хотя бы по логике. А ещё там везде охуенная документация.Зайди в МВП тред, там ссылка на гитхаб со всякой сранью по крестам. Но тебе кресты не нужны, только часть про то, как работают процессоры и RAM. Видосов там вроде на час-два всего. После этого уже становится понятно, что такое указатели, биты и прочая срань.
>>1656290>Как там раст поживает?Хорошо>сделать упор на С++?>Возможно ли найти работу?Ты же никогда не работавший студент?
Че пацаны, когда свергаем с трона дедушек типа Си и крестов и овладеваем царством системного программирования?
>>1656644Когда что-нибудь решат с целым сонмом проблем. Например, линуксы не могут писать на расте, потому что нет хотя бы полустабильного ABI, а новые версии раста выходят чаще, чем новые версии линупса.Есть и другое. Раст хорош, но пока что с легаси слезать никто не хочет, потому что раст сложный и учить его дорого.
>>1656644> дедушек типа Си и крестов Им нахуй ваши безопасные языки не нужны. Няшные UB и use-after-free - самое лучшее что случалось в IT.
>>1656651А не наоборот? Кресты - те же Си по производительности, но с мегакрутым STL, где есть дохуя структур данных и нулевых по стоимости абстракций, ООП и умные указатели, позвляющие минимизировать шансы иметь уязвимости типа use-after-free, nullptr dereference, double free. Я считаю, что Сишка уступит расту лет через 10, но кресты несвергаемы в ближайшие лет 50 так точно
>>1656652Кому им? Безопасники потеряют хлеб, по крайней мере в лоу-лвл бинарщине, да, но компаниям только в плюс, их хотя бы по одному вектору перестанут ебать.
>>1656653У STL самая большая проблема - это переусложнённость. И одна из причин - эксепшоны (которые, что смешное, любой кого волнует перформанс полностью отключают), которые нужно учитывать. Отсюда некоторые коллекции медленней чем могли бы быть.
>>1656656От Линуса зависит разве что будущее Линукса, но никак не будущее всего мира программирования. То, что Линукс на раст перепишут только через труп Торвальдса - это и ежу понятно. Но я говорю глобально о мире. В итоге через 10 лет максимум что останется - это суперсложные дыры в пространстве ядра, юзерспейс должен семимильными шагами перестать юзать дырявые япы. Какой от них смысл, если раст быстрый как си и плюсы, но безопасен и его код нельзя взломать по вектору ошибок с памятью?
>>1656653ты давно видел чтобы на чистом цэ писали? а вот где то заткнуть им дырку он минималистично идеален, кресты сложные и неговнокодить на них тяжело, надо дохуя знать чтоб ненаделать пиздеца, я например понимаю что я их не настолько знаю чтоб увидеть эти подводные камни.
>>1656660> ты давно видел чтобы на чистом цэ писали?Ололо, прошивки для любой эмбедщины, драйвера (Линукс, здарова), рилтайм, средства виртуализации типа гипервизоров. Там почти 100%ый Си код
>>1656662да да про эмбедед я уж вспомнил когда отправилну а кроме не так уж часто>>1656659> юзерспейс должен семимильными шагами перестать юзать дырявые япыха
>>1656663> ну а кроме не так уж частоБратан, это ОГРОМНЫЙ кусок рынка, который с развитием интернета вещей только растет в геометрической прогрессии, алло. К тому же, драйвера все же пишут чаще на чистом Си, и на винду, и на Линукс.> хаКакой смысл подвергать себя риску, особенно если это софт, который крутится на сервере и открыт ВСЕМУ МАТЬ ЕГО ИНТЕРНЕТУ, если можно без потерь юзать яп, у которого неуязвимая память? Где логика блять?
>>1656644Для начала не мешало бы аллокаторы доделать. Да и константные генерики тоже (без них работать с массивами - боль). Обе фичи в зачаточном состоянии и вряд ли до следующего года будут доделаны.
>>1656679Раст, может быть и такой же быстрый, как плюсы, но точно не как С. Вернее сказать, идиоматичный код на Расте и плюсах всегда будет медленнее сишного, потому что не бывает на самом деле никаких зерокостабсракшнс: просто в плюсах и Расте обычно делают выбор в сторону понятности/выразительности без (как правило) существенной потери производительности. И это хорошо, потому что писать на сях - удовольствие разве что для гурманов (читай: ебанутых) типа Торвальдса.
>>1656690В отличии от C++ в расте "зиро кост" имеет именно смысл "такой же быстрый, как и оптимизированная версия написанная вручную" (а не "нет оверхеда если фича не используется"). Те же асинхронные функции в расте например в ночнушке уже могут полностью оптимизироваться, как будто асинхронщины нет вообще: https://rust.godbolt.org/z/jL_5sC
>>1656703Эти зирокост фантазии соответствуют реальности чуть чаще, чем никогда. Речь даже про более простые вещи, чем асинхронность.
>>1656729Ты хоть один баг-репорт заполнил где конкретная абстракция выполнялась медленней чем код без неё? Или речь про твои собственные фантазии?
>>1656736Именно. Потому что они воспринимаются как баги и как отсутствие нужных оптимизаций, а не как фичи. Например раст до сих пор не умеет в NRVO (которому С++ научился лет двенадцать назад) из-за чего куча кода с Box работает медленней чем могла бы (особенно если LLVM не сообразит соптимизировать).
>>1656307>Ты же никогда не работавший студент?Практически, да. Делал сайты и прочую херню.Но в последнее время подсел на плюса и раст. Вот и думаю профессионально заняться, всяко лучше чем в css анимации пилить.
Анон, хуле ему надо? Почему всё так ебано и неочевидно?Я замудохался ошибки к единому типу приводить, сука, а тут такое.Суть - нужен асинхронный метод для трейта, ебать его в рот.
>>1657328> нужен асинхронный метод для трейтаРаст такого изкаробки пока не поддерживает (и в ближайшее время не будет). Тут только костыль использовать: https://crates.io/crates/async-trait
>>1658168>>1658169Дохуя всего.1. Не все нужные либы написаны, не для всего есть биндинги.2. В том, что написано, куча недостающего функционала. Тот же Image не умеет 16-бит png схоронять.3. Очень многое из написанного заброшено и устарело. Я вот открыл тут для себя swagger, OpenApi и это вот всё. Для 2.0 биндинги генератора основаны на старой версии tokio и hyper (да и сами биндинги неполные), для 3.0 вообще ни хуя нет - сам пишу может здесь покажу, как доделаю. Или попрошу помощи, если не осилю
Короче, ты лучше начни писать что-нибудь своё - а там уже столкнёшься с кучей недоработок в сторонних крейтах. Вот и доработаешь по ходу дуела.
Мне сказали что Rust мертвый язык. Если нет, какие проекты на нём распространены и более востребованы?
>>1658605> GUI на раст> Orbtk> 5000 рЧто-то мало. Не знаю насколько простое это приложение, но писать гуй (даже на нормальных библиотеках/фреймворках) это почти всегда боль, даже если уже есть готовый бэкенд со всей бизнес-логикой. Особенно когда начинается ёбля с интернационализацией и (не дай бог) ацессибилити.
>>1658622Там не просто раст, но и гуй для redoxos (ОС на расте), который находится в зачаточном состоянии.
>>1658622>Очень непонятно нахуя тут лучший язык современности.ТЕМ ВРЕМЕНЕМ ЗАКАЗОВ Разработать простое GUI приложение на Rust под MacOS (Orbtk) 1 ШТУКАРазработать простое GUI приложение на Govno под MacOS (Orbtk) 0 ШТУК
>>1658626Не будет. Они от говна даже в своей фуксии откказались, потому что говно оказалось БЕЗ ЗАДАЧ. А для гуя у них флютер с дартом есть.
>>1658630>флютер с дартом есть.они этот флюгегехаймен пишут со скоростью что учебники выходить не успевают, неужели на столько говно что перепиливают постоянно
>>1658633Не знаю что они там пишут, но для десктопа и даже веба эта хуита никак релизнуться не может.
>>1658633Дарт давно готов, ещё раньше го вылез вроде, но не уверен. Флаттером на телефонах они гуй рисуют, так что его всегда надо будет допиливать.
Аноны, есть такая замечательная штукень, как swagger, OpenApi, это вот всё. Кто не знает - позволяет генерить биндинги и документацию на основе декларативного описания апишечки.Решил я, в связи с известными событиями, немного торгануть на бирже. Ну и автоматизировать немного, ессно на расте. Взялся я за неё и что вы думаете? У тинькова апишка для версии 3.0, а в swagger-gen модуль для раста только для версии 2.0.Ну я, короче, промудохался пару дней и выкатил (вроде) рабочую версию для 3.0, отдельным модулем. Интересно кому такое?
>>1658686Го я не знаю, от жабы тошнит, питон слишком распиздяйский язык для финансовых утех есть опыт.
>>1658690И что прямо реально вот эту вебную парашу можно легко на расте делать?inb4 поставил везде Clone, Copy и делаешь
>>1658698А там ничего вебного, апишечка же и всё. Шлёшь запрос, получаешь ответ, десериализуешь - дальше работаешь со своей структурой. Если надо что-то заслать - сериализуешь структуру и также пакуешь в запрос. OpenApi охуенная штука, позволяет просто набросать описание апишечки и по нему генерить клиент и сервер (в серверную часть я не вдавался).
Мне нужно всего лишь получить содержимое определённого URL (с указанием юзер-агента при коннекте), чтобы потом работать с этим содержимым в виде текста. Подскажите наиболее минималистичную библиотеку для такого, а то в инете многие советуют монструозный reqwest.
[[package]]name = "reqwest"version = "0.10.4"source = "registry+https://github.com/rust-lang/crates.io-index"checksum = "02b81e49ddec5109a9dcfc5f2a317ff53377c915e9ae9d4f2fb50914b85614e2"dependencies = [ "base64", "bytes", "encoding_rs", "futures-core", "futures-util", "http", "http-body", "hyper", "hyper-tls", "js-sys", "lazy_static", "log", "mime", "mime_guess", "native-tls", "percent-encoding", "pin-project-lite", "serde", "serde_urlencoded", "time", "tokio", "tokio-tls", "url", "wasm-bindgen", "wasm-bindgen-futures", "web-sys", "winreg",]
>>1658835Делается за пару минут при поможи жопаскрипта или петухона, зачем тебе из раста по мухам стрелять?
>>1658715На чём делал hyper/serde?>>1658835>Мне нужно всего лишь получить содержимое определённого URLЛиба должна>уметь парсить http>при connect уметь в tls>быть ассинхроннойЯ ничего не забыл? Поэтому у тебя любой reqwest будет такой "распухший".>>1658887Разработчики hyper рекомендуют использовать reqwest, если тебе у тебя простой план использования.
>>1658833Я, кстати, с пятнадцатого года на Go и Python писал, и сейчас, изучая Rust рывками в свободное время, понял, что на Rust мне почти заново надо учиться писать, как если бы я на Хаскель перепрыгнуть решил. Если тебе не тяжело, поясни конкретно, в чем я неосилятор.
>>1658960>hyper/serdeЯ за основу взял версию от 2.0, так она и была на этом самом. Подтянул там hyper к последней версии (из-за чего пытался в асинхронные трейты, забил и сделал block_on), заимплементил енумы (костыльно, пулл-риквесты вэлкам), добавил сер-десереилизацию для времени.Юзать как-то так:https://github.com/swagger-api/swagger-codegen/tree/3.0.0/>mvn clean packagehttps://github.com/inferrna/rust-swagger-codegen_v3>mvn clean packageпотом>java -cp rust-swagger-codegen_v3/target/rust-swagger-codegen-1.0.0.jar:swagger-codegen/modules/swagger-codegen-cli/target/swagger-codegen-cli.jar io.swagger.codegen.v3.cli.SwaggerCodegen generate -l rust -i your_swagger.yaml -o your_clientВсё, крейт в your_client почти готов, нужно только руцками прописать версию и название. Я проверял на Тинькове - работает, пок что, правда, единственный запрос проверял. Одна тонкость - для поддержки ssl пока нужно немного попотеть - пикрил (потом можно перенести в саму либу, нужно только задетектить схему).Работы там дохрена, официальная версия для 2.0 оказалась ещё хуже моей.
Почитал высер безлодочного https://boats.gitlab.io/blog/post/why-ok-wrapping/Зачем это говно вообще городить?
>>1659556> Зачем это говно вообще городить?По большей части чтоб не писать return Ok(govno); (или Ok(govno) в конце) для выхода из функции, а просто return govno;/govno как будто функция возвращает не Result<Govno, _> а просто Govno.
>>1659580Удобна же (на самом деле было бы неплохо, особенно в функциях возвращающих Result<(), _>, где с ok-wrapping можно ничего не возвращать вообще). Ты ещё не видел свидетелей отсутствия точки с запятой у которых точка с запятой в конце выражений сразу делает язык неюзабельным говном.
>>1659587>Ты ещё не видел свидетелей отсутствия точки с запятой у которых точка с запятой в конце выражений сразу делает язык неюзабельным говном.ну я сам люблю в кожуре поковырятся, но к точкам отношусь нейтрально>Удобна же (на самом деле было бы неплохо, особенно в функциях возвращающих Result<(), _>, где с ok-wrapping можно ничего не возвращать вообще).руст и так местами переусложнен, а если начать добавлять исключения в одних функциях так в других не так, будет пиздец.
>>1659605> руст и так местами переусложнен, а если начать добавлять исключения в одних функциях так в других не так, будет пиздец.Так это уже сейчас можно сделать макросами (более того ты можешь писать зашифрованный код и расшифровывать его во время компиляции при помощи макросов - https://github.com/matklad/proc-caesar - пикрил). И пока что делать подобные функции даже в планах нету. Только специальные try-блоки, плюс трейт Try, чтобы можно было использовать ok-wrapping (да и оператор ?) с любым типом, а не только Option и Result, которые сейчас немношк попахивают магией.
>>1659622> резалт то магией не пахнетЯ про оператор ?, который работает только с Result и Option. После стабилизации трейта Try он будет работать с любым типом, который имплементирует этот трейт и "магия" внитри Result и Option будет заменена на имплементацию этого трейта (хотя скорее всего ? уже работает через этот трейт и просто в стабильном расте ты не cможешь сделать свой тип, чтоб он имплементировал его).
>>1658581Скорее мертворожденный. Он служит якобы будущей заменой Си и крестов, но на деле временный выпердыш, так как он решает какую-то микропроблему топовых системных япов (Сей и крестов), и то частично, а не полностью. Засим, недостаточно причин для тотального перехода на Раст, тем более на уровне продакшена. Обрастет костылями, биндингами на Си (еще больше чем сейчас) и захлебнется, как и предыдущие мамкины убийцы сикрестов.
>>1659632Ну почему, джава и шарп тоже задумывались убийцами крестов и таки преуспели в этом - теперь на крестах пишут только системщину.
>>1659632>но на деле временный выпердышУх ты, у нас человек из будущего, который пришел сказать, что сикресты вечны. Ставишь жопу, что кресты проживут хотя бы 200 лет? Определи точные границы, когда заканчивается "временный" и начинается "вечный".
>>1659738Нет. Есть некоторые люди, которые ошибочно считают, что Го - это системный яп, но они глубоко ошибаются. Ничего против Го не имею, отличный инфраструктурный ЯП для девопса и микросервисов, у него есть своя ниша и он ее занял, но этот язык не является системным хотя бы потому, что у него есть garbage collector, но это, естественно, не единственная причина.Системщина - это Си и кресты уже много лет, были, есть и будут. Спросишь почему? Потому что создать им замену в их области применения практически нереально, должен произойти фурор и открытие, наподобие тому, что произошло между Ассемблером и Си в своё время (Си сотворил революцию в мире программирования в свое время, которая позволила вывести всю индустрию на новый, ранее неизведанный уровень), что в наши дни имеет шансы 1 к охуилярду. Прибавь к этому тонну легаси, все известные и неизвестные ОС, инфраструктуру, количество специалистов и тонну софта, которые в данный момент пишутся и будут писаться на Си и крестах. Вытеснить такое практически невозможно, во всяком случае в мире, где компьютеры построены по нынешним технологиям.Что получаем из этого? На Си и крестах как писали, так и будут писать системный софт, ОСи и лоу-лвл либы на всех уровнях, а Раст останется на уровне любителей эзотерики.
>>1659895Пока компьютеры имеют нынешнюю архитектуру - вечны.Гипотетически возможный сценарий смерти Си и крестов на уровне системщины - выход квантового компьютера за пределы прототипа и тотальный переход человечества на принципиально новую компьютерную технологию, но это повлечет смерть всех языков, это повлечет даже смерть современной криптографии, блять!>>1659882Джава задумывалась как неебически портативная версия крестов, правда более медленная. А шарп задумывался как убийца джавы, а не крестов, в чем он явно не преуспел, а лишь жидко дал в рейтузы. Я не люблю джаву и если сравнивать ее с шарпом, то как ЯП он больше мне импонирует, но все же от правды не убежишь.Джава поначалу планировался как суперуниверсальный ЯП, на котором хотели писать даже эмбедщину, в чем тоже жестко обосрались. Если Си - строгая системщина, то кресты активно юзают еще и в геймдеве и хайлоудах. Везде, где нужна ебейшая производительность. В итоге джава заняла нишу в кровавом энтерпрайзе и в мобилках, откуда ее потихоньку вытесняет Котлин, а потом обоих вытеснит макакаскрипт (пара-тройка лет и веб просочится в мобилки еще сильнее и пустит там корни). Кресты тем временем где были (системщина, включая эмбеддед, геймдев и хайлоуд), там и остались. Это их стихия и их область, откуда их выбить практически нереально.
>>1659911Настоящий системный язык только Си, без плюсов. Он всегда будет в какой-то своей сфере применения.А вот кресты теснят и сильно, потому что они очень тяжеловесные и ограниченные, Go/Rust как раз занимают нишу между Си и разными питонами с JS.
>>1659920Кресты "ограниченные", блять, ага. Как раз-таки проблема этого языка (парадоксально, но факт, что это проблема, а не плюс) в том, что этот язык имеет НЕОГРАНИЧЕННЫЕ возможности. Язык, где ты можешь ебать байтики, писать инлайн ассембли, разрабатывая ядра ОС и прошивки, при всем при этом есть возможность писать абстракциями из высокоуровневых япов, так как у тебя есть полноценный ООП, шаблоны (которые Тьюринг-полные и через которые можно реализовать бесплатный по рантайму полиморфизм), STL с КУЧЕЙ структур данных для самых разных целей, у тебя, ебаный в рот, есть даже фичи из функциональщины в виде лямбд, мать твою за ногу! Scalability этого языка НЕОБЪЯТЕН, в нем реализованы все возможные и невозможные парадигмы программирования. Да, огромные проекты долго компилятся, но все это для того, чтобы в рантайме прога не проседала и не сосала хуй, так как кресты используются для разработки высокопроизводительных программ. Go не имеет ничего общего с крестами в плане области применения, а Раст не сможет свергнуть кресты, потому что по сравнению с крестами, Раст - костылированная ограниченная поделка.
>>1659928upd - проблема неограниченности в том, что за такую мощь приходится платить, и эта плата - сложность языка. Чтобы писать качественный софт на крестах и уметь его дебажить - нужны скиллы. Но пока собаки лают, караван идет, и 99% компаний по всему миру, выбирая между растом и крестами, выберут кресты по ряду очевидных причин. В проде никто шило на мыло менять не собирается, Раст не решает какую-то глобальную проблему, не творит революцию, как это было в случае с Си в свое время, засим и причин повально на него переходить попросту нет. И это происходило со всеми мамкиными убийцами сикрестов. Они либо занимали совершенно другие ниши, либо подыхали.
Я еще понимаю агонизирующие кровавые очки крестовиков, но каким образом можно даже подумать о сравнении говна с нормальными языками?Даже для самых упоротых фанатов даже не стоял вопрос об использовании этого недоразумения для чего-либо серьезного
>>1659632А по-моему новые проекты чаще выбирают раст чем кресты. Ну а легаси переписывать да, пока не спешат.
>>1659928крестовик, порвался, несите нового лолЩас бы мертвый цепепе за язык считать, на нем бля уже никто не пишет, только какой-то ссаный легаси на нем остался и все, че ты несешь бля
>>1659564Люди какие-то другие проблемы решают, неужели иных проблем-то нет?>>1659587>Удобна жеМожно кучу говна натащить под таким предлогом, мне, например, опускание (не каламбур) типов не нравится (кроме времени жизни - с этим всё ок), у чувака выше IDE их даже заполняет, в редакторе без такой возможности в итоге приходится самому угадывать какие там типы.>Ты ещё не видел свидетелей отсутствия точки с запятой у которых точка с запятой в конце выражений сразу делает язык неюзабельным говном. Вот этот момент не дошёл до меня, в чём суть?
>>1659982>Покажи мне ОС, написанную на крестах. Симбиан в свое время был полностью написан на плюсах, дрова винды и макоси написаны преимущественно на плюсах (ядро на Си).В фуксии есть салат из языков, где имеет место быть и плюсам.мимоанон
>>1659982>Там на подходе 23 стандарт.А в 2018 вышел очередной стандарт языка Фортран. И да, на нём до сих пор пишут.
>>1660000Что не так? Семейство NT точно написано на C. Может какие-нибудь древние 3.11 и были на паскале, может нет, но это было давно и три семейства 3.1/95-ME/NT-XP-10 разрабатывались независимо.
>>1660000Ооо, еблан тупорылый, все ясно. Приятного времяпровождения в гугле, если заморочишься, то поймешь как сильно ты обосрался, лол
сапдвач, разве так и должно быть? a.do_something и a.operate_on_c же никак не касаются a.bhttps://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=deacd51e2896b4d9364aaf4ce249c2a9
>>1659988> Люди какие-то другие проблемы решают, неужели иных проблем-то нет?А чего там решать? Есть древний RFC и уже почти готовая имплементация (правда пока что только try-блоков с ok-wrapping, а не целых функций) и в целом единственное что мешает этой имплементации уйти в стейбл вопрос "Нужен ли ok-wrapping вообще или нет?". Хотя на самом деле есть ещё второй вопрос и выводом типов - нужно ли по умолчанию делать так чтобы try-блок отдавал result и что делать если тип error вывести невозможно, но он нигде и не используется - игнорировать или выводить ошибку - https://github.com/rust-lang/rust/issues/31436#issuecomment-614735806> Вот этот момент не дошёл до меня, в чём суть? В расте точка с запятой имеет важное значение и некоторым это не нравится, потому что они привыкли писать код без неё.
>>1660040Может. У раста минимальная единица для проверок borrow-checker'а - это структуры. Даже если ты взял поле структуры, компилятор всё равно будет считать что ты взял для редактирования всю структуру. В целом решение этой проблемы не очень простое (и скорее всего значительно усложнит сам язык), но разрабам известно о ней: https://smallcultfollowing.com/babysteps/blog/2018/11/01/after-nll-interprocedural-conflicts/
>>1660239> минимальная единицаПервый пример из >>1660123Нет как таковой минимальной, просто не полностью осиливает.
>>1660447Ты статью прочитай. Внутри одной функции да, может работать и с отдельными полями. Но сама функция получает &self, т.е. структуру в целом и компилятор не осилит понять что из структуры она использует только некоторые поля. Потому статья и называется "Interprocedural conflicts". И одно из решений проблемы - ручной инлайн функций, чтобы использование структуры было в пределах одной функции.
>>1660454У него в примере функция получает именно &self:fn do_something(&self) {потому борроу чекер и жалуется на всю структуру, хоть функция и использует только self.c.
>>1660455Всё так. Но компилятор умеет разбивать владение полей структуры, просто получается у него не идеально и не везде.
>>1660456На самом деле это сделано специально (что время жизни полей структуры отслеживаются только внутри блока). Как вариант можно передавать вместо ссылки на саму структуру ссылку на поле, либо выносить связанные данные в отдельную структуруи переносить функции в их имплементации (например в случае того кода сделать так: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d143998f8975de1086059f0928882196 ).
>>1660467Просто представь как просто можно было бы сломать обратную совместимость API (поскольку захват нового поля по сути ломает его, а это можно сделать и случайно, ведь синтаксиса для указания какие поля функция может захватывать нет). Плюс это значительно усложнило ABI раста, поскольку все поля которые функция захватывает нужно как-то указывать.
В моём профанном манямире всё логично и правильно блочится из-за попытки делигировать мутабельность объекта в другой скоп, непонятно чего ожидая от первоначальногоКрутить структы не воспринимая их как единый объект звучит рокетсаенсно
>>1660476Если пишешь код с нуля или используешь растовские библиотеки, то естественно всё будет норм. А вот как начнёшь ебаться с FFI, то сразу увидишь всю боль. Где-то читал, что нормальные биндинги для вейленда практически невозможно сделать потому что там структура сначала удаляется из памяти, а потом программе приходит уведомление мол ваша структура была удалена, не используйте её, плиз, что с т.з. раста моментальный UB.>The main issue seems to be the fact that wayland "resources" - stuff like keyboards and monitor connections - can be removed at any time by the user by just unplugging the video cable. Wayland posts a callback when this happens, but memory like this that could just get deleted at any point is obviously not safe and is not allowed by rust.
>>1660483>but memory like this that could just get deleted at any point is obviously not safeТо есть вайланд тоже является небезопасным, как и иксы. При этом ничего не умеет.
У всех сишных операционок есть фатальный недостаток — они принципиально дырявые благодаря с/с++. Вот тут-то раст и приходит на помощь: https://www.redox-os.org/
>>1660638У всех не-мейнстримовых операционок есть фатальный недостаток: разработчики железа ебали в рот писать под них драйвера. Потому-то андроид и сделан на базе линуха, что в ядре уже почти всё поддерживалось.Я больше верю в то, что ядро линуха частично перепишут на расте, чем в шансы редокса. Хотя, orbtk отдельно уже сорт оф взлетел, судя по вакансии выше.
>>1660677>У всех не-мейнстримовых операционок есть фатальный недостаток: разработчики железа ебали в рот писать под них драйвера. И не нужно, ведь безопасных операционок общего назначения среди них нет. За исключением недавно появившейся redox, про существование которой они тупо не в курсе.
>>1660638И чем редокс безопаснее остальных ос?вобще не понимаю почему раст позиционируется как супер безопасный язык
>>1660691Типа из-за борроу чекера.На деле в ОС, как и в любом другом не хэллоу-ворлде, написанном на расте, будет ДОХУЯ ансейф блоков. И не просто ДОХУЯ, а Д О Х У Я. Использование ансейф блока убирает то самое микропреимущество перед си и крестами в плане безопасности памяти. А в виду специфики низкоуровневого пердолинга, а написание ОС им изобилует, абузить ансейф блоки придется ой как дохуя. По этой самой причине Раст - мертворожденный язык, по крайней мере на мировом уровне он не взлетит и никто с Си и крестов перекатываться на раст не будет. И да, Раст не умеет предотвращать все виды состояния гонок, которыми изобилует любая ОС, даже если гипотетически в ОС не было бы ансейф блоков вообще, что на практике невозможно.
>>1660638наивный переРАСТ... Сколько "убийц" Си и крестов было, видали таких, потом такие по весне оттаивали. D, Cyclone, Vala, Limbo, BitC - продолжать? Бьюсь об заклад, что кроме D, ты о других языках и не слышал, верно?:-) Твоя ржавая поделка тоже будет скоро на помойке, наивный дурачок, думающий, что Си и кресты можно убить, лол! Отсутствие безопасности памяти - это МАСТХЭВ для языка с ТОПОВОЙ производительностью, как ты ни крути и как в свое ржавое очко ни долбись, раст костылирован от и до, и имеет ансейф не просто так, потому что без ансейфа ты напишешь максимум хэллоуворлд. И да, не спеши искать мне поделки переРАСТов аля "3к строк кода и ни одного ансейфа!", там куча небезопасных либ в биндингах как минимум. СОфт системного уровня на Расте без ансейфа не может быть написан, засим это говно нахуй никому не нужно. Если повезет, то займет нишу на более высоком уровне где-то на уровне Го, и то не факт. В системщине у этого языка, как и у любого другого кококоубийцы, нет абсолютно никаких шансов. Мир компьютерных технологий принадлежит Сям и крестам, он полностью построен на них.
>>1660730Jesus, очередной свидетель "ансейфы = C". > Использование ансейф блока убирает то самое микропреимуществоКак раз существование ансейф блоков - это основное преимущество перед C(++), потому что в расте ты сразу видишь и изолируешь потенциально небезопасное поведение. А в С(++) у тебя ВЕСЬ КОД это небезопасное поведение, которое может сломаться в абсолютно любом месте.> низкоуровневого пердолингаДа на железе вообще сложно писать надежный код, ну устроено так оно, ты не открыл Америку. Вот только раст позволяет тебе сделать некоторое количество базовых абстракций, скрыть под ними весь ансейф, и дальше уже работать с нормальным кодом. А не "так, я получил указатель, который прошел через 20 фунций, буду мольиться, чтобы никто больше туда не записал ничего".> Раст не умеет предотвращать все виды состояния гонокЯ тебе больше скажу - он их никогда и не должен был предотвращать в общем случае. Максимум - data races, и их он прекрасно отлавливает, а если уж ты решил deadlock на мьютексах устроитьт, ну, ССЗБ (хотя в parking_lot есть какой-то детект deadlock'ов).>>1660758> Vala> убийца CНу, я не уверен, что с тобой имеет смысл вообще разговаривать далее, да. Ты вообще не понимаешь предмет разговора, и походу единственное, что ты можешь - это выделать капсом слово РАСТ. Так что удачи, держись там, хорошего настроения, а господа растоебы пойдут писать годные штуки за 300к/сек.
ку, растач, вижу здесь дефолтный срач, ж вопрос возник=)А как borrow checker предотвращает переполнение кучи? Размер буфера на куче ведь неизвестен во время компиляции, а рантайм чеков у раста вроде нет
>>1660850речь про динамические массивы, чтобы уточнить. Размер которых определяется в рантайме и может меняться в течение исполнения программы
>>1660850Есть мнение, что никак (да и borrow checker тут не при чем). Тут https://doc.rust-lang.org/alloc/alloc/trait.GlobalAlloc.html#tymethod.alloc пишут, что при ошибке вернется 0:> Returns a pointer to newly-allocated memory, or null to indicate allocation failure.Видимо при заполнении кучи просто вылетит паника:> Implementations are encouraged to return null on memory exhaustion rather than aborting, but this is not a strict requirement. Вообще borrow checker про другое - чтобы гарантировать отсутствие data races.
>>1660876ой, я обосрался с БЧ, ну я пока не знаю толком раст, поэтому простительноНе суть, короче, перефразирую.Есть буффер в куче. Его размер - 10 байт, но этот размер известен только во время рантайма. А тут хуяк, я записываю 11 байт в массив на куче. Как Раст предотвратит это, если весь анализ границ в статике, насколько я понял?То, что ты написал про allocation failure, не относится к моему вопросу никак. Переполнение кучи - это когда кусок памяти на куче переполняется и перезаписывает соседний кусок в памяти, где могут храниться указатели на функции и прочие интересные данные.
Если написатьwhile i < stroka.len() { ... }len() будет каждый раз при сравнении вычисляться или только один раз? Как это проверить?
>>1661507Один раз. И часто оно не вычисляется, а просто читает поле (или вызывает метод вложенной структуры, но при компиляции это всё схлопывается, так что тоже самое).https://doc.rust-lang.org/src/alloc/vec.rs.html#1335
Спасибо, ОП, охуенная либа. Забабахал список с контентом, обновляемым из отдельного потока.cursive , если что
Спасибо, ОП, охуенная либа. Забабахал список с контентом, обновляемым из отдельного потока.cursive , если что
>>1662614На винде с таргетом x86_64-pc-windows-gnu отлично, с x86_64-pc-windows-msvc не работало раньше (clion2019.3), теперь должны были починить (clion2020.1), но я не проверял. На линуксе всё искаропки работает.И там и там с thumbv7em-none-eabihf для cortex-m4 через blackmagic probe работает норм.
>>1660483Если это работает именно так как описано, то это пиздец, и на Си это написать тоже нереально. Что, у тебя посередине коллбека удалился объект и ты даже не можешь это проверить? Это не может так работать.
>>1664253Потому что ты ещё не обучен ебать байты как надо и не понимаешь всей стоимости аллокаций. У нормального человекаfn read_line(&mut self, buf: &mut String) -> io::Result<usize>;работает намного быстрее, чемfn read_line(&mut self) -> io::Result<String>
>>1664270Не, я как раз с сишки пришёл, понимаю, что это быстрее, но думал что для раста это менее важно.
>>1664272А какая разница-то? Просто при передачи ссылки можно сделать сразу кучу оптимизаций:1) При создании строки заранее аллоцировать некоторое количество байтов, чтоб в некоторых случаях можно было прочитать данные без реаллокации.2) Если read_line вызывается несколько раз, то есть шанс, что он сработает без реаллокации при 2+ чтении, если свободного места в строке хватит для данных.С возвратом строки такие оптимизации не сработают.
