В этом ИТТ мы можем объяснить базовые и продвинутые концепции языка, и программирования в целом, поможем вкатывающимся, подскажем что выбрать для веба, игр или, прости Абу, блокчейна.
>>2800775 Только не это... как я заебался из треда в тред читать одно и то же - обсуждения ненужности раста, "маркетинга", трансов. Вот бы больше анонов пишущих в продакшен на расте рассказывали про работу, сложности с которыми сталкиваются, наблюдения свои какие-то, всё такое
>>2800806 >Вот бы больше анонов пишущих в продакшен на расте рассказывали про работу А чего рассказывать, пишем бекенд микросервисы. Actix, sqlx, lapin, tokio, serde. RPS небольшой, но у нас работают парсеры которые много html говна и json перемалывают, стучат асинхронно на разные апишки потому и раст. Девопс все красиво делает в докерах. Короче в целом стандартно примерно как у гоферов, ты лучше спрашивай что тебе интересно.
>сложности с которыми сталкиваются Как только начнешь набежит школота рассказывая что в шарпе не так и ваш язык говно и вообще я повелся на маркетинг лол.
>>2800806 >Вот бы больше анонов пишущих в продакшен на расте рассказывали про работу, сложности с которыми сталкиваются, наблюдения свои какие-то, всё такое
>>2801447 >Moq — a .NET mocking library В мире дотнета все стоящие внимания либы очень быстро заменяются их улучшенным клоном от МС, зачастую прямо встраивается в язык или в студию. А вот эта параша никому нахер не нужна, а если и нужна, то будет 100500 альтернатив.
>>2801461 На самом деле тут беда не только шарпистов, а беда попенсорса в целом. Это уже не первый случай, когда у авторов происходит обострение. Если не начнут подавать в суд, количество безумия только увеличится.
>>2801461 Это вроде топ популярная либа там? Вообще это показатель, когда дети копируют поведение взрослых. Вот можно телеметрию им собирать, никто не возмущается, вот и "детки" начинают подрожать.
>>2801558 Это в zig называется метапрограммированием. Я не критикую раст, там все норм. На самом деле и там и там будет эта магия макросов (любой кодген). Сложность надо заворачивать, в любом случае. Просто мне нравится, что в случае зига это средствами языка делается, а не отдельным синтаксисом.
А еще полистал, там обработку ошибок завезли неплохую. Не буду больше флудить, просто у меня вау эффект получился, как-то мимо него проходил раньше, а тут, по сути, годнота. попробуй посмотреть без предвзятости, проект правда смотрится неплохо
>>2801570 Посмотрел. Ммм, фиш, никс, неовим с телескопом и скриншот с юникспорна как пример из продакшена, каеф. Тебя итерация по полям структуры поразила что-ли? Ну так это ещё в старых добрых плюсах на шаблонах делается. Да, там придётся написать побольше кода мягко говоря, тут за сахар жирный плюс. Если говорить про концепцию - разницу между макросами в расте и метапрограммированием в зиге не увидел что-то не увидел. Круто конечно, что это встроенно в язык, но вот тебе одностраничный крейт, который делает то же самое https://crates.io/crates/struct_iterable
Гораздо интереснее то, что он про разработку своего DAW рассказывал. Мол, то что пробовал писать на расте, заебался потому что какую-то фичу сделал на другом языке за 4 дня, а на расте это заняло 16, лол. Вообще, у меня сложилось впечатление, что язык появился потому что C++ слишком старый, а раст слишком сложный.
Я сегодня мониторил разное мнение, я думаю эта хрень может выстрелить, оказывается людям достаточно деффера, вместо тотальной победы над памятью, главное чтобы код проще сопровождался если ты читал код на сях, то там ппц адок
Растерам, кстати, припекает, зачем челик им накинул про раст, я хз. Это всегда только вредит обоим сторонам, но смотреть приятно. https://habr.com/ru/articles/753078/
Что-то психанул и попробовал на расте сделать этот пример. Найди 10 отличий называется. Да зиг чуть лаконичнее получился, потому что в расте нельзя матчить вызову функции, а констант для типов не завезли. Вопрос, нахера я этим ночью занимаюсь, остаётся открытым.
>>2801677 Там, вроде, на видео была ошибка. Типа посыл такой, найдите ошибку, и типа вуаля, вы только что разобрались в неизвестном языке (мол насколько он интуитивен).
>Эмбеддед Ну все же там более лайтово, железка не позволяет разойтись. Хотя может не прав.
На самом деле хз, что так подрывает, язык все еще глубокой бете, а потом после релиза еще тонна времени чтобы жирком обрасти.
Просто так вышло, что о карбоне, который существует только во влажной фантазиях и вообще не были понятны даже концепции, кроме как "сделать все хорошо" - кричали из каждого угла. Даже в каком-то ролике на ютубе вставили его вровень с С, С++ и Растом, как-будто он уже есть. А тут под боком живет полу-готовый продукт и кругом тишина.
Поэтому хз что переживать, без поддержки это будет очередной D. Как минимум интересно было о нём узнать, а так дальше сижу учу раст.
>>2801496 Интересная штука, тут кстати обработку ошибок лучше чем в расте сделали, остальное пока хз как-то там у них постоянно меняется всё, жду 1 версию
>>2801677 Иногда итерации по структурам не хватает, приходится в json перегонять или вот так вот изъебываться. А так пиздатая фича тут можно делать ORM без макросов, которую подсветит любая ide и всякие подобные штуки которые будут работать более очевидно вместо магии под капотом у serde
Посмотрел видос, который всплыл в рекомендациях, лол. И собственно, что я когда-то ныл, то в реальности и присутствует.
Сначала автор показывает в сравнение как раст делает код лучше, безопаснее, но потом приходит асинхронная задача и начинается просто костылеварение.
Так о чем я ныл, а о том, что мне были непонятны, как все эти ограничения раста лягут на сложные системы и большие проекты. Автор наглядно показывает, как в простой задаче можно утонуть. То есть, для разрешения в рамках ограничений языка приходится делать больше, чем требует сама бизнес логика. Возможно, сейчас там допилили что-то, возможно через очередной макрос, но все же сильные ограничение языка могут приводить к такой вот "пробуксовки", когда ты тупо борешься с языком, а не задачей.
>>2801914 > но потом приходит асинхронная задача и начинается просто костылеварение.
Русским по белому чел говорит, что это из-за отсутствия async трейтов. Проблему никто не скрывает, люди работают. Непонятно, почему в либе нет воркараунда с динамическим фьючерсом.
>>2802026 > ибо костыль под это уже четыре года как существует. Как трудно расту даются такие вещи. В зиге в 0.12 планируют тоже асинк/авэйт, посмотрим как у них получится.
>>2801994 Все берут async_trait костыль не парятся и ждут лучших времен. Проблема в том что в трейтах нельзя объявлять асинхронные методы компилятор тебе говорит иди на хуй, а если объявить метод не асинхронным, а имплементацию сделать асинхронной будет говорить что ты хуй и у тебя сигнатура не соответствует. async_trait это исправляет в виде макроса делая примерно такой же изъеб как на видео
>>2802073 >Как трудно расту даются такие вещи. Их похоже проебали когда async/await добавили в 2019, а теперь это добавить стало сложнее
>>2801676 >>2801844 Про обработку ошибок. Прочитал статью и может что-то не понял, но чем она лучше резалтов в расте? Из статьи я вижу такие особенности: 1. try 2. catch 3. автоматическая генерация вариантов енума для разных типов ошибок 4. отсутствие данных передаваемых вместе с ошибкой Ну так и в расте есть оператор ? вместо try; unwrap*, if let или match вместо catch; данные в ошибках из коробки. Да автоматических енумов нет, или я про них не знаю, но во многих ситуациях явное описание вариантов это плюс. Блин, да там автор полстатьи показывал как сделать растовский резалт. >>2801706 Iosevka
>>2801900 Согласен, что это бывает очень нужно, причём метапрограммирование только сериализацией или ORM не ограничивается. На моём примере вся магия улетает в #[derive(Iterable)]. В остальном обычная работа с методами и типами из стандартной библиотеки с соответствующей поддержкой от IDE. Буду честным, под капотом serde всё таки прилетело, лол. Я скорее против разграничения макросов и метапрограммирования. Это актуально было разве что только C, в котором это действительно разные этапы работы тулчейна. Во всех современных си-подобных язычках макросы, темплейты и это самое метапрограммирование обрабатывает компилятор. Поправьте, если ошибаюсь. И всё равно им до лиспа как до луны.
>>2801683 >Типа посыл такой, найдите ошибку, и типа вуаля, вы только что разобрались в неизвестном языке (мол насколько он интуитивен). Хороший ход, но нет, я вот не разобрался лол. Но про поиск ошибки кстати интересное замечание. В зиге (блять, название пиздец триггерит для русских) как и в расте нужно перечислить все варианты в свиче, поэтому мой пример пожалуй тут проигрывает, т.к. компилятор ошибку не подскажет. Поэтому переписал, получилось совсем 1 в 1 как по мне.
>>2802238 Да, все так и еще там более грамотный просброс наверх, есть контекст из коробки и что-то типа стек трейса, короче что-то типа anyhow только из коробки и менее всратый.
>>2801683 >PS ладно, последний разок покушать принес >https://ziglang.org/ru/learn/why_zig_rust_d_cpp/ Чёт кекнул: >В Zig нет макросов и метапрограммирования, но при этом он достаточно мощный для того, чтобы выражать сложные программы понятным, немногословным способом.
>>2801496 Вот честно говоря, мне как системщику пишущему на С эта штука очень интересна
Естесно меняться на это сходу никто не будет, но учитывая его простоту интеграции с С-шным кодом, а также сохранение С-шной возможности ткнуть в любое место кода и дизассемблировать его хоть в голове, может быть когда-нибудь это где-то и приживется
Сап. Платину наверно спрошу, но вдруг кому то не влом ответить. Короче, в качестве хобби хочу вкатиться в системное программирование и пописать что нибудь наконец то для души. Работаю бэкэнд макакой, и самое "низкоуровневое" что я писал это реализация dhcp клиента на go а так вечное перекладывание жсонов
Начал читать пик, и запутался уже на теме с транзисторами, т.к в электротехнике полный еблан. Стоит ли вообще начинать с такого? Или похуй, читнуть про ОС и забить? И стоит ли сразу начинать с раста, или сначала поговнячить на Си или АСМ?
>>2802238 Отсутствие лишних и ненужных сущностей, кастомные юзерские ошибки тот еще бойлерплейт (к счастью или нет, фикситься макросом). catch это скорее unwrap_or_else. Тут просто истетика и наверное показатель для Го. Про сахар "?" я чуть позже узнал, да и он не решает вопрос сигнатуры. Где в зиге возвращаемым типом может быть сам тип с восклицательным знаком. !type = это аналог резальта ?type = это аналог опшена
Что лаконичнее? fn foo() -> <Result<Option<u32>, io::Error>> fn foo() !?u32
>>2803103 >catch это скорее unwrap_or_else Почему же? Может быть unwrap_or() если нам просто нужно конкретное значение, unwrap_or_default() если хватит дефолтного или unwrap() если нужна паника (аналог catch unreachable в зиге). А ещё в расте есть удобные функции для перевода Result в Option и обратно, позволяющие строить прикольные цепочки. >>2803107 Я к тому что между всеми этими понятиями исчезающе тонкая граница. Хз, может есть какие-то строгие определения, я не в курсе.
>>2803128 Не спорю что у раста свой подход. Тут да, резалт может открывать больше возможностей, чем просто прибитый гвоздями синтаксический оператор catch (сахар). В общем я не критикую, я просто дискутирую, что мол есть и другой подход в решение задачи.
PS Всем похер, но скажу: я воспринимаю языки как инструмент и это не просто шаблонные слова. То есть мне не нравятся или нравится языки, я их либо ценю, либо нет. В данном случае раст, это, по сути, единственный инструмент, который реально решает пласт проблем С/С++ и приземляет разработку с того околосистемного траха, до прикладного уровня. Действительно - трахаться с копиляцией, это лучше чем трахаться с дампом памяти. И в целом для меня он становится универсальным языком, где плюс минус можно будет писать все. Поэтому я могу одновременно восхищаться растом и в тоже время какими-то идеями zig.
Язык программирования это технически сложный проект требующий тонну часов для достижения стабильной разработки на нем, поэтому меня радует что могут появляться еще продукты данного типа, но вероятно с раста я не уйду, если мне не дадут "прикладной" уровень разработки без ГЦ. Там в реале тот же zig все еще достаточно сырой и тонна "васянства", это может быть очередной D, "скребущий" дно спроса. Но это не повод не смотреть на его сахар. В общем, всем насрать, просто даю понять что я не троллю.
Подсел на раст недавно плотно, раньше тоже что-то пытался, но получалась хуйня нихуя неполучалось, собственно говоря. Смотрю крастофраст Жона Женгеста охуительны чел, из его видосов получаю больше, чем из книжки, изучаю пару проектов на разбор, сам пишу по мелочи. Странно, но никакой другой язык до этого не давал такое чувство удовлетворения от того, что прога компилится, лол.
Стоит учить Раст если хочу а) сделать скрипты для Хрома и Телефона андроида чтобы скачивать сториз с инсты быстро и чётко (АПИ, атво-соащдние папок по имени и дате, чекать было или нет ранеесохранено) б) работу 300к в неделю в) власть и капитал, уровня 100 млрд баксов+++
>>2804297 Лол, на днях пока девопсы прод роняли и поднимали на работе сидел хуи пинал и потыкал хэлоу ворды на этом говне, нихуя прикола не понял и попросил чат гопоту накидать круд и запросы к sql. Нахуевертила, результат мягко говоря меня удивил, погуглил примерно так и пишут на нем. Сидел экспирементировал с кодом и понял что это бессмысленная хуета которую невозможно поддерживать потому что write only, особенно забавило то как методы пишутся. Я вот не понимаю нахуя его вообще трогать кроме как в академических целях играться с монадами при помощи стрелочек, заебенивая в одну строку факториал. Из языков для ФаПа та же кложа более читабельна
>>2804203 >а) сделать скрипты для Хрома и Телефона андроида чтобы скачивать сториз с инсты быстро и чётко (АПИ, атво-соащдние папок по имени и дате, чекать было или нет ранеесохранено) Тебе лучше js
>б) работу 300к в неделю >в) власть и капитал, уровня 100 млрд баксов+++ Стань другом по дзюдо у нужного человека
>>2801683 > о карбоне, который существует только во влажной фантазиях и вообще не были понятны даже концепции, кроме как "сделать все хорошо" - кричали из каждого угла.
Гуглу в коммитете по стандартизации С++ в чём-то там отказали. Они обиделись и решили сделать свой собственный С++ с блэкджеком и шлюхами. В результате вышел высер под названием Карбон.
Короче, несколько часов было потрачено на попытки заставить дебагер в вскоде показывать значения переменных в винде вместо хуй пойми чего. Побовал и lldb, и c++, и в дебаг консоли прописывать команды - все тщетно. Чтобы все заработало, пришлось запускать через wsl.
Была у кого-нибудь такая же проблема, и возможно ли это пофиксить? Хочу нормальный дебагинг раста в винде. Вроде mature язык, но я не представляю как дебажить приложения в таком виде.
И да, с винды слезать не хочу, я не хочу ставить линукс в качестве основной ос и пердолиться с ним на постоянке. Но при этом не имею ничего против программирования в wsl, в вскоде все очень удобно сделано плюс wsl умеет даже гуи запускать, так что проблема казалось бы решена, но хочется все-таки нативного кодинга на винде.
>>2804887 Бля, я чет уж совсем сдался, но решил еще разок попытаться, и у меня получилось! Я удалил экстеншен lldb, там выбралось c++ расширение, и все заработало хотя я ВРОДЕ бы пытался уже это делать, и у меня не получилось, магия какая-то. В статье, кста, ничего по теме особо дельного не написано, но я пригляделся, увидел винду у автора поста, и то, что у него хэшмапа нормально отображается, поэтому решил еще разок попробовать. Так что спасибо тебе, анон. Я до сих пор думал, что формочки на реакте это удел макос юзеров. Кстати, ничего не имею против реакта, годный инструмент в своей нише.
>>2804973 хуета. дебагер не только для удобного вывода переменных. С ним можно 1) наставить брекпоинтов в разных файлах и пробежать по ним 2) остановить выполнение в конкретной точке и ходить по коллстеку 3) отладка нескольких потоков одновременно
>>2804973 > Дело привычки. Я уже 12 лет дебажу принтами (в разных языках), мне, наоборот, в отладчике ковыряться неудобно. Бля, парни, вы чё дискредитируете язык то своими бест практисез?
>>2805224 >Бля, парни, вы чё дискредитируете язык то своими бест практисез? Тебе же написали в разных языках, кто-то пердолится с дебагом, кто-то принтами тупо вкусовщина
Решил войти в ойти, без опыта но с технической базой. Начал изучать си пласплас, пока что идет легко и довольно интересно но смотрю видосик на ютубе сказали что раст это новый си пласплас но лучше потому что меньше гемора с памятью или вроде того.
Ойти интересует из за финансовой стороны вопроса, что конкретно изучать мне пока что по барабану, все равно еще не разбираюсь. Есть ли смысл переходить на раст в финансовом плане? Или дальше дрочить сишку?
(Думаю именно с самим поиском работы проблем не будет ни там ни там а вот что по зарплатам и рабочей нагрузке уже вопрос. Сишка вроде интенсивная в разработке, ответственность там.)
>>2805344 Ты и в С++ золотую жилу наносека с трудом найдешь, не набрав жир в 10 лет работы. Если кодинг не интересен, выгоришь моментально. Я серьезно считаю, что именно профессия программиста самая неблагодарная, так что не ведись на хайп инфоцыган, вас там джунов на вакансию по 500-1500 приходится.
Сейчас раст в такой стадии, что только киты могу позволить стабильно поиграться в раст (и стартапы, если не стабильно), кабанчику же вообще срать, ему лишь бы число работников побольше (не джунов).
Так что смотри на раст как на личный универсальный инструмент программиста. Наличие такого яп в резюме (и владение им), явно скажет о тебе как о человеке способным расти профессионально. Это реально крутой язык.
Щас бы на компилируемых языках принтами дебажить. Ладно бы спиздить у кабана время для игр или проработки глыбовых тем. Эти же додики ни себе ни кабану. И переключиться на другую деятельность не могут. Сидят смотрят как строчки в консоли бегут. Аутисты. Охуеть дожили...
>>2805416 Как-будто это вина разработчиков раста. Поколение гита, которое привыкли, что все где-то для них написано и за бесплатно. Ну не сидят авторы на винде или затык какой потому, что пропритарщина сплошная, ну вот и получаются костыли.
>>2805461 >Как-будто это вина разработчиков раста Я имею ввиду людей использующих раст, мол какой смысл ныть тем кто буквально юзает инструмент как ты.
>>2805416 >>2805461 Хватить дрочить друг другу или говорить с самим собой Дебаггер крайне неудобная в повседневной жизни штука, мало того что под него все медленно компилируется, так оно еще ужасно тормозно работает. Иногда он полезен но чаще всего нужно просто узнать в нужном месте что будет в структуре, а для этого принт лучше всего подходит потому что все быстро насрет в консоль и готово. А еще лучше под хуевоработающий кусок кода лучше написать тесты, иногда и я так делаю.
>>2805500 Никто не запрещает дрочить друг другу вставлять дебаггер только тогда, когда ставишь точку останова, или когда какой-то ключ передаешь. В общем, одно другому не мешает, если сделать с умом.
>>2805549 Потенциально и субъективно, на-наносекать, где-нибудь в питоне, будет быстрее чем в плюсах.
Но мой идеальный мир - это прогать для себя для души, а работать на чем-то более благодарном. Конечно, если ты не ИТ-звезда, которая может торговать лицом на конференциях или везунчик, который может лениво усваивать капитал кабана.
>>2805534 Лол да, как ты без тестов живешь? 100% кода не покрываю, но то что надо проверить в разных вариациях проверяю тестами вместо того чтобы запускать как-то руками и еще всякие штуки типа парсеров или куски кода с регулярками и тп покрываю в обязательном порядке. Когда что-то дает не такой результат тоже проще тестами покрыть. Если заранее нормальный код писать и максимально все убирать в переменные окружения и поднять отдельную БД для тестов, то потом можно тестировать почти без боли. Сейчас кстати с чатом гопотой удобно стало, даю ей кусок кода она примерно что-то накидает, немного руками поправить и тесты готовы.
>>2805570 В питоне сейчас модно нейронки дрочить, но места там наверное сильно заняты потому что дрочеров много а больших корпораций с мощностями для нейронок мало. А так почему то сложно поверить что питонисты зарабатывают больше сишников, хотя я не разбираюсь может и зарабатывают.
>>2806459 У дарта есть флаттер и мобилки, а мобилки сейчас больше веба. У раста ничего такого нет. Раст не то что бастард короля, это Квазимодо влюбленный в трапа по имени Эсмеральда...
>>2806478 >У дарта есть флаттер и мобилки Ты бы поинтересовался хоть у тех кто под мобилки пишет почему-то все кто попробовал перелазят обратно на котлин
>а мобилки сейчас больше веба Приложения ставят не все и не везде, так что иди верстай еще и мобильную версию
>>2806478 Сейчас бы на каждую чепуху по языку делать. Когда у тебя рядом лежит универсальный язык пригодный для всего, от написания операционных систем, до потенциального инди геймдева в браузере если наконец-то перестанут душить вебассембли. А ты все пытаешься с полутухлым говном на переполненный рынок залезть.
>>2806747 1) У языков бизнес валуе нулевое. Валуе есть только у батареек. 2) Вебассембер душить не перестанут. Однопотоковый одностековый ивентлуп с единым содержимым в IP регистре никто в браузере не отменит никогда. У тех же вебворкеров доступ к DOM отсутствует. 3) Инди гейдеву до пизды ассемблеры с растами. Ему нужно максимально простое апи для графона.
>>2806751 >1) У языков бизнес валуе нулевое. Валуе есть только у батареек. Что несет этот господин?
Ладно, покормлю, как может быть нулевая ценность у технологии определяющую вообще основу продукта? Это как сказать - строительный кран не важен, важен только построенный дом.
Бизнес-ценность определяется как вся ценность организации, общая сумма всех материальных и нематериальных элементов.
иди уже к школе готовься, пока родители мобильник у тебя не отобрали и ты не остался без основного рынка для дарта
>>2806806 >как может быть нулевая ценность у технологии определяющую вообще основу Как у воздуха. Не было бы воздуха на Земле - ты бы амиаком дышал. Ценность жизни не в воздухе.
>>2806885 https://ru.wikipedia.org/wiki/Альтернативная_биохимия#Азот_и_фосфор >Азот и фосфор считают другими претендентами на роль основы для биологических молекул. >В аммиачной атмосфере растения с молекулами на основе фосфора и азота получали бы соединения азота из окружающей их атмосферы, а фосфор — из почвы. В их клетках происходило бы окисление аммиака для образования аналогов моносахаридов, водород бы выделялся в качестве побочного продукта.
>>2806889 >Альтернативная биохимия Для альтернативно одаренных. У тебя там в навучных гипофизах аммиак как растворитель представлен, то есть на роль воды, а не воздуха.
>>2807526 >процесс как-то называется https://doc.rust-lang.org/rust-by-example/scope/move.html >When doing assignments (let x = y) or passing function arguments by value (foo(x)), the ownership of the resources is transferred. In Rust-speak, this is known as a move.
>>2807531 >>Mutability of data can be changed when ownership is transferred. А где-то это подобно объясняется? Или просто "примите как данность". Я нахожу это контр-интуитивным, хотя и очень удобным.
>>2807533 Не знаю насчёт интуитивности, но вполне логически вытекает из правил. Ты создаёшь новую мутабельную переменную и инициализируешь её массивом из старой. В целях экономии ресурсов массив не создаётся с нуля, а используется тот же самый, всё равно на него больше никто не ссылается, старая переменная из-за move становится невалидной. Если бы ты явно указал .clone(), то новая переменная не поменялась бы, а старая была бы по-прежнему доступна в иммутабельном виде, и ссылались бы они на 2 разные копии массива.
>>2807533 Согласен, ощущается как магическая смена типа. Ну раз такое правило то ладно, но хотелось что-то более явное, типа: let mut m = v.get_mut(); или let mut m = mut!(v);
забавно, что еще в примере автор возвращает значение () из main, забыв точку с запятой
>>2807538 >новая переменная не поменялась бы Хотя, если подходить строго, новая переменная была бы новой копией, а вот старая осталась бы на месте. Вообще не силён в объяснении теории, всё время криво выходит.
>>2807538 Мне кажется это странным, потому что изменение сложного типа может порождать сайдэффекты. И допустим ты создал иммутабильный экземпляр такого типа, поработал с ним, передал в функцию и забыл про него. А функция в аргументах изменил его мутабельность и начала менять. И тут неожиданно какие-то сторонние вещи могут начать происходить.
>>2807547 В расте из-за владения и вышеупомянутого move это невозможно. Если ты передал переменную, то она уходит в функцию и больше не доступна за её пределами.
>>2807559 >>2807561 Сначала начал писать длинный пост про то что ожидаю поведения const из плюсов и даже набросал пример, но пока писал его — понял, что действительно жду поведения ссылки на константу, а это совсем другое. Главное, в плюсах-то это тоже уже не новая концепция, это я отстал со своими знаниями древнего стандарта. Надо уложить в голове. Интересно, что получается в расте нет настоящих констант?
>>2807570 Ещё с первого поста заметно, что ты раст пытаешься натянуть на привычные тебе парадигмы из других языков. >в расте нет настоящих констант Есть, объявляются единожды во время компиляции и не меняются. Ключевое слово, как ни странно, const. https://doc.rust-lang.org/std/keyword.const.html
>>2807577 >Есть, объявляются единожды во время компиляции и не меняются. Вот именно, во время компиляции. Это не совсем то, что есть в плюсах. В расте это скорее что-то вроде именованного литерала, хотя наверное так неграмотно называть.
>>2807582 >пикрил const fn build_foo не пробовал? Как раз для таких извращенцев, которым непременно надо константу функцией инициализировать. >что есть в плюсах Нахуя ты учишь этот новый для себя язык, если хочешь ещё одни плюсы? Пиши на плюсах. В расте ты просто по-другому пишешь и не нуждаешься в том, что было в плюсах. Либо без конца воюешь с компилятором и жалуешься в этом треде о том, что в язык не завезли %фича нейм% из %язык нейм%, без которой невозможно писать программы.
>>2807590 const fn и fn это разные вещи. На пике утрированный пример, максимально похожий для обоих языков. Хотел бы более ярко иллюстрации для раста — написал бы что-то вроде const PTR: Box<i32> = Box::new(42); Стандартную библиотеку я поменять не могу, как понимаешь.
По поводу остального — я нахожу раст максимально похожим на современные плюсы. Будто бы язык взяли и сделали с нуля, выкинув все десятилетия ненужной обратной совместимости. Поэтому невольно сравниваю. И вроде бы я ни на что не жаловался, просто писал свои субъективные ощущения, а ты их как будто личный наезд воспринял.
>>2807547 >сложного типа может порождать сайдэффекты Не может
>И допустим ты создал иммутабильный экземпляр такого типа Создал
>передал в функцию и забыл про него >А функция в аргументах изменил его мутабельность и начала менять. Передал и забыл, дальше этот экземпляр полностью перешел во владение функции и ты не можешь его использовать. Если хочешь передать ссылку на него, то она будет иммутабельной. Если тебе нужно передать по ссылке и изменять, то тебе нужно передать мутабельную ссылку &mut, но чтобы её передать нужно сделать переменную мутабельной при объявлении.
Надеюсь ты реально пытаешься разобраться, а не тот шиз с перегрузками
>>2807590 >написал бы что-то вроде const PTR: Box<i32> = Box::new(42); И не скомпилировал бы, потому что это бред какой-то, константа времени компиляции в Box. То, что ты пытаешься сделать - это обычный let без mut. Переменная получает значение 1 раз на этапе выполнения и больше его не меняет. Если не будешь использовать mut, как в примере выше >>2807456 , то ты его никак не поменяешь, сколько ты там не переприсваивай.
>>2807590 Алсо, если тебе нужна прямая аналогия с плюсами, то: "int a = 42;" превращается в "let mut a = 42;", а "const int a = 42;" превращается в "let a = 42;". В расте объявление по умолчанию "const" (в плюсовом смысле), если не указано обратное.
>>2807599 >Не может У меня в голове что-то такое крутилось, когда я про сайдэффекты писал: Представь, что есть некоторая структура, которая содержит какой-нибудь указатель на определённый адрес. Этот адрес замаплен на регистр какой-нибудь железяки, а сама структура предназначена для взаимодействия с этой железякой. Для неё определены методы, например, поморгать лампочкой, которые для своей работы используют тот самый указатель. Т.е. чтобы включить лампочку по адресу в указателе пишется одно число, а чтобы выключить другое. И вот мы создаём иммутабельный экземпляр такой структуры, заполняем корректно все поля для гарантированный работоспособности и передаём её в какую-то функцию в полной уверенности, что всё будет работать как надо. А эта функция приняла объект как мутабельный и по ошибке поменяла тот самый указатель. И теперь все методы, которые вызываются у него в лучшем случае не просто работают, в худшем портят где-то память. И получается, что с точки зрения языка и компилятора всё ок, а вот с точки зрения программиста, который не ожидал изменений переданного объекта - вообще не ок.
Сорян за такой сложный и низкоуровневый пример, но это то что близко мне. Я поленился писать код для иллюстрации, возможно и зря, раст имеет удивительное свойство надавать по рукам даже в самых очевидных моментах. Так что может подобной ситуации в расте не может существовать просто потому что. Либо есть какие-то более правильные идиоматически способы запретить изменение передаваемых значений.
Если что в плюсах простой const тоже в такой ситуации не поможет конечно. Но его хотя бы отменить в середине функции нельзя.
>>2807625 Опять какой-то абстрактный пример ради примера, где непонятно, что ты хочешь сделать (понятно, что переписать буквально слово в слово код C++ и повоевать с компилятором и задаться вечным вопросом "почему так"). Что мешает не срать в иммутабельную структуру?Знаю-знаю, человеческий фактор. Что мешает передавать не структуру, а read-only ссылку (&your_struct), если твоя функция ничего не меняет по определению, а только читает? Методу "поморгать лампочкой" при твоём подходе, как я понял, тоже не надо ничего писать в саму структуру, достаточно только прочитать адрес и работать с ним как с "сырым" указателем.
>>2807619 >И не скомпилировал бы, потому что это бред какой-то, константа времени компиляции в Box. Я об этом и говорю, что const в расте нифига не замена const в плюсах. Они разные. >>2807621 Я с этого и начал в >>2807456, потому что именно так и считал. Но в расте не просто "const" по умолчанию для переменных, а ещё и перемещение по умолчанию вместо копирования или передачи по указателю/ссылке. Это сбивает с толку, и не только меня (>>2807526>>2807539). Типа, в первом примере ожидаешь, что либо дропнутся все значения из вектора либо код не скомпилируется. >>2807630 Не цепляйся к примерам. Это не какой-то случай, который я хочу переписать, просто первое что пришло в голову, когда я стал думать, а чем такое изменение мутабельности может быть плохо. В функцию действительно можно ссылку передавать (правда вдруг я владение хочу в другой поток передать?). Метод "поморгать лампочкой" ничего во внутренней структуре не меняет (ну а вдруг мы хотим там же ещё подсчитывать сколько раз поморгали?).
Короче тут можно много херни напридумывать. Я в целом для себя разобрался, спасибо вот за этот пост >>2807561. Для других ананасов хочу ещё добавить, что раст судя по всему под капотом при перемещении копирует память, но для оригинала уже не вызывает деструкторов при выходе из скопа. Т.е. по факту создаётся новая мутабельная переменная. При этом копирования самого по себе может и не быть за счёт оптимизаций. Возможно так легче для осознания. https://www.tangramvision.com/blog/c-rust-interior-mutability-moving-and-ownership#rust
>>2807641 >мы хотим там же ещё подсчитывать сколько раз поморгали Если ты хочешь это записывать в структуру, тогда ты не сможешь таким образом использовать иммутабельный экземпляр, только и всего. Насчёт cpp не уверен, можно ли для const экземпляра структуры вызывать модифицирующие методы, давненько с ним дело не имел, но что-то мне подсказывает, что это неправильно уже на уровне самой идеи. В расте за такое получишь очередную закономерную битву с компилятором. За это мы его и любим, в отличие от cpp не даёт просто взять и выстрелить себе в ногу на ровном месте, для этого ещё надо постараться обойти ограничения.
>>2807641 > Для других ананасов хочу ещё добавить, что раст судя по всему под капотом при перемещении копирует память Если ты про let mut m = v; то думаю раст там ничего не делает, скорее всего просто меняет флаг "иммутабельности" во время компиляции и все. Тут просто создается еще одно ощущение, это наличие иммутабельных типов в некоторых языках, которые можно конвертить из иммутабельного в мутабельное и обратно, но это как раз не то, тут не целый тип (вектор он один), а какой-то статус идентификатора во время компиляции (как я понимаю).
Возможно я не правильно понимаю, пускай джедаи поправят.
>>2807625 >Представь, что есть некоторая структура, которая содержит какой-нибудь указатель на определённый адрес. Представил
> Этот адрес замаплен на регистр какой-нибудь железяки, а сама структура предназначена для взаимодействия с этой железякой Допустим
>Для неё определены методы, например, поморгать лампочкой, которые для своей работы используют тот самый указатель. Т.е. чтобы включить лампочку по адресу в указателе пишется одно число, а чтобы выключить другое. Если я правильно понял то метод изменяет поле структуры
>. А эта функция приняла объект как мутабельный и по ошибке поменяла тот самый указатель. > который не ожидал изменений переданного объекта Как это ты не ожидал? Ты же в сигнатуре должен был mut написать и если дальше по коду передаешь везде должен написать mut. Собственно о чем я выше писал. Дальше метод в структуре меняющий его поля должен иметь мутабельный аргумент self и чтобы можно было воспользоваться этим методом извне у тебя должна быть мутабельная ссылка на структуру. То есть для "неожиданного" эффекта тебе нужно руками везде указать mut
>Я поленился писать код для иллюстрации, возможно и зря, раст имеет удивительное свойство надавать по рукам даже в самых очевидных моментах. Лучше бы попробовал написать то что ты хочешь
>>2807698 >то думаю раст там ничего не делает, скорее всего просто меняет флаг "иммутабельности" во время компиляции и все Неа, нихрена, я проверил: https://godbolt.org/z/8rTnG4vYE
Простая функция, заводит иммутабельный вектор из одного числа, потом делает его мутабельным, ну и снова иммутабельным для наглядности, больше ничего не происходит. Видим, что на стеке сразу выделяется 72 байта. Сначала аллоцируется вектор, а потом структура его описывающая дважды копируется на стеке. Собственно сам вектор — это три числа (указатель на буфер в куче, вместимость и длина), в сумме 24 байта, каждое копирование видно в коде ассемблера, 24 * 3 = 72, других переменных на стеке мы не заводили, так что всё сходится.
Уверен, что лишние копировании при оптимизации будут убраны, но сам мув как видно никакой особой магии не производит, это просто тупое копирование.
>>2807727 Чел, не души. Мой посыл был не в том, что такое поведение неправильное, а в том что лично я его не ожидаю.
>>2807748 >Неа, нихрена, я проверил: Любопытно. В какой-то момент это логично и в какой-то не очевидно. Не силен в этом низкоуровневом, но видимо так нужно. Хороший вопрос на плохое собеседование.
>>2807748 Под первым же флагом оптимизации мув должен убраться, но да, по дефолту, без оптимизаций, или если оптимизация не может произойти по какой-то причине обычно что-то вроде динамической фигни &<dyn Fn(Vec<()>)>, когда инлайн не происходит , то мув в расте это memcpy
>>2808560 С оптимизациями тяжело придумать простой и наглядный пример, потому что современные компиляторы явно умнее простых работяг.
Тем не менее, вот посмотри на функцию f2() скомпилированную с -O3 https://godbolt.org/z/x4e1vPof8. Она берёт во владение (как это по русски адекватно говорить?) вектор и тут же отдаёт его, т.е. происходит двойная передача владения при её вызове. Компилятор скомпилировал её следующим образом:
1. Вместо одного аргумента ожидается два адреса в регистрах RDI и RSI для возвращаемого и принимаемых значений. 2. Адрес возврата тут же помещается в RAX, строка 89.Если честно, этот момент не понял, почему нельзя было просто входной аргумент передать в RDI (первый аргумент на x64 линуксе согласно fastcall соглашению), а вывод сразу в RAX херачить. Но я крайне редко смотрю код x64 бинарников, наверное что-то упускаю. 3. Копируется 64-битное значение по адресу RSI+16 в RDI+16 через RCX, строки 90-91. 3. Копируется 128-битное значение по адресу RSI в RDI через XMM0, строки 92-93
Таким образом, даже такая тривиальная функция, которая кроме передачи владения вектором, не делает ничего, скомпилированная с максимальным уровнем оптимизации, занимается копирование всё тех же 24 байт структуры вектора. При этом вектор в обе стороны передаётся по указателю, что интересно.
Конечно, если мы попытаемся использовать эту функцию, компилятор её тут же заинлайнит до полного отсутствия. Он даже создание вектора заинлайнил и просто сразу же записал внутреннюю структуру вектора на стеке единственный раз, строки 105-107, перед вызовом принта.
Но все эти оптимизации к расту на самом деле никакого отношения не имеют. Это всё LLVM делает. По хорошему надо смотреть промежуточный код, но я не имею. Да и их там раст вроде генерирует несколько уровней.
>>2808926 Да я тоже его специально не изучал, поэтому запросто могу ошибаться в чём-то. Просто иногда приходилось читать, чтобы разобраться в некоторых особо неприятных проблемах.
В целом, соглашения о передачи параметров при вызове функций зависят от целевой платформы. На современных x86-64 и на 32-битных ARMах для аргументов, которые влазят в слово, предусмотрено несколько регистров. Всё что не влазит или если аргументов больше, передаётся через стек.
Через стек все аргументы обычно передаются на i386, но есть специальные соглашения (fastcall), которые всё же предусматривают пару регистров для передачи аргументов.
Чтобы данный конкретный случай разобрать надо плотненько погружаться в документацию ABI для линукса https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf (п3.2.3) Структура вектора определенно не влазит в слово, поэтому казалось бы должна передаваться через стек. Но там есть такое уточнение: >If a C++ object is non-trivial for the purpose of calls, as specified in the C++ ABI, it is passed by invisible reference (the object is replaced in the parameter list by a pointer that has class INTEGER). Что такое non-trivial for the purpose of calls я хз, но видимо это относится и к вектору в расте. Поэтому он передаётся в функцию по указателю. Т.е. при передаче владения значением вектора в функцию копирования данных не произошло. Хотя если оптимизацию отключить, он всё-таки через стек будет значения гонять. Так что хз, тут надо ещё глубже погружаться, чтобы разобраться. Возврат структур по значению описывается так: >If the type has class MEMORY, then the caller provides space for the return value and passes the address of this storage in %rdi as if it were the first argument to the function. In effect, this address becomes a “hidden” first argument. <...> >On return %rax will contain the address that has been passed in by thecaller in %rdi. Как раз то, чего я не понял в прошлый раз. Оказывается вызывающая функция должна подготовить место для возвращаемого значения и передать указатель на него в скрытом первом аргументе RDI. Вызываемая функция должна вернуть этот адрес в RAX. Что мы и наблюдаем в ассемблерном листинге. Ну и так же видим копирование данных по адресам из аргументов (из RSI в RDI). Т.е. при возврате владения значением вектора из копировани произошло.
На самом деле это всё лютые технические детали, не особо важные. Вывод, который я сделал для себя: раст, как язык, всегда копирует значения при передаче владения, но LLVM, как бэкенд, очень круто может оптимизировать и убрать лишнее.
>>2809156 Я не кодил крупного на расте, но не думаю что по работе владений и их оптимизации стоит париться, ведь оно буквально определяет место/контекст владения, а работать ты больше будешь с ссылками.
На практике у тебя будет не много зон владения. -глобальный, постоянный контекст, -контекст события или контроллера -контекст чистых функций, мелкого скоупа, типа цикла или еще чего.
Мне вот больше интересует, может ли объявленное владение в 1 функции, быть удаленно во вложенной n-функции если очевидно, что в коде это владение больше не используется (логическая утечка памяти).
>>2809204 >быть удаленно во вложенной n-функции Не может. borrow checker не инлайнит функции, если ты передал `qwe: &T`, в функцию, ты можешь работать только с `&T` и не можешь вызвать дроп.
А если про сам компилятор и его оптимизации, то тоже нет, потому что место дропа имеет значение, и раст даёт гарантии для этого самого места. Так что если ты выделил 100500 гигов для вектора и не дропнул его после использования, до конца функции у тебя этот вектор будет жить.
>>2809204 >Я не кодил крупного на расте, но не думаю что по работе владений и их оптимизации стоит париться, ведь оно буквально определяет место/контекст владения, а работать ты больше будешь с ссылками. Соглы. Как говорил Кнут: "Преждевременная оптимизация — корень всех бед". Я полез разбираться только из-за вопроса с отменой иммутабельности. Когда посмотрел как оно реализовано, все вопросы сразу отпали.
>Мне вот больше интересует, может ли объявленное владение >в 1 функции, быть удаленно во вложенной n-функции если очевидно, что в коде это владение больше не используется (логическая утечка памяти). Ну drop() точно вызовется именно во вложенной n-ой функции. Т.е. например, в случае вектора, память в куче будет будет освобождена сразу же как только станет не нужной. А вот описывающая его структура будет лежать в стеке до тех пор, пока управление не вернётся к 1-ой функции. Из середины стека не выкинешь же кусочек. Поэтому, если у тебя в середине цепочки вызовов есть какой-нибудь бесконечный цикл, из которого выходишь только в конце работы приложения, тогда упс, немного стека зарезервированного до его начала будет висеть мёртвым грузом. Можно рассматривать это как своего рода глобальные переменные, только на стеке.
>>2809606 >Так что если ты выделил 100500 гигов для вектора и не дропнул его после использования, до конца функции у тебя этот вектор будет жить. Печалька, есть подозрение, что из-за владения, программисты будут раздувать код такими около-вечно живущими объектами.
Есть такой феномен, где системные кодеры с большим опытом (это важно) отвергают раст, например автор зига, еще до зига написал, что надо быть безумцем чтобы на этом писать, ну и некоторые другие люди с большим багажом знаний в солидных компаниях хейтили раст, вероятно за какую-то сложность. Понятно что тут речь не про очередных "не осилили" и кривую обучения, а реально опытные люди видят в расте некую системную сложность.
У меня возник вопрос к опытным кодерам - о какой "сложности" они говорят? Может быть код становится сложнее поддерживать или просто у них синдром утёнка, или какие еще проблемы есть в сопровождение раста при длительной разработке?
Раст годнота, это не хейт, просто дискуссионный технический вопрос на тему "почему" и у кого какое мнение по этом поводу (если есть).
>>2811715 >У меня возник вопрос к опытным кодерам - о какой "сложности" они говорят? Чтобы писать на нем нужно понять некоторые концепции типа владения и лайфтаймов, плюс компилятор доебывается до каждых мелочей. В первые несколько дней я испытавал сложности с этим, но вцелом они преувеличены.
> или какие еще проблемы есть в сопровождение раста при длительной разработке? Тут как в гошке примерно те же проблемы при сопровождении. Главная из них что здесь отсутствуют фреймворки в которых все прибито гвоздями по полочкам из-за этого здесь каждый волен делать всё что хочет из-за чего могут возникнуть сложности. Мы в команде пишем примерно одинаково, но если придет другой человек со своими взглядами на жизнь то его код будет тяжело читать. В целом работа с растом ничем не отличается от остальных языков.
>>2811715 >о какой "сложности" они говорят Опытным людям, возможно, сложнее переучиваться, чем новичкам учиться с нуля. Сидишь в своём болоте лет 10-20, и не охота уже куда-то переползать.
>>2812053 Сегодня по-исследовал на тему сложности раста. Вероятно раст имеет проблемы в дизайне, когда люди упираются в проблему лайв-таймов и где приходиться компенсировать подобием rc или refcell (или unsafe). А с асинками там что-то вообще звездец какой-то, я даже не вникал.
В общем, даже у грамотных людей в системной разработке от раста начинают плыть мозги на обычных для них задачах и, как говорят, приходится писать больше кода, там где не надо. Есть, конечно, контр мнение, по типу - сишники говнокодят, а раст прививает правильных подход и единственную верную архитектуру, но все это, пахнет утопическим звездежом.
Сделал для себя выводы, что раст реально имеет проблемы в дизайне, где с одной стороны он красив для простых вещей и в тоже время с другой стороны покрыт костылями. Вероятно это реальная причина, что раст развивается только на каких-то агрессивных фанатиках, потому как для практичного человека все это адок. го тоже имеет плохойй дизайн и тонну костылей, но он хотя бы прост как палка
Посоны почему когда пишут вывод чего либо то всегда пишут ("Залупа коня - это {}", переменная_нейм)? Можно ведь писать ("Залупа коня - это {переменная_нейм}") В чем будет разница? Чому пишут именно первый вариант?
>>2812096 >В общем, даже у грамотных людей в системной разработке от раста начинают плыть мозги на обычных для них задачах и, как говорят, приходится писать больше кода, там где не надо. Есть, конечно, контр мнение, по типу - сишники говнокодят, а раст прививает правильных подход и единственную верную архитектуру, но все это, пахнет утопическим звездежом. В сях тоже можно включить -Wall -Wextra -Werror -fsanitize=address,undefined и обмазать это всё сверху каким-нибудь статическим анализатором. Программирование будет таким же быстрым и комфортным, как на расте.
>>2812205 Ну практичными их точно не назовешь. Я еще понимаю тех, кто пытается самоутвердиться за счет раста, мол лайтовая версия для тех кто хаскель не осилил. Но вот я бы не назвал раст сложным, как раз эти костыли (rc, refcell, итд) и решают все эти дыры дизайна, пускай не красиво, но решают. То есть, это не сложно в когнитивном плане, это просто неудобно. Там на полных щах на этом пишут бэкенд, лол
>>2812096 > А с асинками там что-то вообще звездец какой-то Учу Раст, дошел до этих Токио(асинк библиотека) и уже думаю нахуя это все учить было если там все по другому и свои правила, растеры ебанутые что согласны вот на этом вот программировать, такой кал. Решил завести телеграм бота, на всех языках в 3 действия делается, в расте блять то библиотеки нет, она 4сть в зависимости но не ставится автоматом, то версия не та, токио там уже 1.3 версия а боту нужно 0.2, то фьюч не подключил, ага я должен угадать что там при установке всей библиотеки нужно отдельно ещё подключать
>>2813030 Опенсорс хули. Думаю что serde либо форкнут, либо выкинут на мороз того кто придумал бинарники и за либу возьмется команда из крупной компании, либо еще чего. Из red hat уже интерес проявляют Хз где там проблемы при компиляции, у нас разные проекты с разными версиями serde нигде проблем с ним не было
>>2813457 Язык, где даже хелловорд состоит из кодгена, неожиданно уперся в критический кодген.
Тот случай, когда драма возникла на простой продуктовой задаче.
Эксперимент с растом стоило бы закрыть сразу как только утонули в кодгене или когда уперлись в асинки, а по честному, когда уперлись в лайфтами и костыли, которые решают их.
вообще надо смотреть не по репозиторий/ишшу, а пулл реквест/ишшу, потому что это будет отображать как часто разработчики (не)фиксят баги вместо того, чтобы добавлять новые фичи. Поэтому вся статистика переворачивается с ног на голову, и тут уже есть совпадения с реальностью, все репы с жавой являются легаси, где только фиксят баги. А на кресты всем посрать
>>2813749 Да блять, на это вообще бессмысленно смотреть, потому что гитхаб какую-то невалидную херню показывает при таких запросах. Или ты серьёзно думаешь, что в проектах на F# ничего не зарепорчено? Я уже молчу, что это отношение скорее показывает популярность языка в опенсорсе, чем какие-то проблемы в его дизайне.
>>2813783 >но фронтендеры в реакте что-то насрали и счётчик не считает За это это помогает шизу говорить что его до диез и фа диез божественные как песня на фоне других яыков. Интересно расскажет про то как у них в шарпе сделаны джсономешалки или нет
>>2813749 Ппц ты технический фантазер 3 ляма раста - это модно развивающий язык 3 ляма у крестов - на кресты всем насрать 11 лямов у жабы - очевидно легаси.
>>2814031 Одаренный, вместо обсуждения проблем кривого раста, начал сравнивать его с языком у которого виртуальная машина. Ты не тот гений с лора, который сравнивает js с растом и говорит, что они очень похожи?
>>2814091 >кривого раста Проблема в библиотеке, это проблема в языке?
Ты же в тред свой C# принес лол, я хотел узнать как там сделано не в кривом языке. И как оказалось там также кодогенерация, только в рантайме. То есть C# тоже кривой, получается все языки так или иначе кривые? Или тут как с гц пару тредов назад будешь жопой вертеть то считается, а это не считается? Вытер хуй о воротник твоей рубашки
>>2814105 >Проблема в библиотеке, это проблема в языке? Да, именно это и сказал, что проблема избыточного кодгена. То есть, язык настолько ущербен, что продуктовая задача превратилась в адок. вот (откуда ты тут шарп увидел я хз): >>2813528
>>2814142 >Других шизиков кроме тебя тут нет >А всё таки Croco это ты? Как растапёру неприятно, готов всякую херню придумывать, вместо того чтобы обсудить избыточный макросный кодген.
>>2814151 > кодген. Потому что он везде есть, где-то в рантайме, где-то в компайлтайме, вот я и привел пример с твоим любимым C# где в рантайме при помощи рефлексии тоже самое делается. Но ты либо не понял о чем речь, либо всё таки понял и возникло желание все отрицать и включать дурочку. Ты меня теперь запутал и я пытаюсь разобраться: Все языки с кодогенерацией плохие? Кодогенерация в компайлтайме плохая? Почему кодогенерация в компайлтайме хуже кодогенерации в рантайме? Столько вопросов, но мало ответов. Всё таки Croco на лоре это точно не ты?
А можете объяснить, я захожу на Хабр Карьеру, вбиваю в навыки Rust и вижу 1 вакансию. Ок, на hh.ru делаю то же самое, 70 штук (вау, другое дело, казалось бы), но ни в одном заголовке вакансий нет слова Rust. Какие планы на жизнь, ребята?
>>2814397 Ему говорят в расте серьезные проблемы в дизайне, из-за кодгена макросов, примитивная продуктовая задача превратилась в звездец. Тот сливает тему на шарп, только о нем и говорит, хотя о нем в ветке обсуждения вообще не упоминали, но слился почему-то я.
Я сначала подумал, что ты тот местный тролль Серега, который просто пытается увести тему с раста на другой язык. Но походу ты реально шизик, ты даже не понял, ты его с воздуха взял. И ладно бы угадал, но на шарпе я в жизни не писал (ну может пару окон в юности, для перделок своих).
>>2814762 >Когда мы вызываем malloc, мы просто надеемся, что для неё будет достаточно пространства в стеке, и почти никогда этого не проверяем. Дальше стоит читать?
>>2814954 >В дизайне или библиотеке? Три раза написал - в дизайне языка. У вас даже хеллоуворд из кодгена.
>Из-за кодогена в рантайме который в других языках такое не может быть? Как видишь, не встречалось. Проблема то не в самом кодгене, а в его количестве.
>>2815121 Говорить говно потому что говно и в одной из сложных библиотек произошёл косяк значит язык говно, это пиздец как аргументированно прям как у того столяровского шиза, который не один тред набрасывал и в этом тоже отписался примерно в одно время с тобой вот я тебя и за него принял. Откуда мне знать что ты не тот душевнобольной, а просто похож на него.
Что то тяжеловато с сишным при работать Ручки так и тянутся по старинке все делать, а борроу чекер по рукам бьёт
Насколько хуевая идея пользоваться сейфовыми враперами для всяких вулканов и опенгл? Сильно ли по производительности бьёт и не добавляет ли слишком магических штук как например плюсовый враппер для плюсов От простых и ансейфовых у меня ручки чешутся обратно на си перепрыгнуть
Анончики, а есть REPL для раста с интеллисенсом? Лучшее что нашёл so far это https://github.com/evcxr/evcxr но интеллисенса очень не хватает. Люблю REPL, во всех языках с ним играюсь если надо по фасту проверить как та или иная штуковина
>>2800762 (OP) Я так понял, если выбирать раст, то ты сильно ограничен, не можешь использовать OpenGL, SDL, Qt и многое другое. От плюсов так просто не уйдешь.
>>2815790 Да, с кути придется ебаться Но все ещё не невозможно, на другие языки биндинги же есть Просто из за плюсового abi придется трудновато и никому особо не нужно
>>2815798 Кьют это фреймфорк для разработки ПО на С++. Он нужен разработчикам на C++ в первую очередь как некий способ организовать приложение с графическим интерфейсом на С++. Ну и набор библиотек с часто используемым функционалом для таких библиотек. Очевидно, что концепции применимые для С++ никогда не лягут полностью на раст, поэтому полноценно этот фреймворк никогда не получится (наверное — я с ним не знаком). Не знаю есть ли биндинги под раст, но даже если их нет, то доёбываться несколько странно. Так же можно сказать, а вот в расте нет React/AWT/Cocoa/MFC какого-нибудь. Это другая экосистема.
Добиваю растбук, возник один вопрос. В 17 главе на примере FSM показываются возможности раста в области ООП: https://doc.rust-lang.org/book/ch17-03-oo-design-patterns.html Пример описывает блог-пост, который имеет несколько состояний (черновик, ревью, публикация) и функции для перехода между ними. Приведено две реализации: инкапсуляция с помощью trait object и на типах в процессе компиляции. Авторы предлагают такое задание для самостоятельной работы: >Require two calls to approve before the state can be changed to Published.
Для реализации с помощью trait object решение довольно очевидное: добавляем счётчик в структуру состояния PendingReview, который увеличивается в методе approve(). В этом же методе делаем проверку на равенство счётчика двойке и возвращаем либо self либо новый экземпляр стейта Published.
А вот для реализации на типах что-то ничего не могу сообразить изящнее, чем завести вторую структуру PendingReviewPost2, которую будет возвращать approve() из PendingReviewPost. Счётчик применить тут не получится, по понятной причине approve() должен возвращать экземпляр конкретного типа. Со вторым типом всё будет работать, но блин... а если мы не 2 аппрува хотим, а 10?
>>2815988 Ну есть неполноценное веб-говно, qt это единственный полноценный фреймфорк для графического интерфейса. И для раста его нет.
>There are a number of bindings available today to existing frameworks, but those looking for a mature, easy to use, and completely Rust-based solution will most likely find themselves out of luck. https://areweguiyet.com/
>>2816013 Тебе перевести эту цитату, которую ты скопировал? Там написано, что нет зрелых полностью основанных на расте фреймворков. И это прекрасная возможность для амбициозных желающих проявить себя, кстати.
Кьют к расту прямого отношения не имеет. Биндинги есть, наслаждайся.
Не пойму твою мысль. Ты предлагаешь переписать кьют на расте? Или ты утверждаешь, что раст не пригоден для разработки десктопных приложений, потому что кьют не написан на расте? О чём речь? Сформулируй, пожалуйста.
Мужыки и дамы, будьте добры поделиться, кто сейчас работает на расте как с основным языком, с какого языка свичнулись? Как вкатились в раст, сразу шли как раст разработчик? Или перекатились по ходу?
>>2816277 Из тех, с кем работал и кто перекатился - все перекатились по ходу. Хотя вакухи иногда проскакивают - смотри в телеге rust_jobs_feed
В конторе по видеостримингу - делали на ноде что-то похожее на s3, только on premises и для видеоархивов. Заебались с нодой, переделали на расте. Ну и пришлось интегрироваться в прошивки некоторых камер/рекордеров/регистраторов - заебались возиться с сями, их зависимосями, типизацией и китайскими сумрачными гениями, запилили на расте. Этим занимались трое разрабов, двое теперь фулл-тайм пишут код на расте, один в основном на js/ts в ноде. У всех был опыт работы в гейдеве на плюсах. Когда переезжали на раст, я там уже давно не работал, но контакты поддерживаю, от туда и узнал.
В трейдинговой конторе была шарповая обвязка вокруг плюсового winapi/mfc клиента к брокерскому движку, я сделал grpc-обвязку на расте. Я об этой шляпе писал несколько тредов назад >>2568801 . Авторам либы вставили пистон, чтоб они переписали своё говно на Linux, и мою поделку теперь сопровождает и допиливает full time rust developer. Перекатился из шарпистов с бекграундом в плюсах.
На текущей работе (крипто-блокчейны) гошники заебались воевать с сишными/плюсовыми либами в go и сделали несколько микросервисов на расте. Теперь есть один раст-девелопер, перекатившийся из go, и одна девелопересса из плюсов.
В моей команде пилят вторую реинкарнацию криптобиржы, была на шарпах, и снова переписываем на шарпах. Пока думали, на чём переписывать, я предложил раст, но чот не зашло. Сделал прототип движка, который в разы обгонял шарповый прототип и по latency, и по throughput, но когда обозначили дедлайн - я сам и включил заднюю. Впятером за пол-года на незнакотом для большинства стеке такое не делается.
>>2816513 Работаешь в HFT? Алсо, как вообще относишься к этим биржам, просто для меня, как для обывателя в целом в этой области, выглядит как что-то непонятное, которое имеет риск развалиться в короткий срок. Хотя на тех же плюсах, на которых я работают, хватает вакансий в этой области.
>>2816605 Раст это конечно хорошо, но ЗП х2 это ЗП х2
>>2816609 Он тут не единственный кто на шарпах пишет
>>2816823 > HFT? И близко не HFT, скорее wannabe low latency > как вообще относишься к этим биржам Как к источнику денег и интересного для меня опыта, не более. Да, многие разваливаются, но конкретно в моей конторе биржа - не основной источник профита, так что сама она не развалится, но меня могут прост выпиздить в любой момент, если решат что наигрались в биржи. Если хочешь спокойно работать - ищи проект в топ-10 брокерах или мосбирже/спббирже (тут у меня опыт только по РФ), если есть много энергии и свободного времени и нервов - крипто- или финтех- или трейдтех-стартапы. Там до CTO легко дорасти лол. А если тема трейдинга тебе не интересна - лучше не суйся, а то выгоришь.
>Он тут не единственный кто на шарпах пишет Нахер тогда теплое прикладное место менять на околосистемный язык? Чтобы потом в бизнес-логике бороться с ограничениями языка и колебаться между unsafe/refcell и .clone
Уж что что, а в шарпах куда больше варинтов оптимизировать код, прежде чем его выкидывать совсем.
>>2817714 >На#вж#в##хевж#р товж#вжгдавж#в## тевж#пловж#в#е приклвж#адновж#в#е мевж#стовж#во менявж#ть на околосистевж#мнвж#ый язвж#в#ык? Чтобвж#ыв томвж#жпотом в бивж#зневж#с-ловж#гикевж#бовж#ровься с ограниченвж#иямвж#и язвж#ыквж#а и колебаться мевж#жду unvж#safvж#/refcvж#ell и .cvж#lonvж#е
>Увж#ж что что, а в швж#арпах кудавж#болвж#ьшвж#евж# ввж#арвж#интовж# овж#птимизироватvж#ь код, преждевж# чем еговж#выквж#иватvж#ь совсем.
>>2819777 Когда люди недогружены по работе, не придавлены тасочками, то у них появляется куча свободного времени и они начинают заниматься всякой хуйней.
>>2817714 > Нахер тогда теплое прикладное место менять на околосистемный язык? Потому что производительности тёплого прикладного места нехватает.
> Чтобы потом в бизнес-логике бороться с ограничениями языка и колебаться между unsafe/refcell и .clone А так приходится бороться с ограничениями рантайма и колебаться между async/await и span/ref struct, между библиотечными ф-циями для строк/массивов (в т.ч. linq) и самопальными для fixed array в unsafe struct. Бизнес-логика на расте выглядит почти так же, как и в шарпе, проблемы возникают когда тащишь данные от сетевого сокета к бизнес-логике и обратно, по пути записывая что-то на диск.
>Уж что что, а в шарпах куда больше варинтов оптимизировать код, прежде чем его выкидывать совсем. Код моего проекта сейчас находится на таком этапе, когда большинство вариантов оптимизации на latency/throughput влияют мало, а код ухудшают сильно.
>>2820054 >Потому что производительности тёплого прикладного места нехватает. Тесты на techempower показали, что другие вакуумные тесты производительности без реальных тестов приложений - это все тотальное нае..., и доказали что всякие жабы-шарпы - лихо идут в ногу с системными языками, или отставая не критично. а тех же тестах раст сосал несколько лет, пока асинки не завезли, оказалось технологии решают больше чем яп на llvm
Если в продуктовой разработке ты борешься с языком - то нафиг такой язык, потому как сопровождать его потом будет нереально.
>>2821014 Ну не маняврируй ты как, как раз это продуктовые тесты, которые ткунили носом всех любителей тестов в вакууме и показали, что не обязательно жрать кактус, чтобы выпустить продукт. да, дорогой анальник, не забывай что ты делаешь продукты, а не картины рисуешь
>>2820820 Только сегодня варил таску, что мозги от логики пухнули, если бы это были плюсы или расты, я бы обдристался от танца с бубном. Так что да, я не пишу на звезданутых языках и рад этому.
>>2821014 Как раз реальные тесты показали, что мало только взять "быстрый" язык. По опыту и тем тестам, ни раз видел как говнили писари на ваших плюсах и сях, с криком преждевременная оптимизация зло. Да, даже скажи спасибо этим тестам, раст хоть реально в топ попал (если не накрутили хайпующие), он буквально был на дне раньше, но самое смешное, что и тогда все заверяли про якобы сверхбыстрые http серверы на сверхбыстром языке, лол Там даже хайпленный nginx причмокивает.
Так что не удивлюсь, что твои петпроекты тормозят по уровню питона (как, кстати нередко бывает, смотри тесты) и язык тут не причем. А может даже и норм наборщехлебил у себя, но взял какой-нибудь либу не протестировав и она тебе все просадила внулину.
>>2821176 >Там даже хайпленный nginx причмокивает. Может посмотрят на этот позор и допишут нормально, веб сервер раста смогли же до ума довести, правда с тонной unsafe, что аж все это в драму вылилось хз, восстановил ли чел репозиторий, не следил за драмой
>>2821153 >>2821176 Тебе пора съебать из этого треда, пока ты не разберёшься в разнице между throughput (который показывают тесты на techempower) и latency (который они не показывают).
>>2821210 Только у таких домашних кодмонки могут не быть взаимосвязаны responses per second и latency. Ты просто сказочная радость, которая посмотрела на ютубе про хайлоад, но ничего не поняла.
>>2821210 >throughput В контексте производительности, насколько это вообще корректно сказать вне сетевой задачи (и отдадим должное тем гениям которые смешали эти понятия) - responses per second есть throughput.
Но мне действительно пора линять, ведь это безумие сидеть на анонимных форумах, где только что обоссаный, всего через мгновение, продолжит писать как не в чем не бывало. https://www.youtube.com/watch?v=1vgDUbK7Tao
ИГРАЕШЬСЯ С БПЛА @ УСЛЫШАЛ О НОВОМ СУПЕРЙОБА СИСТЕМНОМ ЯЗЫКЕ @ РЕШАЕШЬ ПОПРОБОВАТЬ @ ПРИХОДИТСЯ ОТКИНУТЬ ПОЧТИ ВЕСЬ ЯЗЫК @ ЯЗЫК ПРЕВРАЩАЕТСЯ В ХУДШУЮ ВЕРСИЮ СИ И АСМА @ ПРИХОДИТСЯ ПИСАТЬ КУЧУ ОБЕРТОК, ПОТОМУ ЧТО НА ГИТХАБЕ ЛИБО НИЧЕГО НЕТ, ЛИБО ОДНА ХУЕТА @ НИКТО ИЗ СООБЩЕСТВА НЕ МОЖЕТ ОТВЕТИТЬ НА ТВОЙ ВОПРОС, ПОТОМУ ЧТО ВСЕ ПИШУТ ВЕБ-ХУЙНЮ @ ЗАНИМАЕШЬСЯ АНАЛЬНОЙ ЭКВИЛИБРИСТИКОЙ, ЧТОБЫ УЖАТЬ БИНАРНИК ДЛЯ ЕГО ЗАЛИВКИ НА ПЛАТУ @ ПЛЮЕШЬСЯ И ПЕРЕХОДИШЬ НА ПЛЮСЫ
Тру стори, пацаны. Я, конечно, мог потратить неделю, чтобы разобраться с этим говном, но решил взять то, что просто работает и не ебать себе мозги. А на свободное время я поехал в горы, где с кайфом поползал и вдобавок нашел себе тянку, лол. Поэтому сделайте правильный выбор, мужики.
>>2821291 >У тебя на железке сколько места? На основной железке дохуя, можно хоть линукс крутить. А вот в модулях по-разному: от десятков до сотен килобайт.
>>2821279 Видел похожую драму в чате zig, в ембеддед не оч силен, но тыкал ли ты в зиг (он может вроде как си-либы подключать как есть)? Если тыкал выкати сюда мнение свое.
>>2800762 (OP) >Rust — невероятно быстрый язык для системного программирования без segfault'ов и с гарантиями потокобезопасности. справедливо ли утверждениеи что потокобезопасность и отсутствие сегментейшен фаулт (или бус еррор) достигается дополнительными проверками за счет потери в скорости исполнения?
>>2821339 Зависит от программы. В основном все дополнительные проверки специфичные для раста осуществляются на этапе компиляции, но некоторые структуры данных, например RefCell<T>, делают это в рантайме. В остальном всё как в плюсах.
>>2821310 Будто на сишке стандартную библиотеку не отключают.
Мимо-эмбед-разраб, наелся говна с newlib в многопоточном FreeRTOS, планирую выкинуть её нахер, всё равно только для работы со строками в проекте нужна.
>>2821339 В какой-то степени так и есть, например проверка границ массива или rc, refcell. Вообще с последними страданиями ембеддед господ, можно сказать, что раст и не совсем системный язык. А для прикладных задач избыточно затрахательный. В общем, этакий промежуточный уродец между си и жабо-шарпами.
Но проблема тут не в этом, раст хорош и имеет право на существование, если его так и позиционировать, честно. Но гейский маркетинг так заливает в уши, что ты приходишь к правде спустя n-количество времени и n-страданий и после ощущаешь тотальную фрустрацию (что тебя наеба...). Отсюда и такая реакция и такое обилие хейтеров (сами себе насрали, глупые гей-хипсторы).
>>2821604 Чудес не бывает. Я не шарю в теории ЯП, но попытаюсь объяснить своё понимание.
Раст предлагает относительно уникальную модель владения и заимствования "значениями" и форсит её на весь код ещё на этапе компиляции. Таким образом компилятор выступает в первую очередь как статический анализатор кода, а всё быстродействие и кроссплатформенность идёт от плюсового бекэнда llvm.
Так уж сложилось, что в нашей грёбанной Вселенной статический анализатор не в состоянии разобраться во всех нюансах программы в общем случае. Это математически доказанный факт, см. проблему остановки.
Поэтому перед создателями раста встал интересный вопрос — что делать с программами, про которые невозможно алгоритмически (т.е. на этапе компиляции) сказать верны ли они с точки зрения предлагаемой модели или нет? Из двух зол: пропустить потенциальную ошибку или пофейлить сомнительный, но корректный в итоге алгоритм — они выбрали последнее. Поэтому так сложно сходу написать валидный код, зато это даёт программисту уверенность, в том что ошибки связанные с памятью в нём точно отсутствуют.
К сожалению, как оказалось значительную часть программ просто невозможно написать в таком духе. Поэтому возникли unsafe блоки, в которых часть своих правил компилятор не проверяет (их реально не много кстати, штук 5 всего лишь). Предполагается, что программист будет использовать их осознанно и только в том случае, когда задуманное невозможно сделать иначе. В отличии от компилятора человек обладает знанием контекста программы, и таким образом может прикрыть его слабые стороны. Уже из этого и растут дополнительные проверки, которые есть в стандартной библиотеке для некоторых структур данных, это как раз то, что может человек и не может алгоритм.
Утверждать, что все операции в расте предполагают "растовый рантайм" неверно. Только часть в стандартной библиотеке. Такие вещи, как проверку выхода за границу массива я даже не рассматриваю как оверхед. В 80% случаев если это не делает стандартная бибилиотека, это делает программист руками. Растовый рантайм заключается в проверке владений и заимствований. При этом это настолько минимальный рантайм, насколько это возможно, особенно сравнивая с решениями, использующими сборщик мусора.
Подведя итог, с моей точки зрения раст предоставляет определённый компромисс между комфортом, производительностью и надёжностью с перекосом в сторону последней, но при этом оставляет возможности программировать настолько эффективно, насколько это возможно. Подходит ли это каждому? Не думаю.
>>2822920 Сборщик мусора не бесплатная вещь, он потребляет сильно больше процессора чем ручное освобождение. Требует большого запаса по памяти, чтобы работать эффективно.
>>2822920 Да, потому что сборщик мусора работает во время работы программы. Что такое проблема остановки на пальцах: ты смотришь на алгоритм и на начальные входные данные, нужно понять завершится он когда-нибудь или нет. Оказывается, что в общем случае, т.е. для всех алгоритмов и данных, это невозможно сделать, не запуская саму программу. К этой проблеме сводятся многие другие задачи, вот в частности анализ программы на расте. То что компилятор не может "понять" он отказывается компилировать и переносит на плечи программиста. Ещё раз повторю, это то как я понимаю уникальность раста, я могу ошибаться.
>>2822705 >Такие вещи, как проверку выхода за границу массива я даже не рассматриваю как оверхед. Ну конечно, проверить границу один раз или 200 миллионов раз. Разницу не ощутим. Кодмонки вечно думает в рамках своих крудов.
>>2823725 Кодмонки поднабрался немного опыта, пока писал свои круды и знает, когда надо переживать о производительности, а когда это выеденного яйца не стоит.
Вот тебе простой пример. Пусть где-то имеется массив размером 200 миллионов элементов и два программиста решили написать функцию для его инициализации: 0, 1, 2, ...
Первый использовал константу в цикле, а второй благоразумно воспользовался функцией для чтения длины массива. И что мы видим в результате компиляции? Уже на первом уровне оптимизации все лишние проверки во втором варианте были выброшены. В первом варианте они остались, потому что компилятор всё-таки не может знать заранее, массив какого размера передадут в функцию.
>>2823894 >В первом варианте они остались, потому что компилятор всё-таки не может знать заранее, массив какого размера передадут в функцию. Тогда что ты нам грязные штаны показываешь?
Ты не улавливаешь смысл, мы не платим за то что сами не написали, если там иногда какая-то магия проверки срабатывает, а иногда нет, так это уже какое-то руби-жопоскрипт-программирование, а не системное. Прям безопасное ub, которое мы заслужили.
>>2823904 Да, что-то не улавливаю. "Магия" проверки срабатывает всегда, но исключается на этапе компиляции, если можно гарантировать корректное поведение, так что это не влияет на производительность. Не вполне понимаю, где ты там UB увидел. Это же именно твои слова выше: >Ну конечно, проверить границу один раз или 200 миллионов раз. Разницу не ощутим.
>>2823725 >Кодмонки вечно думает в рамках своих крудов. Кстати, а ты что пишешь на работе? Если она есть Всегда было интересно знать что пишут настоящие программисты. Мимо
>>2815767 Вчера сам заинтересовался темой репла для раста, попробовал этот evcxr. Прикольно, работает, но наверняка есть какие-нибудь ограничения. Как минимум в доках сказано, что нельзя использовать макросы из внешних крейтов и делать глобальные ссылки на глобальные переменные. Касательно твоего вопроса там по умолчанию дополнение по двойному табу. Думаю попробовать прикрутить к емаксу, но в функционале явно не хватает загрузки файла и выгрузки контекста.
Ещё у них в README упоминается IRust. В моём дистрибутиве его нет, поэтому не пробовал. Судя по описанию, будет пофичастее.
Шутить про чулки, думаю, уже не имеет смысла, поэтому давайте разберем действительно важный вопрос, ведь без этой вещи нормально программировать нельзя, компилятор отказывается работать. Какие шрифты используете?
>Thanks to its direct access to both hardware and memory, Rust is well suited for embedded systems and bare-metal development.
А что вообще имеют ввиду когда говорят что какой-либо якзык имеет "direct access to both hardware and memory"? Что именно раст/си/цпп могут сделать с железом чего не могут "высокоуровневые" языки? Я когда-то раньше ардуинкой/stm32 интересовался и там было что-то вроде такого что чтобы котнтрлировать поведение пина нужно записать определённый бит паттерн в определённый адрес в памяти (хотя поверх всего этого есть hardware abstraction layer) - это оно?
>>2829111 Да это оно. А ещё прямой доступ к состоянию регистров на проце, чтение флагов процессора и всякое такое. Реализуется обычно ассемблерными вставками.
>>2829111 >>Thanks to its direct access to both hardware and memory, Rust is well suited for embedded systems and bare-metal development. Только в реальности ембедшики, я так понимаю, плюются, а кругом одни веб-макаки натягивают сову на глобус.
>>2830313 Эмбед это очень консервативная область и раст ещё не скоро будет в ней популярен. Например, во почти во всех проектах на плюсах, в которых я принимал участие, стандартная библиотека была под запретом из-за того, что шаблонный код сильно раздувает бинарник. Сейчас к слову пилим проект на C99. С опаской перешли с gcc 9-ой ветки на 10-ую.
>>2830367 Ну не везде, хотя кресты мы выкидывали полностью (идеологические и практические причины у "тимлида"), но компилятор и шланг и гцц всех версий юзали, лишь бы сжал получше
Какая эмбедщина на всрасте если у него программы по 20мб. Для эмбедщины зачастую и сишная библиотека черезмерная, не то что плюсовая.
Тем более ржавчина которую вообще то для прикладного ПО задумывали но как обычно тараса понесло куда угодно только не в приклад, который продолжают говнокодить на шарпе, си и плюсах обмазанных пистонами и другими скриптами. А все потому что просто так сишные библиотеки с [sp]пидо[/sp]растом не линкуются, без node-подобной инфраструктуры не компилируется и без IDE пидораст не программируется.
Его бы могло спасти появление .Net/Mono - подобия, с прикладным абстрактным апи, но этого не происходит, его пытаются тупо присунуть куда присунется.
>>2830537 > Какая эмбедщина на всрасте если у него программы по 20мб. Не пизди, пожалуйста. Пиздаболище лесное. При наличии прямых рук, можно килобайт до 500 ужать, до мегабайта легко. Смотри опции оптимизации.
>Для эмбедщины зачастую и сишная библиотека черезмерная, не то что плюсовая Рукожопам всегда что-то мешает. То язык не тот, то железо не то, то синтаксис не тот, то страна не та.
>сишные библиотеки с [sp]пидо[/sp]растом не линкуются Всё там линкуется, долбоёб. Не надо дезинформировать людей.
>>2830543 > Рукожопам всегда что-то мешает. > При наличии прямых рук Дожили, теперь с языком и его системой сборки надо трахаться как с настройками винды или андроида что бы добиться желаемого. При этом еще система сборки декларативная, ладно пакетный менеджер, для них это нормально, но порядок сборки то зачем декларировать. Реально какие то пассивные гомосеки разрабатывали, которым без жесткой руки на себе одиноко и некомфортно.
То же самое кстати касается яблочного высера свифт - не ты пишешь (желаемую) "жопу", алоцируешь и ебешь, как в нормальных языках, а расписываешь свой ass по базовому переписываешь нужные методы ебки снимаешь штаны и ждешь. Какое то метапрограммирование через прикладное апи
Вот что бывает когда технологии разрабатывают не ученые из институтов, а корпоративные петухи с пробкой в анусе.
>>2830573 Ну вот lto и валгринд для кого по умолчанию встроены? Для системщиков или может для микроконтроллеров? Да даже на сайте раста (раньше по крайней мере) сходу предлагали написать вместе простой калькулятор.
>>2831467 Ну там шоб сеть (клиент/сервер), треды / ивенты. Всякая хуйня для быстрой разработки приклада.
Может не как моно а скорее как кутэ, но в куте гуй встроенный, а он (еще один велосипедный) нахуй не нужон. Как то там моно линковалось и линкуется с gtk-2/3, как то окна и меню на них рисует, вызывает файловый менеджер при выборе файла.
Просто блять в противном случае раст из далека выглядит как нода или скорее хаскель с кабалом - пустой язык с пакетником полным барахла разной степени захерелости, собирай из этого шо хочешь. Ноде то вон электрон и nw завезли, ее хоть начали для чего то внятного использовать.
Уф, наконец-то закончил растбук. Хочу поделиться своей статистикой с вкатунами (ну и похвастаться, чего уж там). Читал от корки до корки, попробовал почти каждый кусок кода, в непонятных случаях играл с изменениями, чтобы посмотреть что получится. Всё это заняло ровно два месяца или трое суток "чистого" (почти) времени. Старался уделять час-два каждый день этому занятию.
Помимо этого прошёл rustlings, решил 51 задачу на литкоде (начал решать после 6-ой главы) и пофиксил багу в одном опенсорсном проекте на расте, который сам постоянно использую. Правда бага оказалось не в самом растовом коде, лол, но это ничего, зато я получил представление о том, как делаются современные десктопные приложения на расте под гном. Потом ещё с парочкой похожих проектов ознакомился.
Теперь неплохо бы сделать карточки по сделанным записям для запоминания и приступить к своему проекту. В целом пока всё нравится. Офигел только от объёма, который занимает сборка небольшого по своей сути приложения. 3.5G, серьёзно? Но сам язык ощущается очень приятным.
>>2831949 Я не силен в шарпах, но насколько помню открыт и доступен был только Core Net (то есть видимо базовая библиотека + jit наверное), а DotNet был долгое время эксклюзивом винды пока его тоже не открыли и портировали на линупс не так уж и давно на самом деле.
Вот только про гуй и приклад на дотнете под линукс я не слышал, насколько я понимаю оно пригодно только для написания бакендов и других сервер-сайд приложух, что бы отжать долю у жабы, так как языки по сути конкурирующие. А благодаря моно появился фреймворк юнити, который сейчас в определенной нише рулит и педалит.
>>2831944 Ачивки для мотивации и были придуманы, что же в этом такого? Раст учу для себя, потому что интересно. По работе есть пару минипроектов на нём, думаю присоединится.
Карточки пока использовал только для изучения естественных языков, показали себя неплохо, хочется попробовать и в технической области. Понятное дело не для того, чтобы объявление переменных заучивать, а для каких-то редко встречающихся вещей. Например, бегло просматривал приложения в растбуке, встретил описание символа @ и осознал, что к этому моменту напрочь забыл, когда и зачем он используется.
>>2832564 Мозги немного по другому работают, как-то нужен был c/c++ (тогда еще их вместе обмазывали), я его выучил, но писал пару раз в год. В общем, я его каждый раз заново учу лет 15, так как без конкретной цели и долбежки каждый день кода руками, хер там что закрепляется в голове (и не надо выеживаться что ты дитё индиги и только на одном юношеском максимализме - все могу, это вывезешь).
Цель инструмент ради инструмента это борщехлепство. Твоя цель должна быть не на язык дрочить, а конкретный результат/софт/технология. А то будешь как местный Сережа.
>>2832961 Прекрасно понимаю, у меня такие же отношения с питоном. Ты видимо уцепился за слово "вкатун". За меня не переживай, я уже наносек-сеньор-помидор, всё как положено. Я имел в виду только сам раст. А вкатываться в погромирование, начиная с него и уж тем более с растбука, я бы никому не посоветовал.
>>2836095 Работа есть только для конкретных областей айти (в рашке это банкинг, клиент-сервер, андрюхаприложения). В каких областях у нас доминирует раст? Что ты за глупые вопросы задаешь, раст на сегодня чисто для энтузиастов.
Извиняюсь за довольно глупый вопрос но как мне лучше разделить данные на "чанки" по три байта? Мне нужно что бы итератор сразу возвращал 3 отдельных байта за шаг. Или это можно как то сделать ещё во время чтения?
Грозит собес на раст. Я собственно не растовик даже, писал на нем немного энное время назад, но забыл уже все. Что глянуть чтобы хоть минимально подготовиться?
>>2838470 Как классно наблюдать, что на нем как было, так и будет полторы вакансии, потому что, внезапно, мертворожденная хуета Любые попытки "убить" Си/плюсы обречены
Что-то хвалёные передача владением и итераторы оказались медленнее старого доброго перебора в цикле. Пытался через свёртку в хешмапу или в слайс подсчитать количество встреченных букв в строке (закомментированные строчки), оказалось в 10 раз медленнее обычного перебора. Такое ощущение, что аккумулятор в свёртке полностью копируется на каждой итерации, вместо ожидаемой передачи значения. Хотя в другой задаче я использовал такой же трюк и проблемы не было.
>>2838526 > Такое ощущение, что аккумулятор в свёртке полностью копируется на каждой итерации
Такое ощущение, что у тебя каждую итерацию вычисляется хеш и поиск по мапе. Просто сделай статически массив в 26 символов, у тебя отображение 1 к 1. В идеале еще от потенциальных паник избавиться, но наверное пофиг.
>>2838597 Тащит свои библиотеки не линкуется с системными. Сам по себе сложный и перегруженный. Сложная система сборки. Зачастую чужой проект не собирается по причине того что он использует какие то экспериментальные фичи из ночной сборки, надо удалить дефолтный из репозиториев и устанавливать rustup с сайта по инструкции, и вот только тогда оно соберется/скомпилируется.
Так же раздражает генерация кучи какого то мусора и папок/подпапок. На самом деле практически тоже делает cmake но тут еще в более фимозной форме.
>>2838597 А ну и самое главное - все это напоминает ноду жс, где пока в инфраструктуре не разберешься ничего собрать или запустить несможешь. Единственное может отличие это то что если в говноде каждый год одна система сборки/пакетирования устаревает и появляется новая более модная, то тут хотя бы одна. Но минус в том что она не скриптовая как make/cmake/qmake, а блять конфигурируемая. Надо конфиг правильно по шаблону задавать, короче пространства для полета нихуя нет.
>>2838764 Нет не я. Но я вспомнил что кто то мне уже кидал мануал про билдскрипты, они еще помоему на самом расте пишутся, что конечно дополнительное очко к ебанутости.
Глянул снова, так это же сишные плюсовые файлы собирать, и нахуй оно нужно? Выглядит как костыльный инструмент для постепенного переписывания проектов с си/срр на раст, за такое вообще казнить надо.
>>2838828 Ну так это не скрипт для сборки проекта на расте. И не на скриптовом языке, а блять на расте со всеми его типами и конструкциями, но отсутствием вот таких вот элементарных вещей https://rune-rs.github.io/book/template_literals.html Вроде как раст системный язык, но почему то на него пытаются все функции навесить, а ведь в чем проблема сделать простой скриптовый язык и интерпритатор к нему на расте, да и ввести режим интерактивной поэтапной сборки по типу cmake или meason. Нихуя, ишь че захотел, только одна мова, одна вира, одна система сборки.
>>2838959 >Ну так это не скрипт для сборки проекта на расте. А что? >И не на скриптовом языке, а блять на расте со всеми его типами и конструкциями, но отсутствием вот таких вот элементарных вещей https://rune-rs.github.io/book/template_literals.html Каких вещей нет? Чтения переменных окружения и форматной строки? >Вроде как раст системный язык, но почему то на него пытаются все функции навесить, а ведь в чем проблема сделать простой скриптовый язык и интерпритатор к нему на расте Какие проблемы решает отдельный язык? >да и ввести режим интерактивной поэтапной сборки по типу cmake или meason В чём проблема собрать проект на расте с помощью cmake или meson?
>>2838988 >А что? Интерфейс для сборки си/с++ исходников в коде проекта либо неродных модулей. > Чтения переменных окружения и форматной строки? Да, шаблонов нет, как и много всего другого, шела к примеру > Какие проблемы решает отдельный язык? Скриптовый язык (да и вообще любой другой) решает не проблемы, а задачи. Задачу написания сценария сборки. > В чём проблема собрать проект на расте с помощью cmake или meson? Запустить cargo build это не сборка при помощи cmake или meason. Хотя на мейзоне можно наверное карго-томлы генерировать из шаблонов, но это какое то извращение уже.
>>2839019 >Интерфейс для сборки си/с++ исходников в коде проекта либо неродных модулей. Это не так. Прочти дальше первого предложения по ссылке выше. >Да, шаблонов нет, как и много всего другого, шела к примеру Шаблоны: https://doc.rust-lang.org/std/fmt/index.html "Шел" (если я правильно понимаю, что ты так называешь запуск других процессов): https://doc.rust-lang.org/std/process/index.html Что ещё другого тебе не хватает? >Скриптовый язык (да и вообще любой другой) решает не проблемы, а задачи. Задачу написания сценария сборки. Приведи конкретный пример задачи, который невозможно/очень сложно реализовать в рамках предлагаемой системы сборки. Хочу посмотреть. Кстати, в данном контексте слова проблема и задача можно назвать синонимами. >Запустить cargo build это не сборка при помощи cmake или meason. Так запускай rustc, в чём проблема? meson кстати, а не meason, смотрю ты даже не пользовался тем, за что так яростно топишь, раз второй пишешь с ошибкой. Произносится [ˈmiːzɒn], держу в курсе.
>>2839049 Я так и понял что ты обычный гуманитарий свидетель раста. > Шаблоны: https://doc.rust-lang.org/std/fmt/index.html >The format! macro is intended to be familiar to those coming from C’s printf/fprintf functions or Python’s str.format function. Блять, съеби отсюда нахуй, наркоман ебучий.
>>2839344 X вместо Y могут советовать только религиозные фанатики, zig это более консервативное раст-подобие притендующее на альтернативу си и плюсам в определенных сферах. Это просто более правильный подход, однажды может быть пригодиться вместо си или плюсов. Что касается раста то опыт у меня бекпортирование проектов (библиотека и программа). Бэк потому что изначально код был написан на одном языке, но авторы на волне растомании бросились в присядку переписывать на раст. Автор библиотеки молодец все переписал и даже улучшил, но беда в том что вместо сишных и плюсовых субмодулей, с гитхаба, которые гораздо лучше подходят под целевые задачи, постоянно развиваются и в них можно реквестить, ему естественнопришлось обмазываться модулями из репозиториев карги, причем как очевидные так и сомнительные, короче человек увлекся и забыл что это библиотека и ей положено быть легкой и компактной и плюс еще раст либы не линкуются просто так, там надо экспортировать функции в си/с++. Второй переписал самое легкое связанное с io, на другом у него sdl был и его фукционал просто был обернут в плюсовые классы, методы вызывали сишные функции с указателем self структуру, все просто и главное работает, но он решил на расте не сишные вставки делать которые довольно ублюдочно выглядят, а переписать на расткоде как положено - прыгнул на ночную ветку сгреб все самое новое с репозиториев всякую хуйню для окон и графики, писал писал и бросил нахуй. Я посмотрел оно даже работает правда там половины нет, а кода уже пиздец и читать вот это все нагромождение вложенных друг в друга функций тяжело.
>>2839245 >Блять, съеби отсюда нахуй, наркоман ебучий. Ну вот, хорошо же общались. Честно, не понял о чём ты, можешь гуманитарию попонятнее объяснить? >>2839248 Т.е. скрипт сборки на зиге это ОК, а на расте это не ОК? Всё правильно понял? Но вообще-то я просил конкретный пример, который проблемно сделать на растовой системе сборки.
>>2839740 > вообще-то я просил конкретный пример Я тебе принес пример, чем он тебе не нравится? У разработчика свое представление как должен выглядить его проект и как его собирать под разные контроллеры. Но пидораст говорит - "нет". Учи сука мануал какие есть ключики хуючики параметры и поправляй код под них.
Это для таких как ты такое программирование в радость, когда надо больше читать чем применять, и ходить на форумы доказывать какое это для всех благо.
>>2839799 Каюсь, пролистал по диагонали. Видимо "проблемы" системы сборки на пике. В первой проблеме автор хочет от раста сишных ifdef'ов. Я бы на его месте сделал типаж для контроллера и параметризовал им аргумент функции read_keys. Это встроено в язык, возможности системы сборки тут не нужны.
Проблему с RTIC можно решить кодогенерацией, это как раз одно из основных применений build.rs. Т.е. в зависимости от устройства генерировать разные входные точки.
>>2839873 > пролистал по диагонали. > от раста сишных ifdef'ов Судя по всему еще и жопой. Автор в статье как раз кидает камень в сишные макросы, якобы растовые хоть и замудреные по сравнению с зигой зато не сишные.
Лично я на его примере наоборот вижу ущербность растовых макросов по сравнению с сишным препроцессором. Точнее я вижу синтаксическую конфетную обертку над ifdef, то есть где то в файле конфига вбивается таргет, и в макросе прописано какой именно блок включает. И чем это отличается от тупого
cc .. -DARCH_KN232
#ifdef ARCH_KN232 ... #endif
? Ущербность если что в том, что сишный препроцессор может не только играть в "убери лишнее", но и инклюдить допустим файл с функциями целевой архитектуры, что удобно. В расте же макросы приколочены к талмудам (к вопросу о простой компиляции файлов "скриптами") и теперь еще придется каждую ревизию не изменилось ли чего, а то хуяк и поменяли что нибудь. Тепер. Секция называется не futures а ckukolds и перенесена в другое место.
> Ещё примеры? Определение архитектуры, наличия у нее fma библиотек в системе. Для раста это все не актуально в прочем, у него свои библиотеки из своих репозиториев. Но допустим завтра в дистрибутивах начнут появляться раст-библиотеки с сишными abi и заголовками, все как положено как сборочная система раст это учитывает? Можно не отвечать.
>>2840081 >Определение архитектуры, наличия у нее fma библиотек в системе. Можно подробнее? Что там не так с определением архитектуры? Что такое "fma библиотеки"? Первый раз такую аббревиатуру встречаю. >Но допустим завтра в дистрибутивах начнут появляться раст-библиотеки с сишными abi и заголовками, все как положено как сборочная система раст это учитывает? Что именно она должна учитывать? Ты динамическую линковку имеешь имеешь в виду?
Твой высер про макросы распарсить не смог, прости, больше похоже на бред душевнобольного. Какие ещё талмуды?
>>2840174 fma это инструкции fma, а библиотеки это , библиотеки. Но это не важно. > Что именно она должна учитывать? Ты динамическую линковку имеешь имеешь в виду? Имею в виду линковку с библиотекой из линуксового репозитория. Да и вообще просто стороннюю. > спойлер Потушись, шизик. Талмуды, это очевидные .toml -ы Те что в пидорасте играют роль package.json + .bebelrc из ноды или . cabal из хаскеля. Кстати в доках по хаскелю специально пометка для упертых шизиков есть: >Cabal’s build system for simple packages is considerably less flexible than make/automake, but has builtin knowledge of how to build Haskell code and requires very little manual configuration.
>>2840174 А ну и вторая часть о том, что пальцы по экрану не попадают а яндекс клавиатура на хуйню исправляет со временем может выходить новый стандарт/версия конфигурационных файлов (что обычное дело) но вместе с ним получается могут поламаться нахуй еще и макросы, бегай потом код еще поправляй. А все из за того что какой то умный долбоеб придумал препроцессор связать с файлами конфигурации проекта.
>>2840369 >fma это инструкции fma, а библиотеки это , библиотеки. >Имею в виду линковку с библиотекой из линуксового репозитория. Да и вообще просто стороннюю. За машинный код отвечает llvm, он скомпилирует под указанную платформу, оптимально используя доступные инструкции, но при желании можно ему дополнительные флаги передать. Сторонние библиотеки может поискать тот самый build.rs: https://doc.rust-lang.org/cargo/reference/build-script-examples.html#linking-to-system-libraries . Слинковаться тоже может, как по твоему вообще программы на расте работают? Пустой helloworld пяток зависимостей имеет.
>>2840392 >может выходить новый стандарт/версия конфигурационных файлов (что обычное дело) но вместе с ним получается могут поламаться нахуй еще и макросы, бегай потом код еще поправляй. А все из за того что какой то умный долбоеб придумал препроцессор связать с файлами конфигурации проекта. Как они связаны? Атрибуты (ты же их макросами называешь, да?) cargo указывает с помощью флага --cfg у компилятора (rustc). Примерно так же как и дефайны условной компиляции указываются с помощью флага -D у gcc/clang. Если таковое воображаемое событие наступит, воспользуешься возможностью указать произвольные флаги компилятора.
Так, что ещё плохого видишь в растовой системе сборки?
>>2840456 > За машинный код отвечает llvm > он скомпилирует под указанную платформу, оптимально используя доступные инструкции, Главное верить.
>но при желании можно ему дополнительные флаги передать Мы вроде про систему сборки говорили, а ты уже про прямые флаги компилятору. Это признание что сборочная система не справляется? > Атрибуты cargo указывает с помощью флага --cfg у компилятора (rustc) Так cargo указывает, а не ты. Тебе надо забивать в cargo все ключи которые он передаст копилеру. А потом выходит Manifest v3 и говорит что так как было по старому небезопасно, переделываете. > Примерно так же как и дефайны условной компиляции указываются с помощью флага -D у gcc/clang. Я об этом и говорил что растовые макросы в сущности мало чем отличаются от этого, при этом могут гораздо меньше > Сторонние библиотеки может поискать тот самый build.rs Судя по примеру как раз не может, раст не умеет работать с *nix пространством путей, у него все должно быть прописано в его собственных глобал/локал вариаблах, а в os::env он может только попытаться найти библиотеку для си и то только в определенной переменной, помск в LD_PATH я так понимаю не предполагается.
Всё. Я теперь понял что в нем не так. Раст делали разработчики сидящие на винде, где трудности с менеджерами пакетов, в системе нет posix env, а системные библиотеки никому не нужны. Теперь все понятно, вердикт - закапывать.
Какое отношение архитектура и библиотеки хост-системы имеют к процессу сборки? Сборка проводится в изолированном окружении, у неё своя система разрешения зависимостей, любые бинарные артефакты ничем друг от друга не отличаются. То что диды лол, автозамена исправляет на "жиды" устраивали мусорку из хоста и ассьюмили его как таргет - это было от безысходности, а не потому что так надо.
>>2840617 Прямое, разработчики программы собирают не сами для себя, а для пользователя. Пользователь бывает разный с навороченой пкой и старенькой, может быть коммерческим/ведомственным и требовать пользоваться только проверенной библиотекой из состава дистрибутива и линковаться с непонятно чем с возможными дырами нулевого дня. Так же пользователь может быть энтузиастом или маинтейнером дистрибутива, да не болгеноса а авторететного стабильного дистрибутива с коммерческой поддержкой серверов клиентов. В конце концов это может быть другой разработчик, который хотеть что-то свое.
Нет каких то единственно правильных решений, есть единственно неправильный подход - придумывать серебренные пули от поноса и головной боли одновременно.
>>2840544 >Это признание что сборочная система не справляется? Ты сам выдумал какую-то гипотетическую ситуацию, в которой разрабы поломали обратную совместимость и не продумали механизма миграции. Нет большого смысла детально обсуждать то, что не случилось и к чему нет предпосылок. Я всего лишь указал, что даже это можно решать базовыми средствами. >Судя по примеру как раз не может, раст не умеет работать с *nix пространством путей, у него все должно быть прописано в его собственных глобал/локал вариаблах, а в os::env он может только попытаться найти библиотеку для си и то только в определенной переменной, помск в LD_PATH я так понимаю не предполагается. У нас разные примеры? Мой предлагает использовать самый обычный pkg-config, заботливо обернутый в удобный растовый крейт: >This will likely only work on Unix-like systems with pkg-config installed.
Как я понимаю, с реальными примерами проблем мы закончили и перешли к выдумкам и фантазиям. На этом предлагаю дискуссию завершить. Думаю здравомыслящие аноны поняли несостоятельность претензий к cargo.
>>2840669 Рат же не подходит для гейдева из-за мучительно медленной компиляции и отсутствия нормального кэширования и какого-либо хотлоадинга. помню читал в ишшуях эпопею про то, как они это начали пилить, потом обосралтсь, потом выпилили обратно, ну и короче это годами тянется, воз и ныне там
Причём никто об этом в комьюнити ресурсах старательно старается не упоминать, лол
>>2841059 Еще с итераторами беда. Гейдевам итератор нужен не в цикле а при очередной смене фрейма (вот костыль https://github.com/hepek/ri ) Банально что бы текст тот же печатать по словам. Зачем в мозиле сделали итератор сделали таким - загадка. Хотя разгадка скорее всего кроется в js, в необходимости реализовать Object.keys() Object.values() и других итерируемых объектов вроде Set и Map. На плюсах помоему тоже itter_type или что то такое используется.
>>2843492 Чтобы печатать текст по словам используется асинхронное программирование, в частности CSP. Вообще в целом это не имеет отношения ко встроенным типажам для итерации по коллекциям (которые в расте как раз таки корректные).
>>2843492 >с итераторами беда У раста же? Тогда почему по твоей ссылке >This is an attempt to reproduce Rust-like iterators in C++ в расте такие хорошие итераторы, что их переписывают для цпп?
>>2843507 Плохие и хорошие - это воспитатели в детском саду.
Плюсовый итератор создан для последовательного чтения/записи: https://en.cppreference.com/w/cpp/iterator/next Оастовый для перечисления элементов. Кому то понадобился легковесный итератор как в расте он написал IIterator. Можно ли плюсовый реализовать на расте я не знаю, у вас же те же файлы на чтение/запись реализованы как в свифте асинхронным блоком.
>>2843528 Так а в чём беда-то? Вернее, что иллюстрирует твоя ссылка, что там за костыль? Растовый итератор реализуют в цпп, при этом в расте с итераторами беда. Я бы понял, если бы ты принёс гейдев проект на расте, где из других языков переписывают итераторы, потому что в самом расте с ними беда, тогда бы это подкрепляло твои слова. А так выглядит будто ты не ту ссылку скопировал.
Говорят, что если будешь программировать на (пида)Расте, то сразу станешь сиссибоем и начнешь кончать попкой. Стоит ли пробовать, или это опять пиздёшь?
>>2843668 Пример не накидаю, когда возьмусь за движок, тода и накидаю. Но примерно там засада в том что есть например большой файл с диалогами. Один итератор смотрит на кусок диалогов сцены, второй на диалог персоонажа, проходит построчно при этом каждый символ печатается при всплытии frame update. Если зажат пропуск то например вместо символа печатается вся строка или хуй его знает, это уже подстраиватется под визуальное ощущение.
Еще итераторами нужно будет обходить коды эффектов которые тоже в файлах записаны в своем формате. Все привязано к фреймам естественно, это не числодробилка, это не вычисления, твой раст тут порвут на части блять, ты не лезь сюда, подумай блять
>>2843668 > Ну так раст - функциональный язык Ну так я и говорю что он как под жавакрипт был сделан, что бы максимально просто методы интерпритировать и компилировать.
>>2843718 >Один итератор смотрит на кусок диалогов сцены, второй на диалог персоонажа, проходит построчно при этом каждый символ печатается при всплытии frame update.
А причем тут итераторы-то? Рендеришь всю реплику за раз, потом выводишь на экран по маске, маска динамическая по времени.
>>2843718 > проходит построчно Третий проходит построчно конечно же. Смысл его в том что бы допечатывать предложение/два и вставать что бы человек прочитал и нажимал, либо выжидалась задержка.
>>2843729 Еще раз это не нейронка, это нельзя просто циклом обойти и в файле у тебя не бинарные данные которые надо декодировать а то и просто прочитать, а свой фармат который надо интерпритировать. >>2843730 Пререндер это конечно прекрасно, но его все равно надо каждый фрейм кусками переносить на экран, да еще реагируя на клацанье пользователя.
>>2843734 У меня есть опыт рендеренга текста на js в canvas и на Cи через SDL. Остальное дело техники ну и формата файлов с контентом, с которым придется иметь дело. Я не гейдев, просто есть желание написать несколько свободных движков под уже имеющиеся игры.
>>2843752 Fps это frames per second Как блять тебе игры анимации показывают а плеер 1,5мб играет по несколько минут? Да все нахуй циклами за наносекунды проигрывается/рендерится, а потом наверное фея времени делает все по нормальному. Есть вон движок дума3 и квейка3 на си и плюсах, надо посмотреть как там с кадрами все это синхранизовано. Может в SDL специальные калбэки есть, потому что на жабаскрипте в браузере внезапно есть window.requestAnimationFrame().
Хотя музыка неудачный пример, там то как раз как в нейронке граф/синусойда по дельте высчитывается из сжатых данных. А в аудио-cd и на пластинках дорожки напрямую читаются и проигрываются в реальном времени. Но видеоформат это уже фреймы и совсем другое, хотя ноги тоже растут от пленочных проекторов.
>>2843718 Анон, ты первокур, да? у тебя очень смутное представление о вещах, о которых ты говоришь. Никаких проблем с этим нет и интерфейс итераторов тут вообще никаким боком.
>>2843725 Нет, по окамл/хаскелль/клин (которые происходят от лиспа). Жс тоже происходит от лиспа.
>>2843976 Зиг - просто очередной болженос убийца си с нескучными обоями, ничего принципиально нового не привносит, автор некомпетентен в PLT и дизайне языков. Если заняться нечем - можешь и выучить (писать на нём все-таки приятнее чем на голой сишке), но в интеллектуальном плане тебе это ничего не даст, вакансий очевидно тоже нет, так что смысл сего действа сомнителен.
Ближайшая аналогия - кофескрипт. если кто-то ещё такой помнит
>>2844450 Типизация бывает строгая/нет статическая/динамическая итд. В расте насколько я понимаю типизация статическая как в плюсах и си строгая или нет хз. Деление целых не выдает вещественное итп. (деление на ноль выбрасывает ошибку?)
Типизация это то без чего статические языки не смогут еомпилироваться в машинный код так как от типа данных зависит и тип подставляемых операций, банально u8 + 1 и u16 + 1 сложения с разными срезами жанных, а есть ведь еще и u32 >> 4 и i32 >> 4 казалось бы одно и то же и результат может не отличаться, но в первом случае логический шифт, а во втором арифметический.
А переменные и прочая фигня это уже семантика языка.
>>2844497 >Поскольку владение является новой концепцией для многих программистов, требуется некоторое время, чтобы привыкнуть к ней. Хорошая новость заключается в том, что чем больше у вас будет опыта с Rust и с правилами системы владения, тем легче вам будет естественным образом разрабатывать безопасный и эффективный код. Держитесь! Не сдавайтесь! Чёта проиграл с не сдавайтесь. Всё так плохо? в плане порога вхождения
>>2844497 По ссылке написано с предыханием рассказывают про по сути опцию -Wall из llvm, ну и в целом какую то чушь про стек и кучу.
По слухам опцию -Wall протащил кто-то из мцст или унипро, что бы видимо вместо не собирается на LCC под эльбрус в безопасном режиме в составе комплекса противоракетной обороны писать просто не собирается на llvm с опцией -Wall и как то более быстро находить понимание что в говнокод с нехорошей маняпуляцией указателями.
>>2844530 В целом, это ты сейчас какую-то чушь написал. Вместо фантазирования лучше попробуй пару примеров написать. Вот тебе идея — сделать функцию, которая принимает строку по значение и выводит её на экран. Попробуй вызвать её дважды подряд с одной переменной.
>>2845092 Трудно найти что-то что не умеет раст, но еще трудней найти ему практическое применение.
Попытка заполнить нишу между c++ и джавой предпринимается уже во второй раз, но каждый раз разработчики языка на "новых физических принципах" городят что то всратое и требуют чтоб все думали по новому. И ладно бы это что то давало на практике, но ведь хуй.
Ждем третью попытку когда наконец придет кто нибудь нормальный и сделает нормальный функциональный статический язык, без управления памятью. (Первая попытка если что хаскель).
>>2845148 > хаскель > первая попытка > хаскель > "нормальный", имплайинг для практического применения, без "новых физических принципов" Не шаришь - не пиши
>>2845318 Я прочитал текст целиком, сделал очевидный вывод о том, что ты не шаришь, и указал тебе на места, где ты наиболее явственно несешь ахинею. Что-то ещё объяснить?
>>2845372 std::move() отдает объект принимающей функции на совсем, а текущая область видимости теряет его. В расте так это будет?
Не осуждаю такие решения если что, наоборот если это правило языка а не потенциальная пуля для ног как в плюсах, то ок. Хотя и не скажу что мне это нравится, мне многие решения в расте и других новомодных языках не нравятся. Но в целом от подобных языков, которые между си и джавой, то есть с типобезопасностью, но без рантайма, ожидать другого не следует, там будут строгие правила передачи объектов между колами.
>>2845384 Ты выдрал из поста отдельные слова и перетасовал как вздумается. Или ты хочешь поспорить что до раста уже был хаскель? Или что они оба "не ненормальные" а каждому вламываться с переосмыслением это нормально?
Я больше скожу народ давно ждет язык без указателей с typesafety, но нет, нельзя просто сделать нормальный привычный язык, надо высрать что то эдакое, чтоб все охуели.
>>2845563 >а текущая область видимости теряет его. Лолнет. Конструктор перемещения обязан оставить оригинал в валидном состоянии. Как раз в Расте перемещенный объект переиспользовать нельзя.
>>2845563 >std::move() отдает объект принимающей функции на совсем, а текущая область видимости теряет его. >В расте так это будет? В расте это так (за исключением того что в нём объектов нет). Это не так в C++. Посмотри на свой же пример внимательнее. В нём str успешно используется после мува.
>>2845635 Ну то есть он в расте перемещается всегда? > Конструктор перемещения обязан оставить оригинал в валидном состоянии. Кому и куда обязан? На картинке выше с примером из cppreference строку переместили в массив через метод push_back и она исчезла со стека. Или что имеется в виду?
>>2845637 > Посмотри на свой же пример внимательнее. В нём str успешно используется после мува. Ну так потому что в плюсах можно использовать неинициализированные переменные, а в расте видимо нет (что естественоо для языка с типобезопасностью), какая разница то?
>>2845646 >На картинке выше с примером из cppreference строку переместили в массив через метод push_back и она исчезла со стека. Не понял. Вот же она осталась, просто пустая
>>2845649 В плюсах использование не инициализированных переменных это UB, а после мува переменная принимает unspecified state. Это валидное состояние и его можно использовать. Очевидно, что это большой простор для ошибок. Кроме того, это дополнительные накладные расходы в рантайме (изменение состояния и лишние проверки в деструкторе).
>>2845563 Хаскель - это побочный продукт исследований монадного ио, никто его для прода не пилил. Предыдущей попыткой сделать функциональный системный язык был окамл, ну ещё атс. Предшественник раста - клин (а также дюжина вариаций на тему всяких реджион эмэль). Язык без указателей со статической типизацией - джава, сишарп, свифт, го. Для быдла также был ди, для небыдла - кристал, ну может ним (из популярных).
>>2845657>>2845655 На стеке нет никаких переменных, там просто лежат локальные данные (адрес + размер). Поскольку std::move() и раст данные "передают" то они со стека никуда не деваются, не перемещаются, не копируется, не "очищаются". Что бы до строки больше никто не добрался, на нее в текущей процедуре теряют ссылку и выдают всем новую на пустую. Это в плюсах, в расте просто компилятор требует по сути сделать то же самое, только явно объявить заного через let. В плюсах нет операторов вроде var и let, в плюсах есть только выделение сегментов на стеке - std::string a, b; int c, d; поэтому переобъявить ничего нельзя, но неявно подменить адреса в коде - можно, что и делается.
>>2845729 >На стеке нет никаких переменных, там просто лежат локальные данные (адрес + размер). Когда данные лежат на стеке, это и означает, что переменная на стеке. Ты разделяешь как-то переменную и её данные? >Поскольку std::move() и раст данные "передают" то они со стека никуда не деваются, не перемещаются, не копируется, не "очищаются". Это неверно ни для раста, ни для плюсов. В обоих случаях происходит копирование данных (которое в некоторых случаях может выкинуть компилятор для оптимизации). Но раст на этапе компиляции помещает переменную в список неинициализированных и поэтому не будет добавлять код вызова деструктора при выходе её из области видимости. В плюсах программист, написавший перемещаемый тип должен сам явно некоторым образом изменить состояние перемещаемого (оригинального) объекта в конструкторе перемещения так, чтобы в его деструкторе не происходило лишних очисток. Т.е. код деструктора будет вызван всегда, будет менее эффективен чем деструктор не перемещаемого типа и будет некоторое состояние, в котором переменная будет не вполне понятно как себя вести.
>>2845667 > а после мува переменная принимает unspecified state Какого ещё мува какой переменной? В программе просто подменяются указатели на данные. > расходы в рантайме (изменение состояния и лишние проверки в деструкторе). В каком нахуй рантайме, программа компилируется в машинный код, алё. >>2845722 > Хаскель - это побочный продукт исследований монадного ио, никто его для прода не пилил. Причем тут твой прод, шизойд? хаскель компилируемый системный язык линкующийся с си. С репозиториями, со всей хуйней малафьей. Для прододебилов существуют фреймворки, для хаскеля они есть. >Предыдущей попыткой сделать функциональный системный язык был окамл, ну ещё атс. Предшественник раста - клин (а также дюжина вариаций на тему всяких реджион эмэль). Никто о них не знает и в компиляторы их не подвезли. >Язык без указателей со статической типизацией - джава, сишарп, свифт, го. А хули не скала и тейпскрипт? Давай все подряд перечисляй. Че несет, пиздец блять.
>>2845758 "Переменная" это абстракция языка, она может быть на стеке и/или на регистрах. Но в данном случае поскольку у нас объект, поэтому он так и так лежит на стеке. > В обоих случаях происходит копирование данных (которое в некоторых случаях может выкинуть компилятор для оптимизации). Этот мув специально ввели что бы не копировать жирные объекты и массивы, особенно если они не нужны, а просто подменить/переписать указатели. Пей короче таблетки.
>>2845775 >Какого ещё мува какой переменной? >В программе просто подменяются указатели на данные. Переменной, которая была аргументом вызова std::move(). Конкретные действия при муве зависят от программиста, который реализовал её тип. >>2845775 >В каком нахуй рантайме, программа компилируется в машинный код, алё. Во-первых, помимо копирования (неглубокого, а то ведь доебёшься) данных при муве происходит изменение состояния оригинальной переменной (та самая "подмена указателей", про которую ты писал). Это всё явно пишется в конструкторе перемещения. Во-вторых, деструктор будет всё равно вызван и важно, чтобы он не разрушил данные, которые были перемещены. Даже если мув тривиален и просто заменит указатели на nullptr, то всё равно будет проверка на null при освобождении памяти, которую компилятор сгенерирует для тебя. В более сложных случаях это будет сопровождаться триллионом других телодвижений, можешь деструктор той же строки из стандартной библиотеки глянуть для общего развития. Всё это происходит в рантайме, в отличии от раста. >>2845797 >"Переменная" это абстракция языка, она может быть на стеке и/или на регистрах. Но в данном случае поскольку у нас объект, поэтому он так и так лежит на стеке. А про кучу ты слышал? Можно ли переменную переместить в кучу? Подсказка: в этом примере с пушем строки в вектор, где оказываются данные, описывающую строку, после перемещения, если вектор на стеке представляет из себя три числа? Просто как-то принято так говорить, чтобы разделить местонахождение данных, что-ли. Но если ты считаешь это неправильным, то не буду спорить. Специфика раста в том, что после передачи владения, данные хоть и остаются лежать на стеке, но получить доступ к ним по имени переменной невозможно. >Этот мув специально ввели что бы не копировать жирные объекты и массивы, особенно если они не нужны, а просто подменить/переписать указатели. Для C++ это действительно так. Для раста это побочный эффект.
>>2845740 Ну очевидно тот анон имел в виду поинтеры с арифметикой и возможностью отстрелить себе ногу еблей в память. В джаве как бы "указатели" тоже есть.
>>2845775 Хаскель - не системный язык. Тот факт, что ты кроме него ни о чём не слышал, говорит лишь о том, что ты а) не шаришь б) знаком со обсуждаемой сферой по мемам с харкача, не более.
Скала и тайпскрипт не являются/задумывались заменой крестам, а джава и сишарп - задумывались. Го и свифт - это буквально ровно то о чём ты выше просил, компилируемые системные языки с безопасной работой с памятью без непонятных быдлу типа тебя концепций, притом свифт ещё и с нормальным современным дизайном (насколько это было возможно в рамках тз).
Приглядываюсь к расту, но не могу понять, как на нем правильно кодить? Насколько я понимаю, раст не совсем ооп-язык и всякие там наблюдатели не очень удобно на нем реализуются
>>2847047 >Насколько я понимаю, раст не совсем ооп-язык и всякие там наблюдатели не очень удобно на нем реализуются Почему? В расте отсутствует наследование в понимании ООП языков, но все эти паттерны проектирования можно хоть на C реализовать. Раст вполне себе предоставляет полиморфизм с динамической диспетчеризацией. Вот набросал тебе пример наблюдателя. Но я вкатун, наверное можно сделать идиоматичнее. Это просто калька с плюсов/джавы. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1bf1203db3a58c624864b45db54e847f
>>2847047 Для меня лучше работает парадигма "Си с доп. плюшками". Минимум абстракций, структуры используются в качестве контейнера, а их собственная логика ограничена валидацией, свободные функции. Замыкания для реализации инверсии зависимостей.
Когда люди пытаются обобщить всё подряд, получается какой-то ёбаный пиздец.
>>2847650 > Moreover, the library does not provide any input handling nor any event system and you may rely on the previously cited libraries to achieve such features.
При этом да, адрес на стеке не подменяется, что хорошо. Подменяются тупо указатели на данные внутри класса, и видимо данные всегда алоцируются где-то в памяти а при выходе из процедуры деструктор класса их очищает. Мудреное ооп в плюсах, зато программа сама себе рантайм.
>>2852086 >Происходит "перемещение" данных: Которое заключается в копировании внутреннего представления и изменении состояния оригинальной переменной. Чтобы убедиться можно открыть исходники стандартной библиотеки.
_M_move_assign() в лучшем случае создаёт пустой вектор, потом подменяет внутреннее представление целевого вектора представлением оригинального вектора и наконец подменяет внутреннее представление оригинального вектора представлением пустого вектора. В худшем случае производит поэлементное копирование всех элементов оригинального вектора, а потом его очищает. Всё это в процессе сопровождается созданиями аллокаторов, аллокациями в худшем случае и многочисленными деструкторами. https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_vector.h#L1961
То что в твоём примере именно так и происходит можешь убедиться потыкав ктрл+лкм по вызову оператора присваивания в ассемблерном коде.
Ну и вишенка на торте — сравни с мувами в расте: >>2807748. Скопирую картинку для удобства, подробное описание в том посте. Мув в расте это простое копирование внутреннего представления. Ничего лишнего не создаётся, не меняется и уж тем более не аллоцируется. Дроп вызывается однократно. Это просто минимальный минимум. В плюсах такое НЕВОЗМОЖНО.
Всё. один алокатор за всю программу, и поинтер на данные в структуре, через (size_t)(&vec[0]) можно убедиться что внешний перед классом и внутри класса Test после присваивания указывают на один и тот же адрес, а вот внешний после вызова конструктора класса Test указывает на 0.
При этом функции в секции main: функции мува не вызываются хотя внизу там все варианты присутствуют, все что есть в stdlib.
>>2852498 >через (size_t)(&vec[0]) можно убедиться что внешний перед классом и внутри класса Test после присваивания указывают на один и тот же адрес, а вот внешний после вызова конструктора класса Test указывает на 0. Это и есть изменение состояния внешнего. Что сказать-то хотел?
>Всё. один алокатор за всю программу В данном конкретном случае это так. Про аллокации я говорил для худшего случая. А вот данном конкретном примере из лишних телодвижений создаётся пустой вектор (строка 445), разрушается объект аллокатора (строка 447, кстати не пойму где он создаётся), дважды свапаются представления векторов (строки 450 и 453), создаётся пустой вектор m_data (строка 196), потом он же разрушается (строка 465), разрушается временный вектор (строка 88), а так же ещё куча какой-то хрени, в которую мне погружаться лень.
Если ты этого не видишь, я не понимаю, зачем ты мне тогда этот дизассемблер вообще принёс. Своими словами ты мне описываешь только очевидный конечный результат, как будто он произошёл после взмаха волшебной палочки, а внутрь процесса ты не пытаешься заглянуть.
Ну и в конце концов я не понимаю, что делает обсуждение стандартной библиотеки плюсов в треде раста. У плюсов своего треда нету что-ли?
Видимо, ты пытаешься утверждать что мув в расте не вносит ничего нового по сравнению с плюсовым и сделать на этом основании вывод о бесполезности раста, если я конечно продолжаю общаться с тем же человеком. То что это абсолютно не так видно и по примеру использования (>>2844844) и по деталям внутренней реализации (>>2852086). Не понимаю, что тут можно ещё размусоливать.
>>2852562 > Видимо, ты пытаешься утверждать что мув в расте не вносит ничего нового Да, не вносит. > сделать на этом основании вывод о бесполезности раста > если я конечно продолжаю общаться с тем же человеком. Да, с тем же человеком. Я не пользуюсь мувами в плюсах и мне не нравится раст за то что он чуть более чем полностью весь состоит из вот таких решений "не как у всех".
Но в данном случае я просто спорю с утверждением что это некое ноу-хау а мув это совсем другое. Именно что оно и есть. По классике передача данных осуществляется либо указателем либо копией. Всё. В php например все данные передаются копией, как в си. Чтобы передать ссылку на данные нужно явно проставлять ссылку funct(&a) В джаваскрипте все прототипное указателем. Хочешь избежать одновременного доступа к одним данным - копируй.
В плюсах пустились во все тяжкие, сперва функции не которым ты явно передаешь ссылку, а которые сами решают, но хуй с ним к этому как то привыкли, а вот функции которые еще и забирают данные это пиздец к которому привыкнуть сложно. Однако это уже не выглядит как пиздец если этого поведения ожидаешь всегда, как в расте. Вопрос только стало ли от этого всем удобней. Для меня раст это квинтессенция самых плохих решений в одном аккуратно упакованом и поданном продукте. Система сборки завязанная на один анальный репозиторий, как в говноде. Ублюдочные let mut как комплитеры в свифте. Которые нихуя не функциональное и не асинхронное программирование. Асинхронщина это вон промисы в джаваскрипте или QFuture в qt. Навязанная экономия символов в одном месте и избыточное буквописание в другом, навязанное калбеканье и присвоение переменных. У меня свой стиль, почему я должен писать и оформлять код так как любит какой то пидор из мозилы? В общем язык параша редкостная, хотя сама идея то здравая, вместо ооп пойти в функциональщину имитирующую ооп, компилировать программы с lto, с профилировкой-хуевкой, дать из коробки валгринд и мемори санитайзер, но опционально включаемый выключаемый.
Все вроде правильно но по итогу какая то хуйна "не такая как все". Которую ещё завтра некрософт подгребет, а про форк большинство людей и не слышали.
>>2852827 Что значит вкатываться в язык Х? Язык в программировании нихуя не значит, потому что они все учатся за пару недель-месяц или даже по ходу работы. Куда важнее знать предметную область и общие принципы разработки, поэтому бери сишку/плюсы и изучай основы своей области. А когда понадобтся раст, то осилишь его за кратчайшие сроки. Раст, как первый ЯП, полная хуйня.
>>2852864 > поэтому бери сишку/плюсы и изучай основы своей области. А когда понадобтся раст, то осилишь его за кратчайшие сроки. Раст, как первый ЯП, полная хуйня. Не, раст у меня 5 будет. Но после шарпов второй по тому, насколько кайфово с ним работать.
>>2852912 Я вообще искал плюсотред. Но его нигде нет. Видимо тамошние обитатели все таки нашли работу в пятёрочке. По поводу "бесполезности раста", его бесполезность связана прежде всего с отсутствием гуев, сетевых и прочих фреймворков. С другой стороны его позиционируют как замену си, то есть этакий библиотечный системдизайн-левел, но лично для меня не совсем понятно как на него со всеми его ограничениями и правилами напяливаться. Даже мозила не все переписала и как баги были в их песочнице так и остались.
>>2853425 Когда искал (на прошлой неделе) небыло. А теперь мне уже похуй. И даже немного хочется раст в попку примерить. Так на полшишечки, вдруг понравится.
>>2852737 >>2853805 while тоже нельзя. Точнее можно и while и for, но это бесполезно чуть менее чем полностью, результат будет одинаковый.
На пальцах: чтобы использовать цикл в константном выражении необходимо чтобы он всегда возвращал значения одного типа. Цикл while (и for, который по сути синтаксический сахар для while и итераторов) неявно возвращает значение типа unit, т.е. (), когда условие выполнения становится ложным. Поэтому даже если внутри него ты сделаешь break, ты не сможешь вернуть через него значения других типов, иначе код просто не скомпилируется. В компиляторе сделали зачем-то отдельную ошибку для этого, наверное это вводит в заблуждение, но суть именно такая. С loop всё просто, все выходы из него описываются явно, и возвращаемое через break значения могут быть любых типов, поэтому там можно вернуть что-то вменяемое.
>>2801496 Радует, что убийц сиговна становится все больше. Давно пора шатать системные скрепы. В других направлениях программирования технологии постоянно выходят новые, а старое нещадно отправляется на парашу, а в системке до сих пор пишут на говне 70-х годов отказываясь от прогресса и удобств.
>>2854808 > В других направлениях программирования В каких > постоянно выходят новые, а старое нещадно отправляется на парашу Какие новые технологии? Уж не ооп ли с интерпритируемым кодом?
Новых систем программирования с доминированием архитектур типа интела нет и не предвидится.
>>2855269 На си конфигурируют сборочный скрипт с -О0 в компилерфлагах и компилируют с make -j4 если проект большой.
В карге мало того что надо курить полную документацию на этот ебучий ini файл и придумать костыль для имитации гибкости сборки, так еще и фронтенд не такой как все. Альтернативу llvm в виде gcc или icc выбрать просто нельзя.
>>2855457 > перформанс выполняемого кода, и скомпилировалось=работает Это потому что как я и говорил, компилятор и опции компиляции по умолчанию (вроде lto и раскрутки циклов) запихали люди знающие в этом толк.
Однако не знающие что такое профилировка (нигде не нашел опцию профилирования программы), что может говорить о том что даже это делали не инженеры с научным знанием и пониманием, а просто опытные говнокодеры.
>>2854821 >Какие новые технологии? Пакетный менеджер и сборщик из коробки лол
>>2855431 >карге мало того что надо курить полную документацию на этот ебучий ini файл 2 минуты в гугле >придумать костыль для имитации гибкости сборки так напиши makefile/build.rs, чо бухтеть-то? >Альтернативу llvm в виде gcc или icc выбрать просто нельзя. Не так быстро, ковбой https://github.com/rust-lang/rustc_codegen_gcc
>>2855457 > скомпилировалось=работает Дежурно напоминаю, что это мем хаскель-коммунити (и вообще тайп-тиори-тусовки). Это ироничное выражение. Оно не подразумевает, что на самом деле скомпилировалось=работает. Примитивная статическая типизация (систем ф и аналоги) позволяет отловить лишь ограниченное число примитивных ошибок в коде.
>>2855657 > Пакетный менеджер и сборщик из коробки лол Ты про новые направления в программировании и про то как старые отправляют на порашу. пакетный манагер устанавливается с тулчейном rustup который устанавливается с сайта руками, куда у тебя пакетный манагер встроен? То что он есть стандартный это хорошо, но вот то что он крупными компаниями в цепкие лапы прихвачин как жидхаб это уже не очень. > так напиши makefile/build.rs, чо бухтеть-то? Так и на нормальном gnu make наверное можно написать проблема то в том что компилятору нужен конфиг для связи файлов и модулей его все равно надо будет генерировать.
>This is a GCC codegen for rustc, which means it can be loaded by the existing rustc frontend Переводить надо? Судя по всему да и с пояснениями - фронтенд Rustс может использовать альтернативный бакенд. Что бы раст появился на архитектурах на которые llvm не завезли. > "rust performance profiling" в гугле даёт Вот и авторы раста не вдуплили сразу що це и зачем. Man https://kobzol.github.io/rust/cargo/2023/07/28/rust-cargo-pgo.html
>>2855766 То что это напяливание фронтенда на библиотеку из gcc, причем патченый форк, и все в таком духе. Это опять таки к вопросу о том как авторы раста продумывали его будущее.
Ответ: никак чисто высрали инструмент под свою задачу - xml json и так далее парсера. Посколько современные браузеры на моторолах 68k и прочих легаси armv6 работать все равно не могут, то берем модный молодежный llvm.
Но ты можешь дальше кормить себя верой что это на замену си все изначально разрабатывалось.
>>2856988 Когда этот синтаксис задумывался никто не собирался его применять с лямбдами, в отличии от лиспа. Замыкания можно вынести в отдельные переменные, тогда и вложенности не будет и читать станет легче.
>>2857417 Открой код нормального проекта на сях, например ядро линукса. Там нет такого джаваскриптового стиля. Но в целом соглашусь, выглядит кошмарно и действительно встречается в си-подобных языках. Либо косплей на джаву, не знаю что хуже.
Язык созданный для рантайм исполнения всегда будет плохо компилироваться, у него нет макрасов/инлайнов и прочих штук которые в статисеские языки вводят специально что бы программист помогал компилятору убирать из программы ненужные прыжки и лишний код. Рантайм языки в этом не нуждаются так как их на лету многократно перекомпилирует jit с pgo и агрессивными оптимизациями.
>>2855668 Я с тобой не совсем согласен в части того что они примитивные в отладке. Например двойное close() на объект, мутация в процессе итерации, и прочие вещи как дабл-фри. Особенно когда дошел до многопотока.
>>2860463 К счастью второе такое макросное говно, с анальным ограничениями и костылями исправляющие эти анальные ограничения - делать пока никто не собирается.
У меня не одного же есть ощущение о Расте как о "песочнице"? Вроде бы достаточно проектов, интересно выглядят - но они все с плашкой "в разработке, много ключевых функций отсутствуют". К примеру Tauri, Bevy, Slint... и так далее. Многие закрываются просто так, Amethyst закрылся и всё. Так я до сих пор и не вижу полноценного готовго проекта на Расте. А жаль, язык мне вот очень нравится.
>>2862720 Из того, что сам регулярно юзаю и знаю что оно написано на расте либо использует его в значительной мере: firefox, fd, spot. Ещё из популярных проектов могу назвать alacritty и ripgrep. Наверняка есть куча других. До масштабов C/C++ конечно ещё далеко.
>>2862720 Да везде отваливаются, только тут выбора/ассортимента поменьше и сильнее заметно. Ну и всяким монстрам вроде qt, unreal итп уже вряд ли получится отвалиться, а мелкие вполне.
>>2862866 >Ну и всяким монстрам Можно ли wgpu назвать местным "монстром"? Я так понимаю любая rust библиотека где нужно что-то рисовать использует её.
К слову - я вот вообще новичок в расте, и мне wgpu слишком уж запутанным показался как-то. И сразу ещё вопрос wgpu при компиляции нужно указывать какой API использовать OpenGL, Dx12, Metal и так далее или он на ходу может самый оптимальный выбирать при запуске программы?
Поясните пожалуйста за RustRover. Лично мне больше нравятся JetBrains IDE чем vsCode, можно ли уже использовать RR как основную среду разработки не смотря на значок Preview? И когда она выйдет будет ли комьюнити версия как с IntelliJ?
cargo careful is a tool to run your Rust code extra carefully -- opting into a bunch of nightly-only extra checks that help detect Undefined Behavior, and using a standard library with debug assertions. For example, it will find the error in the following snippet:
fn main() { let arr = [1, 2, 3, 4]; let slice = &arr[..2]; let value = unsafe { slice.get_unchecked(2) }; println!("The value is {}!", value); }
>>2867166 Какая задача? Если что-то уровня литкода — удобно использовать получать представление в виде байтов с помощью as_bytes(). Ну а в общем случае итерироваться через chars().
>>2867759 Это не так сложно, как кажется. Если ты осилил раст, то ты легко осилишь асм. Сложно найти хорошие материалы для обучения, но выучить что-то с хорошими материалами совсем не сложно, было бы желание.
>>2867759 Учить си и системщину (это еще будет интересно). С раста начинать в системщину погружаться, это как через жопу гланды лечить, тебя и так ждут трудности и бойлерплейт, а тут еще специфичные рамки, в которые даже тру системщик охеревает.
Смотри, анон, какая диковина: у меня есть дженерик трейт Externalizer, который как бы и не дженерик вовсе. Тело функции прямо в объявлении трейта, а в impl я ему только пропихиваю ассоциированные типы. Зачем это мне? Да вот, хочу растащить свой проект на трейты, а в точке сбора я через вот такие impl соберу всё в кучу и как-то должно поехать. И вот какая проблема: с просто трейтом всё ок, объявляю ассоциированный тип и сразу использую функцию из него. Но вот как быть со структурой? Внутри impl структуры такой фикус не провернуть, а очень хочется, т.к. гораздо удобнее, чем прописывать 100500 дженерик типов, используемых в структуре, во все 100500 мест, где эта структура будет использоваться.
>>2874934 >>2875528 Ты сидишь такой, пытаешься быть умным, дать совет из области задач, как делают другие вумные люди, с другими языками, но смешно тут то, что это для раста не работает. Раст буквально, это только бэкенд и причем нередко крипта.
Ты перед тем как рисоваться и пытаться казаться эрудированным в вопросе, хотя бы подумай сначала.
>>2876005 Твой уровень, это эмуляция чатгпт для ньюфажного треда, ты даже не уловил мысль. Тебя спрашивают какие подводные, ты шаблонно и не думая спрашиваешь какие цели. Цели мои это узнать все подводные этого языка.
>>2876621 Единственный подводный, который встретил я: из-за того, что зависимости добавлять легко и приятно (в растовере оно само предлагает добавить крейт в зависимость просто по вызову), проект может раздуться и начать тормозить на анализе и сборке. А ещё тормоза, если у тебя много структур с derive макросами. Ну, а ещё там такой контролль, я выше писал уже.
>>2876759 > (в растовере оно само предлагает добавить крейт в зависимость просто по вызову) С условиями сколько эта штука жрет памяти, она должна уже за тебя писать, а не просто угадывать слова популярных крейтов.
Каждый раз забываю про раст, @ Начинаю вкатываться снова @ Первая мысль, о как круто сделано, че я раньше бухтел @ Спустя время смотришь кругом какое-то костылеварение, даже макросы, созданные победить костылеварение, сами по себе костылеварения. @ Интерес падает до нуля.
>>2880429 Что-то мне думается, что какой-нибудь zig или ему подобное, если получит покровителя, выстрелит куда сильнее раста. Хоть есть в расте плюшки и не плох он, но что-то с ним не то (имхо, конечно)
>>2880429 Что-то мне думается, что какой-нибудь zig или ему подобное, если получит покровителя, выстрелит куда сильнее раста. Хоть есть в расте плюшки и не плох он, но что-то с ним не то (имхо, конечно)
>>2881755 ГОвноланг тоже выстрелил сильнее раста, так что неудивительно, так и будет. Спойлер: 80% программистов оценивают язык по логотипу и синтаксису.
>>2881987 >ГОвноланг тоже выстрелил Тут не покровитель, тут прямо создатель - аж целый гугл. ГО на момент создания воспринимался для веба как жаба/свифт для мобилок или .net для винды. Даже Sun, когда создавали жабу, были не самой последней компанией в индустрии. Скажем, если бы Го создавался в недрах некой компании уровня Basecamp, то даже если бы гугл взялся использовать его для пары проектов - не взлетело бы, ибо слишком серо, мало чем лучше того же Erlang (который взлетел из недр другой корпорации). Корпорации доверяют корпорациям, в общем.
И раст неплохо стартанул потому, что mozilla в 2013 (что-то примерно тогда анонсировали servo), это совсем не то, что в 2023.
В любом случае я не верю в успех zig, так как вот эта ниша "чуть более лучший си" кем только не штурмовалась и всё безуспешно. Тут надо или радикально лучше, или никак, а радикально - это раст. Показательный пример Objective-C - который, будучи в этой же нише, без поддержки эппл сразу сдулся, как и не было его.
Ну, ещё такое спонтанное замечание: на расте очень много пет-прожектов. Даже вот этот тренд "переписать на расте" существует потому, что писать на нём так приятно, что даже когда нечего писать своего, ручки чешутся хотя бы переписать чужое. Те же го или жаба такой любовью похвастаться не могут. Если сравнить число пет-проектов на количество вакансий, то раст тут будет впереди всех. Не думаю, что zig сможет обойти раст и в этом плане (tsoding на стриме написал игру на zig, долго плевался, а потом и вовсе переписал на Jai). Вот у какого языка есть шансы, так это у упомянутого выше Vale, но только после переписывания на самом себе и с нормальным тулингом.
>>2882097 Ты реально думаешь, что успех языка это гугл? Рядом же он обосрался с дартом и тонной закрытых проектов. Я помню окружение шепталось аля - а что если гугл и го закроет и многие кроме мелких микросервисов боялись писать (из тех кто вообще хотел на вендерлок от гугла садится). Го вывезли его киллер фичи и простота в противовес жабьего тырпрайзного ООП ужаса, даже не помешал откровенно халтурный дизайн языка, вот такая была огромная потребность если бы шарпы попенсорснули где-то в 2010 годах, го может бы даже не выстрелил. Так что как была альтернатива жабе, так есть и альтернатива сям.
>>2882586 >Так что как была альтернатива жабе, так есть и альтернатива сям. Так что как была потребноть в альтернативе жабе, так есть и альтернатива сям.
PS смешно, но я считаю, что нужны и более современные скриптовые языки, чем нынешний зоопарк костылей.
>>2882586 Го они прям пиарили. Да, потребность была, да го её закрыл. А если бы гугл поставил на эрланг, то все бы учили его, как миленькие - стали же учить жабу для андроида. А если бы го родился не в недрах гугла, то и нах не был бы нужен.
>в противовес жабьего Дак и я о том же - говнояз одной корпорации потеснил говнояз другой.
>обосрался с дартом Просто дарт стал ещё одним языком для васма. Ну и вообще, с альтернативами жс сложно не обосраться, это ещё некрософт пыталась затащить бейсик в браузеры, если кто не помнит.
Это ж я всё о чем. Что расту не хватает поддержки крупных корпорастов, чтобы его взяли на вооружение мелкие, но и без этого его любят и используют потому, что он хорош. А вот всякие zig/crystal и прочие odin с таким уровнем ставки/поддержки корпораций (гугл переписал часть прошивки, дропбокс пару сервисов и т.д.) шансов не имеют.
>>2882586 Гугл и логотип же. Ты у дарта помнишь логотип? То-то же.
Ну и не забывай, что дартодегенераты посреди дороги взяли и сделали другой говноязык и назвали его дарт джва ноль, забив на обратную совместимость. А насчёт го, емнип ним вышел в то же время (но не вышел логотипом, азаза).
>>2883182 >Гугл и логотип же. Ты у дарта помнишь логотип? Ну да, именно поэтому, а не за зеленные потоки (без всяких асинк/ойвэй), статичный бинарь с кросскомпиляцией и выкинутое нахер ООП, что упростило сопровождение кода в разы.
Описывается опыт применения TLA+ для создания спецификаций при разработке сетецентричной ОС реального времени (RTOS) и опыт моделирования спецификаций с помощью TLC.
Книга интересна в первую очередь тем, что описывает разработку реального коммерческого продукта. А ещё тем, что использование TLA+ и моделирование позволило оптимизировать архитектуру настолько, что в результате объём кода уменьшился на порядок для той же самой функциональности, что и у RTOS предыдущей версии — Virtuoso. Разработчики даже не подозревали о таком эффекте, для них он стал весьма приятным сюрпризом.
То есть формальная спецификация помогает найти такие способы оптимизации архитектуры, которые позволяют сохранить функциональность ПО и радикально уменьшить объёмы кода (и, соответственно, объёмы ошибок, время отладки, стоимость поддержки и сопровождения).
>>2884364 >Ещё вопросы? Мог бы промолчать, но сейчас ты выглядишь как малолетний дигрод с завышенным юношеским максимализмом. Отдельная одаренность самоутверждаться на анонимных форумах
>>2887249 Зиг конечно неплох, но что может сравниться с чувством победы над ебаным копилятором раста в 4 утра после 3 часов ебли с ебаными FnMut? зато я в них наконец-то разобрался, лол
>>2887841 >но что может сравниться с чувством победы над ебаным копилятором раста в 4 утра после 3 часов ебли с ебаными FnMut? Так тебе инструмент нужен или нужно самоутвердиться? Мне кажется грустным, когда ты самоутверждаешься в достаточно не сложном расте, когда есть такой гигант как хаскель.
>>2887986 Ну, если в твоем понимании самоутверждение = достижение понимания какой-либо неочевидной концепции, то тогда да, я самоутверждаюсь. Раст для меня - пазл, который мне хочется собрать. На других языках мне писать намного менее интересно. А хаскель не пробовал, он вроде со сборщиком мусора, а это не подпадает под мои критерии.
>>2888497 Мне больше нравится контраст. На релизном, натянутом на глобус языке, пилят только утилитки и осилили только серво, которое уже выкинули в какой-то фондейшен протухать. А на другом языке, в бете уже клипают продукты (из последних помню новый интерпретатор для жопоскрипта). Слежу за обоими пациентами, интересен интузиазм в этом зиге у людей.
>>2888775 >интересен интузиазм в этом зиге у людей Зиг Хайль! >>2888842 >а у раста всё-таки порог входа и прорывные (для мейнстрима) концепции Какой же кринж пиздец.
>>2889149 При чём тут маркетинг? тред опять полон школоты Раст - первый мейнстримный язык с аффинной системой типов первый немейнстримный язык с ней вышел в 90-ых, аккурат вместе с хаскелем, так что прорывные инновации уровня /б/ индустрии разработки ПО, как всегда. В зиге никаких новых теоретико-плтшных концепций не используется, это просто альтернативный синтаксис с неплохим тулингом и компилятором. Порог входа в него очевидно ниже, т.к. не надо ничего изучать.
>>2888775 >продукты И где оно в продакшене? >из последних помню новый интерпретатор для жопоскрипта покажи. Я на https://github.com/C-BJ/awesome-zig нашёл только парочку рантаймов типа ноды.
Scryer Prolog https://github.com/mthom/scryer-prolog/- пролог рабочий, сам использовал. Можно решать детские задачки на логику, задавая условия прямо на русском.
>>2889528 >RustPython Это все пет проекты коих в гит-хламе миллионы. Это так называемый попенсорс, использовать это как продукт чаще практически невозможно и нередко существует для галочки - "а что еще переписать на расте/другом языке", к той же херне относились всякие попытки написать на расте ОС, понятно никто всерьез не думал реально написать продуктовую ОС, это все несерьезные игрушки. Вот серво был флагманским продуктом, но что-то пошло не так.
>>2889219 Неожиданно, новый си с тулингом мне как раз и был нужен. Мне не надо второго С++ скрещенным с хаскелем, мне не нужно самоутверждаться на костылях лайфтаймов и макросов, мне тупо нужен низкоуровневый, но современный инструмент. Что он не бросает вызов, мне это не важно.
>>2890703 Суть не в бросании вызовов, а в открывающихся новых возможностях. Но в целом я ж это и написал: порог входа ниже, поэтому популярность вероятна.
>>2890896 >но если активно юзается Только в одной соляне крутятся бюджеты небольших стран, объем торгов около миллиарда долларов в день. Это наверное петпроект
>МММ >испачканный в крипте Лол, ты и правда не селен
>>2890306 >Bun - это новый нодежс. Ебать, ты птица , дятел. Посмотри в педивикии, что такое интерпретатор. И посмотри, что такое Deno с которым Bun, типа, компетирует.
>>2890700 Маня, ау, я писал про интерпретаторы, которые на расте, внезапно, есть, а на зиге, внезапно, нет, вопреки утверждению в псто, на который я отвечал.
>>2890700 >Это все пет проекты Buttplug.io - успешная продуктовая фирма, пишет на расте. А на твоём Зиг-Хайль! пишут только всякую муть в виде пет проектов.
>>2891059 >Только в одной соляне крутятся бюджеты небольших стран Только во влажных фантазиях таксистов и грузчиков. Циферки может и большие, пока не начнут объемно в реал выводить.
>>2890700 Firecracker и bottlerocket от amazon Postgres-ml (и менее известные штуки на pgrx) Wasmer/wasmtime Oxy/pingora в cloudflare Дрова для arm m1 gpu в asahi linux Вообще втаскивание раста в ядро линукса (куда даже плюсы не втащили)
>>2891390 >Циферки может и большие, пока не начнут объемно в реал выводить. При таком раскладе и цена акций упадет и любая валюта рухнет, даже квартиры если все в одном городе Воркута например начнут продавать, то цена рухнет. Ты правда не селен
>>2891590 И? Механизмы взлетов и падений там и там одинаковые, по сути рынок крипты почти тоже самое что и рынок акций. А то что страдают все от кризисов на фондовых рынков, то это все из-за того что этот рынок больше проникает в жизнь людей чем рынок крипты. Вообще речь не об этом в треде, а о том что на расте написано много всего для крипты и он тут во всю используется.
>>2891611 Я к тому, что крипта, особенно не самая популярная, это фуфло, от которого ничего не зависит по сути. Возможно пока не зависит, не берусь ничего утверждать. Причём единственная польза от раста тут — это то что он на слуху и это является преимуществом своего рода в глазах инвесторов. Сужу это по своему стартапчику, в котором нет места ни расту, ни блокчейну, но оно впихивается просто потому что так легче получить бабки на развитие проекта. А вообще я мимо проходил, не отвлекайтесь от своего увлекательного спора.
>>2891533 Банковская масса денег нередко ограничен каким-то числом в котором они могут раздувать пузырь (поэтому и работает если не кризисы), а пирамида фантиков не ограничена ничем, просто объемы столь большие, что можно стричь очень долго пока не схлопнется. В тот же бетховен стригли народ несколько раз (только я помню два раза из крупных), но там столь много вливаний, от продавцов железа, мошеннических схем, бирживых игроков и вкатунов, что пока это все работает.
Это отдельная тема вообще и не хочу с малолетками спорить, тем более я сказал что это "продукт", пускай и продукт скама, поэтому вообще непонятно к чему ты стал спорить (просто как у ИИшки какой-то тригер у тебя сработал).
PS Будем честны от самого любимого всем языка, хочется видеть больше чем скам продукты, малвар и бесконечное переписывание утилиток. Тот же го стартовал рядом и уже наклепал флагманов индустрии.
>>2891878 >Банковская масса денег нередко ограничен каким-то числом в котором они могут раздувать пузырь (поэтому и работает если не кризисы), а пирамида фантиков не ограничена ничем, просто объемы столь большие, что можно стричь очень долго пока не схлопнется. В тот же бетховен стригли народ несколько раз (только я помню два раза из крупных), но там столь много вливаний, от продавцов железа, мошеннических схем, бирживых игроков и вкатунов, что пока это все работает. В банках должен быть необходимый объем капитала, поэтому они более устойчивы, но это не спасает от того когда вкладчики массово изымают вклады, это немного другое. Здесь же я сравнил рынок крипты с рынком акций и там примерно тоже самое акции из доли в компании по сути уже давно превратились фантики для спекуляций особенно IT компании раздуты по полной, цена также ничем не ограничена и точно также стригут лохов в кризисы. А бетховен вообще последнее время ведет себя как индекс SP500 и обеспечен тем что используется как платежное средство.
>>2892052 Спасибо! Как надо было правильно гуглить, чтоб найти? Я гуглил специализшон женерикс и выгугливалось вообще не то.
>>2892252 Там в гц крупные корпы упёрлись, держатели хайлоад серваков, куда уж мне. Теи не менее я раст учу потому что синтаксис нраица, и бдсм с боровингом нраица.
Сап, растаны! Я читаю растбук, но некому показать домашки. Вот я сделяль. https://pastebin.com/ReqzxBYK Покритикуйте, плиз.
>>2892467 > break тут зачем? Бля не бейте. Здесь я при помощи фора вычисляю только первый символ в строке, а потом брейкаю цикл. Щас-то я уже узнал про слайсы и понимаю, как это тупо выглядит. Мне нужно было просто word.chars().next() взять и работать с ним.
>>2892865 > используй линтеры Да. Я mscode юзаю там при первом открытии раст-проекта скачивается и хайлайтер и линтер. Но погляжу и клиппи. Сравню. >>2892688 > Я это упражнение так сделал Нот бэд, нот бэд. К концу третьего упражнения, я если бы переделывал первое, сделал бы уже примерно так.
>>2894051 Я тебе так скажу: большинство "програмистов" - это говнокодеры, которые или на дядю за копеечку, или пилят тетрис мечты. Мало кто пилит либы, которыми пользуются миллионы. Тебе должно быть важно, чтобы именно ты случайно не наговнокодил уб в своём коде, а либы тебе пишут умные дяди при поддержке других умных дядей. Дяди пусть следят за unsafe у себя, а ты следи у себя. Тебе же никто паяльник в жопу не пихал, чтобы заставить этот unsafe использовать? Вот и ладненько.
>>2894182 > Вот и ладненько. Нет, не ладненько. Мне тут этим выебоном с лямбдами как бы намекают, что язык плох, что является демагогией и профанацией. Это следует проговаривать вслух, чтобы мимокрокодящие нубы не испугались. Нельзя такие поползновения на тормозах спускать.
Я тут полгода назад размышлял над гипотетическим языком мечты, и набросал несколько набросков (эдакий доведённый до совершенства по моему мнению шарпопаскаль с нативным компилятором) и запостил скрины с псевдокодом на двач (в шарпотреде кажется, а может и нет). Каково же было моё удивление, когда мне аноны сказали: > это же раст Я загуглил и охуел. Язык моей мечты существует!
>>2894371 Ааа, так ты об этом. Да, и так можно, и эдак. Я тоже замечал, что многие неофиты стремятся закрыть проход новоприбывающим намёками "тут сложна, не идите сюда, только элитка поймёт", подразумевая под элиткой, конечно же, себя. Ну это такое детство в жопе играет, в любой теме такое есть.
Я, вот, ещё к Vale присматриваюсь, но до стадии селф-хоста только краем глаза.
>>2894371 >>2894435 >Язык моей мечты существует! >тут сложна, не идите сюда, только элитка поймёт >После унсафе не читал. >Чудо какое, а! Серега, когда ты пил свои таблетки, ты был лучше. И прекращай общаться с самим собой, ты меня пугаешь.
>>2895044 > уважающего себя шиза Искать семёна среди Анона в 2к23 - вот настоящая шиза. Год за годом ты повторяешь одно и то же действие с надеждой на другой результат. Ведь все мы давно знаем, что мы здесь - один, общаемся сам с собой, с разных браузеров. Осознаём ответ на свой вопрос в момент заполнения капчи. Тем чудовищней выглядит твоя болезнь - маниакальный поиск семёнов.
>>2894435 Мой разум поразила концепция, в которой отсутствует Null, вместо него энум с данными. Концепция энумов с данными тоже поразила до глубины души. Опять, же наверняка всё это было раньше в других языках и наверняка это не новость и не предмет для восторгов, но хули поделать, у меня восторг! ООП без классов и с типажами - ваще охуеть! Лучше, чем сэкс. В том же шарпе просто бесила концепция "всё есть класс и для написания безклассовой функции используй директиву static и всё равно обращайся к функции через литерал имени класса" просто пиздец был. Кроме того я всегда задавался вопросом, если есть структы и интерфейсы, зачем тащить классы? Потому что в последних версиях современных языков функционал классов полностью распределился между структами и интерфейсами, а классы остались пятым колесом телеги, чистое легаси для обратной совместимости. И тут мне двач показывает концепцию типажей. А я всегда считал, что название для интерфейсов выбрано неправильно, как старый паскалист, я помню, что интерфейс - это сумма всех публичных членов объекта, которая в паскале выписывалась в отдельную секцию паскалевского модуля, а мне тут тулят, что интерфейс это отдельная программная сущность. Я нутром чуял, что должно было быть более подходящее название. И вот же оно: ТИПАЖ! У нас есть типы, и у нас есть типажи типов, которые описывают функционал, и есть имплементации типажей для типов, которые собсна, имплементируют функционал. Семантично! Идиоматично! Да еще и зерокост, да ещё и мемсейф.
Есть конечно и минусы. Я привык к функциям с опциональными аргументами, наподобие foo(bar: str, baz: int = 100){} здесь такого нет, печально. И еще что-то было раздражающее, не помню, что. Вспомню напишу.
>>2895083 >функциям с опциональными аргументами, наподобие foo(bar: str, baz: int = 100){} здесь такого нет Кстати, пока писал пост, придумал, как реализовать такой функционал. На уровне пользователя можно предварительно создать нужный структ с нужными полями, в функцию передавать экземпляр, пикрелейтед, кароч.
Но надо, чтобы на уровне языка это присыпали сахарком в виде старых добрых функций с опциональным аргументом. Компилятор просто берёт все аргументы функции, которые ему поданы, делает из них вышеописанное и делает еще одну функцию с единственным структ-аргументом.
>>2895047 >базовая дока это вообще не серьезно Вполне серьёзно. Если ты думаешь, что существует волшебная книга, благодаря которой ты всё поймёшь, прочёл базовую раст-буку и не понял, то это так не работает. Если ты не настроил себя на понимание, то будь автор хоть Алленом Карром, ты не бросишь курить. Аналогия ясна?
>>2895165 Еще можно data: FuncData заменить на data: impl Into<FuncData> и будет по красоте.
На самом деле в реальном коде дефолтные параметры - это почти всегда костыль, когда ты в функцию, которая используется в в 3 местах добавляешь флажок, который чуточку меняет поведение. По хорошему, так делать нельзя.
>>2895109 Там какая-то ньюфажная херня наподобие ютуб видосов как if писать и как цикл циклить. А про архиважные темы типа владений и лайфтаймов - мол смотрите они есть у нас.
Естественно этого хватает только пробежаться вечером и оставить голос за самый любимый язык, но в остальном никак не учит кодить.
Например не хрена непонятно как работает магия с response.set_mut, каким хером строка может превратиться в трейт Modifier и вызвать на себе modify() только смирился с магией макросов, тут еще какая-то магия трейтов
>>2895200 > Там какая-то ньюфажная херня наподобие ютуб видосов как if писать и как цикл циклить. А про архиважные темы типа владений и лайфтаймов - мол смотрите они есть у нас. Лайфтаймы подробно расписаны в главе 10. Ты, видимо до неё даже не дочитал. Всё остальное тоже наверняка есть, просто я сам пока что на 11 главе сижу читаю. С таким отношением у тебя, я вижу всё верно написал выше. Ты не смотришь в книгу, ты смотришь на авторитет автора. И тебе кажется что прямо с первой страницы книги должна работать МАГИЯ АВТОРСКОГО СКИЛЛА, при которой ты волшебным образом сразу начнёшь понимать сложные концепции. Так не бывает. Сначала ты читаешь 200 страниц "ньюфажной херни", либо идёшь нахуй и тебе не перезванивают.
> как работает магия с response.set_mut Ставлю сто нефти, что через передачу владения, как и написано в первых главах книги "все фишки языка стали возможны через принцип владения". > каким хером строка может превратиться в трейт Modifier и вызвать на себе modify() Лол. Прямо в этом треде написано как. Через трейт Into<T>.
> магией > магия > магия Магическое мышление детектед. Тяжко быть тобой. Нет никакой магии, есть байтики на стеке, байтики в куче, указатели байтиками на стеке на байтики в куче. Всё. Больше ничего нет.
>>2895178 >Еще можно data: FuncData заменить на data: impl Into<FuncData> и будет по красоте. Можно, но не нужно. Трейт Into автоматически имплементирован для типов, которые имплементируют From, поэтому для своих типов правильнее имплементировать последний, чтобы не делать двойной работы.
По теме с дефолтными параметрами — не понимаю, что все с ними носятся который тред. По работе пишу на старом стандарте C, поэтому никаких дефолтов. Не испытываю никаких трудностей с этим. Наоборот, когда приходится делать всякие вспомогательные скрипты на питоне, раздражают его километровые списки дефолтных аргументов в функциях. Особенно, когда кто-то использует только часть из них без указания имени аргумента. Сидишь потом гадаешь, с какими же параметрами вызывается функция.
>>2895405 >>2895417 Потому что агрессивный маркетинг вливает ваш раст в неокрепшие мозги и естественно они начинают хотеть то, что есть в других языках, пытаясь натянуть системный раст на свою прикладную разработку.
Я больше чем уверен, что местные школьники перетекли из js, куда в последнее время стали активно заливать евангелисты раста.
>>2895478 Да ну, ты преувеличиваешь. Нет никакого агрессивного маркетинга. Язык опенсорсный. Ни о каком маркетинге там в принципе речи быть не может. Продавать нечего. Всё скачивается бесплатно, то есть, даром. Маркетинг может быть только на мерче и саппорте.
>>2895890 Сидишь себе переименовываешь "слэйвы" и "мэстер" в хэш константах и получаешь боблища как успешный менеджер, когда крупные игроки бегают вокруг тебя и заносят донат.
И чтобы сей источник не иссякал, куда ты будешь бабло заносить? Вот мы открываем ютуб и видим как говорят одно и тоже все 8 лет (см пикчу).
Раст очень замедляет разработку, ресурсов программиста кушается больше чем хотелось бы и потом мы видим на реддите статьи мол - как раст хорош, но...
>>2896259 >Раст очень замедляет разработку Возможно, он замедляет на этапе хуяк-хуяк и в продакшн. Хотя, если сравнивать с плюсами, где часть времени съедает еботня с либами и системами сборки, то примерно то по времени и выходит. Зато потом, когда проект разрастается, на расте его горасдо проще дописывать и рефакторить, на чём-то другом проще сразу переписать.
Почему крипта полюбила раст? Потому, что в отличие от корпораций, им нужен язык, на котором можно писать прямо сейчас, без риска проебать бабло из-за влома. На 10-15 лет вперёд они не загадывают, но вот сделать и не проебать уже сейчас - лучше всего годится именно раст. А корпорации пока принюхиваются, как принюхивались в 90-е к тому же линуху.
>>2897005 Открываешь кнопку ПУСК, выбираешь любую программу там и делаешь клон.
А если серьёзно, у тебя есть наверняка область, в которой ты работаешь, область твоих интересов. Вот в этой области и делай. Вангую, щас будет ответ наподобие "да я ничем не интересуюсь", тогда сделай программу учёта мамкиного борща.
>>2896809 >Зато потом, когда проект разрастается, на расте его горасдо проще дописывать и рефакторить Рефакторить раст, это еще одна известная боль о которой принято молчать. Но тебе, фантазеру, об этом откуда знать.
>>2897095 >1) перепишем всё на расте >2) .. >3) ряяя ансейф Любую полезную хуиту, которую пишешь для себя лучше писать на каком-нибудь заскорузлом языке, чтобы потом не обосраться, когда условные долбоёбы из мозиллы не апдейтнут язык x.x0 до версии x.(x+10)0.
>>2897120 Как раз сейчас этим занят. Очень радует, что это вообще возможно на таком раздутом проекте, как мой. На любом другом языке проще было бы переписать с нуля.
Растаны, а у нас вообще перекатом кто-то занимается? Вы вообще в курсе, что тред давно и плотно затонул? Вы вообще осознаёте, что в любой момент тред может исчезнуть? Конечно, на дваче есть функционал архива, но я бы на него не надеялся. Если перекатывать никто не хочет, я перекачу.