В этом ИТТ мы можем объяснить базовые и продвинутые концепции языка, и программирования в целом, поможем вкатывающимся, подскажем что выбрать для веба, игр или, прости Абу, блокчейна.
Почему трансухи, которые дизайнили это, умудрились сделать синтаксис хуже, чем в плюсах? Код на расте просто больно и неприятно читать. Это не язык программирования, а мова программирования.
>>2923611 (OP) мелкобуква в треде и ему нужна помощь есть некие результаты долгих вычислений, которые нужны для работы программы (мнемоника, т.е. один раз посчитали, чтобы потом не считать) хранятся они в условном векторе(ах) если этот вектор(ы) сохранить на диск получится около гига периодически эти векторы нужно редактировать
как с этим работать, если с базами данных возиться не охота? есть какой-нибудь способ (крейт с соответствующим API) сохранить этот вектор(ы) в бинарник (или отдельно на диск) и потом читать/редактировать
есть два условно вечных цикла в двух тредах. есть импорт следующей хуеты: let gr = Gilrs::new().unwrap();
как блядь шарить её между двумя тредами? Спрашивал чатгпт, нихуя не сработало. пробовал юзать в main, пробовал делать глобальным статиком, везда раст посылает на хуй
>>2925670 >>2925712 error[E0277]: `std::sync::mpsc::Receiver<gilrs_core::platform::platform::gamepad::WgiEvent>` cannot be shared between threads safely --> src\main.rs:164:36 | 164 | let evloop_handle = thread::spawn(|| event_loop(gr_evloop)); | ------------- ^^^^^^^^^^^^^^^^^^^^^^^^ `std::sync::mpsc::Receiver<gilrs_core::platform::platform::gamepad::WgiEvent>` cannot be shared between threads safely | | | required by a bound introduced by this call | = help: within `Gilrs`, the trait `Sync` is not implemented for `std::sync::mpsc::Receiver<gilrs_core::platform::platform::gamepad::WgiEvent>`
Из значимого Корпы очень просили, им добавили unsafe_code = "forbid" чтобы не грепать лишний раз по джунскому коду. плюс что-то, стабилизировали и что-то добавили в анстейбл моде.
>>2926608 >ты манагер, тебе продали БЕЗОПАСНЫЙ язык >пересаживаешь своих лбов на БЕЗОПАCНЫЙ язык, получаешь премию от руководства (им тоже продали) >твои лоботрясы копротивляются и пишут везед ансейф >в интернете растопидары рякают на ансейф, но ты простой манагер, а твои лоботрясы ставят анус, что всё заебок >осадочек остаётся >unsafe_code = "forbid" ))
bincode - это то, что я имел в виду, когда писал пост
я до поста все фрагментировал, чтобы считало маленькими кусками и можно было без проблем потом переписать нужный, а не оставлять комп работать на неделю нон стоп
попытался все запихать в json'ы с помощь serde_json, но охуел от скорости сериализации (она занимала раз в пять больше времени, чем сами вычисления)
после поста уже был sqlite - постоянно database is locked, поставил PostgreSQL - все хорошо, запросы идут, данные в БД появляются и я пошел спасть под шум вентиляторов
утром смотрю - в базе 20к записей (за ночь должно было накапать примерно 100к) и ошибка слишком много подключений (хотя .close() у меня прописано в цикле). к этому моменту уже отписался анон про bincode и я переписал под него. все хорошо, все работает. один фрагмент вычисляется 2 мин, 2 сек - это пару недель сна под гул вентиляторов. ок, терпимо.
через пару ночей я вспомнил, что нам обещали мегаоптимизации и прочую залупу. без всякого энтузиазма прописываю [profile.dev] opt-level = 3 и иду спасть. просыпаюсь через несколько часов и понимаю, что в комнате тихо, делаю вывод, что опять что-то наебнулось и охуеваю, когда вижу, что за это время просчиталось ВСЕ, что должно было считать пару недель.
проверяю, что расчеты верные, там ошибок нет и он посчитал, что должен был, а не какую-то хуйню. снова запускаю вычисления уже на одном фрагменте, чтобы понять как она умудрилась просчитать все за три часа - и там где было 2 мин 2 сек, после opt-level = 3 вижу 8 сек 138 мс.
получается, что хоть с оптимизацией, растобляди не наебали.
есть функций как на пике, которые чекают массивы на дубли массивы разной длины, и для каждой длины своя функция
выбран массив, а не вектор, т.к. вектор в куче, а массив вроде как на стеке, типа так быстрее
так вот, кто-нибудь шарит за все эти оптимизации в расте: если компилятор видит, что вектор можно переделать в массив и переместить на стек, он будет это делать? или оставить все как на пике?
>>2929172 Разберись с тем что такое стек и куча. Скорость работы с данными в них одинаковая, потому что это одна и та же микросхема RAM блять. Разница в том, чтобы выделить память на стеке нужно только из регистра верхушки стека вычесть размер требуемой памяти, а выделение памяти в куче это грубо говоря поиск таких свободных блоков, чтобы они образовывали непрерывную область памяти нужного размера, что гораздо сложнее. Зато в куче можно выделять память произвольного размера, а для выделения памяти на стеке в 99% случаев требуется знать размер на этапе компиляции.
Ну и по алгоритму, если размеры сильно больше 5, то у тебя сложность O(n^2), это медленно. Можешь отсортировать свой массив и сравнивать только два соседних элемента, будет сложность O(n log n). Или вообще завести HashSet, и добавлять в него очередной элемент только если он ещё не был добавлен, тогда вообще будет O(n), но расходы на дополнительную память O(n).
>>2929176 >Разберись с тем что такое стек и куча. Ок, почитаю. Всю дорогу почему-то думал, что L1-l2-L3 кэш - это и есть стек, а куча это ОЗУ. Видимо, кэш - это просто кэш :)
>Можешь отсортировать свой массив и сравнивать только два соседних элемента, будет сложность O(n log n). Самое веселое, что изначально так и делал. vec.sort() и дальше сравнение соседних элементов за одну итерацию (при совпадении дропаем итерацию). И это было существенно медленнее, чем сейчас с массивом и двумя итерациями (O(n^2)). Количество элементов до 10 штук, если что. Не знаю уж по какому алгоритму работает у них sort() и какое там большое O, но все замеры были с opt-level = 0.
>>2929176 >Разберись с тем что такое стек и куча. Скорость работы с данными в них одинаковая, потому что это одна и та же микросхема RAM блять Сразу можно обоссать долбоёба.
>>2929181 Кэш это просто кэш, ты на него никак не можешь напрямую повлиять наверное. Просто следует писать свои алгоритмы так, чтобы процессору не приходилось лазить за данными в сильно разные области памяти.
Инты лучше сортировать с помощью sort_unstable() имхо, обычный sort() выделяет дополнительную память для своей работы, вероятно это замедляло производительность. Впрочем при таких размерах действительно не принципиально какой у тебя алгоритм, хоть вручную все циклы разверни и сравнивай элементы напрямую (может кстати компилятор это и делает). Хотя если ты эту функцию вызываешь очень часто, то можно и оптимизировать. Так же обрати внимание, что данные в неё ты передаешь по значению, это тоже может быть медленно. Эффективнее по ссылке.
Ради интереса посмотрел исходники сортировок в стандартной либе, чисто оценить объём кода. Действительно, смысла в данном случае когда n < 10 применять нет. Миллион разных проверок и рекурсивные вызовы.
Если кого утомляет длительная перелинковка после правки пары строчек, то 1. ставим mold 2. создаём в корне проекта .cargo/config.toml с примерно пикрил содержимым и радуемся ускорению x10
>>2923611 (OP) Делаю GUI. Вызывается обработчик MouseDown на кнопке, который вызывает callback приложения, который может эту кнопку вообще удалить. То есть в крестах у меня MouseUp уже будет работать на области памяти, которая недавно была объектом, на котором уже отработал деструктор, а может быть и free. Мне эти ваши владения как-то помогут отследить такую ситуацию и понять, что вообще происходит?
>>2934658 Статически вряд ли, но в каком-то месте у тебя возникнет что-то типа RefCell, которую надо залочить. Если один коллбэк стриггерится из другого, то возникнет паника
>>2935274 А ты по другим тредам тоже носишься с этим обскурным говном? Не то чтобы мне было дело до этого, просто я не понимаю какое отношение раст имеет ко всем этим поделкам? Надоело, что тут постоянно обсуждают какие-то зиги, валы и лобстеры. Почему бы не завести свой отдельный тред для них, если они такие классные?
>>2935670 > Надоело, что тут постоянно обсуждают какие-то зиги, валы и лобстеры. Потому что мы на них реагируем, вот ты сейчас среагировал, они получили дозу дофамина и теперь будут срать ещё 300 постов.
>>2935782 >Хоть бы на один вопрос ответил. >>2935670 >просто я не понимаю какое отношение раст имеет ко всем этим поделкам? >носишься с этим обскурным говном
>>2938723 У тебя 2 ошибки в посте: Во-первых, пидорасы не няшные. Это они себя такими изображают в качестве коупа, прям как жирухи феминистки. Няшных пидоров можно по пальцем пересчитать, да и они по своей сути ЧСВ хуесосы, которые не могут в любовь и которые озабочены только похотью и лукизмом. Многим ошибочно кажется, что с пидором отношения построить легче, но нихуя подобного - красивые пидоры ебут больше мозгов, чем самая стервозная тян, а страшные пидоры по факту не няшные, так как выглядят как мужики. Во-вторых, трапы полностью наследуют класс Пидоры, но добавляют свою шизу, отчего становятся более тяжелыми пациентами. Дальше переходим к вопросу >откуда взялся стереотип Существует такой класс людей, которые по жизни бездарности и ничтожества, но вместо принятия своей природы и работы на слабостями они начинают бежать от трудностей и создают группы нетакусиков. Чем больше очков нетакусика ты соберешь, тем больше можно обвинять других в тупости и всех смертных грехах. Именно поэтому можно встретить комбо из транса + эзотерический ЯП + музыка от исполнителя с 2 подписчиками на Bandcamp + ноунейм "глуболкое" анимеи и т.д. Так как по своей сути эти люди бездарности, то ничего нового создать они не в состоянии, поэтому приходится внедрятся в сообщества здоровых людей и паразитировать на них. Так же эти парни очень падки на хайп и моду, так как по своей сути являются адскими вниманеблядями, ведь нельзя же жить спокойно, нужно постоянно завялять о себе. Ты можешь сам открыть профили нетакусиков и проследить путь развития этих людей, там сто процентов будет руби, хаскель и прочая хуйня, которая была на хайпе у нитакусиков в свое время и очередным геймченджером в мире ИТ, раст не последний. И как и любой другой проект, раст создавался здоровой, умной и цисгендерной хуемразью из-за чего и привнес что-то новое в эту индустрию. А учитывая, что разработка раста полностью подвластна корпорации Мозилла, которая в свою очередь подчиняется американской шизе и социальному проекту по расколу общества для облегчения управления этим обществом и сокрытию настощих причин экономических проблем с расслоением, то раст просто не мог не оказаться райским местом для нетакусиков. Именно внешние ярлыки(транс никогда не промолчит, он обязательно укажет у себя в профиле все нужные ему баззворды, ведь если никто не будет знать, что он транс, то в чем смысол его копротивлений) и причастность к чему-то "прогрессивному" заглужают их боль от собственной ущербности. Вот ты нацепил значок, насобирал самой ебанутой хуйни, вступил в сообщество к таким же, присосался к нормальным людям и все, ты больше не какой-то там биомусор, а прогрессивная личность с оригинальным видением мира, которого быдло очевидно не понимает и хейтит просто так, без причины. И именно ты двигаешь мировой технический прогресс своим хеллоуворлдом на очередном модном язычке, именно ты улучшаешь сообщество на небинарных сходках, прожирая гранты выделенные твоему проекту.
>>2938734 >Существует такой класс людей >«Да, я пидарас. Так уж вышло — что теперь делать… Но может быть, я гениальный пидарас! Буду писать программы на эзотерическом языке, люди будут думать, что я - гениальный программист! Разве посмеют плохо говорить о гениальном программисте…»
Хочу написать программу которая будет искать, или изменять тег Description в метадате картинок. Хочу сами операции сделать через exiftool, и process::Command, но я хочу все это показывать в гуи. Как мне это собрать? Или в какую сторону копать, подскажите
Любители пожаловаться на избыточность функций стандартной библиотеки Rust посмотрят это видео, но все равно не поймут https://www.youtube.com/watch?v=TBGu3NNpF1Q Такова их судьба
>>2944434 > но все равно не поймут А чо там понимать? на 8 минуте показывается главное отличие си от раста. Си даёт скомпилировать (выстрелить себе в ногу), раст в аналогичной ситуации просто не скомпилирует.
Есть множество случайных событий, для каждого события есть вероятность, что оно произодет (f64).
Задача: написать функцию, которая бы случайным образом возвращало одно событие, с учетом прописанных вероятностей.
Т.е. если бесконечно количество раз ее вызывать и считать события которые она возвращает, то в итоге мы должны получить примерно те же самые вероятности.
На пике то, что пока получилось высрать. Интересует именно foo, т.е. на вход коллекция (вектор, массив, хэшмап и т.д.), а на выходе одно событие. Пик рабочий, но уверен, что можно написать короче.
>>2944720 > можно написать короче Просто генери рандомное число, от 0 до 1 И сразу по массиву проходись и проверяй попал ли ты в него, или нет Нет особого смысла для этого отдельный массив рэйнджей делать
>>2944720 >>2945081 Всё в стандартной библиотеке есть. Переписал твой код из первого варианта. Вместо того чтобы на каждый вызов foo() суммировать элементы — сделай это один раз в самом начале. Вместо линейного поиска используй бинарный. Не забывай сравнивать числа с плавающей точкой в окрестности, хотя может раст это сам делает, не знаю точно.
>>2945429 И у нас есть победитель! Приз, как обычно, нихуя, но от всего сердца.
Для таких же даунов как и я поясню, что f64::EPSILON - это машинный ноль, т.е. в замыкании мы проверяем, что число отрицательное и, как только оно становится положительным, возвращаем индекс.
>>2945534 > EPSILON - это машинный ноль Вообще-то не совсем. Эпсилон это предел погрешности. Флоаты нельзя просто так сравнивать с нулём, из-за погрешности. Эпсилон из матана спешит на помощь и решает эту проблему.
>>2945534 Гляди какой прикол. Трансформация массива вероятностей представляет из себя кумулятивную (накопительную) сумму всех элементов. Очевидно это достаточно долгая операция O(n), потому что необходимо пробежать все элементы массива без исключения. Если ты foo() будешь много раз вызывать с одними и теми же данными, то эти вычисления будут выполняться каждый раз. Они являются подготовительными и их можно сделать один раз, например сразу после объявления массива вероятностей в удобном тебе виде. И в функцию foo() передавать уже суммы. Сам выбор события при этом будет занимать гораздо меньше времени O(log n).
Конечно если у тебя foo() часто вызывается с разными вероятностями, а самих вероятностей не очень много, то это необязательно. Смотри сам короче, зависит от твоих потребностей, просто мне глаз режет.
И ещё один момент по стилю — растаны рекомендуют функции, принимающие массивы оформлять с помощью указателя на слайс:
fn foo(input: &[f64])
Тогда ты сможешь вызывать её и с вектором и со слайсом и с массивом.
>>2945623 Ошибки нету, не вводи в заблуждение. Абсолютное значение сравнивается когда нужно проверять на равенство нулю. В этом алгоритме надо проверить, что p < random.
>>2945623 если написть f64::abs(p - random) < f64::EPSILON, то оно всегда true, т.е. перестает работать а вот p.abs() - random.abs() < f64::EPSILON работает как надо
>>2945640 Спасибо, там до десяти элементов в векторе и поэтому можно не заморачиваться. И вызывается функция не настолько часто, да и не в цикле. Учет вероятностей больше нужен для успокоения души, типа предусмотрел этот момент. На самом деле там вообщее [(енум, вероятность), (енум, вероятность), (енум, вероятность)...], но не суть.
>>2951631 Ковырял и VSCode, и nvim, и helix, и RustRover (+ ideavim). Все хуйня, оставил просто RustRover. В VSCode, например, не нашел, куда запихнуть "--color=always", чтобы работала подсветка синтаксиса в cargo. Прописывание в launch.json (configurations - cargo - args) не помогло. >>2951656 У RustRover'а ранний доступ, поэтому пока бесплатно. >>2951716 На моих скринах шрифт не дефолтный, поэтому по ним не судите. Памяти у меня 64GB, поэтому похуй. В утечках памяти IDE замечена не была.
>>2951833 >RustRover Кстати, сыроват. На мой вкус, лучше всего идейка с растом работала где-то с полгода-год назад. Потом как начали, видимо, переписывать плагин, так то одно отвалится, то другое.
>>2951833 > не нашел, куда запихнуть "--color=always", чтобы работала подсветка синтаксиса в cargo Штоблять? Установи любой аддон для формата TOML. Какой "--color=always"? Что за бредок?
>>2953130 предполагалось, что я не буду руками вбивать "cargo run", а нажму F5 (или что-нибудь другое) и оно дальше само >Ты просто ламер. >русский интерфейс интересный манямир
Что приуныли, растаны? Ну-ка, подскажите как избавиться от уродливого &* при обходе дерева? Можно наверное каждое поддерево обрабатывать отдельно в своём if и результат наращивать последовательно, но хочется использовать match для наглядности.
>>2956574 слишком громкий заголовок для подобного скрина - может это какой-нибудь линейный инженер-программист ради интереса решил переписать/дописать пару строчек кода
>>2962586 Боюсь вот прям такого нет. Но ты опять же с помощью partition_point можешь получить индекс массива, значения левее которого меньше проверяемого числа. Пусть это будет индекс i. Потом посчитать абсолютную разницу между проверяемым числом и числами в массиве по индексам i и i - 1. Остаётся выбрать минимальную, она будет соответствовать искомому элементу. По сути два вычитания и одна проверка, константное время. Лень писать пример. Не забудь аккуратно обработать случаи, когда partition_point возвращает 0 или длину вектора.
Сап, программач. Кто-нибудь может пояснить за зависимости в крейтах.
Добавил зависимость axum (веб фреймоврк), он использует токио под капотом, я вижу токио в зависимостях после сборке, но не могу получить доступ к его функциям. Почему так? В мануалах отдельно добавляют зав-сть токио.
Чтобы не запихивать Enum в Option и потом не писать if foo.is_some_and(| x | x == FooBar::Foo) и прочую хуйню, делаю как на пике. Eсть ли в std derive, которой бы сам выводил подобный impl?
>>2970488 Реши актуальную для себя задачку. Мне вот например, недавно понадобилось поинлайнить скрипты, стили и картинки в 300МБ html отчёт. Нашлось какое-то говнорешение на ноде, которое не работало, pandoc, который лениво сожрал всё мои 48ГБ оперативы и до конца не отработал. Написал сам на расте c регулярками - 120 строк кода, работает хорошо, быстро, задачу выполняет теперь схороняю им двачетреды, т.к. мозилла пихает всё по папочкам
>>2971165 Тебе в любой книжке про успешный успех скажут, что сперва цель "Заработать ярд баксов", а уже потом "Как мне этого достичь?" разматываешь по этапам. А не как ты: "Пацаны, купил в сельпо титановые вилы, охуенная вещь - как теперь с их помощью заработать ярд баксов?"
>>2971351 Если тебя мотивирует сам процесс зарабатывания бабла, то я тебе даже завидую. Ты - Кабанус Вульгарис, на таких, как ты, земля держится. Открой лавку или парикмахерскую. Советую выбрать биз с большим порогом вхождения, чтобы конкуренции поменьше. Один мой кореш так подкопил бабла, а когда женился, вложился в биз по лазерный эпиляции девиц , чтоб жена не скучала. Внезапно, попёрло, филиалов панаоткрывал. Я бы так не смог, скорее бы с тоски подох.
>>2971425 Вовсе нет. Бабло мне нужно как средство достижения более высоких целей, перспектива свершения которых сейчас меркнет потому что приходится по 40 часов своего времени убивать на этого самого кабануса и шлюх и наёбышей.
>>2971466 Видишь ли, 30 лет назад не у всех был компухтер, поэтому взять и написать хуету, чтобы продать её потом за сотни лямов, мог каждый второй шиз, у которого он был. Сейчас времена не те. Поэтому иди от бизнес-идии: что ты собираешься дать людям полезного? А уже в процессе реализации делай упор на раст в айти составляющей проекта, если видишь в этом конкурентный потанцевал.
>>2971165 Даже не знаю, с помощью кодинга, кроме как типикал работы, нечего предложить. Если у тебя есть биз-хватка, тогда ты можешь сделать деньги более простым способом. А если у тебя такого нет...
Ну если так пофантазировать, сначала тебе нужно как-то охуенно контрибьютить в Ржавчину, прямо в ядренные вещи, чтобы шишка у всех на тебя стояла, привлекаешь шизов-энтузиастов, открываешь компанию. А потом пробуешь выбить какой-нить грант от мелкософта. Повторюсь, если у тебя нет бизнес яиц, любая идея в любой сфере обречена на провал, в тч и эта. Помимо гениального кододрочерства, нужен охуительный продаван. В общем, всю эту базу чел выше выдал, чего тут...
>>2971165 >Единственная актуальная для меня задача - заработать лярд баксов. Как мне этого достичь с помощью раста? Сделай финансового бота, который будет удваивать деньги каждый год. 1 год - $10,000 2 год - $20,000 3 год - $40,000 4 год - $80,000 5 год - $160,000 6 год - $320,000 7 год - $640,000 8 год - $1,280,000 9 год - $2,560,000 10 год - $5,120,000 11 год - $10,240,000 12 год - $20,480,000 13 год - $40,960,000 14 год - $81,920,000 15 год - $163,840,000 16 год - $327,680,000 17 год - $655,360,000 18 год - $1,310,720,000
Как видишь всё реально. Давай приступай удваивать. К 2041-му году ты должен управиться. Удачи.
>>2971165 >Единственная актуальная для меня задача - заработать лярд баксов. Как мне этого достичь с помощью раста? очевидно, что надо продавать курсы по расту
>>2971722 >Сделай финансового бота, который будет удваивать деньги каждый год. Зачем так сложно если можно просто зайти в админку бд банка и сделать SET balance = 10e12?
>>2973060 Есть мнение (не мое), что rust как первый язык - это самое оно, т.к. все ограничения rust'а воспринимаются как само собой разумеющееся, без мыслей типа "что за хуйня? в C/C++ всю жизнь такая конструкция работала без проблем..." и соответствующего желания дропнуть этот язык.
>>2970819 Твоё решение хуйня, если оно не евалит жс после загрузки страницы, поскольку страницы могут тащить за собой дохуя ленивых бандлов, шрифтов и стилей. Поэтому, наиболее годный вариант с тз совместимости - ранать что-то наподобие Паппеттира и использовать MHT как сингл-файл архив для страницы со всем её содержимым. У холма есть соответствующее АПИ: https://vanilla.aslushnikov.com/?Page.captureSnapshot
>>2982206 В текущих реалиях 🎁 - язык нишевый. Корпы, если и смотрят в его сторону, то в качестве эксперимента, и берут под это дело не анона с двача, который "прочитал все материалы из шапки", а персонажей уровня Кладова (автор 🎁-analyzer, есть его лекции на ютубе).
Поэтому если конечная цель - трудоустройство, то я бы учил ту же 🍊.
>>2982865 >персонажей уровня Кладова пока вакансий мало, берут самых крутых, это ессно. Когда распробуют, будут выгребать всех, даже бывших продавцов и шиномонтажников, как в жс/похапе.
>>2982996 >Когда распробуют, будут выгребать всех, даже бывших продавцов и шиномонтажников, как в жс/похапе. Ну так когда это будет и будет ли?) 🍾 так-то существует с 1991 года и только пару лет назад о нем начали вещать из каждого утюга. Помню времена, когда 🎁 (с Rails) был на хайпе и где он сейчас?
🎁 - нишевый язык и я бы исходил из того, что скорее всего он таким и останется.
>>2983148 🐍 из каждого утюга полез тогда, когда индустрия начала пылесосить всех подряд. Так-то он и до этого был востребован в том же вебе - с джангой, зопой и прочими фреймворками. Ну и как дефолтный язык, когда баша уже мало, а сишечки с джавой ещё много, он чуть ли не с тех же 90-х и использовался. 🎁 - сразу ясно было, что ещё один чуть более сахарный, но и чуть более тормозной 🐍, не нужен.
Раст - нишевый, да. Метит в нехилую такую нишу C/❄️, причём в нишу сразу обоих. И, в отличие от 🎁, решает проблемы тех, на чью замену метит.
Лучше бы вместо снежинок и автозамены добавили на доску подсветку синтаксиса, или, на худой конец, блок, где разметка не съедала бы форматирование кода.
что он делает? должно быть просто 6a 07, и 68 72 7c или 66 68 72 7c 00 00, ещё и адрес 0x7c3e неверный. таргет файл и линковочный скрипт из крейта загрузчика, под раст осдев
С новым годом, анончег. Назрел довольно странный вопрос. Кто-нибудь работал с Голубой Огонёк? Даже если нет, можете высказать свое имхо. Предположим у нас есть два воспроизводимых Голубой Огонёк: 1) в браузере 2) в десктоп плеере Вопрос такой в вакууме, есть ли разница в перфомансе и чем её можно измерить.
Есть хитровыебаный парсинг хитровыебаного сайтика с помощью крейта headless_chrome. Хитровыебанность парсинга заключается в том, что там имеет место быть рекурсивная функция (обходим древовидные менюшки).
Мы создаем структуру браузер, от браузера структуру вкладка, а вклюдку передаем в функцию. И все заебись работает, но браузер по непонятным мне причинам падает.
Соответственно, когда мы создаем новые браузер и вкладку, старый Tab, который прописан в вышестоящий рекурсии, становится недоступным, т.к. адрес нового таба уже другой.
С дуру пытался запихать этот Tab в once_cell, но rust меня послал нухуй, т.к. Tab не имплементит Debug.
>>2985239 А с аудио не работал? Вот житейский пример, ты скорее предпочтешь скайчку Новый Годез фильма на хард или будешь на лордфильме довольствоваться очень ужатым 1080р....
Хотелось бы узнать как работает браузер внутри... Я чуть пытал Полярная Почта на предмет того, насколько риалтайм аудио обработка реализована, можно ли к примеру ОС функции дёргать в браузерах, но как понял что это песочница, значит есть какой-то оверхед так или иначе. Но могу ошибаться.
>>2985261 Под каждую вкладку процесс выделяется. Вообще хром конечно охуел знатно, переоцененное говно как по мне!
>>2985317 Песочница, да. Вся эта херня работает посредством различных апишек реализованных в браузере. За подробностями тебе на mdn. Но в целом то там обычные С/❄️ код для дёргания сисколов, так что если у тебя обычные audio/video теги с прописанным сорсом без всякого жс говна работающего с ними особого оверхеда нет.
>>2985157 Сейчас основная разница в используемых кодеках и используемы фиьтрах. У себя локально ты можешь настроить плеер как тебе хочется - подобрать более производительный Дети в костюмах снежинок для аппаратного ускорения или интерполяцию до 60 фпс включить, например.
Когда уже бинарники станут весить нормально? Протестил сейчас хэллоуворлд - 125 кб, сборка стд из исходников во время компиляции и тримминг не уменьшают размер. В это же время у зига хэллоуворлд 4.5 кб, а упх жмёт его до 2.5 кб, лол. Такими темпами сишарп догонит скоро, там после упх собраный на АОТ бинарник весит 350 кб. Как мне малварь сисадминский софт обновлять через ICMP не привлекая внимания санитаров безопасников с такими размерами в сотни кб?
>>2990341 Раз уж ты выбрал путь страданий, гугли "rust winapi no_std no_main" Количество доступных тебе крейтов сильно поубавится, сборка чуть усложнится, но таков путь
>>2990404 > 1536 байт Ну меньше на целый кб чем зиг с стд. Но как этим говном пользоваться без стд? Даже хуже сишки экспириенс. На зиге страдать не надо чтоб иметь мелкий файл.
>>2989507 > Трейтами Шаблоны всё равно мощнее инструмент. Интерфейсами ещё в джаваговне нажрались, от того что их назвали по другому лучше они не стали. > отслеживанием лайфтаймов и более жёстким borrow checker-ом Не понятно одно - почему ебаться должен кодер, а не компиляторостроители. Санитайзеры в крестах с этим справляются без проблем, но там хоть не заставляют ублажать компилятор, когда хочешь ссылочки на объекты попередавать. >>2990434 > Отсутствием многолетнего легаси. Это конечно вопрос философский что хуже - легаси или сырой полудописанный код, но я бы всё же предпочёл не иметь ничего из этого в модном и молодёжном ЯП, учетшем ошибки предков.
>>2990493 > эффективность Как-то он неэффективно расходует место на моем диске. Я сейчас ещё могу вспомнить про 5-гиговые папки deps, которые он оставляет после сборки.Или могу вспомнить про то что в расте нет ленивой загрузки внешних библиотек в рантайме, как у майков на MSVC, что влияет на скорость запуска, если уж зашла речь про эффективность и бинарник. Мне больше не понятно в чём проблема триммить стд, нахуй он тащит его весь с собой. Зиг же может выкинуть всё что не надо из бинаря. Кресты на LLVM тоже без проблем избавляются от мусора, у которых так-то рантайм жирный килобайт на 5 аж, я не верю что у раста чего-то полезного и жизненно необходимого есть на 120 кб, это же не ГОвно, которое сборщик мусора и ещё гору всего таскает с собой.
>>2990515 >Интерфейсами ещё в джаваговне нажрались, от того что их назвали по другому лучше они не стали. Трейты это не интерфейсы. >Шаблоны всё равно мощнее инструмент. Шаблоны вообще перпендикулярны и трейтам и интерфейсам. >Санитайзеры в крестах с этим справляются без проблем Они в рантайме работают, это проблема по определению. Например, их не на любой платформе можно включить.
>>2990552 > Трейты это не интерфейсы. Ты видимо совсем глупый, семантически это абсолютно идентичный функционал. > Шаблоны вообще перпендикулярны и трейтам и интерфейсам. Ясен хуй, они кодогенерацией занимаются, а не просто выполняют функцию полиморфизма. > Они в рантайме работают Они в дебаге работают. В релиз их никто не тащит. > это проблема по определению Проблема - это когда компилятор/рантайм не может сам справиться с проверкой памяти на дыры. Не вижу проблем когда он всё же может сделать это не накладывая никаких ограничений на кодера.
>>2990515 >Не понятно одно - почему ебаться должен кодер Ебля только пока не щелкнёт. Или пока не столкнешься с кейсами, когда случается ложное срабатывание. Это еще и средство, чтобы задать контракт для API.
>>2990555 >семантически это абсолютно идентичный функционал Нет, семантически они разные. Говоря простым языком, трейты это свойства типов, а интерфейсы это описание общего поведения, организованное в иерархию. Например, ты можешь хранить свою коллекцию изображений аниме-шлюх в иерархии папок, это классический ООП подход. А можешь каждой картинке проставить несколько тегов, это трейты. Хз, как ещё проще объяснить.
Разница в реализации тоже значительная, трейты это обычное раннее связывание, в то время как интерфейсы это позднее связывание.
Трейты дают больше возможностей. Например, можно добавить новый метод для чужого класса или даже примитива языка. Вообще, там много всяких интересностей, я не так хорошо растом владею чтобы их тут перечислять, лучше почитай растбук, если интересно.
>они кодогенерацией занимаются, а не просто выполняют функцию полиморфизма. Иногда это называют статическим полиморфизмом...
>Они в дебаге работают. В релиз их никто не тащит. Т.е. если в дебаге вручную проблему не отловят, то она попадает в релиз. В то же время эти же проблемы в расте исключены на этапе компиляции.
>Не вижу проблем когда он всё же может сделать это не накладывая никаких ограничений на кодера. Не может. Вернее может, но тогда ты вообще заебёшься что-то сложнее сложения двух чисел писать. Уже писал в этих тредах про проблему останова >>2823357
>>2990571 > семантически они разные Это классический полиморфизм, от твоих фантазий он не перестанет быть таким. > А можешь каждой картинке проставить несколько тегов Чел, с каких пор класс в джаве перестал иметь возможность реализовывать сколько угодно интерфейсов? > можно добавить новый метод для чужого класса Если сильно хочется, то jvm тебе позволит хоть очко на глобус натянуть, Manifold даст тебе возможность чужие классы изменить просто подставляя аннотацию @Extension.
>>2990601 > классический полиморфизм Классический полиморфизм предполагает виртуальную таблицу, тут её нет. Олсо, какие вообще проблемы с интерфейсами, их раньше называли множественным наследованием здорового человека. Когда их зумеры успели засрать?
>>2990623 Что-то ты уже совсем бредишь, это всё полиморфизм подтипов, детали реализации не равно семантика. И в джаве тоже нет виртуальной таблицы так-то, в жвм уже давно избавились от такого. > наследованием > здорового человека Здоровый человек использует дженерики для полиморфизма. В крестах концепты есть - это самое близкое к определению "интерфейсы здорового человека", хоть они и могут показаться как руны древних шизов для свежих крестов это норма. > Когда В момент создания, когда гении легасистроения придумали как использовать легаси не снимая штанов которые очевидно уже обосраны, заодно запретив трогать это самое легаси, выпадающее из штанин.
>>2990601 >от твоих фантазий он не перестанет быть таким. Прекрасно тебя понимаю, поначалу я тоже очень скептически относился к таким заявлениям. Если тебе действительно интересно, всё-таки рекомендую ознакомиться с растбуком. Мне Весело на утреннике в одном посте выразить то, что разжёвывается в целой книге. Свою лучшую попытку я уже сделал. Может есть более сжатые источники, я таких не знаю, а гуглить за тебя не собираюсь. >с каких пор класс в джаве перестал иметь возможность реализовывать сколько угодно интерфейсов? Ну вот ты просто не знаешь раста, поэтому пишешь такое. Приведи пример, как в джаве сделать подобное (пример из растбука собственно): pub fn notify(item: &(impl Summary + Display)) {} Если ты не понимаешь, что тут написано, то это шаблонная функция, которая принимает в качестве аргумента ссылку на любое значение, для которого реализованы типажи Summary и Display. inb4: сделать интерфейс, который наследуется от двух других интерфейсов. >Если сильно хочется, то jvm тебе позволит хоть очко на глобус натянуть, Manifold даст тебе возможность чужие классы изменить просто подставляя аннотацию @Extension. Не очень понимаю, о чём речь, ты как-то с классов на джаву соскочил, будто это синонимы и все её знают. Я вот её почти не использовал. Но догадываюсь, что речь о каких-то хаках уровня поправить в рантайме указатель на vtable для объекта в C++. Конечно здорово, что это можно сделать. Но в расте это базовая возможность, которая описана в официальном руководстве для начинающих. А твой пример это похоже на хак, основанный на понимании внутреннего устройства конкретной реализации. Feel the difference, как говорится.
>>2990608 Ну можешь поковырять, как оно там у тебя линкуется. ldd есть на винде? В принципе, ты только что наглядно продемонстрировал, почему по умолчанию линковка растовых бинарников статическая. В противном случае, критики завалили бы разрабов сообщениями подобными твоему.
>>2990659 > как в джаве сделать подобное Легко: public <T extends Summary & Display> void notify(T item) {} > которая описана в официальном руководстве Тебе бы самому не помешало почитать документацию, потому что методы расширения работают только для типов из твоего крейта и std, т.к. он в твоём крейте. Для типов из других - даже хаков нет. Хуй знает чего ты так доебался до этого, это просто синтаксический сахар, передающий произвольный объект методу в виде self.
>>2990671 >public <T extends Summary & Display> void notify(T item) {} Прикольно, не помню чтобы было такое, когда я ковырял джаву. Проверка, на ограничения Т будут применены в рантайме или при компиляции? >Тебе бы самому не помешало почитать документацию, потому что методы расширения работают только для типов из твоего крейта и std, т.к. он в твоём крейте. Да, я читал, в расте есть так называемое orphan rule. Нельзя имплементировать чужие трейты для чужих типов. Это сделанно намеренно, чтобы не сломать функциональность чужого крейта. Все остальные сочетания (свой-свой, чужой-свой, свой-чужой) работают. Последний параграф https://doc.rust-lang.org/book/ch10-02-traits.html#implementing-a-trait-on-a-type >доебался до этого До чего этого? >это просто синтаксический сахар, передающий произвольный объект методу в виде self. Что?
>>2990659 >с каких пор класс в джаве перестал иметь возможность реализовывать сколько угодно интерфейсов? Класс в джаве реализует ровно те интерфейсы которые указаны в спеке класса. Добавление нового интерфейса возможно только расширением или изменением класса. >>2990679 >Прикольно, не помню чтобы было такое В районе 9 джавы дотюнили систему типов.
>>2992127 Ну хаскеллисты-то всё о хуях знают. Как не спросишь хаскеллиста, о чём он думает, так всё время отвечает, что о хуях размышляет, и как их каррировать приятно.
>>2992169 В Rust'е много синтаксического "мусора", потому что там более сложная семантика. Всё-таки нужно близко к железу держаться, а не опираться на GC.
Разберём, откуда что берётся. - Rust с энергичной стратегией вычисления, а не с ленивой, и коллекции гораздо более непрозрачные для компилятора, чем ADT для компилера Хаскеля. Rust не может просто опираться на `Foldable` и на то, что оптимизатор может доказать, что промежуточные списки строить не надо. Отсюда и берётся lazy external iteration. Следовательно, появляется `.iter()` и `.collect()`. - В Rust'е функции – не first-class objects, потому что это бы создавало слишком много виртуальных вызовов. Поэтому, как и в плюсах, всякие лямбды и даже обычные функции имеют анонимные типы. Из-за этого приходится возиться с `Fn`-трейтами. Наличие сечения операторов и частичного применения сделало бы эти ограничения слишком неявными. Поэтому пишем `|x| x + 2`.
Короче, в рамках поставленных задач, Rust, на мой взгляд, получился очень хорошим. Тут хотя бы не надо своё очко трансформерами монад, свободными монадами, tagless encoding и прочей хуетой дрочить
>>2992574 > Всё-таки нужно близко к железу держаться, а не опираться на GC. Есть Perceus. Взгляни как синтаксически чисто выглядит koka-lang, хотя в нём тоже нет GC и рантайма. Ручной работы с памятью там тоже нет.
> Rust с энергичной стратегией вычисления, а не с ленивой У схемы тоже не ленивые вычисления, что не мешает использовать функторы по-человечески.
> и коллекции гораздо более непрозрачные для компилятора, чем ADT для компилера Хаскеля Что значит «прозрачность»? Связанные списки - они в Африке связанные списки.
Не вижу проблемы сделать прямое отображение map :: (a -> b) -> List a -> List b.
Заодно нам вообще не нужно указывать где либо типы, их можно спокойно вывести согласно сигнатуре.
> В Rust'е функции – не first-class objects Обычно после это предложения на какое-либо использование в Real World язык уже не претендует.
>>2992033 Потому что функциональщину пришили костылями, а синтаксис для неё не завезли. Даже в шарпе LINQ придумали, потому что понимали насколько всрато монады будут смотреться через точку, а в расте на похуе сделали лапшу. В итоге имеем на каждой строчке новый уровень вложения и миллион скобочек трёх видов. То что монады не отформатировать без лесенок - всем похуй, жрите как есть, а если через пол года разработки код превращается в нечитаемое месиво - переписывайте заново. Причём видимо у кого-то всё же были приступы озарения какое дерьмо они делают и кто-то пытался бороться с этим, но ничего дальше заглушек типа unwrap не ушло. >>2992574 > Из-за этого приходится возиться с `Fn`-трейтами С чем ты там возиться собрался, когда дедукция типов уже хуй знает сколько редакций крестов есть, ничего кроме auto тебе не понадобится. Это в расте тебе аж дженерик параметр надо делать, чтоб лямбду передать, вот что это за нахуй: > fn pizdec<F>(f: F) where F: Fn(i32) { f(123); } В то время как в крестах оно выглядит вот так: > auto zaebis(auto f) { f(123); }
>>2993087 Да, с "auto f" он примет что угодно и IDE будет похуй, только на этапе компиляции он скажет что не может сделать f(123) с аргументом. > чтобы понять тип переменной, нужно лезть в код Есть же концепты. Достаточно написать "invocable<int> auto f" и туда можно будет передать только то что можно вызвать с аргументом int. Алсо, в крестах настоящий duck-typing, т.е. ты туда можешь передать вообще что угодно, что подпадает под условия концепта, а не только то что реализует трейт. Т.е. в случае с invocable там может быть хоть указатель на функцию, а не обязательно лямбда. Пикрилейтед, раст так может?
>>2993102 >Алсо, в крестах настоящий duck-typing Это не всегда хорошо. Путь к костылям. Но если бы плюсы пытались во что-то строгое, то было бы еще хуже, поэтому пусть будет.
>Пикрилейтед, раст так может? Указатель вроде нет, просто функцию по имени да.
Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'lldb.embedded_interpreter' /usr/lib/local/lib/python3.10/dist-packages
Когда питухон пакаджи там лежали? Что за блядство Пробую раст ваш, какое-то нахуй все сырое...
>>2993102 >Есть же концепты. Достаточно написать "invocable<int> auto f" и туда можно будет передать только то что можно вызвать с аргументом int. А в чём отличие от трейта Fn(i32)?
>>2993102 >Т.е. в случае с invocable там может быть хоть указатель на функцию, а не обязательно лямбда. Пикрилейтед, раст так может? В расте указатель на функцию это так называемый fn тип. Он реализует все три трейта замыканий (Fn, FnOnce, FnMut). Поэтому да, в расте достаточно объявить функцию ожидающую замыкание и передавать туда указатель на функцию. https://doc.rust-lang.org/book/ch19-05-advanced-functions-and-closures.html
По поводу автоматического выведения сигнатур функций, в растбуке кстати сказано так: >In function signatures, you must declare the type of each parameter. This is a deliberate decision in Rust’s design: requiring type annotations in function definitions means the compiler almost never needs you to use them elsewhere in the code to figure out what type you mean. The compiler is also able to give more helpful error messages if it knows what types the function expects. Честно говоря, я не силён в современном C++ и хаскелле, не знаю как они справляются с обозначенными проблемами.
>>2994263 >>2994267 В крестах в концепте просто пишешь как есть - тип должен вызываться с таким-то параметром. Компилятор/IDE проверяет возможно ли сделать такое с этим типом - если да, то пропускает его. > template<typename T> > concept zalupa = requires(T t) { > t(123); > }; Можно чекнуть возвращаемый тип, или то что с аргументом можно какие-то операции делать, типы объектов или его полей проверить, чекнуть есть ли нужные поля или методы у объекта { arg.hui };. Короче любое выражение можно написать и если оно валидно для этого типа - он пропускается. Причем при самом использовании этого концепта не надо использовать дженерики и прочее, просто перед auto добавить концепт и например работать с любым типом, умеющим в арифметические операции - в IDE будет всё чекаться и подсвечиваться, а тебе похуй там float, int или вообще объект из какой-то либы. Можно вообще как на питоне сидеть, обмазавшись auto и концептами для ограничений типов. template<typename T, typename Arg> concept zalupa = requires(T t, Arg arg) { > { t(arg) } -> same_as<void>; > { arg + 1 }; > };
>>2994480 А потом ты пишешь t.sosat(hui) и идёшь на этот самый хуй, так как классов, имплементящих этот sosat может быть несколько и означать этот sosat может разное - а по году твой дженерик функции поди догадайся, что именно. Вот и получается, что C++ для хэллоуворлдов с одним - двумя разрабами, которые в курсе, как именно sosat, а раст для серьёзных проектов, где куча разрабов и всё должно быть строго - вот корпорации к нему и присматриваются.
>>2994480 Всё ещё не понимаю в чём разница. Ты привёл пример: >просто перед auto добавить концепт и например работать с любым типом, умеющим в арифметические операции Как я понимаю, для этого нужно написать 5 строк самого концепта, а потом добавить многословное описание аргумента в сигнатуру функции. На расте это как-то проще и лаконичнее выглядит.
>Причем при самом использовании этого концепта не надо использовать дженерики и прочее Это либо дженерик с другим синтаксисом, либо это полиморфизм в рантайме, другого не дано. И судя по ключевому слову template в описании концепта, это не последнее. В расте тоже есть синтаксический сахар для Fn трейтов, можно просто писать f: impl Fn(usize, i32) -> bool. Конечно, когда ты хочешь наложить ограничения на аргументы передаваемой функции уже приходится полноценное синтаксис обощений использовать, благо он довольно выразительный и легко и интуитивно читается.
О чём спор вообще, исторически концепты по-моему это спизженные из раста трейты. Поправьте если ошибаюсь.
>>2994563 > А потом ты пишешь Как говорится, с дури можно и хуй поломать. При написании кода должен быть хотя бы минимальный здравый смысл. А вообще сишка и кресты weakly typed, а тот же питон внезапно strongly typed. Это никогда не мешало писать код ложа хуй на типы и ничего не ломалось. А вот в расте меня сильно бесило, когда в обёртке winapi один тип, а либа возвращает другой, хотя я точно знаю что это блять просто uint64 на самом деле какой-нибудь HANDLE, но раст позволяет их взаимозаменить только в ансейфе, "безопасно" они не кастуются. Т.е. я имею две "безопасные" обёртки, но должен использовать ансейв чтоб передать один объект в метод другого, это уже граничит с шизой. И такое на самом деле очень часто встречается в расте среди либ для системщины, пока майки сами не сделали единый биндинг к своим APi так и пользовались ансейфом в безопасных обёртках. Хотя оно и сейчас часто есть, например в DirectX и графических либах, где кому-то вдруг захотелось вместо майковских типов написать свои, или Result использовать другой. А ты потом ебись с этим, когда каждая либа свой Result имеет и ты банально Ok не можешь кастануть к Ok, вот уж где меня точно не ебёт что это за Ok. > раст для серьёзных проектов Почему же тогда на расте пишут только опенсорс-пердолики, причём забагованный, зато безопасный, код? Я каждый раз проигрывают с безопасности, которую каждый интерпретирует по своему, хотя речь вообще-то про безопасность от уязвимостей. От логических багов всё это не спасает от слова совсем, а ведь они в первую очередь и важны для юзера. > присматриваются Сколько присмотрелось за 5 лет? Видел только полтора бэкенда для веба у каких-то крупных компаний типа Дискорда. Все остальные как писали системщину на крестах, там и пишут новые проекты на них, за пределами веба раст вообще отсутствует. Ты можешь аргументировать это легаси, но это всё хуйня, за 5 лет можно было бы и написать хорошие либы. Я вот с графикой имел дело в расте и наблюдал одно и то же - делают обёртки на графические API и через год проект сдыхает потому что поддерживать код уже даже авторы не могут и в итоге начинают новый проект, в этот раз говоря что учли все ошибки прошлого нет. В итоге сейчас кроме wgpu который тоже уже вторая итерация переписывания всего кода, лол ничего нормального и нет, на чём можно было бы начинать реальный проект.
> Взгляни как синтаксически чисто выглядит koka-lang, хотя в нём тоже нет GC и рантайма. В Koka подсчёт ссылок. Это всё равно оверхед в рантайме. Достижение атомарного счётчика нуля – гораздо более сложный критерий для проверки в рантайме, чем выход из области видимости. Но гораздо более опасный. Идея borrow checker'а в том, чтобы можно было во время компиляции доказывать, когда использование этого критерия безопасно
> У схемы тоже не ленивые вычисления, что не мешает использовать функторы по-человечески. Ты выдираешь названные мною причины по-отдельности. А я говорю, что они все в совокупности приводят к тому, что в Rust'е нужны ленивые итераторы.
> Что значит «прозрачность»? В хаскеле основная коллекция – список (`[]`), в расте – вектор (`Vec`).
Список выражается естественным образом через ADT и его определение для хаскеля прозрачное и понятное. В хаскеле операции над списками выражаются через два примитива: fold, unfold (ну или эквивалентные им, я не помню). И компилятор умеет оптимизировать их композиции так, чтобы не создавать промежуточных коллекций.
В расте вектор –дрочево указателей на полу-инициализированную память с невыразимыми в системе типов инвариантами. Если написать `(map f . map g)` в расте он не сможет доказать, что это то же самое, что `map (f . g)`.
Даже если мы добавим `Vec` и его комбинаторы в компилятор, чтобы он его мог оптимизировать, это всё равно не решит всех проблем. Потому что эти оптимизации не могут пересекать границу функций. Когда мы возвращаем `map g xs` из функции, мы обязаны это вычислить и построить новый контейнер из-за энергичной стратегии вычисления, даже если это значение после этого сразу будет запихнуто в `map f`. Тут спасёт только инлайнинг, но он не всегда возможен и не всегда помогает.
Поэтому приходится использовать совсем другой подход: ленивые итераторы. Они достигают того же эффекта (отсутствие промежуточных контейнеров), гарантированно работают, не требуют компиляторного шайтанства, но у них менее лаконичный синтаксис.
> Заодно нам вообще не нужно указывать где либо типы, их можно спокойно вывести согласно сигнатуре. Раст тоже умеет выводить типы много где. У него, правда, гораздо более сложная система типов, поэтому, скорее всего, полный вывод типов неразрешим, да и никто даже и не пытается, потому что типы – часть документации. В данном конкретном случае с `.collect()` надо указывать тип контейнера, потому что из итераторов можно построить не только `Vec`, но и многие другие контейнеры. Тут надо смотреть на контекст, в которой появляется эта строчка, потому что часто компилятор справляется вывести тип контейнера.
Последнее замечание, но самое главное. Раст – системный язык программирования, рассчитанный на работу в отсутствие глобального аллокатора и кучи в принципе. Для него, куча – это ресурс, а не расходник.
И тут мы подходим к последнему: > > В Rust'е функции – не first-class objects > Обычно после это предложения на какое-либо использование в Real World язык уже не претендует. У лямбды есть захваченный контекст. Если у любой лямбды с одинаковой сигнатурой должен быть одинаковый тип одинакового размера, то это вынуждает класть лямбду с контекстом на кучу. А это оверхед в обычном мире и невозможность использование в embedded. Не понимаю, чем embeddedне Real World.
> О чём спор вообще, исторически концепты по-моему это спизженные из раста трейты. Поправьте если ошибаюсь.
Трейты в расте и классы типов в хаскеле –более мощная вещь, чем концепты в плюсах. Концепты в плюсах гораздо ближе к интерфейсам в тайпскрипте.
Разница в том, что концепты выражают структурную типизацию: они просто проверяют, что у класса есть все нужные поля и методы. Концепт реализован на типе, если у него все эти структурные вещи есть.
Трейт же надо реализовывать на типе явно. Потому что трейты помимо нужных методов формулируют законы/свойства/инварианты, невыразимые в системе типов. Например, `Eq` требует, чтобы `==` задавал отношение эквивалентности.
Это позволяет иметь, в том числе маркерные трейты – трейты, формулирующие только свойства, которыми должен обладать тип. Например, трейт `Send`, который говорит, что тип можно безопасно передавать через границу потока. Более того, т.к. компилятор это свойство проверить не может, но он при доказательстве безопасности кода на него опирается, этот трейт помечен `unsafe`. Пользователь должен тысячу раз подумать прежде чем реализовывать этот трейт для типа. Если это свойство не выполняется, то он сам еблан, но он хотя бы будет знать куда смотреть.
>>2994630 Назови хоть один язык, который появился (для широких масс) после 2010 года и был бы хоть вполовину также популярен. Говно разве что, но там хорошая такая поддержка от гугла и ниша была посвободнее - вообще не было языка, на котором можно было бы кодить с хлебушком вместо мозга, но чтобы оно ещё и быстро работало. Питон/руби тормозили, жаба сложна.
>Видел только полтора бэкенда для веба у каких-то крупных компаний типа Дискорда Гугл новую системные компоненты андроида пишет почти исключительно на расте, плюс потихоньку переписывает старые. Я не знаю, куда уже ближе присматриваться.
>>2994778 > более мощная вещь Я не вижу где ты нашёл мощность, если одинаковые свойства с разными названиями в расте не считаются одинаковыми. Особенно когда в реальности нет чёткой стандартизации трейтов и ты всегда можешь обнаружить неведомую хуйню, дублирующую дефолтные трейты, но для компилятора они не совместимы. > концепты выражают структурную типизацию Вот не пизди. В концептах можно проверить например константная переменная или нет, или проверить какой тип получится после передачи объекта как аргумент функции например int& станет int, так же как и const int&& будет просто int. Или проверить можно ли деференсить переменную для этого она не обязана быть указателем или иметь оператор дереференса. Примеров бесконечное количество можно придумать, которые к структуре объекта вообще никакого отношения не имеют. Это я ещё не вспоминаю про constexpr. > трейты помимо нужных методов формулируют законы/свойства/инварианты Совсем шиза пошла, твой трейт ничем не отличается от интерфейса, кроме того что он сбоку прилеплен, а не при объявлении типа. Как будто ты не можешь пустой интерфейс прилепить и притвориться что он какое-то свойство имеет. Если уж на то пошло, то свойства типов, о которых ты пытаешься рассказывать, в крестах называют type traits ахуеть, да?, ещё с С++11 есть они в стандарте. > невыразимые в системе типов Чел, трейт 'Eq' требует реализовать оператор сравнения, ты таблетки что ли забыл выпить. В расте ты должен реализовать метод 'eq', в крестах 'operator=='. И в концепте ты можешь проверить что два типа можно сравнивать или умножать, не проверяя реализован ли у объекта этот оператор или он наследован. В отличии от раста, где надо проверять наличие трейта, вместо самого фактического свойства типа. > трейт `Send`, который говорит, что тип можно безопасно передавать через границу потока Т.е. это просто аннотация, которая к реальности не имеет вообще никакого отношения. Трейт может формировать указанные свойства, а может и не формировать, зависит от уровня долбоебизма пишущего код. Если сильно захотеть на тип повешать что-то, чего не будет в рантайме, и тебе не нравится всякое наследование, то в крестах можно какой-нибудь constexpr enum использовать для аннотации и проверять значение в концепте. А потом писать 'requires Trait<Eq>' и туда нихуя не пролезет без правильной аннотации и реализаций чего надо. >>2994963 > Назови хоть один язык ЯП на JVM считается? Ты смотри, а то так и третий ЯП популярнее Раста наскребём, если подумать хорошо. Можно ещё Dart вспомнить, по количеству компаний, пишущих на нём, он не сильно ниже Раста.
Походу на С++ пишут две категории разработчиков - одна, представители которые берут и пишут и не заморачиваются, вторая, представтели которой любят попиздеть о теории, поучить других, пообсуждать новые ебучие стандарты, но которые не написали в жизни ни одной востребованной народом программы.
Как-то так видится. Остановиться надо было где-то вот на этом: (11-й стандарт) for (auto const& i : data) { std::cout << i.name; }
Ну ещё constexpr () бывают реально полезными - можно switch со строковыми значенями делать, что удобно.
В остальном - С++ движется куда-то не туда и обрастает вредными фичами.
Вы говорили, вам тяжело читать сетевой код с сишными колбеками, да? А мне вот не тяжело совсем. И дело тут не в readability, а в нехватке оперативной памяти у читающих, который в голове не могут удержать пару-тройку раскинутых мест по назначению колбека, его вызова и самой функции назначенной колбеком.
А вот современный супер ASIO c++20 с корутинами, вообще шедевр (пикрил 1), да? Его читать у вас глаза не ломаются?!
И теперь каждый долбоёб, который не хочет тащить ASIO, но хочет юзать корутины, будет писать свои future и promise
Каким же с++ говном становится с каждой пятилеткой.
>>2994981 >И в концепте ты можешь проверить что два типа можно сравнивать или умножать, не проверяя реализован ли у объекта этот оператор или он наследован. В отличии от раста, где надо проверять наличие трейта, вместо самого фактического свойства типа. А в чём разница-то?
Все примеры, которые ты назвал, про структурные свойства типа. Даже type_traits нужны только для того, чтобы проверять, если у типа нужный конструктор/оператор и т.д. Но они ничего не говорят про свойства, которые в коде даже явно не прописаны, но на которые корректность кода опирается.
Как выразить в системе типов требование, чтобы operator== задавал отношение эквивалентности? Без зависимых, refinement или ещё какиъ-то ёбнутых типов не сделать.
То, про что я говорю, это совсем не про type_traits, а ближе к named requirements, которым тоже в стандарте плюсов сто лет в обед. Но тайпклассы и трейты доносят идею объединения структурных и функциональных требований до масс.
Это называется "design by contract". Формулировать свойства абстракции прямо рядом с абстракцией следует этой идее. Когда функция принимает тип "T: Eq", это означает, что её корректность опирается на то, что метод eq задаёт отношение эквивалентности. Но это не нужно прописывать явно, т. к. это уже описано в трейте.
Да, это можно делать с интерфейсами. Да, это можно делать добавлением ассоциированных контант/типов, чтобы структурно классы получались различными. Но это всё костыли. Я сравнивал конкретно концепты и трейты. Всё. Я вообще не нападал на плюсы, только твоё раздроченное тонкостями стандарта очко на месте усидеть не может.
Любую программу и на ассемблере написать можно написать. Наличие всех этих фич на тьюринг-полноту не влияет (может, наоборот, её забрать). Речь идёт про то, что язык ставит в приоритет.
>>2995084 > ASIO Так-то boost - это рак всех крестов, из-за него все считают что все крестовики ебанутые говноделы, пишущие антипаттерны. К счастью этот кал довольно нишевый уже, к свежим крупным проектам его стараются даже близко не подпускать. >>2995087 > структурные свойства типа Как ты вообще умудряешься приплетать структурные свойства, если то что я перечислил не является частью типа вообще ни в каком виде. По твоей шизоидной логике как раз трейты структурные свойства, раз они являются частью структуры объекта. > type_traits нужны только для того, чтобы проверять, если у типа нужный конструктор/оператор и т.д. Ясно, ты реально дегенерат. Я думал ты хотя бы документацию читал, а ты оказывается просто шизишь. > design by contract Ну это уже троллинг пошел, потому что у Раста из коробки в принципе нет инструментов для определения контракта. Трейт - это не контракт, потому что не гарантирует что этот трейт реально реализуется. "Компилятор опирается на трейт" - это design by trust me bro, а не by contract. Ты бы хоть ознакомился с тем про что пишешь. Именно из-за такой каши в башке и получаем забагованное говно в Расте, пиздос.
>>2995149 >Так-то boost - это рак всех крестов, из-за него все считают что все крестовики ебанутые говноделы, пишущие антипаттерны. К счастью этот кал довольно нишевый уже, к свежим крупным проектам его стараются даже близко не подпускать. Погляди вакухи плюсовые. Через одну BOOST BOST BOOTS BOST
>>2995169 > вакухи > BOOST BOST BOOTS BOST Так хрюши копипастят одно и тоже из вакансии в вакансию, в них какой хуйни только не увидишь, на собесе никто и не вспомнит про boost.
Ты вообще нихуя не выкупаешь, я смотрю. То, какой у тебя получится тип после передачи в функцию –всё ещё очень синтаксическая вещь, никак не отражающая семантики типа. Всё, что ты назвал – синтаксические вещи.
> > type_traits нужны только для того, чтобы проверять, если у типа нужный конструктор/оператор и т.д. > Ясно, ты реально дегенерат. Я думал ты хотя бы документацию читал, а ты оказывается просто шизишь. Чел, я много лет на плюсах писал. Покажи мне хоть один пример не чисто синтаксической проверки. Ты просто не можешь, потому что это невыразимо в системе типов.
> > design by contract > Ну это уже троллинг пошел, потому что у Раста из коробки в принципе нет инструментов для определения контракта. Я говорю про принцип дизайна, а не про формальный инструмент. Плюсовый компилятор тоже никак не проверяет, что итератор, который заявляет, что он в категории random access, действительно таковым является.
Прежде чем утверждать, что то, о чём я говорю, это не design by contract, ты бы хоть погуглил, что это такое. Реально позоришься.
> это design by trust me bro, а не by contract Конечно, компилятор не всегда и не всё может проверить и всегда есть некоторый trust surface. Именно, поэтому трейт Send unsafe. Только в плюсах unsafe –это весь код, а в rust'е несколько изолированных мест, к которым очень пристальное внимание. При желании, можно написать вменяемую программу без строчки unsafe кода.
И прежде чем строчить ответный высер, ответь уже наконец-то на вопрос, который я задаю третий раз. Как выразить, с помощью концепта/интерфейса/constexpr/whatever, что operator== задаёт отношение эквивалентности?
>>2995257 > Я говорю про принцип дизайна Что за хуиту ты порешь. При предоставлении контракта ты должен иметь возможность проверить его выполнение, это просто ключевой момент в design by contract. В Расте ты не можешь сделать это средствами языка, не написав ебучий тест. Посмотри хоть как в других языках это реализуется, клоун. > Как выразить, с помощью концепта/интерфейса/constexpr/whatever, что operator== задаёт отношение эквивалентности? Ты реально тупой, да? Я тебе могу в пятый раз объяснить, что в крестах свойства объекта и структура - разные вещи. operator <=> тоже может использоваться для определения эквивалентности вместо operator==. Наличие этого свойства определяется концептом, прямой проверкой что объект имеет это свойство, блять, а не наличием какого-то атрибута у типа, как в Расте. Ты лучше свой высер про design by contract объясни, как узнать что трейт Eq задаёт отношение эквивалентности, а не просто рандомный bool возвращает.
>>2995311 > Нет, не считается, семантика ведь та же. Не, у котлина она отличается от джавы, больше функциональщины. Там в свежих версия конвертация в джаву выдаёт совсем нечитабельные простыни, потому что джава просто не имеет альтернатив языковым конструкциям котлина. Ну и если уж быть точным, то Котлин может LLVM компилиться в нативный код. > гугол его уже закопал Зато китайцы подхватили. Тенцент на нём писал. Он как видишь даже Свифт обходит, хотя казалось бы кому вообще нужен этот Дарт, но его довольно активно развивают. >>2995332 > вообще не уверен, неси другую стату, если найдёшь Надо по хорошему стату по коммерческому использованию, а не просто какой-то опрос непонятно каких 90к человек. В вебе котлин точно обходит раст, у котлина какие-то огромные списки корпораций, использующих его для бэка.
> При предоставлении контракта ты должен иметь возможность проверить его выполнение, это просто ключевой момент в design by contract. Нет, нихуя. Design by contract – просто способ мышления при проектировании приложения. Всё. > Ты лучше свой высер про design by contract объясни, как узнать что трейт Eq задаёт отношение эквивалентности, а не просто рандомный bool возвращает. Я нигде не говорил, что в расте можно проверить (в смысле "доказать") это свойство средствами языка. Я ровно это и написал: "невыразимо в системе типов". Именно поэтому оно пишется рядом с трейтом в комментарии.
Если ты вообще посмотришь на мой изначальный комментарий, то увидишь, что речь шла ровно про разницу между концептом и трейтом. И я говорил про идейную разницу, а не только про физические возможности. А идея в том, что ты рядом с трейтом описываешь законы этого трейта, которые НЕ выразить в системе типов. Я для тебя, ебаната, ещё раз это повторяю.
Конечно, компилятор не может их проверить, в этом ровно блять и смысл, что не может. Идея в том, что разрабы раста поставили идею design by contract в приоритет и энфорсят её в дизайн-решениях. То, что трейт нужно реализовывать явно, помогает энфорсить эту идею. Всё. В этом весь сакральный смысл.
Если от невыполнения этого контракта, описанного комментарием, можно получить UB, то трейт помечают unsafe, чтобы переложить ответственность на реализующего этот трейт.
Если ты хочешь формально проверять эти свойства, то используй тулы для формальной верификации. Удачи это сделать на плюсах. Если хочешь неформально проверять, то используй рандомизированные тесты.
Ещё раз, для конченых. Идея трейтов ровно в том, чтобы обычные разрабы освоили идею design by contract. Чтобы язык был построен вокруг этой идеи. И чтобы это приводило к лучшему дизайну приложений.
Приводит ли это по факту– другой вопрос. Человек задал конкретный вопрос, я на него ответил. Прости, что я пощекатал твоё хрупкое эго, просто назвав разницу между механизмами двух языков. То, что тебя это так будоражит, говорит лишь о том, какой ты уебан
>>2995410 Ты ещё начни настаивать на конкретном определении слову "абстракция" или "полиморфизм".
Если контракт можно верифицировать, круто, только это очень сложно. И я писал на всяких коках, агдах, тла и прочем. Оригинальная идея, может, и была такая, но ничто не мешает её адаптировать для языков, в которых нет формальных инструментов для проверки этих контрактов. Называть её так же, не я придумал.
Я несколько раз чётко дал понять, что я имею в виду. Не нравится то же название, имей в голове: "design by contract 2TM" и запрись в своём крестовом царстве.
>>2995426 > Ты ещё начни настаивать на конкретном определении слову "абстракция" или "полиморфизм". Вот не надо передёргивать. У какого-нибудь TDD нет никаких других шизоидных определений. > не я придумал А кто? Ты хоть одно упоминание этого в доках раста покажи. Я тебе могу даже показать костыльные реализации контрактов в расте, почему-то всем кроме тебя прекрасно понятно что это такое и как оно выглядит. https://docs.rs/contracts/ > Я несколько раз чётко дал понять, что я имею в виду. У тебя такая каша в башке, что ты даже сам не понимаешь что пишешь, чел. Ты ведь буквально пишешь "компилятор не может проверить" хотя design by contract сделан ровно для того чтобы проверять это. Ебучий цирк.
>>2995437 > У какого-нибудь TDD нет никаких других шизоидных определений. Шизоидное оно, только потому что тебе не понравилось.
> Ты хоть одно упоминание этого в доках раста покажи. С чего это именно там должно быть? Я назвал конкретную идею и объяснил что имею в виду. Если тебе удобнее так считать, считай, что я так называю. Можешь меня в чём угодно обвинять. Но идея от этого не изменится.
> https://docs.rs/contracts/ Есть ещё миллион инструментов: https://rust-formal-methods.github.io/tools.html Всё это достаточно ограниченые языки спецификации, которые только небольшое количество контрактов могут сформулировать. Я не могу представить, как в них сформулировать свойство "безопасно передавать через границу потока".
Это не каша. Я нигде по ходу не переобулся. Я вёл одну и ту же мысль до конца, начиная с первого сообщения.
>>2995383 > В вебе котлин точно обходит раст А что там у сей/плюсов по вебу? Если не считать готовые вебсерверы типа нжынкс, то как бы не меньше, чем у раста. В том и фишка, что раст, он и для фронта, и для бэка, и дла ядра линуха, и для всего остального. Он как питон, только здорового человека.
Меня воротило от сей/плюсов вот это самое - "накосячил позавчера, ебис с дебагером сегодня". Джава громоздко, питон медленно, но с numpy хоть как-то. Потом решил уползать с питона. Сперва попробовал julia, но её индексация с 1 и охуеть какая долгая компиляция тогда в 2019 меня шибко расстроили. Потом выдохнул и попробовал раст и зашло на ура. Внезапно, батареек оказалось достаточно уже тогда в 2019/2020
>>2996581 Зачем, если можно сам D использовать? У него только две проблемы - он слишком непопулярный и хохлы. Это всё ещё лучше чем раст, даже с учётом второй проблемы D.
появилась странная идея для структур данных вместо типов использовать трейты. например, не struct Tree, а trait Tree, т.е. данные отделяются от внешнего интерфейса, зачем это? чтобы одни и те же структуры данных можно было реализовать по-разному, что скажете норм идея?
>>2998251 Сначала делаешь по тупому, а если поймешь, что есть какой-то постоянно повторяющийся код (больше чем три раза), можешь начать думать о каких-то абстракциях.
>>2998473 по-тупому на самом деле зачастую проще, просто иногда хочется делать с заделом на будущее, если надо будет что-то добавить хотя ни разу до этого не доходило >>2998292 >1. да, когда-то помню делал какую-то ебаторию с трейтами с закосом под ёба универсальный интерфейс, потом выяснилось, что без hkt работать не будет. >>2998399 хз. есть в этом некий шарм
>>2998495 > хочется делать с заделом на будущее, если надо будет что-то добавить Ты либо пишешь по солиду расширяемое легаси, либо выкидываешь ООП и пишешь модифицируемый код.
>>2999496 > За последние пару лет На самом деле с Edition 2021 никаких изменений нет в языке. Так-то даже в сишке больше изменений за последние годы произошло, чем у пидорастов. Мёртвый язык.
>>2999524 Непонятно. Ладно на западе их всяким лиспам со студенчества учат, а у нас в тех вузах до сих пор с++ билдер 6. Казалось бы проще забыть как тебя зовут, чем лабы на плюсах...
>>2999529 > в тех вузах Ты так говоришь, как будто питонисты, пересаживающиеся на раст, в вузе учились, лол. Там в большинстве случаев максимум курсы на фулстака для 300к/сек, после которых можно только хуи сосать за 500$. Они ахуев от такого пытаются уйти из веба и вкатываются в безопасный раст, люто ненавидя всё что заставляет их думать, ведь на питоне/жс им это не приходилось делать.
>>2999826 У сишки теперь будут релизы каждые 3 года как у крестов, чел. Огромный список изменений есть в C23, теперь будут тащить фичи из крестов, которые оттестированы десятилетиями и не требуют ООП.
>>2999887 >теперь будут тащить фичи из крестов, которые оттестированы десятилетиями и не требуют ООП Дак, это, зачем оно, если сразу на крестах можно писать без ООП? Типа, "вот вам язык, а вот такой же, но кастрированный". Ща мы методом обрезки фич тоже сварганим пару десятков языков из раста, сишники, сосать.
>>3000402 Есть куча многообещающих языков, возможно даже чем-то прогрессивнее раста, но без коммьюнити, без доки, без батареек и без тулинга. У раста это всё есть, поэтому пока без особых альтернатив.
>>3000428 > У раста это всё есть Хотелось бы узнать в каком месте. Я помню на кресты пиздели за то что в темплейтах куча скобочек, какие-то непонятные выражения там и прочее, пиздели на то что вместо названия типа вермишель на пол страницы и название переменной утопает в этой лапше. Кресты с этим боролись ещё со времён C++14, в итоге пришли к дедукции типов и auto, когда можно делать дженерики без использования синтаксиса дженериков и тип вообще не писать. А что имеем в расте? Вот что на пикрилейтеде такое? И ведь в реальном коде постоянно видишь как 2-3 строчки занимает сигнатура метода со всеми этими потрохами. Как по мне, раст уже даже обгоняет кресты по количеству ебанутого мусора в синтаксисе и размеру кода. Безопасность это хорошо, но код раста читать банально неприятно.
>>3000615 >ABI. Который завязан на платформу. И ты либо работаешь на любом говне, но не имеешь стандартного Аби, или имеешь, но работаешь на ограниченном выборе платформ (или на виртуальной машине, у которой под капотом очередной нестандартный Аби). мимо
>>3000641 Спроси у пердоликов зачем это, на винде оно точно не нужно, значит красноглазики или красноглазые корпорации зачем-то тянут всё. Майки вот пытаются заставить комитет отказаться от старого ABI, но они проебали голосование прошлый раз, в этом году тоже. С++26 всё ещё без официальных изменений в ABI. При этом почему-то никого не смущает, что компиляторы с С+17 уже вынужденно сломали его, потому что комитет не пишет компиляторы и не думает о том как их стандарты реализовывать будут.
>>3000639 Ты пиздишь на синтаксисис, ни разу не возражая тому, что я перечислил. Да, если проблемка, может однажды сделают тоже что-то типа auto и автовыведения дженериков. Код, который ты привёл, в реальности крайне редок.
>>3000639 мимо c++ тупняк от зануд которые байты считали, давно уже не нужен байто-дроч, кэш проца больше чем экономия от выравнивания байтов, и асм который произошёл от экономии бит, уже давно устарел. Раст вообще недоразумение, как будто его придумали чтобы вообще испортить здравый смысл в программировании. Всё уже придумано давным давно, Java лучший язык- можно его компилировать хоть в бинари хоть в vm байткод любой, зачем ещё выдумывать тупейшие вещи, которые давно в java решены?
>>3000836 Подскажешь инструмент для джавы который поможет не блевать когда приходится прикосаться к этому мерзотнейшему античеловечному поделию из прошлой эры?
>>3000971 >Скала или хотя бы Котлин. В обоих недорешена проблема null, оба тормозят. Котлин-нейтив выдаёт тормозной код по скорости не обгоняющий джаву, это костыльное решение для разработки под гейось. Тулинг у обоих всясывает расту. Дети, давайте проблеем дружно ме-ее-еэээйвен, бля.
>>3000971 выкинь на помойку Scala и Кotlin, это смехотворные и ненужные компромиссы, от людей которые ни одного софта нормального полностью целиком не написали за всю жизнь. Только java лучший, объяснять почему займёт не один том рассуждений, любой умный прогер это знает. Просто умных кодеров не существует, те кто умные- идут в начальники или бизнесмены. Код пишут тупые, такова селяви по фактам.
>>3001039 нет, ты дурак, я ни одного русского человека не знаю, который так бы тупо и не по делу написал. Даже васян который мне сантехнику делал, умнее в сто раз написал бы, даже не зная предмета обсуждения. просто те, кто наводнили борду чат- ботами, конченные деграданты, идиоты, пидоры, нелюди одним словом. Ваши нейросети- обучены на генетических отбросах, а обучали и корректировали нейросети- такие же унтерменши, за мелко- баксовый прайс. Почему вас не банят, непонятно.
Есть по вашему расту какие-то замеры перфоманса у разных фич? Типа стек против кучи/динамическая диспетчеризация против статической/копирование против перемещения. Понятно что оно быстрее, но это какое-то абстрактное "быстрее" меня не сильно устраивает, там может разница в два раза, а может в пару процентов и нахуй в реальном коде не нужно.
>>3000819 > Код, который ты привёл, в реальности крайне редок. Потому что в реальности ещё хуже? У пидорастов какое-то странное понимание краткости кода. Краткость должна быть в минимальном повторении конструкций языка, а не письмена душевнобольного на клочке бумаги.
>>2999529 >>2999675 >>2999887 >>3000402 Как же забавно, что в треде раста постоянно тусуются сишники и плюсеры, и высерают тонны желчи. Интересно, почему от ржавчины столько батхерта и хейтеры готовы инвестировать свое свободное время в срачи на форумах. Найдите уже себе работу, выйдите на улицу траву потрогайте.
>>3001977 > почему Потому что кресты кал и пишущие на нём хотят перекатиться в ЯП получше. Но получают ещё более жидкую и вонючую кучу дерьма, вместо ожидаемых исправлений проблем, с которыми крестовики уже живут второе десятилетие. А местами даже наоборот деградацию, поэтому с удивлением высераются тут, как можно было сделать плохо то что уже сделано нормально задолго до раста. Естественно видя такое хочется плюнуть в лицо тем кто этот кал делал и поддерживает всё это.
>>3002058 Да и хуй с вами. Я в кресты даже вкатиться не мог, а вот в раст запросто. Вы просто передохнете, а новое поколение будет писать на расте, не подозревая, какие там охуенные плюсы были в древности (а пашкаль-то какой был, мм). Кстати, с полгода назад понадобилось разобрать ресурсы одной старенькой игры, дак мне на форуме какой-то олд скинул код на паскале. А я сконвертил его в раст через GPT. Вот ты этому олду не пояснишь, как он неправ, что пишет не на плюсах.
Впрочем, если сделают корпы начнут форсить язык с достоинствами раста и без его недостатков, я первый на него перекачусь. это я тут форсил lobster в прошлом треде
>>3002045 >как этим калом пользоваться Никак не пользуйся. Это сторонний трейт, там у него макрос, внутри которого он сочинил свой синтаксис. (если ты про эти вот _1). Чувак, видимо, беженец с хачкеля, тоскует по родине вот таким вот образом.
>>3002093 > Вы просто передохнете, а новое поколение будет писать на расте Для начала надо всё легаси переписать, что никогда не случится. Раст прижился только там где кресты и так только извращенцы использовали. Я почему-то не наблюдаю чтоб те же Майки стали что-то на расте делать, хотя от них есть официальное API под раст для всего в винде, даже для WDK. Я подозреваю что корпорации, так же как и ноющие в треде, сталкиваются с теми же проблемами - невозможность поддерживать старый код на расте. В итоге где-то мелкие куски на расте с сишки переписывают, а чтоб прям огромный проект целиком на нём - это уже нет.
>>3002106 >невозможность поддерживать старый код на расте Ну, во-первых, он от нового почти не отличается. А во-вторых, благодаря более продвинутой системе типов, в старом коде на расте проще разобраться с тем, что имелось в виду его автором - это не эти ваши сиси, где можно хуй прибавить к пальцу и помножить на залупу.
Да и, ну это же просто бред: возьми любой заброшенный проект на расте 5+ летней давности и такой же на плюсах - и проверь, что у тебя получится собрать прямо сейчас. Сдаётся мне, шансы собрать на расте будут раза так в 2 повыше.
>>3002117 Заебок. Если проект больше 1000 строк, то дописывать и поддерживать на расте будет куда проще. У раста лучше обстоят дела с зависимостями - всё прописывается вместе с версиями, просто клонируешь, cargo build и всё делается само. Как язык он выразительнее, сравни if x := call_to_func()... или if let Some(x) = call_to_func()...
первое - костыль, который работает только с None, второе - общий подход, который работает с любым enum.
Из минусов: 1. Конпеляция. После скриптового языка будет непривычно сперва подождать. 2. Нужно больше места на диске.
>>3002179 > продвинутой системе типов, в старом коде на расте проще разобраться с тем, что имелось в виду его автором Так-то абстракции предполагают что тебя не должно ебать как оно работает, просто достаточно знать что делает API. Вот в питоне только совсем недавно начали делать аннотации типов, а до этого и без этого жили - функции хуй пойми какие структуры данных принимали и всем почему-то было понятно что туда засунуть. Типы нужны компилятору, а кодер и так будет послан компилятором в случае чего. > 5+ летней давности Даже код до 2021 эдишен не собирается уже, лол. Какие 5 лет. Я не уверен как предполагается с легаси работать в расте, но скорее всего либу собирать со старым эдишеном, а потом линковать к своему проекту. Скопипастить код из пятилетнего проекта раста не получится так просто, если ты используешь актуальный эдишен. > на плюсах - и проверь Регулярно так делаю. Проблемы могут возникнуть только с устаревшими скриптами сборки. Если там header-only либа или нет зависимостей, то вообще похуй, хоть C++11 там, хоть сишка - всё соберётся. С большими проектами может придётся из-за зависимостей поебаться, в которых тоже обоссаные системы сборки.
>>3002272 >Вот в питоне >Типы нужны компилятору Ебать, ты, не в теме. В питоне интерпретатору до сих пор глубоко класть на типы, он их не замечает. Они именно что для программиста, что если у тебя ф-ция принимает str, а ты послал туда int, то тебе ide подсветит косяк. В расте то же самое, только глубже: ты можешь создавать, например, типы Speed(f32) и Distance(f32), которые на машинном уровне будут тем же f32, но которые нельзя будет, скажем, складывать между собой, зато можно будет делить Distance на Speed и получить какой-нибудь Duration. Твоя сосишечка так может?
>Даже код до 2021 эдишен не собирается уже, лол Если ты версии зависимостей не фиксируешь, то это твои проблемы. Да, знаю, ещё была одна фича, которую убрали из языка как небезопасную, но это такие мелочи по сравнению с плюсопиздецом, что не стоит упоминания.
>Проблемы могут возникнуть только с устаревшими скриптами сборки Которые могут ещё и не только устареть, но и быть написаны так, что собираются только на компе у автора, ага. А ещё там отдельный язык, поэтому чтобы оно работало, надо держать в штате отдельного чела, который будет заниматься только сценариями сборки. А ещё зачастую нужна какая-нибудь либа, именно системная, но у тебя она шибко новая, поэтому иди на хуй, а добавить её гит-сабмодулем автор поленился.
С выхода rust 1.0 прошло почти 10 лет. Почему до сих пор с этим языком так мало вакансий? Почему работодатели предпочитают убогий go вместо раста? Или 10 лет мало? Надо ещё подождать столько же?
>>3002338 >Почему работодатели предпочитают ПОЙДИ У НИХ СПРОСИ Малое количество вакансий - это не проблема самого языка. Язык может быть каким угодно замечательным-презамечательным Причины могут быть разными: 1) Программист посоветовал другое решение 2) Не рискуют пробовать новое 3) Привыкли к другому стеку 4) Думают, что rust подходит только для блокчейна 5) Не слышали о таком языке 6) Бояться что не найдут исполнителя Ну и так далее.
>>3002340 Появляются, но слишком мало. Я понимаю, что для джавы/сишарпа вакансий больше, так как нужно поддерживать тонны легаси. Только зачем для новых проектов больше берут го вместо более продвинутого раста? Вот загадка.
>>3002322 > В питоне интерпретатору до сих пор глубоко класть на типы Чел, в питоне сильная типизация. Всё ровно наоборот. Со стороны кодера нет типов, полная динамика, но в самом JIT-компиляторе сильная типизация как в Расте. Ты в питоне не можешь кастануть какой-то тип как в сишке во что угодно и компилятор его сожрёт. У питона в большинстве случаев под типом есть некий нативный код, который намертво прибит гвоздями и не предусматривает свободную конвертацию во что угодно. Я, как написавший тонну кода на пайторче и куче либ для вычислений, сразу тебе говорю - если в либе не написан нативный код для каста в другой тип, питон просто кинет тебе эксепшен и пошлёт нахуй, опрокинув интерпретатор. Как я тебе и писал до этого - все как-то жили и живут, когда в коде нихуя не подписано, а какой тип нужен можно узнать только из документации или получив эксепшен. У жс-пидоров немного другая ситуация с динамикой, у них там язык для конченых дегенератов и он действительно будет пытаться хоть как-то работать даже если ему хуиту подсовывают. > мелочи по сравнению с плюсопиздецом Ты так и не рассказал что это за пиздец. Я в отличии от тебя на практике знаю, что современный компилятор просто берёт и компилирует десятилетний код. Я тебе уже написал - возможная ебля не в языке, а в конченых системах сборки. Если ты можешь выкинуть выкинуть систему сборки либы и просто скопипастить файлы - всё скомпилируется. > А ещё там отдельный язык Это как раз вопрос к пердолям с кроссплатформенностью головного мозга. На той же винде никаких скриптов сборки нет. А проект от старой студии в большинстве случаев соберётся на новой после нажатия кнопочки "ретаргет солюшена", без каких-то дополнительных вмешательств.
>>3002190 Спасибо за развернутый ответ. Сам работаю на питоне, но думаю надо паралельно изучить еще какой нибудь язык. Думаю между го и растом. Шоб було так скозать.
>>3002376 Да нет никакой загадки. На самом деле всё литералли как тут в треде пишут - и про синтаксис, и про обратную совместимость, и про либы, и про доработку языка. При старте проекта прекрасно понимают что его будут писать куча людей, возможно будет ебейшая текучка, возможно надо будет макак нанимать. И поэтому важно чтоб макаки могли быстро разобраться и продолжить писать в таком же стиле - в стиле, про который даже студент омского ВУЗа знает. И тут не важно что ты такой молодец, выучил раст и готов РАБотать. Джава вечная, на джаве есть фреймворки, с джавой есть уверенность в завтрашнем дне до дна ещё далеко. А что раст может предложить бизнесу, кроме соевых идей про безопасность? На первом же обсуждении его вычеркнут нахуй из-за слишком больших рисков. Он сейчас и пролезает только в соевом молодёжном коллективе, который может выбрать ЯП какой нравится, а не какой реально эффективно решит задачу бизнеса. У нас на соседнем проекте сидят шарписты, пишут такой кал, что их каждый день хуями обкладывают и они не успевают лицо от харчи вытирать. Но ничего, их сервисы пердя-кряхтя работают, полного останова или критического говна ни разу не было. Всех оно относительно устраивает. Нужна ли кому-то там безопасность и скорость раста? Нет.
>>3002512 >Нужна ли кому-то там безопасность и скорость раста? Нет.
Пришёл к тому, что в конечном счёте у нас есть cpu bound задачи и сетевые, дроч с перфомансом имеет смысл только если что-то считаешь на проце, а задачи принеси подай легко решаются асинхронкой + легчайшим параллелизмом тредпула. В принципе с этой херней и питон может справится... Дроч на перфоманс это какой-то инженерно-кодерский фетиш.
>>3002476 > в питоне сильная типизация Она там отдельно от аннотации типов, или что ты имел в виду, когда писал >Типы нужны компилятору в пизду такую аннотацию, как по мне.
>современный компилятор просто берёт и компилирует десятилетний код. ага, ага. Да похрену, изначально речь шла о поддержке, и я таки настаиваю, что плюсоговно поддерживать тяжелее, так как 1. обилие фич и обратная совместимость позволяют наворотить жуткого дерьмища, где не разобраться даже в теории. 2. зависимость от системных либ, без внятного версионирования. На самом деле что-то есть, знаю, но все стараются указать >=, наивно надеясь, что года через 3 оно не сломается. А вот хуй.
>вопрос к пердолям с кроссплатформенностью головного мозга Ой, прикинь, а на расте вообще без проблем на любой системе, а через cargo apk, даже под ведроид можно.
>студии Так ты и сиди там, в своём m$ мирке, что ты к нам лезешь-то ? Девелопь дальше бэк под некрософт тырпрайз хуитанейм и прочую лабуду. Или что, тырпрайз шарписты зажимают? Дак, сбегай и им расскажи, какое их .нет говно.
>>3002564 > позволяют наворотить жуткого дерьмища, где не разобраться даже в теории А раст как будто не позволяет писать такое, вон даже выше либы кидают для написания такого дерьма. > зависимость от системных либ У тебя в расте точно так же при написании системщины зависимость от libc/winapi/winrt и их версий, лол. Я уж не стану говорить про то что на Винде с крестами это не проблема, а то опять бахнешь. > а на расте вообще без проблем на любой системе, а через cargo apk Чуть выше уже был пример, что твой каргобилд может молча собрать нерабочий бинарник и разбирайся сам почему. > в своём m$ мирке Как там раст работает без MSVC-тулчейна на винде, лол? Или это другое, а поддержка ОС кроме прыщей не нужна?
>>3002645 >поддержка ОС Ключевое слово. Прыщи, это ОС для работы и разработки софта, винда, это запускалка софта.
>зависимость от Скажем, на расте есть egui и Qt, а у вас только Qt, который системный, хаха. Плюс сишники любят брать системные либы для всяких мелочей, типа, вот, нам нужна либа для хитровыебанной трансформации звука, утонови, слыш. И похуй, что система загажена этой либой ради одной этой софтины.
>для написания такого дерьма Там всегда можно раскрутить макрос и заглянуть в логику. А понять, что имел в виду сишник в своей функции, принимающей указатель на void, можно примерно с тем же успехом, что ковыряя ассемблерные коды.
>>3002741 > egui Который клон крестового imgui? Ты траллишь? При том что твой egui тянет зависимостей гору и весит пиздец, в отличии от оригинального imgui, не имеющего зависимостей вообще. Заебись пример ты привёл. > сишник Давай сразу на ассемблер перескочим, а то уже с крестами не получается сравнивать раст. В крестах нельзя так просто кастовать к воиду, лол.
>>3002512 Джавараст, что ты тут сидишь и ноешь? Ты себе пытаешься что-то доказывать аутотренингом или что? Съеби в другой тред, раст никому не нужен, он никак не развивается, на этой или на следующей неделе точно загнется, ты победил.
>>3002916 >клон крестового imgui которым за пределами игровой индустрии никто не пользуется, почему-то.
Вообще, смотри, если вкратце. Раст это те же плюсы, но: - с нормальным тулингом в виде cargo + rustup, которых хватает для всего - с нормальным менеджментом зависимостей - с чуть более выразительной семантикой - с более продвинутыми макросами вышеперечисленного мне уже хватило бы, чтобы предпочесть его плюсам, но он же ещё и - безопасный за что на него обращают внимание корпорации, иначе бы он им не сдался и был бы просто ещё одним маленьким языком для фанатов прогрессивных веяний.
рад за вас, что вам нельзя кастовать войд во что угодно в этих ваших плюсах. Вот ещё многое другое было бы нельзя, было бы совсем заебок. Ряяя, не трожь, я знаю что делаюпримерно так отреагирует сишник на попытку отобрать у него свободу обращения с войдом
>>3003112 >как реверс инженеры такой код реверсят На уровне машинного там нет никакой разницы. Конпелятор тебе из идеального, понятного даже твоей информатичке, кода выплюнет ту самую кашу, в попытке абстрагироваться от которой и придумали высокоуровневые языки.
>>3003202 Это из мира unsafe. Например, если тебе надо работать с сишной либой, то для раста там всё будет заведомо void, который надо небезопасно кастануть.
>>3003278 Если у тебя, скажем, указатель на структуру из сишной либы, куда автор добавил новые поля, а твой код об этом не в курсе, то будет ошибка доступа к памяти. Поэтому, таки, опасно.
>>3003431 Он прост, как 5 копеек. Сложности возникают из-за необходимости разбираться в ABI, версиях libc, флагах сборки, сборочных системах и прочей параше, которая в расте от тебя скрыта по большей части.
>>3003449 >Он прост, как 5 копеек. Такой охуенно простой язык с хуилионом подводных камней, обходить которые помогают лишь набитые десятилетием шишки. >разбираться в ABI, версиях libc В чём тут проблема? >флагах сборки, сборочных системах и прочей параше То есть знание, как сделать из си нужный тебе диалект != знание языка?
а есть тут такие, кто активно пишет на раст, но может высказать критику, обрисовать минусы языка, с которыми уже смирился или забил? интересно сравнить со своими впечатлениями о языке.
>>3003449 > необходимости разбираться в ABI Это откуда такая необходимость появляется, шиз? > флагах сборки, сборочных системах В 2024 году с cmake тебе даже в конфиг заглядывать не придётся, чтоб написать и собрать сишный/крестовой код. В VS Code даже гуй есть для менеджмента проектом. На флаги совершенно поебать, cmake за тебя всё сделает. > в расте от тебя скрыта Это в том расте, где для минимальной кастомизации сборки надо писать build-скрипты на этом самом расте? Где аргументы компилятору надо передавать через println?
>>3003919 >где для минимальной кастомизации сборки Для минимальной кастомизации у тебя есть features. build.rs нужен для всяких хитрых штук, вроде кодогенерации или переконпеляции сторонней либы на другом языке. Это не минимальная, а максимальная кастомизация, которая делается на том же самом расте, а не на хитровыебанном cmake или иной залупе.
>>3003959 Даже если бы и так, не труп крестов же колупать. В расте у тебя продвинутая семантика и одалживания, что-то похожее сейчас есть в любом новом системном языке без сборки мусора. Если какой-то из них выстрелит, переползать с раста будет легче.
>>3004542 У опытных программистов пямять не течет, поэтому всякие системные штуки до сих пор пишут на си. Не потому, что деды пердуны не шарят за мемчики в тиктоке, а потому, что в программе на си ты берешь дамп памяти и можешь понять, где у тебя что лежит. В том же расте хуй проссышь, что оно там набесоебило с замыканиями и прочим говном.
>>3004560 >У опытных программистов пямять не течет опытных программистов не хватает на всю индустрию. А растишка с годом опыта перформит не хуже опытного сишника и тоже ничего не течёт.
>>3005689 И ты хочешь сказать, что это ебаное месиво из символов лучше кода на чистом си? Нахуя там map с пустой лямбдой, чтобы что? Посмотри, как выглядит открытие сокета на си и сравни с этой шизофазией.
>>3005716 >map с пустой лямбдой Чтобы в одну строку избавиться от значения результата. Как видишь, сишная функция возвращает c_int, который нам не пригодится, поэтому для успешного результата мы вернём Ok(()) вместо Ok(c_int), а в случае ошибки она уйдёт без изменений.
>>3006300 Дак, в биндинге она и проверяется (Result откуда взялся, по-твоему), но на всякий случай пробрасывается наверх. Я хз, зачем это сделано, может для работы на каких-то экзотических системах, где есть шанс получить ошибку с неизвестным кодом и тогда перенести его обработку выше.
>>3006325 Немного не то гоню. Проверяется она вызовом cvt, но суть особо не меняется - он проверяет ошибку и возвращает значение, а на месте ты решаешь, нужно ли оно тебе. никогда не копал так глубоко, на расте оно почти не нужно, кроме как для споров с сишниками на двачах
>>3005758 Я так и не понял почему бы просто не прокидывать наверх вопросом? Или опять чудеса сильной типизации, когда Ок не равно Ок? Если значение в Ок не используется, то это компилятор обычно оптимизирует нахуй.
>>3006495 Ну вот не нужен наверху результат сишного вызова, поэтому с вопросом будет 2 строки, без можно в одну. Это вкусовщина.
>>3006509 Изначально там проброс идёт на самый верх и unwrap'ится уже в коде непосредственно сервера. Чтобы понять, на каком этапе ошибка, я размотал все вызовы и проставил unwrap вместо ?. Собсно, до конца не вполне понятно, в чём именно ошибка, надо разбирать структуру по байтам, а мне лень. Там идёт создание структуры сишного сокета из строки вида "ip:port", потом это всё скармливается сишному bind из libc. В 1.57 тулчейне работает, в новом не работает. Вполне возможно, что это баг и его пофиксят, если отрепортить. Не тот баг, где они убили сокеты, азазаз, а поломка совместимости со старым кодом 5+ летней давности.
>>3006641 Обходятся и страдают, и наворачивают в "альтернативно-популярные" языки. В js их нет а в ts есть, в java нет а в scala есть, в csharp нет а в fsharp есть, в типизированном питоне есть, в плюсах страдают с std variant и шаблонами, в сишке и гошке страдают с енамами.
>>3003919 >В 2024 году с cmake тебе даже в конфиг заглядывать не придётся, чтоб написать и собрать сишный/крестовой код. В VS Code даже гуй есть для менеджмента проектом. На флаги совершенно поебать, cmake за тебя всё сделает. Звучит, как пиздёж.
>>3006728 Почему же? На винде пишешь в консольке: > choco install visualstudio2022buildtools cmake vscode Открываешь VS Code, ставишь экстеншены для крестов и cmake, жмёшь на команду "CMake: Quick Start", жмёшь на кнопку Build, видишь в консольке: > [driver] Build completed: 00:00:01.281 > [build] Build finished with exit code 0 Вот и всё, больше ничего не надо делать на чистой винде, чтоб собрать кресты. Пикрилейтед уже все профили сборки есть на выбор. Лезть в CMakeLists.txt нет нужды, писать в консольку какие-то команды сборки тоже.
>>3006771 >На винде пишешь в консольке Как это прекрасно.
>ставишь экстеншены для крестов и cmake Здорово, конечно, но что, если чукча не только читатель, но ещё и писатель? Готов потратить полгода жизни на изучение искусства написания cmake скриптов?
>>3006809 > Как это прекрасно. Что тебе не нравится? В винде ещё с десятки есть встроенный менеджер пакетов, для кодинга там все пакеты актуальные, в том числе и раст можно ставить без всяких rust-up. > потратить полгода жизни на изучение искусства написания cmake скриптов А зачем? Все твои скрипты ограничатся вызовом пары местных "функций" - заданием переменных окружения через set(переменная значение) или find_library()/include(). Ну ещё натыкать ифов для разных ОС. Там же синтаксис беднее чем у lua, чего учить. Реальные скрипты придётся писать только если ты ебанутый шизик или у тебя проект уровня игрового движка с десятком зависимостей. Так-то у cmake функционал огромный, он может даже сам собрать либу на расте и прилинковать.
>>2923611 (OP) велосипедные пидорастеры. вы же просто крутите педали на готовых программах просто всё перепечатывая по 10 раз, воруя ресурсы прямиком из энтропии. из-за вас скоро гитхаб станет платным потому что вы начали срать копипастом с плюсов из всех щелей.
как только в сишку зайдут упругие зумеры, и начнут недовольно стучать попытами по столу, старые пердуны из коммитетов начнут писать сахар, и вы окажитесь не у дел.
>>3007179 нет лишних десяти лет, чтобы набивать шишки в этих ваших плюсах, а потом все равно где-то раз в год охуевать в стиле "а что так разве можно/нельзя было?"
>>3007211 >нет лишних десяти лет, не пизди, как будто ты метишь к докторской в 24. волоёбишь как и все. наверняка и диплом какой нибудь с дженерик темой "как сделать говно на си"
>>3007299 Идешь в 1-й класс в 6 лет, пропускаешь 4й класс, но учишься до 11го. Поступаешь в вуз, за 4 года получаешь бакалавра, уезжаешь сразу на пхд в пиндостан, делаешь его за 4 года. Вуаля, доктор в 24 года. Спешите принять оффер в фаанг на ресерч позицию.
>>3007310 Само собой. Семья очень важна, лет до 20ти практически все зависит от того, как тебя семья поддержит и какая она. Одному трудно будет, даже если на таланте работать. Так что если не повезло, то придется работать вдвойне и не факт, что к чему-то хорошему придешь. Перегоришь и будешь на харкаче сидеть в треде про раст.
>>3007314 На пиндосский пхд можно без маги. Там многие поступают на пхд с финансированием, а потом выпускаются со степенью магистра и идут работать. Но это вроде фишка штатов, что можно с бака сразу на пхд прыгнуть. В России и Европе такое не прокатывает вроде. Про Азию не в курсе.
Хотел посоветоваться, посоны. Кратко изложу суть. Хочу сделать простое приложение, которое будет взаимодействовать через браузер. Хотел написать серв на чистом раст+токио, с минимальными зависимостями. Но гонять туда-сюда заголовки, поддерживать сессии - тот ещё гемор. Мне точно нужен webrtc или websocket, наверное tls еще, чё думаете вообще? Axum и всякое такое кажется тяжелым.
>>3007552 Пиши фронт в виде PWA, на жс, блять а хули хотел?. > Мне точно нужен webrtc Нет, тебе это говно не нужно, его ещё и блочат в браузерах часто потому что это дырявая параша. WS хватит. >>3007553 > я ваще далек от фронта Земля тебе пухом. Лучше тонкий клиент напиши, если инвалид.
Добрый день, граждане. Я классическая веб обезьяна. Хотел попробовать что-то серьёзное. Аля С++ или Rust. Насколько я понимаю, они решаю одни задачи, но rust современее что ли.
Собственно вопрос: стоит ли пробовать ковырять rust или это чисто хайп?
>>3008186 >стоит ли пробовать ковырять rust или это чисто хайп? А цели какие? Хайп, но не чисто. С С++ можно переползти практически на любой юзык, но не факт что захочется.
И малюсенький нюансик, который большинство назовёт недостатком, а считаю достоинством - по большей части С++ это надмножество над Си. Обратная совместимость очень высока и опытный программист даже не обращается внимание на эти нюансы - он напишет сишную программу так, что её соберёт С++ компилятор.
Если до этого не трогал языки без сборщика мусора, советую начать с Си. Язык без лишних абстракций и максимально приближен к ассемблерному коду. Как освоишься с управлением памятью, можно уже и раст или плюсы потрогать.
>>3008186 Я так тоже хотел попробовать раст, в итоге пишу на чистом си, пытаюсь во всякие сетевые штуки чисто для саморазвития. Си оказался внезапно очень простым и понятным языком, в отличие от раста с его наркоманским синтаксисом. Плюсы - это помойка, куда срали шизофреники, даже не думай вкатываться. Если хочется язык с беспощадным месивом из символов, лучше возьми раст, тут хотя бы сообщения об ошибках компиляции написаны для людей.
По-моему раст без знания си учить бесполезно. Иначе ты не поймёшь зачем нужны такие страдания и у тебя просто сгорит жопа, а потом прибежишь на харкач рассказывать какое раст говно. Собственно, чем половина треда и занимается. С плюсами то же самое кстати, только мотивация другая.
>>3008333 Я как бы давно пишу на сишарпе и жалкими 1к строк меня не напугаешь. Достаточно не писать весь код в одной гига функции, как любят чистые сишники.
>>3008309 В моем манямирке Си - это синтаксический сахар/фреймворк/надстройка для асма, т.е. ты сначала учишь асм, а потом уже Си. Не зная асма Си - бесполезен. Да, ты на нем напишешь, он скомпилируется и будет работать, а потом наебнется в самый неподходящий момент и ты заебешься искать место где и что ты там не туда записал/прочитал.
Си++ это надстройка над Си. Изучая С++ автоматом учишь С.
А вот rust - это уже самодостаточный язык, с которым можно работать не ломая голову, что там произходит на более низких уровнях. Да, расплата за это в том, что возможностей у тебя сильно меньше и приходится больше изъебываться, чтобы ублажить компилятор.
>>3008345 >По-моему раст без знания си учить бесполезно. А по-моему все ровно наоборот. Изучение Си просто выработает в тебе вредные привычки. > Иначе ты не поймёшь зачем нужны такие страдания и у тебя просто сгорит жопа, а потом прибежишь на харкач рассказывать какое раст говно. Если rust для тебя первый язык, ты не поймешь, что твои страдания - это именно страдания, т.к. не будешь знать как с этим обстоят дела в других языках. Ты будешь воспринимать все ограничения раста как данность и учиться с этим жить.
>>3008349 Выше в треде анон пытается понять, почему у него в расте сокеты не работают. Расскажи ему, какой раст самодостаточный. В си открытие сокета - это четыре функции, вызываешь их по порядку и все ок. В коде на расте накрутили ооп, монады, лямбды, чтобы в итоге вызвать четыре фунции. Оно еще и не работает в итоге, лол.
>>3008349 >В моем манямирке Си - это синтаксический сахар/фреймворк/надстройка для асма Ты не знаешь языка на хорошем уровне, поэтому для это это так, продолжай жить в своём манямирке.
>>3008365 >Выше в треде анон пытается понять, почему у него в расте сокеты не работают. ну это его право, я бы просто ишью создал на гитхабе и разбирался бы с сокетом уже автор проекта
если бы у анона выше свет в доме вырубили, ты бы тоже писал, что раст гавно и надо ставить генератор?
>>3008373 >Ты не знаешь языка на хорошем уровне, поэтому для это это так, продолжай жить в своём манямирке. спасибо, я уже испугался, что будет как на пике
>>3008411 и это тоже) в целом все как обычно: - вы просто язык(а|ов) не знаете - это было раньше, сейчас исправили - у вас у самих ничего не работает etc.
>>3008419 и это тоже) в целом все как обычно: - вы просто язык(а|ов) не знаете - это было раньше, сейчас исправили - у вас у самих ничего не работает - препарат_нeйм прими, шизик etc.
>>3008475 кидай сюда что ли может там 3+ лет имеется в виду опыт разработки в целом, а не на расте во всех вакансиях, что мимо меня проходят, rust идет как доп требование т.е. если ты не знаешь C/С++, то твое знание rust'а и не нужно особо на текущий момент на рынке труда раст - это просто очередной выебон работодателя типа пусть будет, может пригодится
но я не сильно мониторю все это дело и не ищу работу, поэтому могу ошибаться
>>3008491 >в этом же проекте, но в другом месте, возвращается nullptr если всё заебись или char * c подробным описанием ошибки Попросту навалил говна и хвалится. Вот тут-то и вылазит проблема сишечки: делать хорошо, по-кармаковски, трудно, а говна навалить легко и приятно. goto не распробовал ещё?
>Извращаюсюсь как хочу Вся суть сишника. Вернёшься к проекту года через 2, поймёшь, что над собой же поизвращался в итоге.
>>3008803 >. goto не распробовал ещё? > Я использую goto иногдв. В сложных конечных автоматах. Это позволяет в разы сократить колиество кода. Мне можно.
>>3008849 >Я использую goto иногдв. В сложных конечных автоматах. >Это позволяет в разы сократить колиество кода. Мне можно. Это собственно единственное место, где использование goto оправдано -- реализация математической абстракции типа упомянутых КА. Только в таких местах goto не только не снижает читаемость, но и повышает её.
>>3009390 >единственное место, где использование goto оправдано -- реализация математической абстракции типа упомянутых КА >единственное место Специалисты уровня б.
>>3009380 Делают редокс, но пока хуйня Даже не в плане функционала, а того как работает Но они сами заявляли что пока не пытались в оптимизацию и прочее
Насколько мне известно, в Расте до сих пор нет aliasing model. То есть, строгое понимание того, что "можно и нельзя" делать в unsafe-коде в принципе отсутствует. Почему об этом так мало говорят и почему это не мешает отдельным даже, вроде как, серьёзным людям продвигать Раст в качестве настоящего и будущего всего системного программирования?
Написал пост, и тут вспомнил, что на C++ <20 (до implicit object creation) невозможно было вектор написать. Так что, в целом, такое положение дел в порядке вещей, наверное.
>>3010715 > что "можно и нельзя" делать в unsafe-коде в принципе отсутствует Почему же, у пидорастов есть чёткое понимание как работать с ансейфом - никак. >>3010716 > на C++ <20 (до implicit object creation) невозможно было вектор написать Шиз, плиз, явные аллокации всегда работали, сейчас просто сишку подтянули под defined behavior.
>>3010794 >как работать с ансейфом - никак Примерно так.
>>3010715 Давай конкретику, чего тебе не хватило. Я лично вижу раст, как замену крестам с той же стороны, что жаба и дотнет — безопасный язык для написания различного рода приложух и сервисов. Поэтому меня ансейф не особо парит, я байтоёбством не занимаюсь. Но одно то, что гугл использует раст в адроиде для вполне себе байтоёбских целей, говорит, что ты неправ.
Что значит "не хватило", ты пост читал, ты с чем споришь вообще? Этот пост вообще не для тебя, зачем тебе Раст, если ты только джейсоны перекладываешь?
>>3010892 "Любой алиасинг от дьявола" - это значит, что на Расте нельзя написать его стандартную библиотеку, что, как бы, несколько не ОК для языка общего назначения (ещё и для системного программирования)
>>3011184 > В какую именно реализацию, какой версии? Любую майков хотя бы. Там нет выделения куска памяти и гуляния по нему указателями. У тебя по ссылке наивная реализация, естественно так никто не делает.
>>3011248 "Гуляние по указателям" в каком-то виде там неизбежно, и проблема как раз в том, что гулять можно только внутри array object, который до C++20 там не создавался.
По-моему, это ты траллишь и стандарт ни разу в жизни не открывал. Я тебе дал ссылку на пропозал в стандарт, который приняли. Там в качестве основного мотива написано, блять, "динамическое конструирование массивов", а ты мне доказываешь, что я шиз. Получается, автор пропозала - тоже шиз и весь комитет заодно.
>>3011378 Тебе автор пропозала написал специально, где там UB. Ты мне всё ещё доказываешь, что _Mylast++ - это не "арифметика указателей", или это уже пройденный этап?
>>3011383 Раст не позволяет напрямую что-то делать с указателями, поэтому пока ты не сделал из него borrow, никаких проблем с элиасингом случиться не может.
>>3011419 > там null Используй нормальные языки на жвм, где null запрещён. > ConcurrentModificationException А что не так с итераторами? В расте они так же кидают панику. Если ты имел в виду потокобезопасность и просто назвал первый попавшийся эксепшен с Concurrent в названии, то в нормальных ЯП на жвм корутины потокобезопасно обращаются к памяти.
>>3011453 А почему я не могу иметь указатель на память, которую собираюсь трогать? Где швабодка, нахуй? Даже в питухоне я могу указателями раскидываться куда угодно.
>>3011475 В жаве такое вылазит, когда пытаешься изменить вектор (List), по которому итерируешь. >расте они так же кидают панику Хуюшки, боровчекер не даст.
>>3011438 >язык с ручным управлением памятью Ну ты чудак, а. Оно не ручное, а автоматическое, просто делается не в рантайме, а при конпеляции.
>>3011475 Когда в языке пятнадцать видов указателей - это не автоматическое управление. RAII до пришествия ржавой сои никто в здравом уме автоматическим управлением памятью не называл.
>>3011453 Боровы живут примерно столько же как мьютекс-локи. То есть нет ситуаций когда ты захватил объект в мапе через get, а после этого рандомный коллбек его затер или удалил.
>>3011497 > только зачем? Чтобы не ебаться с borrow cheсker. Это опять же плохо для читаемости кода, где dependency inversion. Почему Раст вынуждает меня проектировать структуры данных с оглядкой на низкоуровневые вещи и borrow checker, а не как в нормальном ООП - сверху вниз? Даже в крестах это соблюдается - высокоуровневым абстракциям поебать что там с памятью на низком уровне, а раст имеет ебучие деревья лайфтаймов и borrow, идущих снизу.
>>3011511 Можно поебать, как в C++, с ошибками доступа к памяти, можно поебать, как в го, с уборкой мусора, можно поебать, как в свифте, обернув всё в Arc. У всех этих вариантов есть недостатки. Впрочем, где-то я видел опциональное отслеживание владения, то ли в Vale, то ли в Lobster. А может приснилось, не ручаюсь.
>>3011530 Правильно, но вот вопрос: современная джейсоноукладка редуцировалась уже максимально - всю тяжёлую работу делают базы данных. Зачем ебаться с владением, если можно взять язык со сборкой мусора?
>>3011563 Я хочу владеть одним универсальным инструментом "для всего". Чтобы работало быстро, было много сахара и мало ошибок в рантайме, которые, ссук, бесят. Иногда я люблю и пиксели поперекладывать, али какой-нибудь гуй по-быстрому сваять. Боровчекер меня особо не парит, я к нему привык. Не держу постоянно в голове весь набор правил, а примерно чувствую, когда ругнётся, а когда нет. Скажем, адаптировал я тут некий код под обновившийся winit: 98% времени ебался с изменениями апи, 2% засовывал в Arc переменную, на которую заругался боровчекер.
>>3012547 Так-то он всё верно пишет, интерпретатора TS не существует в природе, только компилятор из TS в JS. А ещё для работы с TS надо иметь ебучие комбайны на бэке.
>>3012654 > интерпретатора TS не существует > компилятор из TS в JS существует Он написал, что TS - не ЯП, но TS - ЯП, можно писать и запускать код на нём. Так-то можно про плюсы и джаву сказать, что они не ЯП - джава только в байткод компилится и запускается в интерпретаторе байткода, а плюсы фронтендом gcc/clang в glimpse/llmv-ir компилируются, а в машинные коды их бекенд gcc/llvm компилит. Охуеть тут знатоки собрались.
У меня есть основной поток, в нем запускается тред по конвертации файла и не дожидается окончания, чтоб не блочить основной поток. Можно ли как-то асинхронно пингануть, что поток завершился? Оповещение о окончании операции хочу вернуть, чет не знаю как
>>3014307 В том что ты предлагаешь забивать гвозди кувалдой. А потом и получаются бинарники жирнее шарпа, берёшь либу и каждые 10 строчек кода дают +100 кб к размеру файла.
>>3014319 Активный поллинг редко когда бывает лучше системы сообщений. А реализация его в виде флагов ведёт к большим проблемам при расширении и сопровождении кода. Конечно, если это софт уровня laba3, то это не страшно. Бояться же использовать стандартную библиотеку в расте... ну не знаю, как эта болезнь называется?
>>3014360 >Бояться же использовать стандартную библиотеку в расте... ну не знаю, как эта болезнь называется? Нищессд на 256 гигов - ОС - Какое-то говнецо портированное с плойки = 2 гб на работу.
>>3014360 Чел, для этой задачи достаточно возвращать atomic bool, как это сделано с is_finished. Нахуй ты собираешься прикручивать к этому какую-то синхронизацию потов, ты совсем ебанутый? > Бояться Дело не в боязни, а в использовании инструментов не по назначению. В каналы лезет что угодно - значит будем не думая пихать в них всё что можно. Ну ахуеть теперь.
>>3014371 Повторю ещё раз, это решение более расширяемое и лёгкое в сопровождении. Код с флагами это очень хрупкая конструкция. Изначально в >>3013454 анон хочет вернуть оповещение обо окончании операции конвертации файла. Через некоторое время ему захочется отображать её прогресс (кстати, я думаю, что ему именно для этого и ищет неблокирующую проверку, уверен на 80%, в противном случае хватило бы простого джойна). Потом потребуется добавить функционал паузы/возобновления. Потом придёт в голову обработка сразу множества файлов. Потом возможность изменять очередь файлов на лету. Потом делать это не в отдельном потоке, а отдельном процессе или даже на другой машине. А может делать конвертацию сразу в несколько потоков. Можно ли это всё сделать на флагах? Безусловно. Но это будет выглядеть как лапша с миллионом условий и иметь множество трудновоспроизводимых багов.
Понимаю, что это выглядит как какая-то блажь, но я имел счастье поработать над проектами с обоими подходами и поэтому хочется поделится опытом. Хз конечно, насколько оно релевантен конечно, т.к. описании задачи без деталей, не исключаю что каналы будут over-engineered, но уж больно красных флагов для меня, простите за каламбур.
>>3014414 > более расширяемое Но ведь у тебя должно быть чёткое API. Конкретно этот кусок будет отвечать за понимание состояния выполнения операции. Ты туда собрался что-то ещё прикрутить? Тогда это вдвойне пиздец. > Через некоторое время ему захочется Тогда и надо делать это расширяя API, а не изменяя его. Нет ни одной причины зачем надо переусложнять то что можно сделать просто. > Можно ли это всё сделать на флагах? Как будет подходящая задача под каналы, так и надо их применять. Что за бинарное мышление - мы либо пердолимся с примитивами и флагами, либо каналы для всего. Так можно и до уровня Линуса дорасти, когда будем сетевой стек использовать для коммуникации - там вообще сказка, отправляй что угодно куда угодно.
>>3014451 О, началась моя любимая игра: "выдели каждое утверждение собеседника гринтекстом и доведи его до абсурда". Без дополнительных пояснений со стороны >>3013454 плюсы и минусы в данной конкретной ситуации обсуждать довольно бессмысленно. С позицией, что лучшее враг хорошего я в целом согласен.
>>3014451 >> более расширяемое >Но ведь у тебя должно быть чёткое API. Конкретно этот кусок будет отвечать за понимание состояния выполнения операции. Ты туда собрался что-то ещё прикрутить? Тогда это вдвойне пиздец. И да, а что тебя удивляет? В расте это можно сделать очень тупо. Заводишь енум под сообщения, который расширяется при необходимости. В основном цикле просто диспатчишь варианты. Классический паттерн наблюдатель, только без полиморфизма в рантайме. Но и его легко добавить при необходимости.
Аноны, полегче. Жене надо по работе конвертировать видеофайл в mp4 и я решил просто попробовать сделать на расте это, вместо своего основного языка. Для нее терминал - дебри, поэтому взял tauri + ffmpeg_sidecar. У последнего при выполнении спавнится дочерний тред. Вот мне и хотелось узнать, как из него эмит сделать. Ну как передать его назад я знаю, а получить подтверждение окончания операции не знал как. Ни прогресс баров, ни множественной обработки или еще чего.
>>3014603 Глянул быстренько этот ffmpeg_sidecar. Там в отдельном потоке парсится выхлоп ffmpeg, который оборачивается в варианты енума FfmpegEvent и передаются через каналы с помощью итератора в основной тред, лул. Что и требовалось доказать в общем-то, тупо то, о чем я писал выше. Тебе нужно обработать cобытие Done.
>>3014778 В плане? >>3014781 Угу, то ли дело святые плюсы. Сказать-то что хотел? Хотя я использование for_each() тоже нахожу неуместным. Алсо, за те полгода, что я имею дело с растом, ни разу подобных ассоциаций не возникало. Ты сходи на улицу, потрогай снег что-ли, слишком много на дваче сидишь.
>>3014877 > плюсы Тут недавно на концепты гнали и говорили что не понятно что там за типы, а вот ты можешь догадаться что тут между точками за хуита? Так что это ещё открытый вопрос где хуже. Ну и на твоём пике вермишель типов убирается через using, так же как в расте c use.
>>3014885 Так там написано сверху, что это Builder API, поэтому очевидно, что &mut FfmpegCommand (ну кроме последних двух, конечно, по ним нужно документацию смотреть, особенно iter() возвращающий Result меня с толку сбивает). Но это и без комментария в принципе видно по характерному коду. Это характерный для раста паттерн, потому что нет дефолтных параметров. Вот, просвещайся, если интересно: https://rust-unofficial.github.io/patterns/patterns/creational/builder.html
>>3014894 > очевидно > кроме последних двух И что тебе там очевидно? Начиная со spawn там идёт пляска разных типов, а заканчивается обработкой событий. Хороший паттерн, который плавно перетекает в кашу из типов.
>>3014781 Всё таки раст пидорасты писали, ведь могли сделать простой и понятный язык с бч, но нет, хлебом не корми, надо было завалить всё свистелками и перделками в угоду читаемости. Тупо дебичи.
>>3015256 Ебать, ты довнич, а. Точно такой же код можно соорудить на котлине, например. Билдер-хуилдер-матчер. И выглядеть будет также. Вот автор этой конкретной либы решил сделать так, ты чего бухтишь-то? Это современное программирование, не осилил - обтекай.
>>3014959 Ну это вопрос к конкретному автору. В принципе, он делал по аналогии с std::process::command, который из spawn() возвращает Child обёрнутый в Result. На самом деле, под капотом именно это у него и происходит. Только вот FfmpegChild, в отличии от Child из стандартной библиотеки не конечный тип сам по себе, а ещё позволяет создать итератор, чтобы получать оповещения о работе ffmpeg. Собственно, в этом вся суть этого крейта, которая в двух строчках описания указана. Поэтому при её использовании всегда эти две последние строчки будут (я бы ещё wait() вызвал, чтобы зомби-процесс почистить в конце), а перед ними борода из сколько угодно вызовов билдера. Хз, в целом прикольно. Причём при желании, это можно написать в классическом виде, привычном джавистам и плюсовикам, т.е. создать "объект" FfmpegCommand и по очереди вызывать его методы, а потом получить отдельно "объекты" FfmpegChild и FfmpegIterator. Но зачем?
>>3015287 >язык позволяет делать говно, значит, язык - говно (c) растопидораха >поправка: работает только в одну сторону (верно для с/с++, не верно для раста) ))
>>3018439 > Zed Выглядит как хуйня. VS Code хорош именно электроном, который позволяет новые фичи/экстеншоны пилить хуяк-хуяк и готово. Поэтому функционал у него ахуевший и гуй красивый с кучей удобств. А на скорость поебать, кому какое дело что раст на 40% быстрее текст жуёт.
>>3018522 У вскода всратая интроспекция, вот это всё. А идейка память жрёт и фризит на больших проектах. Я надеюсь, что может хоть тут растаны сделают хороший редактор для раста. А то впадлу жидбрейнсу платить, когда они ровер этот платным сделают.
>>3018538 Всё равно нахуй не нужно, пока опенсорс-пердолики не сделают аналог этого - https://continue.dev/ С нейросеткой хоть поприятнее, когда всратые скобочки лесенкой за тебя сами рисуются.
Они есть, но походу, тоже на расте. С другой стороны, если во главу угла ставить скорость, то будет странно добавлять расширения на скриптах. Хотя, есть тот же самый rhai.rs, можно будет добавить икстеншон уже с его поддержкой для быстрого прототипирования (у него синтаксис максимально близок к расту).
>>3019996 Не хотели раньше времени принимать патчи для поддержки линуха и винды. А если не принимать, то сообщество захейтит нежных и ранимых поняшек.
>>3020057 Следи за руками: - фряха - основа для макоси и спонсируется эппл - часть компонентов фряхи собрались переписать на расте - кода этого зеда наворотили с моё почтение, прям серьёзно взялись - тут явно не обошлось без щедрого спонсорства - зед прибит гвоздями к макоси на низком уровне, там свой ui поверх metal (https://github.com/zed-industries/zed/blob/main/crates/gpui/src/platform/mac/metal_renderer.rs) - догадайтесь, кто спонсор там всё настолько плохо, что, мне кажется, проще будет сделать форк на egui, чем добавлять поддержку Vulkan/OpenGL
В-общем, эппл тоже присматривается к расту. Одним свифтом сыт не будешь, шланг слегка устарел, собсно, вывод очевиден.
>>3020143 > Вскрылось интересное про zigунов. Там нечему вскрываться. Вместо того чтобы зарелизить 1.0 зига под x86 для линукса/винды и потом уже пердолить зоопарк платформ, эти дебилы пишут и под MIPS компилятор, и под арм с макосью, и ещё хуй знает что. Переписывают libc, LLVM и вообще занимаются неизвестно чем. В итоге версии апают, а язык всё так же сырое говно с мерзотным синтаксисом, не исправляющий никаких проблем сишки. Даже встроили компилятор крестов и называют его "лучшей заменой clang", но по факту это такое пердольное говно со скриптами сборки на самом зиге, что пиздец. Ну и бонусом идут разрабы этого кала - идейные борцы за мазоли Столмана, у которых идеология на первом месте, я уже видел васеры Эндрю про швабодку он даже из ютуба выпилился потому что "несвободная платформа", сразу стало понятно что он за ЯП придумал. Хули ещё можно было ждать от чела, живущего в кладовке, проецирует комплексы куда может. > Они знают раст А ведь Эндрю высрал зиг потому что бомбанул от того какой раст говно. Уже даже мазолееды забыли за что боролись.
>>3020316 Ну лан, ну лан, всё же так красиво сходится. У нас нет 100% сведения, эппл молчит, но выглядит всё так, будто они таки тянут свои лапки к расту. Бсдуны как-бы сами решили попереписывать на расте, зед как-бы случайно написали плотно так онли под макось.
>>3020165 > Ну и бонусом идут разрабы этого кала - идейные борцы за мазоли Столмана, Ну да, куда лучше успешные менеджеры, которые доят натянутую сову 9 лет. Без опенсорса, сосали вы бы сейчас бибу у пропретарного софта с платными закрытыми либами, а не няшились на гитхабе.
>>3020165 >>3020143 Забавно как ржавые стали бояться зиг, а ведь еще полгода назад даже не замечали его.
Раст, имхо, очень сильно тормозит разработку, дальше хелловорда он тупа неудобен. Единственный выигрыш это встроенный пакетный тулинг, что облегчает вкат всяким петонщикам, больше плюсов там особо нет.
>>3020600 >дальше хелловорда он тупа неудобен Аха, бля. Нам ведь надо быстро и мноога говна наваять. А потом отдать на аутсорс, пусть галерщики ошибки фиксят. Стандартная тема на тех же плюсах плюсах, никто не жалуется, нах здесь раст, действительно.
>>3020600 >бояться зиг Ты это, уже сразу новость кидай куда-нить в зиг-сообщество: растаны боятся зигунов, чтобы зиг-воены воодушевились и, ну я не знаю, переписали на зиг alacritty, например.
>>3020865 Всему своя цена, если кабану нужно качество, кабан платит временем и деньгами, тебе какая разница, раст тут ничем не поможет вообще. А вот платить больше за одну и ту же работу и тем более сопровождать, это уже другое. Раст не отменяет ошибок, в управляемых языках тоже нет проблем с памятью, стало там меньше багов?
>>3020907 >стало там меньше багов Итить, ну конечно стало.
> если кабану нужно качество, кабан платит временем и деньгами Вот только ручное управление даёт очень мало гарантий качества - придётся платить ораве тестировщиков. К тому же, в том и смысл раста, что качественно на нём писать дешевле и быстрее, чем на тех же плюсах. Просто потому, что проще сразу не ошибаться, что перелопачивать потом половину кода из-за ошибки. И ты прикинь, бывают такие проекты, которые не "написал и забыл", постоянно в разработке, обрастают новыми фичами и тэ-дэ. И такое проще допиливать на расте, чем постоянно подрываться на оставленных хуй пойми когда минах.
>>3020948 Кто сейчас из вменяемых пишет промышленный код на плюсах? Что мне даст твой раст, если перформанс топ веб-серверов отличается лишь на 0,01%, а траха там на порядок больше?
Кому ты это хочешь "продать"? Ну и код менее читабельнее чем на сях, да еще бытует мнение, что пишут на расте медленнее чем на си.
>>3021127 Дотнет ахуенен, и АОТ тоже. Но эти пидоры вообще ложат хуй на совместимость со старыми системами, самое хуёвое что они 32-бита дропнули, это вообще пиздос.
>>3021082 Раст среди этих всех языков: 1. Самый безопасный 2. Один из самых выразительных (возможно в C# плюшек больше, зато в расте нет null) 3. Один из самых кроссплатформенных - от утюга до браузера. 4. Тулинг вне конкуренции.
>бытует мнение, что пишут на расте медленнее чем на си Среди сишников-неосиляторов оно бытует. Разрабы TOR его сами на раст переписывают, в том числе ради более быстрой разработки.
>>3021153 Не ас шарпов, но писал оконную перделку для 7 винды, так в общем, писал на последней версии шарпов, а потом просто под дотнет 6 собрал. Разве нельзя так же делать?
>2. Один из самых выразительных (возможно в C# плюшек больше, зато в расте нет null) Котлиновский вопросик для типов, куда круче и современнее костылей опшинов (да, в шарпах нуллабл типы накатили давно, даже в дарте завезли).
>3. Один из самых кроссплатформенных - от утюга до браузера. На 98 винде запущу? Но я уверен что все ограниченно llvm или только популярными платформами, и скорее только словами, ибо кто там тебе будет тестить, там надо бюджеты усваивать.
>4. Тулинг вне конкуренции. Пакетный менеджер, этим даже гоферку не удивишь.
>в том числе ради более быстрой разработки. Фанатики даже на го большие приложения клепают, но это не делает го удобным для этого.
>>3021230 > Разве нельзя так же делать? AOT в принципе только под х64. Весь смысл пропадает, ведь экономить ОЗУ и размер бинарника обычно надо на некрожелезе. Вообще у майков очень много чего находится хуй знает сколько лет в разработке с отмазкой "низкий приоритет". Им-то похуй в своих облаках, всегда свежая ось.
>>3021292 На работке пара тысяч клиентских 2гига/2ядра стоят на объектах, инцел атомы/целероны, везде 32-битная десятка. Я в итоге на крестах пердолю автоматизацию, ибо ещё надо защищаться от сисадминов/подрядчиков/инженеров, которые увидев неведомую хуйню, жрущую 100 мб ОЗУ, могут её просто ёбнуть по-тихому, чтобы им оно не мешало ковыряться в и так тормозящем кале.
>>3021313 Так в случае aot как раз и будет все в одном месте и за сотню метров, а когда вирт машина, она просто будет сбоку, а твой процесс будет весить копейки. Можно даже под старый фреймворк 4 собрать, чтоб не светить последний рантайм.
А раст хорош. Я ради интереса написал простенький тайм сервер, который по tcp возвращает текущее время. Сделал на си и на расте. Проверил через apache benchmark 1 лям запросов в 20 потоках. Однопоточный сервер на clang выдал 37к rps, многопоточный раст на токио 34к лол, однопоточный на расте 41к. Токио оказалось хуйней, компилятор раста охуенен.
2. > Котлиновский вопросик Нуу, такое себе, такой же используется в Vala, например. Также см. пик: в котлине это ворнинг, в расте сравнение с None будет ошибкой. И котлин сливает по скорости и ресурсам.
3. > На 98 винде запущу? Код на плюсах на /360 мейнфрейме запущу?
4. > Пакетный менеджер > go Какой-то он хреновенький. Модуль добавить, прям целое колдунство. И логика импорта завязана на версию языка, что ломает совместимость. А какой-то общий способ указать фичи для модулей есть? Сомневаюсь. Ну это я так, погуглил, не вдаваясь.
>Фанатики Вот ты поясни, как разрабы TOR, которые всю жизнь писали на сях, вдруг стали фанатами раста. Для крупного проекта важный критерий - это контроль, чтобы конструкция не рассыпалась. Поэтому, например, в своё время так зашла Java, что она этот контроль давала. А python не давал, хотя хэлловорлды на нём писать в 10 раз быстрее. В расте контроль строже, чем в джаве, следовательно, на нём удобно писать ещё более крупные проекты.
>>3021532 Токио хорошая вещь, но для других задач. Например, у тебя веб-сервер общего назначения, который и в базу слазит, и картинку отдаст. Токио тут и пригодится: пока один клиент ждёт свой запрос из базы, другой в это время получит свою картинку.
Ещё попробуй такую аннотацию, може увеличит чего #[tokio::main(flavor = "multi_thread", worker_threads = 8)]
>>3021634 > в котлине это ворнинг В чём проблема? Он тебе и пишет, что он всегда не null. А String? ты не сможешь присвоить к переменной String без явного каста с рантаймчеком. Никаких проблем с безопасностью нет, тем более вопросик можно выключить на уровне компилятора. > в расте сравнение с None будет ошибкой Ты тёплое с мягким сравниваешь - null с енумом. Сравнивай тогда котлиновские енумы, там тоже String и None не сможешь сравнить потому что разные типы.
>>3021663 >В чём проблема? Проблема в том, что когда переменная вдруг перестанет быть nullable, на этот кусок кода можно просто забить. Это безопасно, по поощряет распиздяйство.
>котлиновские енумы не поддерживают вопросик, ха-ха.
В плане работы с отсутствующим значением котлин, конечно, далеко ушёл от жабы, но чутка не дотягивает до раста. А на расте есть ещё и Result, тоже с поддержкой вопросиков. Вот и получается, что раст, помимо того, что быстрее и экономнее по памяти, ещё и продвинутее по семантике.
>>3021690 > Result, тоже с поддержкой вопросиков Лучше бы ты не вспоминал этот кал, не умеющий кастовать Ок к Ок, ахуеть какая продвинутая семантика. Даже эксепшены лучше.
>>3021657 Результат тот же. Видимо, зависит от машины, я тестирую на линуксе под виртуалкой, у нее 1 проц 4 ядра. Ради интереса добавил голанг, с корутинами он выдал 35к рпс, без корутин еще меньше.
>>3021695 >не умеющий кастовать Ок к Ок Ну-ка, поясни. Типа, Ok(u32) as Ok(u64) или что?
>эксепшены Фу, фу, никакого сравнения. Для Result и Option в расте есть куча функционального сахара, хошь так ими верти, хошь эдак, хошь одно в другое, а хошь - в итераторе filter_map и прочее кастуй.
>>3021708 > хошь так ими верти, хошь эдак А почему если у меня есть Result и CustomResult, то я должен вручную обрабатывать Ок и Error? С эксепшенами если всё Ок, то я вообще ничего не должен делать, совсем. И в случае Error я могу проигнорить что за ошибка конкретно случилась и обработать сам факт ошибки. В то же время раст заставляет ебаться каждый раз с этим говном, а если там разные типы Result, то вообще пиздец хуже кодов ошибки из сишки. > в итераторе filter_map и прочее кастуй Заебись, но я всё ещё не понимаю зачем всё это надо делать вручную с заведомо идентичными Ок. Совсем не чувствую сахара. Получается больше ебли без причины - это сахар и гибкость? Ведь по факту в расте на уровне языка в принципе нет функционала для работы с ошибками, только через енум-костыли с Result, отличающиеся от кодов ошибки в сишке только тем что туда прилепили непосредственно результат. Как в сишке делали if (result != SUCCES), так и тут та же срань с явной обработкой, только покороче.
>>3021721 > С эксепшенами если всё Ок, то я вообще ничего не должен делать, совсем Ты никогда не отлаживал код, в котором ловится ". . ." в какой-то жопе, да?
>>3021721 >я должен вручную обрабатывать Ок и Error Ставь .unwrap() для паники или пробрасывай наверх через ? для дальнейшей обработки. Ты, видимо, совсем не в теме.
>И в случае Error я могу проигнорить что за ошибка конкретно случилась и обработать сам факт ошибки И тут ты тоже можешь, прикинь. Есть такой метод Result::is_err() Точно не в теме, залётный.
> Как в сишке делали if (result != SUCCES) Ебать, ты даун, слов нет. В сишке при таком подходе ты возвращаешь код в одном месте, результат по указателю в другом месте. Тебя никто не обязывает проверять код, ты можешь просто забить и пойти использовать результат, хотя там может оказаться что угодно. В расте ты получаешь явно - или результат, или ошибку, что-то одно.
>>3021730 Если в кишках либы сломалось что-то, то ты и в расте заебёшься дебажить unwrap(). >>3021734 > Ставь .unwrap() Заебись, будем ронять весь код, безопасность чувствую прям. > пробрасывай наверх через ? Только если типы одинаковые, если нет, то ты идёшь нахуй со своим вопросиком и пиздуешь свитчевать эту парашу. И так каждый раз, пока код не превратится в пилу из лесенок. > Result::is_err() Я надеюсь ты траллишь, потому что это как в сишке с if (result != SUCCES), только ты предлагаешь if result.is_err(). > Тебя никто не обязывает В крестах ты варнинг получишь. Получается разница лишь в том что в расте кодера держат за конченого долбаёба, неспособного прочитать что компилятор пишет?
>>3021740 >Только если типы одинаковые Тут есть варианты: 1. Сделать общий enum для всех ошибок, руками или через custom_error, тогда ? будет работать для всех ошибок 2. Через map_err приводить всё к общему типу ошибки. Можно вообще сделать Result<T, String> и кастовать все ошибки внутри функции в строку.
>и пиздуешь свитчевать эту парашу точно также, как с иксепшонами - однажды придётся свичевать
>В крестах ты варнинг получишь. Ебать, какая эвристика, конпелятор видит, что функция получает указатель и возвращает int и на этом основании как-бы предполагает, что в неиспользуемом инте могло быть что-то важное. А могло и не быть, может там текущая погода в градусах, правда? Ну и пиши сразу на асме тогда, ты же знаешь, что там у тебя по регистрам распихано.
>>3021949 Что проще: отловить возможную гонку на этапе конпеляции или ебаться с этой гонкой через год, когда она появится из-за кривизны кода? Под не ошибаться сразу я имел в виду первый вариант.
>>3021824 Для всех этих махинаций давно существуют 2 крейта - thiserror и anyhow. С первым ты пишешь конвертеры ошибок одной строчкой, со вторым можешь вообще нихуя не писать, он сконтвертирует как сможет и пох.
>>3022710 Вот идейка с дефолтными настройками. Только var/val подсветила. Постоянно забываю, что val в котлине такой же неполноценный, как жс - val нельзя перезаписать, но можно добавить значений в список, например
>>3023602 Пиздос он ебало отожрал. Хорошо хоть не из кладовки стримит, видимо надонатили достаточно. Слушать не собираюсь, он сказал когда 1.0 планируют? К 0.99 хоть успеют, а то на гитхабе уже issues до 0.16 на год вперёд отложенные валяются?
>>3023460 Изменение списка внутри итератора по этому списку не подсвечивает, а это главное.
>>3023540 А он, что val, что var, всё равно мутабелится. Это ж котлин. >Котлин плохой. Ты ж сам его знаешь меньше моего, довнич, откуда тебе знать, что он хороший?
>>3023967 Ты настолько тупой, что требуешь подсветки синтаксиса момента исполнения? Я уверен он это и делает в момент исключения, тыкает носом, что не так.
Котлин и так долго компилится и эти проверки в момент компиляции были бы очень дорогими и возможно не достижимыми. Если ты берешь управляемый язык, то меньшее что хочется это долгая компиляция. Все равно любое приложение крупнее утилиты линукс будет иметь дело с динамическим внешним миром, такова цена и таков путь приложений.
>>3023993 Я пруфаю то, что на управляемом языке можно сесть в лужу там, где нельзя на расте, причём не будет даже ворнинга. Не больше, не меньше.
>>3023997 Жвм, это среда исполнения, да. И? У сишки и раста тоже одинаковая среда исполнения, как у жабы с котлином, но это не мешает расту отлавливать такие ошибки на этапе конпиляции, а вот котлину что-то мешает.
>>3024116 >Я пруфаю то, что на управляемом языке можно сесть в лужу там, где нельзя на расте, причём не будет даже ворнинга. Не больше, не меньше. Зато есть еще 100500 способов сесть в лужу обоим языкам, динамические системы никто не отменял. То что у тебя компиляция дольше, такая себе радость, если бы взял иммутабельный тип, котлин вообще бы не дал тебе методов импакта и не нужно оверхеда с анализом кода.
>>3024187 >иммутабельный тип Но я хочу мутабельный, но что-то подобосрался слегка. А код, который меняет лист, срабатывает по if раз в полгода. Расставил, значит, везде перехваты всего, что можно, попиваешь кофий, сервис тебе ошибочки в телегу шлёт, чуствуешь себя владыкой, а тут хуяк - и нежданчик, всё упало, и ты об этом узнаёшь от кабанчика. На расте такого не будет - если ты перехватываешь ошибки, то они таки перехватятся. Может упасть сторонняя либа, ну дак пользуйся хорошими либами с пробросом ошибок.
>>3024232 > Но я хочу мутабельный Я тоже хочу мутабельный в расте, но он говорит "пошёл нахуй теперь вектор иммутабельный", даже если объявлен как мутабельный. Я даже не знаю кем надо быть, чтоб топить за такие анальные унижения. При этом в джаваговне всё же можно через .next() сделать мутабельную итерацию, в отличии от раста, где тебя ставят перед фактом что ты идёшь нахуй.
>>3024245 Надо для вас какой-то клуб униженных растом организовать. Где бы вы делились своей болью, как хотели отстрелить себе хер на полшишечки, а раст не дал.
Во-первых, goвно взлетело потому же, почему взлетел swift. Поддержка крупной корпорации.
Во-вторых, он очень лёгок в изучении и на него может переползти любая макака с php/python в анамнезе. Причём, эта фича, лёгкость освоения и переползания, очень активно форсилась с самого появления языка "Мы, гугл, пилим простой и быстрый язык для макак и будем его поддерживать." Раст, наоборот, сразу отпугивает "У нас сложно, зато безопасно". На самом деле человеку, не испорченному сишкой, а переползающему, скажем, с джавы/питона, раст не покажется таким уж сложным, каким его малюют сишники, мыслящие арифметикой указателей.
В-третьих, есть фактор сферы применения. Go - хороший язык для стартаперов, так если Вася знает питон, а Петя джаву, то стартап им проще будет пилить на го. Сфера стартапов очень бурная, один лопнул - два появилось, поэтому goвно поражает этот мир со скоростью коронавируса. Раст же затрагивает несколько более медленную сферу - к нему приходят состоявшиеся стартапы, которые понимают, что питона/жабы/го им уже мало, а сишка отстало и небезопасно.
Поэтому расклад примерно такой: го - это быстрая и мимолётная сезонная инфлюэнса, а раст - это вич, который медленно, но верно и надолго.
Я прикладная макака - заводчанин, хочу пощупать раст, чисто для себя, интересна вся эта низкоуровневая тема. Где взять идею для такого низкоуровневого ПЕТ-проекта? Ну либо посоветуйте что можно навоять вечерами под пивко
>>3024825 Караван охуительных историй. Раст не взетел потому, что нахуй не нужен. Для прикладного программирования он слишко засран наркоманскими абстракциями, это место у параши уже занято плюсами. Для системного программирования ты не можешь просто взять и написать код, как на сишке, ты долго и нудно ебешься с бороу чекером, а потом все равно ныряешь в unsafe. В итоге получилось говно без задач.
>>3025321 >Для прикладного программирования Он очень хорошо подходит и изначально задумывался
>это место у параши уже занято плюсами хуёво занято, иначе не появились бы жава с сисярпом, которые часть проблем решают, но не вполне, а также добавляют новых. Раст, это ультимативное решение проблем плюсов в прикладном направлении, единственное "но" - хватило бы мозгов. Мне хватает, я пользуюсь.
>>3025100 Уже поддерживают, но робко и неуверенно - переписывают по кусочкам.
Языку сколько лет вообще, стабильной его версии особенно? Комьюнити у раста пиздец какое огромное, реддит открой, ебанько. То что в рашке работы нихуя нет - не значит что он не используется нигде вообще и не взлетел.
Раст засунули в винду и ядро линупса. Всё только начинается вкачусь сразу как появится немного свободного времени
>>3025124 Для проекта сперва должна быть идея, а уж потом инструмент. Если идей нет, то попробуй что-то связанное с графикой/играми. Для обучения эта тема хорошо подходит, так как даёт мгновенный дофамин: накодил, увидел результат, кодишь дальше.
>>3025681 Ну хз, девятый год после релиза, интерес околонулевой, несмотря на количество навязчивого маркетинга (купленных постов и видео). В том году даже начали работать на джаваскрипт аудиторию, что совсем смешно. И вот после этого всего мы видим такое явление и такой абсурд, как фанбой пытается сравнивать раст и котлин.
Так что не все однозначно, но слежу за яп, любой язык победивший си и плюсы будет у меня в фаворитах.
>>3026040 Конечно до питона и других титанов ему далеко. Он никуда туда не заберется.
Но я бы не стал называть язык мертвым хотя бы потому что вокруг языка сложилось больше комьюнити.
то что языку потребуется больше времени, чтобы набрать критическую массу - факт. На рынке уже больше 40 лет доминируют си и плюсы, а системное программирование, в общем и целом, не самое популярное сейчас направление.
Да и честно говоря писать на языках из твоего топа я ни за что не хотел бы. Ну разве только на гоупараше ок.
>>3025681 Лол ты даун. Вакансии открой, ебанько, а не раковый чятик с фурипидорасами. Вот когда найдешь работу на расте никогда тогда и приходи. Ты напоминаешь фанатов лиспа, те тоже рассказывают, как лисп скоро взлетит, вот еще немного и огого.
>>3025321 >а потом все равно ныряешь в unsafe Но ведь адепты сказали, что раст безопасен, можно сразу без ошибок писать ПРОЩЕ ЖЕ. >>3026459 >Бля, приятный язык Пикрил.
>>3026842 >>3027794 Плюсовики пугали выводом ошибок, растеры пугают сигнатурами функций. Вы в курсе, что мы читаем код больше чем пишем? Как это сопровождать, если тело функции проще сигнатуры?
>>3027821 В общем, сторонние челы переписывают у себя что-то в облаке, но деврелы уже накатили/купили статью на целое переписывания ядра винды. Какой же сюр.
>>3027805 Так это по сути сигнатура не функции, а обобщения. Поэтому такая сложная. Если написать функцию с конкретными типами всё станет просто и понятно. Собственно, по той же причине в плюсах такие монструозные ошибки - из-за шаблонов. Ну и конкретно этот пример мне кажется довольно легко читаемым.
Тут надо отделять 3 вещи: 1. Раст как язык - пригоден даже для разработки ядра. 2. Тулинг и инфраструктуру - а. проблема leftpad Ответ - используйте свои крейты/форки, где это возможно, сделайте свою репу и отзеркаливайте на ней надёжные версии крейтов. б. Тяжёлый и дорогой бутстрап. Увы, ментейнёров у них маловато, а без бутстрапа там никак. Ответ - продайте почку. 3. Реализацию async Тут скорее проблема рантайма. Напишите свой, заточенный под FreeBSD, рантайм и используйте его в своих утилитах сколько угодно. Или вообще обходитесь без асинхронности, никто не заставляет, действительно.
>>3027930 Забавно, что к С++23 внезапно оказывается что кресты победили почти все свои недостатки и на кресты больше надежд чем на раст. >>3028000 > проблема leftpad Она вообще не решаема. Тут уже жаловались что хэллоу-ворлд жрёт 150 кб. У самого стд куча зависимостей. Если взять любую низкоуровневую либу - там 25 зависимостей. Удобный пакетный менеджер сделал только хуже, все просто прописывают тонну зависимостей в карго и ебись оно конём. Тут только писать в но_стд и фактически выкидывать абсолютно всю, почти 10-летнюю, кодовую базу раста. > Тут скорее проблема рантайма. Напишите свой Получается проще свой раст написать, чем на уже существующем что-то делать.
>>3028025 >Получается проще свой раст написать Я про асинхронный рантайм, полно альтернатив тому же токио.
>Удобный пакетный менеджер сделал только хуже, все просто прописывают тонну зависимостей в карго и ебись оно конём хуже чем что? Чем приписывание зависимостей через git submodule или чем зависимость от системной либы, которая ещё может оказаться не той версии? Или чем банальное Ctrl+C/Ctrl+V, как сделано в ffmpeg, например ?
>>3028050 > Я про асинхронный рантайм, полно альтернатив тому же токио. Проблема не в конкретном рантайме, а в том что асинхронность в принципе существует в том виде как она придумана в расте. https://blog.hugpoint.tech/avoid_async_rust.html > хуже чем что? Чем осмысленный выбор зависимостей для проекта, а не забивание хуя и добавление вообще всего что можно. > проблема leftpad таким образом решаема Ты похоже не понимаешь в чём проблема. > раст позволяет дёргать отдельные куски из стд Нет. А даже если научится делать это адекватно, то это всё ещё не убирает кучу зависимостей для сборки стд. Я тебе больше скажу, в последней версии раста со свежим майковским тулчейном раст вообще не может собрать бинарник без стд в релизе, только в дебаге, лол. Issue по этой же проблеме ошибки линковки без стд есть на гитхабе, закрыт как решёный два года назад, блять.
> осмысленный выбор зависимостей для проекта "Ваши плюсы, плюсы?" - "У нас нет пакетного менеджера!" - "Какой же в этом плюс?" - "Подбирать зависимость будете долго и обстоятельно, а не пихать всё подряд". Ну пиздец.
>Ты похоже не понимаешь в чём проблема. Ты, похоже, не понимаешь, в чём решение.
>>3028076 Этот код всего лишь берет строку "key=value" и возвращает пару строк (key,value). Задача тривиальная, но на расте насрали буковками просто чтобы было.
>>3028085 > на пути к решению Не вижу решения ни одного пункта из приведённой ссылки. Ты читать умеешь хоть? Решение может быть только одно - выкинуть асинхронщину, а не добавлять ещё больше, как ты тащишь в пример. Единственное применение асинхронщины по назначению - однопоточные системы, где нет многопоточности и надо её как-то эмулировать. Собственно в крестах асинхронщина только для этого и используется. > Ну пиздец. Ты жопой не виляй. Есть проблема с зависимостями, от того что ты попытаешься перевести стрелки на кресты она не пропадёт. > unstable.html#build-std-features Чел, сборка std из исходников ничего не режет, -Zbuild-std:std соберёт полный std, а других вариантов нет. Разницу можно получить лишь собрав std с оптимизациями на размер, а не как оно собрано по умолчанию на скорость. > Юзай гнутый x86_64-pc-windows-gnu Проще вообще не использовать раст. В этом говне постоянно всё разваливается. На гну новая ебота будет из-за левого тулчейна, он ещё и порт libc наверняка потащит с собой.
>>3028076 >Вообще хер знает, зачем ему Box, Sync и Send. >>3028192 Разобрался. Потому что трейт From<String> имплементирован только для Box<dyn Error> и Box<dyn Error + Send + Sync>. Поэтому подходит только второй вариант, если функцию предполагается использовать многопоточном окружении.
>>3028102 >Не вижу решения ни одного пункта из приведённой ссылки. В глаза ебёшься >Still no async closures. Quite painful when you need to move stuff into it.
>Единственное применение асинхронщины по назначению Нет. Рядовой пример: веб-сервер со 100500 медленными клиентами. На тредах ты отожрёшь слишком много ресурсов.
>Есть проблема с зависимостями У раста нет проблемы с зависимостями. Можешь использовать хоть cmake и линковаться с чем угодно и как угодно.
>>3028102 >сборка std из исходников ничего не режет ну, используй prefer-dynamic, чо.
>>3028234 >Рядовой пример: веб-сервер со 100500 медленными клиентами. На тредах ты отожрёшь слишком много ресурсов. Для защиты от ддоса ставят прокси. Асинхронная параша в виде корутин - это медленное говно, просто мода сейчас такая, все его форсят. Когда-то все надрачивали на ооп и наворачивали абстрактные фабрики абстрактных фабрик, сейчас бесятся с асинками, это пройдет. Для хай перфоманс задач быстрее всего работает, внезапно, однопоточный сервер, который просто ставит вызовы в очередь io_uring.
>>3028234 > На тредах ты отожрёшь слишком много ресурсов. Сразу видно что ты не умеешь в многопоточность, вот такие дауны и лепят потом тормозящее говно на асинхронности. > prefer-dynamic Работает только под линуксом.
>>3028307 >Для защиты от ддоса ставят прокси. Сразу видно, что ты не потратил 5 лет жизни на администрирование хостинга. Сервер может быть какой угодно: pop3/imap, smtp, ftp. А ещё может случиться медленная отдача от сервера БД, где асинхрон тоже не помешает.
>Асинхронная параша в виде корутин Это универсальное кроссплатформенное говно, которое работает с любым медленным ио.
>io_uring >Работает только под линуксом.
>>3028346 >Сразу видно что ты не умеешь в многопоточность Ебать, а ты у мамы умелец, да? Ну, сходи, скушай блинчик.
>>3029032 Все правильно сказал. Макросы - это пиздец, каждый первый автор изобретает свой язык. Crates.io - тупо список функций, который в нормальных языках и так показывает в иде, еще полтора примера, которые в 95% устаревшие и не компилируются. На каждую мелочь приходится гуглить примеры и лазить по гитам с исходниками. Каждый мудак обязательно пытается высрать декларативный код на шаблонах, хоть там задача на две строки. Я бы посоветовал тому анону попробовать сишарп, а не нырять в говно.
>>3029032 Ничего нового он не сказал, основная претензия по вакансиям. Поест говна какое-то время, потом встретит нормальную вакансию на расте и перекатится обратно. А вот это >клепают БПЛА уже интересно. Также интересно, на чём пишут софт для дронов уважаемые западные партнёры.