Rust — невероятно быстрый язык для системного программирования без segfault'ов и с гарантиями потокобезопасности.
ИТТ мы можем объяснить базовые и продвинутые концепции языка, и программирования в целом, поможем вкатывающимся, подскажем что выбрать для веба, игр или спасибо абу блокчейна.
>>1299707 В С++ можно обходится без сырых указателей, new и delete. Где твой бох теперь? А ещё там есть лямбды, темплейты, автоматический вывод типов, сементика перемещения, треды, компилторЫ, отладчикИ, IDE с автокомплитом, а самое главное ООП.
>>1299787 Когда сделают С++ хотя бы сильнотипизированным, тогда и приходите. А пока это всё костыли, усложняющие синтаксис и семантику. Пожалуй самые годные вещи в С++ - темплейты и перегрузка, они худо-бедно обеспечивают параметрический и адхок полиморфизм.
Но слабая типизация с этими вашими кастованиями все портит. Кроме того, вещи типа мув семантики, лямбд, умных указателей не избавляют от утечек памяти, а наоборот, делают их еще более не очевидными и усложняют отладку. При этом читаемость кода нихуя не улучшилась.
Шота я не понял, ткнул на рандомный туториал в растбуке, а там > Unfortunately, the Rust compiler isn’t perfect yet > Rust is still a work in progress > compiler could be improved, but in the future И в таком духе. И как позвольте им пользоваться тогда, м? Алсо языку 8 лет, так то. Пора уже быть пёрфект.
>>1300103 Потому что это правда. Например nll который завезут в декабре сделает борроу-чекер намного приятней в использовании. Сделает ли это язык пёрфект? Конечно нет. Компилятор крестов и сам язык пилят уже хер знает сколько десятков лет, а он все еще ни капли не пёрфект.
>>1299813 -Werror -Wpedantic Вот и не соберется без явного преобразования. А как реализовать адхок полиморфизм без преобразований типов? Кароч отсутсвие возможности что то сделать фича раста.
>>1299813 >Когда сделают С++ хотя бы сильнотипизированным это значило бы отказаться от совместимости с си, те отказаться от нетипизированного указателя и неявных преобразований в си-стиле но в современном с++ это и не используют потому что в тех случаях когда нужен был нетипизированный указатель (например, для adt) используются шаблоны, а для задания преобразований для типов есть масса способов, начиная хотя бы с задания явного оператора преобразования к типу в классе и конструкторов преобразования
>>1300257 >это значило бы отказаться от совместимости с си с++ и так вобщем-то отказался от совместимости с си: как на уровне исходников - си не является подмножеством с++, так и на уровне бинарников - настандартизированный name mangling этому способствует.
>>1300252 А это в рантайме работает? Например у меня есть интерфес для объекта, в рантайме можно выбрать квадрат или круг. Интрфейсу все равно что выбрано у всех объетов есть метод draw(). Как это сделать в расте?
https://www.reddit.com/r/rust/comments/9zuk09/rust_in_aaa_game_engine/ > C++ > On the last game we shipped, in my team about 75% of the last year was spent on issues that Rust promises to prevent. Double free, Dangling pointers, out of bound access, threading issues, non initalized variable, null pointer, etc.
>>1300773 0) Статическая типизация 1) Дженерики 2) Лямбды 3) Отсутсвие ГЦ 4) Производительность 5) Нет главных проблем крестов: Double free, Dangling pointers, out of bound access, threading issues, non initalized variable, null pointer, etc. 5) Компиляция в бинарник
Лично я жду когда игровые движки допилят до вменяемого состояния.
>>1300773 >>обилия великолепных языков программирования >тонны легаси-говна почти в каждом языке, которое не вычищают ради обратной совместимости. вплоть до шизы вроде поддержки обратной совместимости с багами, как в C# >широко используемых языка без GC вообще только 2 >>обилия великолепных языков программирования
Крайне сложно представить себе реальный проект в котором писать Rust было бы экономически оправдано. Вся структура языка заточена на то, чтобы вынуждать человека указывать достаточно низкоуровневые подробности не тогда, когда это действительно нужно, а ПОСТОЯННО. Исключение где Rust может быть реально полезен могут составлять только Embedded и hard real-time системы. Однако это капля в море разрабатываемого софта. На Rust нельзя написать ни одной программы, не имея хорошего понимания lifetime & ownership. Это автоматически делает его очень сложным. Так же стоит отметить очень свобразный апострофо-кавычечный синтаксис Rust значительно усложняющий написание кода. D в этом отношении гораздо проще и универсальнее. К тому же в D есть режим `betterC` позволяющий использовать ручное управление памятью и сводящий 80% преимуществ Rust к нулю. http://dlang.ru/faq
>>1300888 Сто раз уже обсуждали. 1) Без ГЦ D не нужен 2) У нас на 10к строк растокода лайфтаймы есть в основном в определнии структур с реферансами (тривиально), либо в редким хитровыебаных трейтах, которые пишутся один раз. 3) Для того чтобы писать на си/++ точно так же нужно понимать lifetime & ownership, с той разницей что компилятор тебе не поможет.
Вообще такое то говно там написано. Большая часть заявлений это просто пук без какой-либо аргументации, например
> Крайне сложно представить себе реальный проект в котором писать Rust было бы экономически оправдано
Вот я пишу энтерпрайз на расте, и вроде как пока не разорилась контора. И чо?
> указывать достаточно низкоуровневые подробности не тогда, когда это действительно нужно, а ПОСТОЯННО Это про что вообще?
> На Rust нельзя написать ни одной программы, не имея хорошего понимания lifetime & ownership. Охуеть, чтобы писать код, нужно знать язык и используемые в нем концепции.
> апострофо-кавычечный синтаксис Rust значительно усложняющий написание кода Вообще пушка. КОД НЕ КАК В МОЕМ ЛЮБИМОМ %ЯЗЫК_НЕЙМ% ВЫГЛЯДИТ, ЗНАЧИТ ГОВНО
> в D есть режим `betterC` позволяющий использовать ручное управление памятью Там есть борроу чекер, лайфтаймы, овнершим и иммутабельность по умолчанию? Если да, то тогда это можно зачесть за аргумент.
> сводящий 80% преимуществ Rust к нулю ясно-понятно
ИЩЕШЬ В КАКОЙ БЫ СИСТЕМНЫЙ ЯЗЫК ВКАТИТЬСЯ @ ПРОБУЕШЬ НЯШНУЮ - УЧИШЬСЯ НЕ ПРОГАНЬЮ, А КАК НЕ СТУПИТЬ В ДРЕВНЕЕ ДЕРЬМО ДИДОВ @ СМОТРИШЬ В СТОРОНУ КРЕСТОВ - ТО ЖЕ САМОЕ, ТОЛЬКО КОНЦА И КРАЯ ДЕРЬМУ НЕ ВИДАТЬ @ ПЫТАЕШЬСЯ ОБМАЗАТЬСЯ РЖАВЧИНОЙ - СЛОЖНО ППЦ, СЛОВНО НЕ ДЛЯ ЛЮДЕЙ ПРИДУМЫВАЛИ @ НАКОНЕЦ НАХОДИШЬ АДЕКВАТНЫЙ ЯЗЫК - ДВИЖУХА НА НЕМ МАЛЕНЬКАЯ, ВАКАНСИЙ С ГУЛЬКИН НОС @ СИДИШЬ НЕДОВОЛЬНО УРЧИШЬ
>>1300961 > ПЫТАЕШЬСЯ ОБМАЗАТЬСЯ РЖАВЧИНОЙ - СЛОЖНО ППЦ, СЛОВНО НЕ ДЛЯ ЛЮДЕЙ ПРИДУМЫВАЛИ Может хоть кто-нибудь внятно объяснить, что там такого сложного и не для людей?
>>1300966 Да нет ничего сложного. кроме futures, которые тоже не сложные, просто ебать какие неэргономичные. Просто неосиляторы привыкли не до конца понятый код запускать в прод.
>>1300967 > кроме futures, которые тоже не сложные, просто ебать какие неэргономичные Я сам их не осилил, как бы не было стыдно. Вообще не вдупляю всю эту асинхронщину ебаную. Один раз пришлось потрогать actix-web (там как раз тиоже вроде эта поебень используется), так было прям больно.
Может есть какие материалы, чтобы вкатиться в асинхронщину? Или хоть идея, чтобы разобраться в этой хуйне?
>>1301722 >magic зато не обосрешься с lifetime-ами объектов охуенная идея, аж стало любопытно раст потыкать эксперты, вопрос: насколько эффективно проверка на borrow совмещается с многопоточностью?
>>1301930 Охуено сочетается. Компилятор не даст тебе отправить в соседний тред значение если оно не Send/Sync. То есть компилято заставить тебя завернуть свое говно в Arc/Mutex
>>1301930 Все проверки borrow checker'а, lifetime'ы проверяются на этапе компиляции. Естественно всякие Arc и Mutex в рантайме, но очень шустро все еще работает.
>>1305242 у меня слишком подгорает, поэтому все таки высру свое охуенно важное мнение
Не понимаю, какое говно он решает.
> In other words, this list: > zero-cost abstractions > move semantics > ... > doesn’t explain what you can do with Rust
Как раз объясняет. Я сразу вижу фичи, которые выделают язык. И понимаю, почему мне нужно выбрать его, на не, например, джаву.
Новый слоган: > Rust: The programming language that empowers everyone to become a systems programmer.
А, то есть язык тупо для ОС и микроконтроллеров, ясно-понятно, пойду на го писать микросервисы. Нет, серьезно, язык отличный для написания чего угодно, но нет, СИСТЕМНЫЙ ПРОГРАММИСТ.
>Even if people have different ideas about what “systems programming” means, they at least have some idea. “guarantees thread safety,” not so much.
Вон из профессии таких программистов (ну или обратно на первый курс).
Ну и тащемта то, чего не хватало на старой версии: ссылок на различны ресурсы экосистемы раста: crates.io, play.rust-lang.org (даже песочницу убрали, суки). Какой-нибудь This Week in Rust. Но нееееет, давайте сделаем ебучий лендинг с маркетинговой хуйней для даунов и кучей пустого места, блять.
Вон D (https://dlang.org/) имеет очень хороший, как по мне, сайт. Может не такой "красивый", но сразу можно и код увидеть, и что и нахуя надо, все ссылочки в верхней панели красиво есть (и выпадающие списки, Карл). Годнота.
>>1305890 Ну а ты не думал о том, что сайт нужен как раз чтобы продавать продукт даунам? Остальные и так разберутся. Может поэтому этот ваш Д такой мертвый?
>>1305926 > Ну а ты не думал о том, что сайт нужен как раз чтобы продавать продукт даунам? Не думаю. Вкатываться в программирование ты почти гарантированно будешь через что-то более мейнстримовое. Расту до этого ОЧЕНЬ ДАЛЕКО (я вживую не видел людей, у которых раст был первым языком). А вот тех кто перекатился видел (целый, блять, офис). И этот сайт вообще никак этому не способствует.
> Может поэтому этот ваш Д такой мертвый? Хз, я на нем не пишу.
Короче на само деле это вкусовщина, каждому свое, но жаль, что убрали песочницу, это действительно прикольная штука, и есть почти везде. Сразу дает минимальное представление о том, что же за язык.
>>1299618 (OP) Можете пояснить, где в играх можно применить раст? Директ икс же написан на крестах. Опенжл на сишке. То есть вся графика с использованием аппаратного ускорения работает на сях. При этом большинство игровых движков так или иначе работают так же на сях. Край энжин - кресты. Анрил - кресты. Юнити - сисярп.
Или это все планируется в будущем? Насколько далеком? Вы точно уверены, что нвидия и мелкософт уволит своих индусов-крестоебов и наймет заместо них школьников-растоебов, чтобы переписать весь прилагающийся к работе с графикой софт?
>>1306761 > Опенжл на сишке Тащемта ничего тебе не мешает писать код, использующий OpenGL, на любом удобном тебе языке. Уверен, что и DirectX также. А сишный интерфейс это хорошо, легко интегрируется с любым языком.
Я думаю, что в большом геймдеве есть следующая проблема: консоли. И вот хрен знает, можно ли под них вообще сейчас хоть как-то писать на расте. А почти все игры это кроссплатформа. Надо чтобы кто-то запилил весь инструментарий, тогда взлетит. А мало кто захочет тратить свои кровные на эту хуйню, ведь и так работает, чо трогать то.
>>1306794 Что значит отдрочка до уровня Clang/GCC? По каким параметрам сравнивать? Типа скорость компиляции или чего? Ну и да, там даже Clang сосет у GCC все еще.
>>1306862 >Что значит отдрочка до уровня Clang/GCC? По каким параметрам сравнивать? Типа скорость компиляции или чего? Ну и да, там даже Clang сосет у GCC все еще.
>>1303677 Ferris is the unofficial mascot of the Rust Community. Many Rust programmers call themselves “Rustaceans,” a play on the word “crustacean.” We refer to Ferris with the pronouns “they,” “them,” etc., rather than with gendered pronouns.
>people often assume that Ferris is a boy and use (he/him), but Ferris is non binary
>>1307037 ого, круто! прогрессивные модные девчонки в команде раста, которые открыты для самых смелых предложенийгусары, молчать!, не то что заскорузлые комитетчики от древних языков программирования! всё, решено - после си буду учить раст!
>>1307795 >из-за обвинений в "поощрении насилия в отношения мужчин" >according to an anonymous Reddit post то есть это какой-то анонимус с реддита напел, крутой источник, чо
Ржавчина или Питон? Было бы не плохо вкатиться в системку, т.к иногда NodeJS не выезжает Хотел 10MB wav через марковскую цепь пропустить, а он вылетает
Посоны в расте можно сделать чтобы распараллеливались вычисления в виде описаном ниже?
Например есть масcив из 1000 элементов координат точек x и y; Mass vector2D = new Mass(); vector2D.add(X, Y); и так 1000 раз
И нужно что бы для отрисовки этих точек использовался не один процессор а 4. Paralleling.Draw(vector2D.pos(0, 249)) Paralleling.Draw(vector2D.pos(250, 449)) Paralleling.Draw(vector2D.pos(500, 749)) Paralleling.Draw(vector2D.pos(750, 999))
Тогда на экране в 4 раза быстрее отрисуются точки нежели с одним процессором.
>>1308525 Раст, какой бы хуйнёй без задач он ни был, тут ни при чём. За рисование отвечает видеодрайвер. Твой Draw() где-то внутри вызовет функцию графического апи, которая вызовет видеодрайвер. Драйвер же собирает вызовы в списки команд и в некие моменты шлёт списки на исполнение в GPU. Ну или в CPU через софтверный рендерер, если GPU не завезли, но на него всё равно никак не повлиять. Так вот, поскольку обычно GPU только один, то подумай, насколько вырастет производительность при вызове Draw из нескольких потоков по сравнению с одним потоком. Ни насколько, даже упадёт из-за оверхеда при переключении сначала контекста треда, а потом, что хуже, контекста графического api. Но даже если бы в системе стояло три 1080 в SLI, это бы не сильно помогло: драйвер назначит одну из карт мастером, и этот мастер будет выдавать остальным карточкам некоторые наивно распараллеливающиеся последовательности команд в очереди выполнения. То есть прирост специфичен для некоторых операций, а стоимость ожидания ответа от слэйвов может и превысить профит. Специально для решения проблем мультипоточности придумали Vulkan, в котором можно руками сабмитить списки команд в очереди выполнения драйвера, а самим очередям добавили простые примитивы синхронизации, чтобы можно было управлять порядком выполнения.
Но конкретно для того, чтобы рисовать точки с максимальной скоростью, не нужны ни многопоточность, ни вулкан, достаточно базового знания графического апи. Просто почитай про hardware instancing для своего любимого апи. Например, в ogl это засунуть все точки в один VBO и отрисовать его через glDrawArrays(GL_POINTS...)
>>1308785 Получается что все игровые движки так или иначе работают с api Direx, Vulkan, OpenGL, а сам по себе язык не может через видяху все это отрисовать кроме как через CPU.
>>1308800 >а сам по себе язык не может через видяху все это отрисовать кроме как через CPU.
Даже этого не может, потому что даже в ДОСе, где вывод на экран делался через запись по какому-то адресу, нужна была отдельная железка для отправки изображения на монитор.
>>1309334 Раст взлетел. Хочешь работу? Учи жабу[скрипт]. Хочешь чтобы было быстро, больно и дешманскую работу, учи кресты. Чтобы раст был популярен нужно чтобы люди начали думать о том, как типы помогают решать проблемы.
>>1309346 >Раст взлетел. Вот руби взлетел, да, вроде и ебанутый язык. По твоей логике и D взлетел. >Хочешь чтобы было быстро Значит раст таки еще один высер без задач? Зачем же он нужен такой медленный?
>>1309315 > 1) Почему раст не взлетел? Потому что он лезет туда где не привыкли прыгать и всё переписывать на каждую новую модную хуйню. Потихоньку растёт популярность и хорошо. > 2) Быстрее ли раст чем си++? Чудес не бывает. Скорость на уровне цпп это уже очень заебись. Сокращение времени на написание и отладку кода тоже очень хорошо. > 3) Что надо сделать, чтобы раст был популярен? Он и так достаточно популярен.
>>1309351 >Значит раст таки еще один высер без задач? >Зачем же он нужен такой медленный?
на раст переходят с питона, руби, перла, хацкеля, сишарпа, жабы, жабоскрипта и прочих медленных языков программирования вот в этом и есть великая польза раста!
>>1309315 > 1) Почему раст не взлетел? Да вроде взлетел. Хотя я хз, че ты вкладываешь в это понятие. Язык развивается, новые вакансии появляются. Да, не пщ с котлином, но там за языками стоят серьезные конторы.
> 2) Быстрее ли раст чем си++? Сложно сказать. Быстрее ли C чем C++? Мне кажется, что раст, в теории, побыстрее, ибо все таки там меньше рантайма, чем в плюсах. Но тащемта можно и на C++, и на расте забить на классы/трейты и писать как на C, тогда вообще its all the same shit.
3) Что надо сделать, чтобы раст был популярен? Да тащемта ничего. Он и так потихноьку становится все более популярным.
Лол, нужели растодауны правда думают что у них в языке дохуя выразительная система типов, а не просто кучка ad hoc решений, выразимая в любом языке с дженериками, и некоторым количеством boilerplate при реализации (типо лайфтаймов и тайпклассов без HKT) >>1309671 >>1309346
>>1310035 Все в сравнении познается. У каких языков с равной или большей популярностью система типов по выразительности такая же или лучше? Haskell и Swift, больше нихуя нет.
>>1310037 Мне например трейты раста нравятся. И то как генерики с ними работают. Ради интереса в тот же Хаскель заглядывал, тайп классы - это какой то duck typing, если в типе функции есть с нужными названиями, то он автоматом становится членом тайпкласса (или я ебу дал и несу хуйню).
>>1309315 >1) Почему раст не взлетел? Чтобы "взлететь" в современном мире нужно быть жаваскриптом или goвном похуже. Это как с соцсетями и техникой — все пользуются техническими испражнениями вроде инсты/фб/айфонов/итд просто потому что ПРОСТА. >2) Быстрее ли раст чем си++? Токой же. >3) Что надо сделать, чтобы раст был популярен? Почаще срать в этом треде, и держать его в топа. Своеобразный местный смм.
>>1310325 Запили ядро на расте и чтобы было быстро как в си, и показаны главные достоинства языка. Алсо, я вкатываюсь в раст и все думаю, зачем я учу ебанутый синтаксис и эту экосистему, если есть кресты, которые куда интуитивнее и где хотя бы инкремкнь с декрементом есть.
>>1310328 Чтобы не быть ограниченным мудаком с ЛОРа и выучить новые концепты, до которых ты не додумался бы самостоятельно, а потом применять их на практике и в других языках.
>>1310332 Например, я раньше думал, что за шаблоны в прикладном коде нужно пиздить палками, но раст мне показал, что дженерики на каждый чих - это вполне легитимный и удобный способ писать код.
>>1310332 Главная фича раста — борроу-чекер и зеро-кост абстракции построенные вокруг него. Так ьы получаешь безопасное и быстрое управление паматью и безопасный многопоточный код с функциональным вкусом.
>>1310330 Програмач вчера: > Иди учи хацкель и поменяй полученные откровения в других языках Програмач сегодня > Иди учи раст, чтобы не быть как долбоебы с лора)0 Програмач завтра > Ну бля, черепашка вперёд потом налево)00Ы Пагади бля, направо) соре
>>1310378 В смысле конкретную либу для шарпов или похожий MVVM-тулкит, который рендерит XAML? Первое вряд ли получится сделать эргономично, а второе почему нет? Биндинги для SDL, OpenGL и Cairo уже есть, херачь.
Уже 2019 год на подходе. Сколько лет должно пройти после выхода первой версии языка программирования, чтобы можно было делать вывод о его востребованности? Ну чтобы отмазки типа "язык мало времени существует, поэтому ещё ничего крупного на нём не написано" не прокатывали?
>>1311067 Язык востребован, когда за него платят деньги. Вакансий на данный момент мало и, в основном, криптопараша, но тем не менее, они существуют.
>ничего крупного на нём не написано Назови несколько крупных проектов, которые написали за последние несколько лет на на плюсах, на джаве, на шарпах. Т.е. именно написали с нуля, я не про поддержку легаси говна. Рынок проприетарного софта поделен, опенсорцу тоже не особо нужен ни второй блендер, ни второй nginx. Ну вот недавно выходцы из дайсов объявили, что будут пилить свой движок на Расте. Если взлетит, это сделает его востребованным в твоих глазах?
>>1311097 >что будут пилить свой движок на Расте На крестах это боль потому что. В расте хоть рефлекшн есть и тулзы для AST. Не надо свои метаклассы лепить из говна и палок как в Qt и анриле.
>>1311178 И не только, в крестах легко проебатся с памятью и указателями, в статьях на хабре посвященной теме PVS-Studio, там и показываются те трудно уловимые ошибки.
>>1311197 >в крестах легко проебатся с памятью и указателями Это редко бывает, сейчас тулзы хорошие, валгринд все вылавливает, да и с голыми указателями нечасто работаешь. Для десктопных программ это не слишком критично опять же.
У меня есть желания на расте попробовать написать игровой движок, но как толь задумаюсь сколько миллионов строк кода нужно написать и нужно будет ебатся с математикой сразу желание отпадает.
>>1311211 Движок писать - самое бесполезное занятие. Лучше сразу игру пиши. То есть реализуй необходимый минимум, который нужен вот прямо сейчас, и не больше. Граф сцены, например, можно сразу выкинуть, он реально не нужен для игр, там сложной иерархии не встречается обычно. >нужно будет ебатся с математикой Какая там математика? Либ для векторов-матриц-кватернионов полно, бери любую.
Подскажите, wasm он только для фронта нужен? Где посмотреть и поконтрибьють в него можно? Насколько он нестабилен сейчас, чтобы на нем писать веб-приложения? Алсо, возможно ли сейчас или в будущем писать SPA, как на реакте? Вот четыре вопроса. Ответьте на каждый плис, ребята поопытнее.
>>1311255 В wasm сейчас нет полноценного доступа к DOM и очень куцый интероп с js. Можешь накодить свой движок для рендера и лейаута через webgl, и на нем рисовать гуй.
>>1311224 >Движок писать - самое бесполезное занятие. Ну почему же? Движок это разные программные компоненты для удобного создания игры, создания анимаций, игровых событий, всяких эффектов и т.д. без этого нужно будет писать много кода, а так все это инкапсулируешь и работаешь через удобные интерфейсы.
>Какая там математика? Физика столкновений, работа с тенями, работа с отображением материалов и многое другое.
>>1311302 С webgl ты js гораздо реже будешь дергать, чем при работе с DOM. Вся производительность от нативного кода сожрется оверхедом на вызов js из wasm.
>>1311306 > Движок это разные программные компоненты для удобного создания игры, создания анимаций, игровых событий, всяких эффектов Пока ты игру не напишешь, ты не узнаешь, какие компоненты удобные, а какие-нет. Поэтому и глупо их писать заранее, если у тебя опыта нет. >Физика столкновений, работа с тенями, работа с отображением материалов и многое другое. Обычно все это даже с готовым движком приходится писать в каком-то виде, особенно материалы. Или по крайней мере очень хорошо представлять, как оно работает внутри. Базовый колижен, кстати, во всех физических движках искаропки, если ты еще и физику не собираешься сам писать.
Хочу вкатиться в раст и пилю всякие hello world'ы. Но вопрос не об этом. В качестве IDE использую vscode, но из неё не получается собрать проект, валится ошибка
Compiling some_project v0.1.0 (C:\rust\some_project) error: linking with `link.exe` failed: exit code: 1181 = note: LINK : fatal error LNK1181: cannot open input file 'advapi32.lib'
Нагуглить ответ не получилось, поэтому запускаю сборку из x64 Native Tools Command Prompt for VS 2017, но это не очень удобно. Может кто-нить подсказать, как наладить сборку из vscode?
>>1311656 Сорян, братиш. Помог бы, но винду юзать для разработки это добровольный мазохизм. Вкати себе прыщи на виртуалку для экспериментов, поймешь как там все удобно сделано для разработки.
Когда уже в раст завезут нормальные асинхронные функции? А то после языков с ними даже элементарные многопоточные задачи превращаются в мучение. Например нужно сделать поллинг функции в отдельном потоке, при этом поток в любой момент можно остановить. В расте приходится городить свою структуру контекста, откуда вызывать функцию сна (у меня оно реализовано через мютекс с булеаном внутри, означающим завершить тред или нет + условная переменная).
Так, доны-аноны, настало время провести заседание по вопросу rust + wasm.
Контекст. Из wasm кода не доступно браузерное апи. Единственное решение -- использовать биндинг к js. Группой энтузиастов разрабатывается и поддерживается stdweb (https://github.com/koute/stdweb) как такой вот биндинг, и cargo web (https://github.com/koute/cargo-web) как основная тулзовина, автоматизирующая разработку/сборку. На прошлых выходных в Москве состоялась конференция RustRush, на которой Ashley Williams, одна из основных контрибьюторов wasm working groupe, пришедшая в rust из nodejs, презентовала, по сути, wasm-bindgen (https://github.com/rustwasm/wasm-bindgen) как биндинг и wasm-pack (https://github.com/rustwasm/wasm-pack) как основной инструмент автоматизации процесса разработки. Среди прочего хорошего, как новый легковесный аллокатор, следует особо отметить, что wasm-pack сильно завязан на инфраструктуру nodejs/npm.
Вопросы. 1. Как оцениваете такой шаг, когда вместо улучшения существующего решения, создают новое с почти тем же функционалом? 2. Как вам такая жесткая привязка к nodejs/npm в разработке rust + wasm приложений? 3. Как считаете есть ли теперь будущее у stdweb и cargo web? 4. Почему такое маленькое сообщество у такого крутого языка? (риторический вопрос)
Мнение. С учетом того, насколько маленькое сообщество у rust, мне бы хотелось видеть как люди объединяются вокруг уже существующих решений, а не пилят такиеже, но свои. И, как сторонник разумного минимальзма во всем, я совершенно не понимаю зачем мне зависимости (nodejs/npm/WebPack), без которых я явно смог бы обойтись, разрабатывая что-то на rust + wasm. Это ещё и с учетом того, что я не являюсь хейтером js стека, писал под nodejs и среда эта для меня родная. Просто не понимаю, зачем всё в кучу смешивать.
>>1312535 Пытаются облегчить перекот для жс-макак. В стиле элма. У тебя есть приложение которое явно повязано на нпм. Ты хочешь оптимизировать вот этот кусок, и для этого юзаешь раст. И для тебя это выглядит как подключение обычной либы из npm. Как по мне, звучит логично. Эшли похожа на продавщицу из овощного.
>>1312550 В таком подходе выглядит логично, но что делать тем, кто не повязан на npm и хочет в стиле этого https://github.com/DenisKolodin/yew что-то писать? Получается нужно писать с использованием их инструментов и и шаблоны, потому что это же core team и их подход дефолтный и правильный.
>>1312535 >Вопросы. >1. Как оцениваете такой шаг Быстрее работает на тех же принципах (нпм/ноджес говна) благодаря бороу чекеру и зиро-кост абстракциям (плюс) >2. Как вам такая жесткая привязка к nodejs/npm в разработке rust + wasm приложений? Полная хуйня, к сожалению >3. Как считаете есть ли теперь будущее у stdweb и cargo web? Возможно.
Вот был бы rustscript, быстрее ваших жсов в тыщу раз, то было бы круто.
>4. Почему такое маленькое сообщество у такого крутого языка? Синтаксис ебанутый, ну и еще надо все в ансейф оборачивать, чтобы быструю программу написать.
>>1312553 stdweb никто не отменял. Не вижу ничего плохого в том, чтобы иметь несколько конкурирующих подходов. Либо один из них со временем отомрет, либо место найдется для обоих.
>>1312555 >Быстрее работает на тех же принципах (нпм/ноджес говна) Имел ввиду сравнение stdweb и wasm-bindgen, а не rust и nodejs. >надо все в ансейф оборачивать Это как раз очень плохая практика. Чуваки из Baido рассказывали, что нашли 2 уязвимости в стандартной библиотеке раста. В стандартной библиотеке раста! Чувствуете иронию? А появились они там как раз из-за таких вот подходов и ошибочных представлений. Почти везде, где используется unsafe, можно и нужно обойтись без него! Но это отдельная тема.
>>1312567 Что ты несешь? Уязвимости были из-за неверного использования unsafe. Разница в том, что в расте unsafe изолирован и явно виден, а в крестах, например, у тебя все приложение unsafe.
Интересно, что баг был не в unsafe блоке, а в коде, который этот unsafe использовал.
>>1312535 cargo-web + stdweb значительно медленнее чем wasm-bindgen + web-sys + js-sys. В первом случае ты просто все вызовы в js!() макрос оборачиваешь и пишешь на джаваскрипте, а втором случае у тебя готовые типобезопасные биндинги ко всему API js и DOM. Плюс wasm-bindgen автоматом будет поддерживать работу с DOM в обход js, когда добавят такую возможность в стандарт и браузеры.
>>1312761 Разумные аргументы! Меня смущает только попытки определить стандартный workflow с использованием излишних зависимостей. В гайде по wasm-bindgen в разделе Basic Usage (https://rustwasm.github.io/wasm-bindgen/whirlwind-tour/basic-usage.html) сразу про webpack и npm пишут. Может я зря парюсь и так оно и должно быть всё, если по нормальному делать.
>>1312784 Я на draco начал пилить, правда там всего один разраб который пропадает постоянно. Но там все что от него нужно это реализация VirtualDOM, а дальше хоть форкай и пили сам что хочешь. Есть еще несколько разных реализаций VDOM на wasm-bindgen, но они все как и draco делаются в половину человека, поэтому пофиг что брать, только производительность VDOM волновать должна. Я вообще свой синаксис шаблонов поверх написал чтобы можно было на другой фреймворк съебать безболезненно.
Раньше тут ошивался шизик и общался сам с собой, теперь его затопили ебланы, тащащие раст в фронтенд. Ладно если был бы в этом смысл, но ведь переусложнённый и баганный вариант работает ещё медленнее жса потому что это просто ебаная прослойка над ним.
>>1313166 > просто ебаная прослойка над ним. Шта? WASM это не прослойка, он через специальный AOT+JIT работает напрямую с железом. Для доступа к DOM и прочим WebAPI да, нужна прослойка для JS. Но например для WebGL уже можно писать безжаваскрипта вообще.
>>1313182 >Но например для WebGL уже можно писать безжаваскрипта вообще. Там тоже через js сейчас все вызывается. А значит за кадр не больше нескольких тысяч вызовов gl-функций. Это примерно как в 2001 году, когда DirectX на каждый чих сискол делал. Очень небыстро.
>>1313182 >для WebGL >в треде только и обсуждается работа с DOM, веб-фреймворки и прочий фронтендный вебмакакинг >>1313226 Да на текущий момент однохуйственно слишком дорого рисовать в браузере что-то кроме анимаций в плане ресурсов, ещё лет 5 хотя бы надо поперетаскивать людей со старых железок, и уже думать о браузерных ммо и прочей дрочильне.
>>1313166 Ты чё, пёс, wasm это киллерфича раста. Во всех остальных направлениях уже есть устоявшиеся стеки, а здесь у раста реальный шанс взлететь. Осталось только апи нормольное дождаться.
>>1313265 Фронт и бэк на одном языке, можно суб-крейты шарить с общей логикой. Нормальная система типов с которой не страшно рефакторить. Скорость компиляции c wasm-pack незначительно отличается от скорости траспиляции всяких webpackов c babelом.
>>1313267 Быстрее дробит цифры ты хотел сказать. Только вот в вебе это нахуй не нужно, рисовать интерфейс так — слишком оверкилл по всем параметрам. Когда полноценные игори начнут переезжать в бровсер можешь высрать этот аргумент, а сейчас иди пукай в другом месте. Или иди покажи как рокетсаенс в браузере мутить. >>1313271 Хорошо, нахуя тащить его что на бек что на фронт? По времени и деньгам, это как дворников/маршрутчиков/строителей-джамшутов пытаться заменить роботами — никогда не окупится.
Система типов для гуйни, где нужна возможность прототипировать и смотреть выхлоп на лету — это, конечно, нечто. Сидишь такой, анимируешь кнопку, а тебя борроу-чекер в гц окружении (которое там так или иначе будет) ставит раком.
>>1313334 Кекнул с сурьёзного челибосса, пишущего гуй на васме с растом. Иди работу найди, не страдай синдромом хачкеля. >>1313338 А вот это уже серьёзно, два чая этому хвосторекурсионному лиспогосподину.
>>1313355 >>1313349 Я просто не растовый виабушник, сори гуйз. >>1313358 Дык, это можно высрать на жсе за пол дня, да и работать в текущем виде вебасма будет быстрее. Нахуй пихать раст в фронтенд (ладно ещё в бэк, можно придумать йоба-хуйлоадный кейс), до сих пор не понятно.
>>1313358 Без таких выебонов как у тебя на пике. Тупо формочки можно будет лепить без еботни с HTML, плюс десктопные проги переносить в веб. Хоть автокад, хоть 3дмакс.
>>1313374 > десктопные проги переносить в веб Разве что это, да. И еще в виде обычного приложения высрать хуйню на электроне. Ну и браузерки. Как-то это всё ощущается так, как будто надо не дать производителям железа отдохнуть. 2025 год, фотошоп перестал тормозить? Следующую версию сделаем в браузере хули.
>>1313378 >фотошоп перестал тормозить? Следующую версию сделаем в браузере хули. Почему ты думаешь, что раз в браузере, то будет тормозить? Идея как раз в том, что с wasm+webgl будет производительность и потребление ресурсов близкие к нативу.
>>1299618 (OP) Итак напомните-ка еще раз, зачем раст высрали?
1. Зачем нужен раст, когда уже давно есть рельсы, жаба, котлин? 2. Раст, как язык с сахаром. На самом деле тебе придется ебаться с с++, чтобы по-настоящему оценить это говно. 3. А зачем ебаться с с++, чтобы потом ебаться с растом, если можно стать жабой-меном и получать свои 200 ? 4. А лучше вообще становится гошником и получать 300 ? 5. По своей сути - раст - это высер, который только усложняет код своим "безопасным" подходом. Трудночитабелен, и не понимаем. Требует бекграунда определенного, для новичка - самый кал. 6. Ну и что за ебанутый 4 пикрил? Фриендс оф раст? Какие-то мелкобуквенные компании. 7. И вообще, сейчас низшее программирование неблагодарное занятие.
>>1313415 >Чудес, к сожалению, не бывает. При чем тут чудеса вообще? Там никакой магии нет. Нативный код и ручное управление памятью быстрее и тратят меньше ресурсов. Это факт.
>>1313602 В вебе нет настолько тяжелых скриптов, чтобы была заметна разница в скорости выполнения. Большая часть вычислений - это DOM, но его Раст не ускорит.
>>1313814 >все коллы к вебгл к через жс >жс крутится в отдельной вм, и коллы извне это дорого как с жавой >весь код энивэй будет работать в вм >а эта браузерная вм работает в осевой вм >сама ос тоже своего рода вм >а ещё следующее поколение процессоров сделают с изолированной вм на уровне микрокода Вот этот господин уже высрал сценарий такого будующего >>1313338. Гуд лах хэв йор перформанс.
>>1313375 Угу, для десктопа. Причём на Qt нет софта, который не выглядел бы везде одинаково ущербно. А ещё до Qml там кастомизация была на уровне изменения цвета кнопок. А теперь давай перенесёмся в реалии веба, где сайты открывают с хуйлиарда типов устройств, от компуктеров с экранами 21:9 с разрешением 5к до ебучих смартчасов c 272x340. Под каждый тип экрана свой интерфейс будешь делать по каждому пуку дизайнеров? Короче, к чему это я — веб со своими жсами/хтмлми/итд это конечно кривая жопная хуйня, но она такая из-за рынка, и это её оптимальное состояние. >>1313602 >Нативный код и ручное управление памятью быстрее и тратят меньше ресурсов. Это факт, но ещё есть другие факты: 1) Это ебать как дорого; 2) Это ебать как долго; 3) Код всё равно работает в вм; 4) Ты конечно убежишь от гц, но он там рано или поздно появится (см пропозалы), и большинство кода в окружении будут его юзать если это не твой код на расте, лол (будет ситуация как с языком D). Собственно, если нет нужды на это никто не пойдёт. Дропбоксов в мире очень мало, видишь ли.
>>1313833 >все коллы к вебгл к через жс Они обещают нативные вызовы. >вмвмвм Читай, как webasm работает. Там нет ВМ. Байткод компилируется в натив после статической проверки на безопасность. Производительность хуже, чем у оффлайн-компиляторов, но достаточно высокая.
>>1313833 >Причём на Qt нет софта, который не выглядел бы везде одинаково ущербно Да похуй как он выглядит. Тот же 3дмакс далеко не шедевр дизайна, люди его не за это покупают. Главное функционал, который на жабоскрипте ты никогда реализовать не сможешь. >Под каждый тип экрана свой интерфейс будешь делать по каждому пуку дизайнеров? Это и так приходится делать для сайтов. Некоторые еще и мобильную приложуху делают. Я говорю о софте, а не о сайтах. Автокадом на часах никто пользоваться не будет.
>>1313566 Хуйню спизданул по почти каждому пункту:
> 1. Зачем нужен раст, когда уже давно есть рельсы, жаба, котлин? Разные сегменты как бы. Тащемта вполне даже в рамках одного проекта могут сосуществовать раст и, например, джава (сам на таком сижу).
> 2. Раст, как язык с сахаром. На самом деле тебе придется ебаться с с++, чтобы по-настоящему оценить это говно. Ну хз. В чем то ты прав (сам писал на C++, и тут сразу прям зашло), но при этом знаю людей, которые перекатились с других языков (джава, скала), и им тоже заебись.
> 3. А зачем ебаться с с++, чтобы потом ебаться с растом, если можно стать жабой-меном и получать свои 200 ? Не понял, при чем тут С++. А вот про джаву: не всем нравится говнокодить энтерпрайз (внезапно). Есть еще и другие задачи. И иногда и за больше деньги.
> 4. А лучше вообще становится гошником и получать 300 ? Сейм щит: не для всех задач подходит.
> 5. По своей сути - раст - это высер, который только усложняет код своим "безопасным" подходом. Трудночитабелен, и не понимаем. Требует бекграунда определенного, для новичка - самый кал. Ну такой трейдофф: ты получаешь безопасный язык с zero-cost абстракциями, офк появится некоторая сложность. Но немного попишешь, перестроишь мышление), и уже будешь так же легко, как раньше, писать код.
> 6. Ну и что за ебанутый 4 пикрил? Фриендс оф раст? Какие-то мелкобуквенные компании. Ты явно новенький в ИТ. Куча хороших контор, которые делают супер годные продуткы.
> 7. И вообще, сейчас низшее программирование неблагодарное занятие. Очередной смузихлеб поравлся, несите следующего.
>>1313844 >Главное функционал, который на жабоскрипте ты никогда реализовать не сможешь. Реализовать-то что угодно можно, только работать будет лет через 15-20. >Это и так приходится делать для сайтов. Вот вообще нет. > Я говорю о софте, а не о сайтах. Автокадом на часах никто пользоваться не будет. На сайтах тоже. По факту сайты это самые обычные гуй-приложульки. Весь чертёжный 2д функционал автокада (и как минимум статичную проекцию такого добра хотя бы под парой углов) можно реализовать уже сейчас (см. приложения вроде Figma), остаётся вопрос — а нахуя? Прогреть процессор чуть сильнее? Ведь всё равно для работы таких приложений тем более нужны полноценные компутеры, с планшетика не поработаешь в дороге, а на любом пк, тем более на ноутбуке, банально быстрее будет нативный софт, ведь даже самое оптимистичное отставание в 10-20% (которое будет обязательно) превратит работу даже в фш в полный пиздец.
Короче, пока высирал свою "войну и мир" до меня дошёл смысл вебасма — эту движуху гугл затеял чтобы всех анально привязать к софту, который нельзя спиратить. Это пока что единственный логичный кейс, без выдавливания обоснований нужности из неоткуда.
>>1313566 > усложняет код своим "безопасным" подходом Если тебе это сложно и не идёт, а борроу чекер тебя просто пиздец доебал, то в цпп ты творил бы полностью корявую, лагающую, дырявую херню.
>The variable name is highlighted in transgender pride flag colors. >str::replace() swaps in "E" for "T"; the program prints out "Hello, E!" >"E", as in estrogen.
>>1313863 > спиратить В теории можно будет так же васм данные пропачить и запускать офлайн сохраненный файл. >>1313844 > функционал, который на жабоскрипте ты никогда реализовать не сможешь https://clara.ioхоть я и все равно считаю идиотизмом вынесение такого в браузер.
>>1314016 > JS, внезапно, уже овер 10 с хуем лет работает точно так же что в пихле что в макаке. Я в курсе, но в WASM (1) байт-код может быть гораздо более оптимизированным (хотя это зависит от конпелятора язык_нейм в байткод) и (2) там идёт AOT компиляция, что в js можно делать очень ограниченно из-за того что язык динамический, а все современные движки AOT не делают вообще и более того даже минимально парсят неиспользуемый код, чтоб страницы с несколькими сотнями килобайтов (если не мегабайтов) жс-говнокода быстрее загружались.
>>1313936 >В теории можно будет так же васм данные пропачить и запускать офлайн сохраненный файл. Ты не понимаешь концепции. В той же фигме у тебя все данные банально болтаются на сервере, спирачивание каждой версии будет необходимо начинать с эмуляции сервера со всем апи, который будет постоянно меняться, и это без учёта шифрования и банальной большей защищённости от патчинга и дебагинга кода налету ввиду изоляции в браузере (ну разве что кто-то будет ради этого форкать движки браузеров и выпускать свои, лол).
Короче, пиратить-то будет можно, но с такими затратами что это нахуй никому не будет нужно.
>>1314057 Ок, и к чему это? Ну загрузится скомпилированный код на пару секунд быстрее, дальше что? Он будет работать в тех же условиях что жс, и всё, кроме числодробления там будет работать с той же скоростью.
>>1314069 >и всё, кроме числодробления там будет работать с той же скоростью. Кроме числодробления там еще есть ебаная динамическая типизация жабоскрипта и его же объектная система, которые с любым джитом будут тормозить.
>>1314222 Вась, а рендерить и работать ты где будешь? Такое даже для гугла дорого. Суть вебаппов в том, что движуха в плане нагрузки-то твоя пека берёт на себя, но ты привязан жопой к дилде гугла под эгидой "безопасности и удобства".
>>1314190 >челы сначала запилили полностью свой парсер и анализатор для ИДЕИ на котлине >потом челы додумались что МЕДЛЕННА и решили сделать всё готовыми нативными средствами Прям как местные со своим васмом. Только в терминальной стадии, местные ещё в начальной.
>>1314246 Так а причем тут ИДЕЯ то? Ты сравниваешь инструмент, которым можно пользоваться везде, с плагином для исключительно своей хуеты.
Все таки инструмент скорее замена Racer и RLS, у которых действительно есть некоторое количество критичных недостатков.
>потом челы додумались что МЕДЛЕННА Вот тут бы как раз поспорил, ИДЕЯ с растом работает вполне прилично, особых тормозов не видел. Другое дело, что не все пользуются ей. Жаль, что jetbrains вместо помощи сообществу пилит свою хуету.
>>1314124 >Кроме числодробления там еще есть ебаная динамическая типизация жабоскрипта и его же объектная система, которые с любым джитом будут тормозить.
Если ты сам не станешь передавать при каждом вызове параметры с рандомными или динамически запиленными типами, то после пары прогонов жит прогреется и на динамическую и объектную систему ему станет похуй. Не похуй ему будет, если ты в очередной раз внезапно вместо числа передашь строку тут то он и охуеет и откатится в интерпретацию.
>>1314404 > то после пары прогонов жит прогреется и на динамическую и объектную систему ему станет похуй Ты слишком всё упрощаешь. Во-первых не пары, а несколько десятков раз (зачастую JIT делаются уровневыми и максимальный уровень оптимизаций достигается только после сотен итераций циклов или вызовов). Во-вторых это будет справедливо, только если особенным образом писать код на JS. Например те же итераторы сделаны так, что оптимизировать из чрезвычайно сложно. Так что если хочешь быстрый код, придётся отказаться от кучи сахарка со времён ES6, но этого, разумеется, никто делать не будет.
>>1314411 И да, добавлю, что именно поэтому раст мне нравится. В JS если вместо for(;;) будешь использовать for(of) то можешь сразу попрощаться с пирформансом (для того чтобы оптимизировать итераторы, которые использует for of, нужны очень мощные оптимизации вроде escape analysis чтоб убрать все аллокации при создании кучи побочных объектов, которая оффициальная спецификация ECMA требует создавать в реализации). В расте же все эти итераторы изначально делаются zero-cost и могут занять больше времени разве что при конпеляции.
Растаманы, лишился тут своего ноута на время и придется работать за старым компом , на котором только под шиндой. Что там вообще можно устроить , чтобы с ржавчиной работать? Решил попробовать на эмаксе , но racer работает через жопу , плодя процессы и блокируя буффер на каждом дополнении. Vs code просто говно, на котором постоянно что-то отваливается. Idea накатить нет возможности , ибо 32 бит. На чем вообще тогда писать остаётся ?
Биндинги curses тут кто-нибудь пердолил? Я ньюфаг и в Расте и в Проклятиях, если что. Т.к. у меня винда выбрал вот эту либу: https://github.com/ihalila/pancurses/ Не могу понять чем различаются функции addstr и printw. У них в Расте одинаковая сигнатура, просто принимают строку которую выведут. В примерах зачем-то используются обе функции, хотя делают они одно и то же. В сишке сигнатура разная, addstr принимает просто строку, а у printw сигнатура и предназначение как у классического printf - си-стайл форматирование. В расте понятное дело этот функционал обрублен, переменного числа аргумента у printw нет. Но если в строке будет какое-нибудь "%s" - выводит рандомный мусор. Короч я не понял зачем было в биндингах оставлять такую ущербную версию printw, ещё и в примерах его использовать в перемешку с addstr.
>>1317345 Не, мы не отрицаем факт того, что ты дебил ибо свой прошлый высер про "в 70 раз медленнее крестов" ты как-то ничем не подтвердил, дапокормил зеленого
>>1317905 > у меня оно не упало Потому что компилируешь в debug режиме. Баг работает только в release. > Кажется как раз в последних версиях запилили workaround Это не для компилятора, а для библиотеки. Компилятор всё выдаёт неправильный код.
>>1317909 Да, ты прав. Я таки в дебаге скомпилил. С opt-level=3 упало.
В любом случае, это таки: а) баг компилятора (и даже не Rust, как ты сам и заметил), а не языка, и б) баг при оптимизации. Это совсем не то же самое, что стрелять себе в ногу, долбясь в unsafe к нулевому указателю.
Котоны. У меня есть enum варианты которого имплементят Display. Как мне сделать без бойлерплейта реализацию Display для самого енума, который будет просто передавать вызов конкретному варианту?
>>1317928 Ну сорт оф решение будет в будущем: запретить такое нахуй, как написано в ворнинге. Хотя пока пример валидный. (блять, какой норкоман писал этот код)
>>1317930 Не согласен. Мне кажется, что ворнинг это как раз то, что можно проигнорировать и оно продолжит работать (может медленнее, или код будет менее красивый). А если ты (компилятор) уверен, что это некорректный код и все сломается, то стоит запретить.
>>1299618 (OP) Ребята привет! Напомните-ка, почему раст такой ущербный? Даже в соседних тредах людей сюда заманивают. Он уже настолько плох? Алсо, еще и плохочитаемый. Как вы вообще дышите здесь?
А расскажите мне про раст-ембедед, что там да как вообще. Там есть нормальная отладка? Что-то сложнее консоли и светодиода можно написать при этом чтобы не требовалось внешнюю оперативу и флешку для бинарника?
>>1318099 > Там есть нормальная отладка? Отладка стандартная GDB (или LLDB) + OpenOCD. Интеграция с IDE это уже другой вопрос, я не пробовал. > А расскажите мне про раст-ембедед Начиная с 1.31 версии (последняя на данный момент) можно писать no_std бинари (в которых нет встроенного аллокатора) без включения экспериментальных фич и почти без пердолинга (лютый пердолинг начнётся если захочешь сделать библиотеку, особенно универсальную). > не требовалось внешнюю оперативу Странный запрос. Обычно программы на слабеньких bare-metal мк внешнюю (т.е. в виде отдельных компонентов) оперативную память и не требуют. > и флешку для бинарника А это уже решается линкером, а не компилятором. Насколько я знаю в расте можно указывать в виде атрибутов куда линкеру размещать определённые куски данных, но возможно придётся попердолиться.
Я пробовал писать программы для Cortex-M3 на RTFM [1] и работало всё норм. Кстати, асинхронные функции (они же корутины) изначально делаются так, чтоб работать без аллокаций, так что в no_std (а значит и в embedded) они тоже будут работать. Интересно будет испробовать когда их закончат.
Пока что напрягают две вещи: неполноценные константные функции и отсутствие констант в генериках. Частично можно решить шаманством с макросами и абсолютно ебанутым шаманством с трейтами [2] уровня шаблонов C++98, но выглядит некрасиво и непонятно.
>>1318004 Неудобный вопрос: >с гарантиями потокобезопасности Как вы их гарантировать собрались? Нарушить теорему Гёделя? Или расписаться в неполноте языка? Нахуй вы вообще такие вещи на первую страницу вешаете, ваш язык рассчитан на полных дебилов, которые в элементарную логику не могут? Если так, что хорошего в языке с коммьюнити, состоящим из дебилов?
>>1318166 > Отладка стандартная GDB Супер, меня устроит. Интеграция с ide не так важна, если есть gdb. По моему опыту зачастую gdb бывает удобнее некоторых дерьмовых ide (не знаю, какая для раста там есть). > в которых нет встроенного аллокатора Встроенный не умеет нормально с мк работать? А сторонних понаписали уже? Впрочем, на небольших мк без операционки или с какой-нибудь rtos обычно на моей практике все старались не выделять память динамически. > лютый пердолинг начнётся если захочешь сделать библиотеку, особенно универсальную Универсальную в смысле для разных архитектур или о чем вообще речь? > Обычно программы на слабеньких bare-metal мк внешнюю (т.е. в виде отдельных компонентов) оперативную память и не требуют Ну я преувеличил, конечно, но вообще к тому, что в newlibc из arm-none-eabi тулчейна, которым я пользовался последнее время, некоторые инструменты из libc жрали очень много стека (например форматирование строк), и оказалось, что для мелких мк хорошей практикой является подмена printf на что-то попроще. > можно указывать в виде атрибутов куда линкеру размещать определённые куски данных Это хорошо, но меня размер бинарника интересовал. При одинаковой функциональности программы сильно ли отличаться будет размер от того же самого, написанного на C. > асинхронные функции Под мк корутины? Интересно поглядеть. как это всё будет работать.
А это проект энтузиастов или это прямо разработчики раста пилят? Я так-то за раст пока не решился взяться, но прям читаю про него и держу кулачки, чтобы когда-нибудь в ближайшее время он стал достойной заменой C/C++ для встраиваемых (особенно bare-metal) систем. Было бы здорово. Спасибо за развернутый ответ.
>>1318172 Раст очень мощный язык. Пост анона за написаный по наитию за 30 секунд, конечно опровергат все талмуды CS и труды учёных, которые разрабатывали язык.
>>1318276 > Встроенный не умеет нормально с мк работать? А сторонних понаписали уже? С этим пока всё плохо. В no_std аллокатора нет, а std для bare-metal не подходит. Есть API для аллокаторов (так что запросто можешь написать свой, там 2 функции: аллокация, деаллокация), но в no_std нет коллекций и объектов, которые могли бы его использовать. Сейчас хотят вынести все коллекции и объекты, требующие динамические аллокации из std в отдельный крейт [1], который будет работать в no_std и где будет возможно использование любого аллокатора + свой собственный обработчик OOM [2] (где например ты сможешь перезагрузить мк). Но сейчас тишина. > Универсальную в смысле для разных архитектур или о чем вообще речь? Ну да. Для условной компиляции придётся использовать флаги карго и в отличии от #ifdef из Си нельзя использовать целочисленные значения, только булевы. > размер бинарника интересовал С размером всё норм. Причиной большого размер растопрограмм, на который некоторые жалуются, являются две вещи: (1) стандартная библиотека и (2) статически скомпилированные несколько версий одной зависимости. (1) для no_std не является проблемой, а вот (2) вполне себе может всплыть. Например ты используешь крейт XXX версии 1.1 и крейт YYY. В свою очередь крейт YYY использует крейт XXX версии 1.0 и указано, что только эту версию и никакую другую. Из-за этого в бинарник слинкуются обе версии пакета XXX, что увеличит размер. Для тех кто программирует на С/С++ это будет в новизну, поскольку в си эта проблема решалась отсутствием пакетного менеджера и полностью ручным управлением зависимостями.
Ну и ещё может всплыть размер debug-версии программы. Хоть раст и использует zero-cost абстракции, в debug-версии они далеко не zero-cost и могут быть как медленней, так и занимать больше места. Иногда в разы. Особенно весело выглядит когда в debug-версии, чтобы подёргать пин дополнительно пишутся пара ветвлений и вызовов функций. > Под мк корутины? Угу. Их изначально пилят без динамических аллокаций. > А это проект энтузиастов или это прямо разработчики раста пилят? Автор japaric является разработчиком раста и вносит в язык/компилятор изменения для улучшения работы в embedded. Но конкретно RTFM это не официальный проект, да. Официальные проекты все находятся здесь [3]
А вообще там куча хотелок для embedded-разработки [4]. Учитывая как круто всё продвинулось в 2018 году, думаю скоро допилят недостающие части.
>>1318309 Насчёт std и аллокаторов: получается сейчас использовать большинство встроенных непростых типов данных, в МК не получится, так? То есть с точки зрения "батареек" сейчас раст под голый мк не лучше C? А управление зависимостями вручную возможно вообще как-то? То есть, описанная тобой проблема разных версий она вообще как-то хоть решаема на данный момент?
Алсо, а что с поддержкой конкретных МК и их периферии? Кто-то пилит либы или обходятся биндингами на libopencm3?
>>1318314 > Насчёт std и аллокаторов: получается сейчас использовать большинство встроенных непростых типов данных, в МК не получится, так? Встроенных - да. Я использовал в своём проекте библиотеку heapless [1]. Мне оттуда всего хватало. > То есть с точки зрения "батареек" сейчас раст под голый мк не лучше C? Сложно сказать > А управление зависимостями вручную возможно вообще как-то? Можно. Просто скачиваешь нужную версию крейта, проводишь необходимые изменения и в качестве источника указываешь каталог с крейтом [2]. Теперь вместо crates.io будет использоваться локальный каталог и обновлять зависимость сможешь только вручную. Можно даже сделать так, что при любом запросе этого конкретного крейта (даже если остальные берутся с crates.io) карго всегда отдавала локальную версию [3]. > Алсо, а что с поддержкой конкретных МК и их периферии? Тут ответ нужно разбить на две части. (1) - поддежржка архитектуры и (2) поддержка периферии. Первое касается компилятора и пакетного менеджера, второе - библиотек. 1) Если твоя архитектура оффициально поддерживается [4], поздравляю, никаких проблем не будет. Учитывая, что боддерживаются Cortex-M[0-7][F] то скорее всего с этим особых проблем не будет. Иначе придётся пердолиться и самомму компилиовать libcore под свою архитектуру. И это если сам llvm эту архитектуру поддерживат. Если llvm не поддерживает, то есть два варианта - транслировать раст в Си, а потом компилировать уже сишный код [5], самому пердолиться с llvm и добавлять возможно компиляции на свою архитектуру, как делают с AVR [6]. 2) Тут вопрос библиотек. Для работы с периферией используются специальный раст-файлы сгенерированные из SVD при помощи утилиты svd2rust [7]. Там генерируются относительно безопасные абстракции для работы с периферией. Для некоторых мк есть уже готовые [8]. Плюс пилится универсальный hal [9], работающий поверх этих файлов, сгенерированных из SVD. Для некоторых мк также есть уже готовые реализации [10].
>>1318340 Не знаю что такое SVD. Ладно, буду читать, потому что очень интересно стало. Круто, что это всё активно развивается, в том числе самими разработчиками языка. Ещё раз спасибо за развернутые ответы и ссылки.
- User doesn't like that dining philosophers is cited with some male and/or gender-neutral pronouns and placeholders (even though the original exposition was already changed to female pronouns) -- proceeds to change the rest of the pronouns to female (I guess gender-neutral didn't make sense) https://github.com/rust-lang/rust/pull/25640
- User thinks that the code of conduct is too general in its suggestions that all people be respected and treated fairly -- it needs to explicitly cite certain groups https://github.com/rust-lang/rust-www/issues/268
>>1318276 >чтобы когда-нибудь в ближайшее время он стал достойной заменой C/C++ для встраиваемых (особенно bare-metal) систем Он там нахуй не нужен. Там же микроконтроллеры с килобайтами памяти, все пишется на ассемблере или очень низкоуровневой сишке без динамической аллокации (потому что стандартная библиотека с маллоками тупо не влезает). Плюс там всякая низкоуровневая ебала, в принципе не совместимая с идеологией раста. Вроде того, что регистры МК мапятся в глобальные переменные, и ты через них дергаешь какой-нибудь аппаратный функционал.
>>1318888 > Там же микроконтроллеры с килобайтами памяти, все пишется на ассемблере или очень низкоуровневой сишке без динамической аллокации Bare-metal это не только старинные 8-битные контроллеры, где каждый бит на цену золота. Плюс раст вполне себе работает без аллокаций. > в принципе не совместимая с идеологией раста Не пизди. Тут только вопрос абстракций. Множество проверок неправильного использования проделываются во время компиляции. Для остальных используется unsafe (и то по большей части это не ограничение языка, а из-за того, что CMSIS-SVD файлы не описывают мк достаточно подробно, чтоб добавить все проверки). > Вроде того, что регистры МК мапятся в глобальные переменные, и ты через них дергаешь какой-нибудь аппаратный функционал. В расте (конкретно в файлах, сгенерированных svd2rust) можно использовать как и синглтоны (но такое использование нужно оборачивать в unsafe) либо как специальные типы, которые могут быть только в единичном экземпляре, зато могут свободно перемещаться по функциям и потокам (в случае есть используется RTOS). Плюс встроенные в систему типов стандартные гарантии безопасности, например что может быть сколько угодно ссылок на чтение, но только одна на запись и т.д.
>>1318906 >Bare-metal это не только старинные 8-битные контроллеры, где каждый бит на цену золота. У большинства 32-битных микроконтроллеров ОЗУ не больше 64 килобайт: https://www.chipdip.ru/catalog/ic-microcontrollers?x.3713=UCU Остальная память - ROM разных видов. >Тут только вопрос абстракций. Ну так в условные 64 килобайта у тебя много абстракций не влезет. Часто бывает, что и стек не влезает. Приходится делать локальные статические переменные вместо стековых. Раст такое умеет?
>>1318949 > Ну так в условные 64 килобайта у тебя много абстракций не влезет. Влезет. Почти все они zero-cost и все проверки происходят во время компиляции. Правда много оптимизаций (по встраиванию функций и удалению мёртвого кода) ложится на плечи LLVM, а не самого компилятора, так что ассемблерный код на всякий случай стоит проверять, учитывая что 90% багов мисскомпиляции это баги LLVM. > Приходится делать локальные статические переменные вместо стековых. Раст такое умеет? Умеет. Правда любой доступ к подобной переменной считается небезопасным. https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=1ab67d50fec6df4d9eae343630749b9d
>>1318888 > Там же микроконтроллеры с килобайтами памяти, все пишется на ассемблере или очень низкоуровневой сишке Лол, ты давно последний раз этим занимался? Сейчас разница в цене между микроконтроллерами не такая большая, поэтому очень часто конторы просто ставят железку позабористей, лишь бы сделать заказ быстрее и получить бабло. Никому не упёрлось мудиться с ассемблером и высчитывать байты полгода, если можно ту же задачу решить за месяц. На моем последнем рабочем месте вообще в некоторых проектах часть высокоуровневой логики была написана на питоне и работала под их собственной адаптацией micropython. Может, крупные компании при производстве в огромных количествах при таком подходе и меньше профита получат, чем если будут писать на асме, но тут ни в одной конторе я сам ни разу такого не видел и не слышал такого ни от одного из знакомых, кто байтоёбством ещё со студенческих годов занимается. > без динамической аллокации (потому что стандартная библиотека с маллоками тупо не влезает). Аллокаторы с разными фичами по-моему в любую ртос уже завезли, да и newlibc не настолько жирная, не помню, чтобы она не влезала, но обычно без динамики можно обойтись в голом железе. Я не любитель такого подхода, когда вместо оптимизации и использования приемлемых средств запихивают кучу говна и ставят железо помощнее и памяти побольше, но есть какая-то граница разумной борьбы за ресурсы, за которой уже начинается абсурдный дроч.
>>1318953 >Почти все они zero-cost и все проверки происходят во время компиляции. Как ты будешь, например, лямбды без стека делать, ты подумал? Инлайны тоже придется отключить.В итоге программа на расте под микроконтроллер будет выглядеть хуже сишечной из-за unsafe через каждое слово. Нахуя тогда этот раст нужен, если сишка для таких задач тупо проще?
>>1318966 > Как ты будешь, например, лямбды без стека делать, ты подумал? Путём встраивания. Учитывая, что 90% лямбд одноразовые это наилучшее решение. > Инлайны тоже придется отключить. Можно сказать LLVM, чтоб он не инлайнил автоматом, но инлайны заданные вручную через атрибут #[inline(always)] всё равно будут встраиваться. Это тебе не С/С++ где компилятор может игнорировать любой запрос ели ему захочется. > В итоге программа на расте под микроконтроллер будет выглядеть хуже сишечной из-за unsafe через каждое слово. Никто не заставляет использовать unsafe. Я на мк писал довольно сложные приложения с RTOS и (псевдо)многопоточностью и unsafe там не нужен был от слова вообще поскольку библиотеки давали неплохие безопасные абстракции. Например если заранее известно, что на мк одно ядро и одну функцию не могут одновременно вызвать два разных потока, то локальные static mut являются безопасными. Так например делает фреймворк RTFM при помощи макросов.
>>1318957 >Сейчас разница в цене между микроконтроллерами не такая большая, поэтому очень часто конторы просто ставят железку позабористей, лишь бы сделать заказ быстрее и получить бабло. Очень сильно зависит от задачи и от серии. Если серийность небольшая, то можно и одноплатник с линуксом поставить. А если девайс миллионной серией выпускается, то заказчик каждый цент считает. То есть в условный китайский фонарик, который красиво моргает светодиодиками, ты можешь поставить только супердешевое восьмибитное говно без корпуса.
>>1318969 Это все равно на уровне можнаследать. Вопрос, нахуя ебаться, если сишка с IDE у тебя искаропки, а с растом приходится пердолиться? И каких-то особых преимуществ он не дает, потому что нет ни многопоточности ни динамической аллокации, а все данные - в основном в глобальных переменных. Писать на нем может и приятнее, но каких-то суперудобных фич там нет.
>>1318970 Так я об этом и писал. Просто в России по-моему китайские фонарики никто не делает, потому что стоимость выйдет не та, и они никому не нужны будут. А всё остальное не в таких масштабах делается. Алсо, в фонариках и прочей подобной ебале часто заказные микросхемы стоят, которые реализуют нужную логику работы, написанную на каком-нибудь vhdl, и микроконтроллерами там не пахнет даже.
>>1318974 > Это все равно на уровне можнаследать. Это всё на уровне ужеработает. > И каких-то особых преимуществ он не дает, потому что нет ни многопоточности ни динамической аллокации Это тебе для китайских фонариков многопоточность нужна? Чтоб двумя светодиодами моргать одновременно без задержек? И да никаких проблем с многопоточность нет, что в одноядерных системах, что в многоядерных (хотя на многоядерных мк я на расте не писал).
Странно ты как-то тему сменяешь, сначала мычал про то что абстракции не бесплатные. Хотя большинство абстракций тот же RTFM предоставляет через compile-time макрос, который всё проверяет во время компиляции и после чего генерирует растокод, т.е. по факту ты пишешь даже не на расте, а на растоподобном DSL заточенном на работу с мк. Теперь же вообще тебе раст не нужен, потому что тебе он не нравится.
Раст это поделие тупых либерал-феменисток и лгбт, и для подобных создан. Когда они заменят все маняоффенсив термины, ни один нормальный человек никогда не станет писать на этом ебучем языке. Тьфу в ебало, растопидор.
>>1318977 >Это всё на уровне ужеработает. Прямо раст искаробки в фирменном IDE идет? >то что абстракции не бесплатные Так и есть. Лямбды не бесплатные, трейты не бесплатные, инлайны не бесплатные. Тупо вызов функции - не бесплатный, когда каждый такт и байтик экономишь. >Теперь же вообще тебе раст не нужен, потому что тебе он не нравится. Мне он не нужен, потому что я от него какой-то особой пользы не вижу. Можно типа срать не снимая свитера, охуенно.
>>1318982 > Прямо раст искаробки в фирменном IDE идет? Нет. Такое доступно только илитным программистам на ассемблере. ИДЕ с линтером, который сыпет фатальными ошибками на каждый несэкономленный бит. > Так и есть. Верю тебе. Честное слово. Зачем мне смотреть на сгенерированный ассемблерный код и делать выводы, если анон с сосача всё пояснил как боженька. Вопрос закрыт. Ты абсолютно прав. Это даже обсуждать нельзя. Я запрещаю.
>>1318992 > говно Это слово запрещено к использованию согласно нашему Code Of Conduct, кроме тех случаев если вы феминистки или транссексуалки и говном называете патриархально-белое капиталистическое общество и его адептов.
Пожалуйста, соблюдайте правила, или я вынуждены буду пожаловаться модератору.
И да, единственное число по отношению к человекам использовать тоже запрещено, как и все местоимения третьего числа, кроме они.
>>1318995 Раст использует особую систему типов, разработанную на основе GST (gender studies theory), разновидности type theory, изначально испробованной в хаскеле, но убранной оттуда по причине недостаточной прогрессивности мейнтейнеров языка.
>>1319305 Пару раз возникала мысль посмотреть раст как альтернативу крестам для своих проектов, но каждый раз я открывал список мейнтейнеров и кор команды языка, и понимал что не хочу шквариться используя что-то созданное этим биомусором. Воистину, нормальный язык может быть создан только людьми.
>>1319347 Да уж, что говорить о применимости языка вообще, если его кор разработчики на сайтах знакомств для пидоров сидят. Не удивлюсь, если еще и в чат-рулетках.
>>1319437 На расте пилишь? Я бы такое в терминале пощупал, неплохо сделано, но хорошо бы вимоподобный инкрементальный поиск по тексту шапки например...
Нормально-ли в контроллере Rocket на необрабатываемые ошибки высираться с помощью panic!("[здесь_название_метода_который_вернул_error]: {:?}", e)? Есть-ли какие-то более правильные решения, чтобы не приходилось постоянно это писать в ручную?
>>1319604 Как видишь добровольно и бесплатно пока что получается в основном на расте. Особенно это хорошо заметно в трендах гитхаба, где новые тулзы каждую неделю появляются.
>>1317439 >нативную Гм, не понятно в каком смысле они "нативные". >tui-rs Под юниксы, у меня шиндовс. >Cursive Ну оно какое-то не оче и заточенное под менюшки, я вообще зачем-то тетрис пилю в терминале и мне было интересно потрогать curses.
Да и вообще вопрос был "какого хуя оно так?", не в том что я не могу осилить curses (просто использую addstr и по-прежнему не понимаю зачем в расто-версии printw и почему только у меня этот вопрос возник).
>>1321000 Убрали необходимость в mod.rs типа потому, что если у тебя есть три модуля: ./foo/mod.rs ./bar/mod.rs ./baz/mod.rs То в некоторых говноредакторах у тебя будет три вкладки mod.rs mod.rs mod.rs
Что-то пока не очень понимаю enum. Производит впечатление какой-то смеси enum и union из C, правильно? У самих вариантов явного значения как в C это было нет, но при этом принцип работы при использовании в match примерно такой же, как в switch из C. Но при этом в вариантах можно хранить данные разных типов, если мы создаем экземпляр варианта и кладём его в переменную. Зачем это нужно, кроме случаев Some/None? Какие еще сценарии использования enum могут быть?
>>1321951 Гугли "алгебраический тип данных". Гапример в хаскеле все, что не примитивные типы - оно самое.
Вообще enum'ы это полезная штука. Простой пример: мы любим запускать таски в тредах, а потом сохраняем все результаты. Таска может: успешно выполниться, завершиться с логической ошибкой или запаниковать. Для этого можно описать такой enum:
>>1321124 Поддержу. На Win10 ноутбучной решил поставить Раст вдобавок к Cpp, Haskell, Go... и только rustup отказывается ставиться: rustup install stable вываливается с ошибкой SSL[35], проще говоря валится на curl. Я даже _curlrc сделал. Ну и чего ждать от людей которые работу инсталлятора не могут сделать нормально настраиваемой?
> обработка ошибок как в win32api > дженериков нет и не будет > официальный сайт и документация без подсветки синтаксиса, потому что главный разработчик (!) языка считает что она не нужна (!!) > ущербный менеджер пакетов > конфликты т.к. один монолитный путь GOPATH на все
>>1322477 > > дженериков нет и не будет Н-но ведь во второй версии обещали гонерики. Как генерики, только круче и проще для использования молодыми специалистами.
Служу в секретной мурманской залупе, читаю TRPL и Programming Rust, оторваться не могу. Единственное, не хватает сухой документации по стандартной либе, чтобы программировать на бумажке. Где-нибудь такое можно достать? Как же ущербно выглядит Go в сравнении. Зря столько говна писал на нем.
>>1322642 >>1322644 У меня только телефон на Андроиде, которым я могу втихаря пользоваться несколько часов в неделю, и компьютер на Windows без доступа в интернет. Я не даун, честное слово.
>>1322661 Увидишь нить в какое-то не то русло, но отвечу. ЗГТшный софт, логирующий все подключенные PCI/USB устройства, отсутствие любой сетевой карты в принципе, отсутствие админских прав, возможность посидеть за компьютером без присмотра офицеров только во время дежурства по роте после общего отбоя. Я тут себе PDFки печатаю и сшиваю, а не с пацанами в доту и хартстоун катаю по сети, как пацаны с флотилии делают. Только за праздники чекист четыре раза приходил.
>>1322712 Если прочитать статью об уходе целиком, то станет понятно, что чел - гендерно небинарный вертосексуал и ушел оттуда из-за неравенства и харассмента, а не изза доков, как несведомый анон пишет.
>>1322742 Ну он и не программистом был. Вот его интересные цитаты из hn: > Mozilla is actually the best-paying job I've ever had, if that tells you anything. And it was an okay salary. I've never been more financially secure. But I'd like some of that "easy SV money" :) > My peers are engineers, my job title was technical writer. Across the industry, writers make less than engineers do.
И судя по гитхабу кодер из него так себе: > Looking at Steve's 177 'source' repositories @ Github and disregarding documentation and presentations, there is absolutely nothing that can be described as substantial engineering. Throwaway code, small sample projects and tiny tutorials and more often than not, skeletons and incomplete beginnings.
>>1322748 Я понимаю, что евангелисты нужны. Но он даже сам себя евангелистом не считает, хотя я его видел в каждом треде по расту, что в реддите, что в hn. Да и зачем кому-то нужен будет евангелист раста, кроме мозиллы?
>>1322744 Меня это тоже удивило, но не так сильно, как отсутствие возможности обращаться к строке по индексу и отсутствие в стандартной библиотеке возможности вытаскивать из строки букву. Только слайсы, причём я пока не понял как надо будет угадывать индексы, чтобы в середину символов не попадать, либо итерироваться по символам или байтам. После питона мне такие ограничения как серпом по яйцам.
Модули же как namespace в плюсах? Зачем для методов отдельное ключевое слово impl, почему их нельзя сразу в структуре описать? Ну или хотя бы заголовки там, а тело ниже. По-моему это гораздо нагляднее, учитывая, что методы непосредственно к структуре и её данным относятся.
>>1322818 А отдельных файлов с хедерам с копипастой сигнатур и ifdef тебе не хватает? Попробуй разобраться, сначала, почему что-то сделано так, а не иначе.
В чем ваша проблема-то? Как по твоему пиздон это делает без итерации, то?
impl можно не только кастомные методы, но и трейты. Плюс ты можешь impl свои трейты для импортированных структур. Короче, это для унификации синтаксиса.
>>1322986 > В чем ваша проблема-то? Просто не все привыкли к utf8 где нельзя взять символ по индексу, используя только арифметику указателей. Впрочем с приходом эмозди и прочего говна в 16-битрых кодировках тоже такая хуйня появилась.
Например, в C# вся инфа объекта хранится в куче, а в стеке только адрес. Заметил что в С++/расте не так, и много инфы объекта хранится в стеке (например, длина векторов). Из-за чего приходится переменные из стека передавать по ссылке, со всеми "прелестями" вроде dangling pointer и прочего. Я не понимаю, зачем так сделано и почему нельзя сразу хранить в куче свойства объекта?
>>1323107 Ты сишарп тоже недавно изучать начал? Там с самого появления есть структуры, которые тоже на стеке хранятся. А ещё недавно появился Span, который вместе со stackallock позволяет хранить на стеке вообще что угодно без использования небезопасного кода. Правда майки не добавили АПИ для определения свободного места на стеке из-за чего этот stackallock довольно опасен (раньше он вообще был только для unsafe кода). >>1323110 > это сложная хуйня с обращением к ОС А в C# и подобных языках ещё и нагрузка на GC.
>>1323125 >stackallock позволяет хранить на стеке вообще что угодно без использования небезопасного кода Я аж вспомнил как спорил с каким-то дауном в си треде где-то год назад, и он доказывал что надо всё выделять только на стеке и вообще куча это хуйня, небезопасно и 4 мб хватит всем, alloca наш б-г. >раньше он вообще был только для unsafe кода Да потому что он и не может быть безопасен, долбойоб блять. >Правда майки не добавили АПИ для определения свободного места на стеке из-за чего этот stackallock довольно опасен Определение стека знаешь? Смысл превращать его в кучу? >>1323107 > Из-за чего приходится переменные из стека передавать по ссылке Ахуеть, а ты откуда вылезла, обезьяна? Где ты вообще такое видел? Всё, что вмещается в стек, обычно просто копируется, ибо это примерно всегда быстрее из-за особенности работы процессора с оперативкой.
>>1323294 > Определение стека знаешь? Смысл превращать его в кучу? Чтобы снизить нагрузку на GC. Особенно актуально для короткоживущих объектов, даже escape analysis не всегда осиливает их убрать. Не зря же даже в жаве проект вальхаллу пилят (аналог структур из C#).
>>1323294 > Да потому что он и не может быть безопасен, долбойоб блять. У тебя странное определение безопасности. stackalloc был небезопасен потому что возвращал raw-указатель на стек, который CLR не мог отслеживать. Span же это умный указатель, про содержимое которого CLR в курсе, а потому stackalloc с ним стал абсолютно безопасен. StackOverflowException это вполне себе безопасное исключение.
>>1322962 Бля, вот хэдеры и вся эта ебатня с ними и миллион ifdef и прочего макросоговна, размазанного тонким слоем по проекту -- это пиздец. Но пока я не понимаю какое это отношение имеет к выносу реализации методов. И копипаста сигнатур нинужна, если реализовать методы прямо там же, но насколько я помню, в какой-то книжке по ++ писали, что в самих классах обычно заголовок только. >>1322984 Зачем нельзя по индексу букву получить я понимаю, причины хорошо описаны в разделе про String. Чего я не понимаю так то, что не включили возможность вытащить именно букву в стандартную библиотеку. Если правильно понял, то основная проблема в том, что операция взятия значения по индексу должна выполняться за o(1), а с буквами это не прокатит. Ну хуй с ним, почему отдельный метод нельзя запилить?
>>1323318 > Чего я не понимаю так то, что не включили возможность вытащить именно букву в стандартную библиотеку. В жаве сделали так же. Хочешь нормальный символ с учётом всех этих суррогатов, используй метод chars(), который возвращает IntStream. И оттуда уже бери необходимый символ используя методы stream'ов. В расте просто нет легаси API, которые не учитывают многобайтовые символы.
>>1323294 >Я аж вспомнил как спорил с каким-то дауном в си треде где-то год назад, и он доказывал что надо всё выделять только на стеке и вообще куча это хуйня, небезопасно и 4 мб хватит всем, alloca наш б-г. Ага, потом выясняется, что >Из ядра Linux убрали массивы переменной длины (VLA), размер которых определяется на этапе выполнения, а не компиляции кода. Они замедляли работу и могли влиять на безопасность операционной системы. Линуса Торвальдса уже давно просили избавиться от VLA, да и сам он активно критиковал решение использовать массивы переменной длины. В kernel 4.20 большую часть из них наконец исключили.
>>1323298 Я у тебя, дурака, про определение спросил. Не про высосанные из пальца проблемы вм. Ты писал что >майки не добавили АПИ для определения свободного места на стеке из-за чего этот stackallock довольно опасен Я тебе, овощу блядь, отвечаю: стек отличается от кучи в том числе принципиальным отсутствием индексации, о каком апи для определения свободного места можно говорить? >>1323303 Ты это вообще к чему написал? Ну придумали майки (auto)unique_ptr спустя 15 лет его появления в крестах, ну залатали они дырку которую сами сделали хз когда. stackalloc безопасен? Нет, блять, он тебе за выигранные спички потенциально создаст ещё хуйлиард проблем. Если escape analysis не понимает, что объект можно держать на куче, то этот код гарантированно запутаная хуйня, где и человек рано или поздно накосячит.
Вообще, не понятно нахуя дотнет-то нужен, если ебаться приходится похлеще чем в плюсах. В жаве-то ладно — всё под капотом, рядовой мартышке не накосячить.
>>1323318 >Ну хуй с ним, почему отдельный метод нельзя запилить? Потому что итераторы, архитектура и у-н-и-в-е-р-с-а-л-ь-н-о-с-т-ь.
>>1323413 > стек отличается от кучи в том числе принципиальным отсутствием индексации, о каком апи для определения свободного места можно говорить? Изи. Это managed-стек. VM запросто может отслеживать свободное место на нём. > Ты это вообще к чему написал? А, понятно. Ты managed от unmanaged не отличаешь. Точно дурачёк и пытаешься умничать. Не мудрено, что > Вообще, не понятно нахуя дотнет-то нужен
>>1323424 >Изи. Это managed-стек. VM запросто может отслеживать свободное место на нём. Отлично гений, из управляемой кучи в управляемый стек. Почему он такой какой есть используется, ты, ебанатина, не задумывался? Носом опять ткнуть или сам головой подумаешь? >А, понятно. Ты managed от unmanaged не отличаешь. Точно дурачёк и пытаешься умничать. Не мудрено, что Ну да, не мудрено что ты пришёл в растотред и начал пороть нюфагу бред про хуй пойми что. Про ненужность дотнета хуйню спорол, извини. Специально создавать столько проблем для холостой траты на них времени и денег — такой хуйнёй даже плюсы никогда не были, такой вот кортельный заговор погромистов.
>>1323496 > из управляемой кучи в управляемый стек. Он и так управляемый. Безусловно взятие оставшегося места будет занимать относительно много времени (на раскрутку стека и расчёт уже занимаемого места), но такое можно сделать и на простом стеке, ничего волшебного тут нет. Хватит под умного косить. Работал бы ты хоть раз со стеком, знал бы, что ничего невозможного тут нет.
>>1323499 К тому же JIT/интерпретатор сам по себе хранит кучу метаинформации о функции (даже если она заинлайнена, чтобы при эксепшоне выдавать полный стек), так что ничего сложного тут не будет.
>>1323421 > Ну и commmon lisp в продакшне. А вот тут расскажи подробнее? Что делаете, как используете? Я думал что CL вообще только как промежуточный этап до Scheme какого-нибудь.
>>1323499 > Безусловно взятие оставшегося места будет занимать относительно много времени >>1323298 >>>1323294 >> Определение стека знаешь? Смысл превращать его в кучу? >Чтобы снизить нагрузку на GC. >Хватит под умного косить. Работал бы ты хоть раз со стеком, знал бы, что ничего невозможного тут нет. Что с этим ебанавтом? Это managed рак мозга?
>>1323511 Наш хаскель гуру заебался месить говно лопатой в жабо-имплементации openauth и сделал свой сервис. Потом еще фронтэнд тесты на нем же были, но загнулись. Как по мне, >>1323512 прав. Смысла никакого в CL в 21 веке нет.
Я раньше пробовал на кложаскрипте писать, но все что хоть немного связано с jvm тормозное и уебищное, поэтому бросил это дело. А недавно начал немного заниматься синтезом, и вот для этого дела clojure+overton зашло мне на ура.
>>1322101 Пошел нахуй. Вот просто пошел нахуй. У меня всё собирается без проблем. Это единственный язык и система сборки/менеджер пакетов где у меня всё собирается без проблем. Всем бы языкам такое. У тех же npm и pip нет кучи очевидных фич которые есть у cargo.
>>1324166 Да, признаю ошибку. Просто трафик с мобилы был завернут в ВПН, а ноут подключался к мобиле. С pip та же история, что-то в этой цепочке ломает SSL. Дома нормально зашло.
Как создать вектор фиксированной длинны заполненный пустыми String'ами? (В общем случае заполненный выдачей функции-конструктора, в случае String'ов - String::new()) Только ручками пушить в цикле?
>>1322818 >Зачем для методов отдельное ключевое слово impl, почему их нельзя сразу в структуре описать? Ну или хотя бы заголовки там, а тело ниже. По-моему это гораздо нагляднее, учитывая, что методы непосредственно к структуре и её данным относятся.
Потому что дженерики. У тебя может быть такая структура:
[code] struct Cage<T> { animal : T } [/code]
Ты можешь сделать так:
[code] struct Cat {} struct Dog {}
imlp Cage<Cat>{ fn meow(){} }
imlp Cage<Dog>{ fn bark(){} } [/code]
Само по себе это не даёт нихера, но ведь есть еще система трайтов:
[code] trait Mammal { } impl Mammal for Cat{} impl Mammal for Dog{}
Ну и красота. Теперь у тебя есть клетка с котом, которая может мяукать и вонять и клетка с собакой, которая может гавкать и вонять, причем второе ты описал только один раз, но обошлось без наследования, когда хрен проссышь, из чего в итоге состоит класс, и без динамической диспетчеризации. А если динамическая диспетчеризация таки нужна, то не нужно вносить никаких изменений в структуру, работает из коробки.
>>1324588 и тут я неожиданно понял как переводится dinamyc dispatch. Все время думал что это динамическое расщепление. Кстати Generic Programming это изначально русское определение Обобщенное програмирование, перевденное на английский.
>>1324456 >let mut v = vec![String::new(); 5]; Лол, я почему-то думал что этот вариант макроса только с литералами работает. >но default идиоматичней, как бы. Поясни о чём ты или ссылку на почитать дай.
>>1322986 >Как по твоему пиздон это делает без итерации, то? Насколько я помню в Пиздоне у строк фиксированное кол-во байтов на символ в рамках одной строки, которое подстраивается в зависимости от того какие символы в строке. Ну, то бишь если в строке только ASCII - символы один байт занимают. Но если ты к строке зааппендишь какой-нибудь смайлик на который нужно 4 байта - вся строка станет 4-х байтной (UCS-4 кодировка) и те ASCII-символы тоже конвертнуться в UCS-4.
>>1324868 Ну так Питон оптимизирован так чтобы код быстрее писался, а не быстрее работал. Ну и в реальном коде переходы к более многобитной кодировке наверное редки. И ничего плохого в этом нет, должны быть языки и для хуякхуякиготово.
>>1324921 Зависит от криворукости бенчера. Вполне может победить питон, если питонокод будет представлять из себя тонкую обёртку над оптимизированной библиотекой на С/С++, а растокод будет написан вручную и при этом вместо использования ссылок (потому что автор не осилил борроу чекер) большая часть объектов будет копироваться при передачу в функцию.
Хотя чаще всего теститруют I/O и тут может победить кто угодно в зависимости от того у какого языка запись на диск быстрее с параметрами по-умолчанию, поскольку про такие страшные вещи как flush или буферизацию большинство бенчеров даже не слышали.
Аноны, сам я не местный, вкатываюсь с пистона с промежуточной остановкой на джулии. В пистоне заебали вылеты в рантайме после пары минут работы, а я то ещё невнимательное хуйло. В джулии вроде всё заебок, но эта задумчивость, это пиздец, да и от ошибок рантайма защита немногим лучше. В связи с чем вкатываюсь в раст и обнаруживаю, что работы с матрицами-массивами никакой и нет. Даже инициализировать массив циферками от 0 до 10 - уже сложность-невозможность м.б. есть макрос для этого?. Сторонние либы юзать пока не хочу - доверишься им, а они заглохнут, тем более, шта мне многого и не надо. Хочу, для начала, такие вещи: - глубокие срезы многомерных массивов. Типа xs[::2,::3]+1 - простенькую инициализацию циферками-интервалами
На будущее, когда надоест велосипедить, нашёл такие либы ndarray cgmath nalgebra simple-matrix - кто что из этого юзал, что скажете?
>>1324943 Бери nalgebra. Ее решили юзать как дефакто-старндарт для игростроения, так что не прогадаешь. Раст все таки не интерактивная хуйня для математики, а типа системный язык, поэтому странно ожидать от него таких специфичных штук в стандартной либе/языке.
>>1325152 >Очевидный HH. Но тут нет баксов и адекватной работы >Ну или ищи работу на C(++) Хороший вкат в язык >и чем тебя криптохуйня не устраивает? Я не гей.
>>1325194 >Я не гей. А чего ты хочешь? На дворе 2019 год, тут либо месить легаси лопатой и потихоньку толкать что-то новое, либо пилить очередной криптовысер (ибо только тут все свои высеры пишут с нуля).
Ну, а вообще есть вариант повысерать чего нить на гитхабе и попробовать разослать резюме во всякие дропбоксы/мозилы (но с твоим отношением к геям тебя туда не возьмут, лол) и другие компашки с 4-го оппика.
>>1325726 >Последний раз когда я смотрел вакансии Когда ты вообще вакансии в открытом доступе видел у таких компаний? Я не про висячую хуйню, которую просто всем лень убрать. Там очень высокая конкуренция и либо ты сам всем своё cv будешь пихать в рот, либо на тебя всем будет похуй.
ИТТ мы можем объяснить базовые и продвинутые концепции языка, и
программирования в целом, поможем вкатывающимся, подскажем что
выбрать для веба, игр или спасибо абу блокчейна.
https://www.rust-lang.org
> Пачиму helloworld весит как моя мамка?!1й
https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html
Читать
Оф. книга, она же растбук
https://doc.rust-lang.org/book/
https://rustbyexample.com/
Очень хорошая книга, отлично зайдет после растбука:
http://shop.oreilly.com/product/0636920040385.do
Упражнения
https://exercism.io/tracks/rust
https://github.com/crazymykl/rust-koans
Писать
IDE
https://areweideyet.com/
Вебня
http://www.arewewebyet.org/
Игры
http://arewegameyet.com/
Etc
https://wiki.mozilla.org/Areweyet
Список интересных проектов
https://github.com/rust-unofficial/awesome-rust
Новости
Компиляция всего, что произошло за неделю
Иногда постят вакансии
https://this-week-in-rust.org/
Сколько вешать в лайках
https://github.com/trending/rust
Оп рекомендует:
https://www.amethyst.rs/