В этом ИТТ мы можем объяснить базовые и продвинутые концепции языка, и программирования в целом, поможем вкатывающимся, подскажем что выбрать для веба, игр или, прости Абу, блокчейна.
Попробую еще раз. Есть текстовый файл с хексом типа такого \x03\xea\x81 и так далее. Я читаю этот файл построчно, но не понимаю как перекодировать такие строки в равноценные байты. Помогите советом как это сделать, аноны.
>>2286886 В этом файле не только такие хексы, есть и обычный текст. Я нахочу нужные мне строки посредством регулярок и вот тут уже затык, не пойму как мне его конвернуть.
>>2285976 → >Заметил, что в языках без ООП код читается лучше. Может потому что мой первый код был когда-то в процедурке, хз, но явно без ООП абстракции размазывают меньше. Мне лично все равно как оно читается, но вот что анализатор в IDE не справляется с 3/4 кода, потому что не может процедурные макросы распарсить - вот это для меня проблема. https://github.com/kas-gui/kas/blob/master/crates/kas-macros/src/widget.rs
>>2265593 → >Удивительно как язык яростно сопротивляется ООП, а так же вещам которые есть в других современных языках (значение поля|аргумента поумолчанию). Ладно, спасибо. Все из ООП кроме совсем упоротых случаев связанных с наследованием в расте есть. Когда завезут https://github.com/elahn/rfcs/blob/delegation2018/text/0000-delegation.md уже нечего будет против сказать.
>Нахер это все нужно, если программы на расте не достижимы? >То есть, без unsafe или сборки мусора (Rc), нельзя растом покрыть 100% потребностей системного языка. unsafe это не проблема, а преимущество. В виде локализации потенциальной ошибки, и упрощения code-review. Необходимость в Rc - физический ограничитель, результат дизайна архитектуры фон Неймана - проблему совместного непротиворечивого асинхронного доступа к ресурсу переложили на программиста.
Гораздо приятней многие другие плюшки языка. (перепечатал с другого места, но согласен сам) - В отличии от многих других компилируемых языков со статической типизацией в Rust присутствует единая система сборки и менеджер зависимостей проекта. Добавить зависимость можно одной строкой в конфигурационном файле (поддерживаются также приватные репозитории, git). Также одной командой cargo vendor можно скачать все зависимости и использовать их в дальнейшем без необходимости доступа к интернету. - Экосистема Rust заботится о безболезненной возможности обновить инструменты и зависимости, так что автоматизация процесса сборки не будет стоить столько нервов и усилий как в экосистемах типа NPM, например репозиторий crates.io был спроектирован с учетом проблемы left-pad в том смысле, что когда разработчик пакета меняет версию, пакет предыдущей версии все еще будет доступен любому. При внесении изменений в компилятор или стандартную библиотеку бот https://github.com/rust-lang/crater проверяет внесенные изменения на предмет совместимости с пакетами crates.io. - Мощная система типов Rust позволяет закодировать множество различных инвариантов, чтобы компилятор мог их применить. Как пример приводится паттерн https://cliffle.com/blog/rust-typestate/ который позволяет удостовериться в корректности прохода состояний конечного автомата на стадии компиляции. (HTTP библиотека Hyper использует этот паттерн чтобы обернуть "попытку установить заголовок запроса/ответа после начала отправки тела пакета в поток ввода-вывода" в ошибку времени компиляции) - Система типов Rust и модель владения+заимствования сильно упрощает композицию и переиспользование структур данных, позволяя с легкостью использовать структуры данных написанные кем-то более искусным в оптимизации, и облегчая способность подстроить ваше API таким образом, что вы сможете переключиться позже к новой имплементации. (Внутренности HashMap стандартной библиотеки недавно заменили на более быструю реализацию hashbrown, и начались обсуждения по импорту урезанной версии crossbeam-channel для исправления давних проблем с std::sync::mpsc, а также для значительного ускорения ее работы) - Проверяемые компилятором тип-суммы. Ты пишешь enum с несколькими вариантами, содержащими данные, и получаешь тип-сумму без лишнего шаблонного текста, а компилятор удостоверится что ты не прочитаешь из ошибочного варианта. - Отсутствие NULL. Поскольку Option<T> и match были в языке изначально и использовались повсюду в стандартной библиотеке, никакие &-ссылки не могут быть null. И даже если Option не присутствует в сигнатуре функции, можно не беспокоиться за null'ы. (И если любая из переменных где угодно в T промаркирована как необнуляемая, тогда компилятор использует этот бит информации чтобы выделить вариант None из Option, так чтобы не тратить память понапрасну на вариант enum'a. Т.о. получается бесплатный по памяти Option в Option<T>) - Result<T, E> это тоже что в Java проверяемое исключение, только реализованное как положено. В Rust это просто тип-сумма, и стало стандартом по всей экосистеме и в стандартной библиотеке. Если функция возвращает не Result, значит она не может отказать. (Кроме разве что макроса panic!, но это Rust-овый вариант assert'a - и используется в целях отладки) - Великолепные комбинаторы. Серьезно. Загугли список методов типов Option, Result и Iterator. Они почти во всех случаях компилируется в такие же по эффективности реализации как если бы ты написал их вручную на Си с использованием if и for... если не лучше в некоторых случаях, поскольку компилятор может полагаться на то что вы не сможете поменять ненароком данные, находящиеся внутри; и благодаря этой информации может применить дополнительные оптимизации. - Гигиенические макросы базирующиеся на разборе потока лексем, вместо простой подстановки строк. - Поддержка срезов как объектов первого класса (могут быть переданы как параметр, возвращены из функции, присвоены переменной). Позволяет производить zero-copy разбор без необходимости беспокоиться о висячих указателях. Оптимизируйте в волю. - Объектно-ориентированный синтаксис без необходимости думать о том POD-ли мой класс (как в С++) поскольку my_obj.method(foo) это просто синтаксический сахар для чего-то вроде MyStruct::method(&mut my_obj, foo) можно прямо так и писать если хочется. (гугли "Universal Function Call Syntax") - Если обратиться к динамической диспетчеризации, она все равно не модифицирует структуру ( https://docs.google.com/presentation/d/1q-c7UAyrUlM-eZyTo1pd8SZ0qwA_wYxmPZVOQkoDmH4/ ). Вместо этого структура становится (&object, &vtable) толстым указателем - Автоматическая упаковка структур. Если не укажешь #[repr(C)] в целях FFI, раст за тебя реорганизует поля структуры чтобы минимизировать заполнение (padding). - #![forbid(unsafe_code)] позволяет удостовериться что небезопасный код не проникнет в модуль силами менее опытного коллеги. - Когда unsafe необходим можно использовать не только санитайзеры LLVM, в Rust присутствует свой собственный санитайзер Miri ( https://github.com/rust-lang/miri#bugs-found-by-miri ), который выискивает множество возможных случаев неопределенного поведения, и разработчики поставили себе целью довести его до состояния когда он сможет отлавливать все такие ошибки (см. также Loom https://lib.rs/crates/loom ) - Одна из основных целей Rust - минимизировать или совсем убрать необходимость размышлять о поведении кода на глобальном уровне, в том смысле что к примеру вам бы пришлось подумать о потенциальной возможности другого модуля освободить память, на которую у вас имеется указатель. И не важно кто тут был неправ, тот кто освободил память или вы, тем что взяли этот указатель. Rust не позволит коду в таком состоянии скомпилироваться, потенциально сэкономив время и труд разработчиков. - По поводу владения и заимствования. У компилятора есть преимущество в том что он не устает, не отвлекается, и у него не бывает критических дней. - В дополнение сборщику проекта (cargo build) и линтеру (cargo clippy), вы получаете Искаропки Работает™ систему документации API (cargo doc), форматировщик кода (cargo fmt) с выработанными сообществом предустановками стиля, и замечательно интегрированным стандартным фреймворком для автоматического тестирования (Аннотация #[test] чтобы указать что функция является юнит-тестом, папка "tests" для интеграционных тестов, любые кусочки кода в вашей документации будут, по-умолчанию, запущены как тесты документации, для проверки их корректности на текущей кодовой базе и для уменьшения количества тестов, которые вам требуется написать)
>Этот язык нужно было закрыть на уровне эксперементов, когда уперлись в то, что недостижимо написать программы в парадигме языка. >Зачем этот баран-чекер, если он влияет только на хелло-ворд?? Он будет вторым языком в ядре Linux. Линус сказал что в целом доволен, но есть небольшие недочеты. Согласно отчетам разработка спонсируется ISRG (Internet Security Research Group) и Google https://lore.kernel.org/lkml/[email protected]/
>>2289260 Ты же понимаешь что это саботаж от анальников и жуткий недосмотр менеджмента (либо он тоже в доле), если они переписали что-нибудь критическое? Теперь эти анальники могут до пенсии сидеть и пилить свой кусочек, завязав все процессы на себя и откладывая какашечку. набрать новых индусов заниматься разгребательством так просто не получится, а если уволить текущих то можно остаться с оптимизированными, но обосранными штанами и креслом. И даже на паркете будет размазано. Но если у них все хорошо получится, то майн респектирунг.
>>2288483 Если ты работаешь в бизнесе, то на практике выходит, условно (для примера), что 70% сопровождаешь код (читаешь, изучаешь) и только 30% пишешь. Даже в хваленной либами джаве или шарпе, вне топ либ приходится сталкиваться с поверхностной документации и лесть в сорцы чтобы понять как это работает и как этим пользоваться. А в динамико-дрисне вообще через IDE хер что прочитаешь, тут вы вместе с IDE не понимаете что за код.
Так что если кодер говорит, что важнее как пишется код, а не читается, он не работает программистом, это домашний писарь, или сантист с питоно мозгами. Отличие, наверное, только у сишников, которые пишут ембеддед. Они там паяют и каждый раз с нуля пишут. Там им читать, может, не особо надо. Но этим ребятам даже С++ не особо подходит.
>>2288915 Программы недостижимы, система владений работает только для простейших примитивных решений, а во всем сложном придется юзать сбощик мусора с подсчетом ссылок или unsafe.
Но зато посмотрите какой хороший пакетный менеджер. Во всем виноват фон Нейман!
>>2289045 Естественно для хранения практичнее UTF-8, но в программирование, при потребности пройтись по чарам, тебе нужно будет не бесплатное преобразование, потому как все строки хранятся как сырой список из 8 байт (что в реале не является вообще UTF-8).
И даже не важно, что там поколение зумерков на-мечтало. Сэкономленный байт дешевой памяти для UTF-16, никогда не будет стоит дорогого процессорного времени при частом преобразование строки из сырого потока 8 байт в UTF-32 (4 байта).
>>2289255 В расте нет ООП. То что зумерку видится как "объект.метод()" через точечку, то в расте это просто сахарок для функции с некоторыми возможностями для закрытого доступа.
Нет наследование, нет ООП. даже не фантазируй и не спорь.
>>2289276 Двачую это хитрый саботаж для бизнеса. >>2289260 Забавно, но даже если переписать того же языка на этот же, можно получить кратные цифры. Гордиться тем, что системный компилируемый язык победил динамико-дресню, это как гордится что ты на феррари обогнал школьника на велосипеде. Победы, которые мы заслужили. Переписали бы на Го, не попали бы в найм-яму. Теперь модные и молодежные сбегут (или загнут требования) и бизнес останется один на один с растом.
>>2289273 1. Rust оказывается не медленный в написании, если ты его действительно учил, а не пробежался глазами по "rust by examples". 2. Компилируемый != быстрый. 3. Из языков позволяющих писать скоростной код (железного уровня) соответствующий уровень безопасности может предоставить только Ada.
>>2289323 Раст и Го действительно не ООП языки @ В реальности в промышленном программирование это является достоинством. @ Все дрочат на анемичность данных, в котлине подефолту зафиналенны классы. В шарпе надо явно пукнуть чтобы сделать виртуальные методы. @ Тупенький с двача сидит доказывает что в расте есть ООП.
>>2289392 >Тупенький с двача сидит доказывает что в расте есть ООП. Кто доказывает? Это ты тупенький. Я говорю, что классы и наследование это не ООП. Всё!
>>2289283 >Так что если кодер говорит, что важнее как пишется код, а не читается, Но ведь в комменте не это написано. Сказано про семантику, а не синтаксис.
К слову, в Rust он нормально читается. Существует большое количество языков, в которых по одному объявлению непонятны инварианты кода (иногда даже объявление оторвано от определения без явной и существенной причины, как в Си или С++). В Rust же обязательно указывать ссылочность типа и мутабельность. Что позволяет через простой взгляд на заголовок функции понять уже многое из того что происходит внутри. И что произойти ни как не может. Бывают в заголовках также и времена жизни (что позволяет по одному только заголовку увидеть отношение входов функций к выходам).
Такой читаемости на уровне только определений, без необходимости заглядывать в реализацию могли бы позавидовать многие.
>>2289405 Все это превращается в громкий маркетинговый пук, пока ты не натыкаешься на переопределение переменных в расте. let my_var = 100; //тона кода let my_var = "пук";
>>2289392 >Тупенький с двача сидит доказывает что в расте есть ООП. Но он ведь прав в чем-то, оно действительно есть в некоторой степени (3,5 из 4 парадигм). Наследование в Rust появляется в урезанном виде - наследование поведения, но нет наследования состояния.
>>2289412 Самое забавное, кодя на js, я иногда торопился и писал к определенной переменной повторно "let", просто на уровне мышечной памяти. И меня интерпритатор ругал за переопределение. То есть из-за этой херни в расте и человеческого фактора, я могу словить не хилую такую плавающую ошибку.
>>2289417 Я помню гоферы тоже фантазировли, что у них есть ООП, а потом как-то резко перестали это говорить. Расту тоже нужны евангелисты, а то среднестатистический фанбои несут порой херню. Когда мир устал от ООП эти додики гордятся что у них там какое-то кастрированное ООП
>>2289443 Тебе нужно на входе преобразовать и на выходе - и все. А там где у тебя сырой список 8 байт и нужно "чариться" ты будешь все это преобразовывать в 4 байтовый список. Это достаточно нативная операция и в каком-то парсинге строк в цикле ты опустишься до питонов.
>>2289449 Домашний писака может позволит себе не использовать js в жизни. Но из-за монополии js в браузерах не использовать его, становится все сложнее.
>>2289458 У тебя два стула, Либо преобразовывать на входе и выходе. Либо преобразовывать всегда в программе. Понятно, что опытные разработчики выбрали ~20 лет назад и что выбрала хипстота сегодня, когда памяти хоть жопой жуй
>>2289471 большего щитпоста и придумать сложно для развития сходи сделай бенчмарки одного и другого способа, раз всему миру не веришь, ну или хотя бы погугли их чтоли
>>2289473 То-то я смотрю уже даже на js десктоп пишут. А среднее говно приложение со всеми абстракциями весит как винда 95. UTF-16 хватило бы за глаза.
>>2289456 Одно дело когда тебе втирают какой раст правильный со всех сторон и крутой. И когда на фоне этого ты натыкаешься на затенение. И такой "чего??".
Попильный язык без души, с прикрученными сладостями для заманивания глупого юзера. Я думаю, что и внутри либ и такой же бардак.
Я вот думаю, а нахуя растобляди пиздят о том какой их язык дохуя системный и заменит Си, если в реальности он конкурирует с Говном и плюсами? На два стула сесть не получится, поэтому придется выкидывать бОльшую часть раста, чтобы писать на уровне где используется Си. Очередной маркетинг?
>>2289619 выполняет свою прямую функцию если ты уж не можешь сам проследить что за переменную используешь в данные момент, то включай руками ограничения, зачем всем запрещать удобную фичу, когда каждый может себе её включить\выключить если им понадобится
>>2289683 если ты уж не можешь сам проследить за выделением памяти, используй смарт-поинтеры, зачем всем запрещать удобную фичу, когда каждый может себе её использовать\не_использовать если им понадобится.
>>2289619 Это не просто неочевидное затенение, это еще и скрытый drop предыдущего содержимого. Вот есть вещь поинтереснее: let mut i = 0; match 1 { 1 | _ if { i += 1; false } => {} _ => {} } // i == 2
>>2289882 Я эльфийский не знаю, но вроде на 123 строке реально на выходе два раза дропается вызов. Так что может растер и не звездел (редкость, но бывает и такое).
Как понять время жизни этой записи fn get_message<'a>() -> &'a str { "hello" } Типа жить будет в области видимости использования функции или что? И почему компилятор тут сам не может сделать что-то, ведь параметров нет и вариантов не особо то и много?
>>2289932 Второй вопрос. Как вообще прописывать эти лайфтамы, если функция не знает как может жить внешняя переменная? fn foo<'a, 'b>(name: &'a str, default: &'b str) -> &'b str
То есть, тут я программиста заставляю, чтобы параметр жил ровно столько же как возвращаемое значение. А что если у программиста будут другие условия?? Он тупо не сможет воспользоваться функцией или из-за моей функции будет все переписывать?
>>2289915 Разве они конкуренты? У них вроде разные основные области применения будут. Это конечно плохо что есть неочевидности, но их все же меньше чем скажем в С++, которому Rust реально конкурент в далеком будущем.
>>2289932 Оно выводится из переданной строки, у которой время жизни static. Запись 'a можно воспринимать как тип. Это как бы коробочка для какого-то конкретного времени жизни которое может прийти извне. В данном случае пришло изнутри. Можно было и fn get_message() -> &'static str написать
>>2289936 В твоем примере времена жизни относятся только к деталям реализации тела функции. Она просто обещает что вернет ссылку внутрь параметра name, но не ссылку на default.
>>2289971 Неудачный пример, я имел ввиду нечто такое fn foo<'a, 'b>(name: &'a Type1, default: &'b Type2) -> &'b Type3 Я же, как автор функции, не могу знать сколько живет переменная во вне? А тут я явно говорю что должно жить столько же как default. Для меня это выглядит дико что кто-то меня может ограничить функцией или я кого-то могу огрничить функцией и придется переписывать, подстраиваться (или же я чего-то не понимю)
>>2290010 Зачем ты мудришь, придумываешь себе сложности на пустом месте? Либо в функцию пришло, она обработала и отдала, и дальше ей похуй, либо она сама заспавнила полноценный объект и отдала без всяких лайфтаймов. В твоём случае ты же не переменную возвращаешь, а ссылку на неё. Сама переменная живёт где-то в другом месте, это не твоя головная боль, а владельца переменной.
>>2290071 Хз, это профдеформация, мы когда пишем что-то, то пытаемся покрыть все возможные случаи, так же и тут, я просто смотрю что возможно и как будет. Я бегло листал сорцы, там активно используют лайфтаймы, мне показалось они нарушают концепцию функций как "черных ящиков".
Другая история в том, что он мог бы их вывести сам. Ведь он уже анализирует тело функции, и тебе бы не пришлось их указывать. Но тут подумай что ты можешь не иметь доступа к телу функции, поскольку она уже у тебя скомпилирована и находится во внешней библиотеке - как тогда гарантировать лайфтаймы? Как определить что вернулось из функции ссылка во внутренности первой переменной, а не второй?
У меня нубский вопрос. Все носятся с этим двухсвязанным списком. Его как бы вообще нельзя написать на расте? Или речь идет про то, что безопасно написать нельзя, а через unsafe возможно?
>>2290173 >безопасно написать нельзя, а через unsafe возможно? Можно, просто это кейс в котором концепция владения и система типов раста текут, и так себе оно пахнет.
>>2290173 Тут прикол в том, что безопасное подмножество Rust запрещает гонки по данным. И те кто "носятся" просят увидеть не стандартный связный список, как в Си (который в Rust тоже будет unsafe). А безопасную многопоточную имплементацию, которая и в Си выглядит интересным образом https://www.microsoft.com/en-us/research/wp-content/uploads/2001/10/2001-disc.pdf
>>2289417 >Наследование в Rust появляется в урезанном виде - наследование поведения, но нет наследования состояния. Это называет, вроде как, композиция или агрегация, но не наследование.
Слышал в подкасте о том, что амазон хотел якобы подмять под себя фонд раста, подкастеры как всегда сыкливо намеками обменялись и ничего толком не сказали. Кто в теме, что там случилось?
ООП ради ООП, как в учебниках 90ых годов по крестам, никому нахуй не нужен. Оно нужно только там, где сама логика программы просит объекты. Читай гуй и игры.
>>2290406 Да уже полгода как идёт, к сожалению всё никак.
Расклад такой: Есть амазон, который и так топ донатер, так ещё и хочет выкупить нахуй эту НКО, и нормально развивать руст с соответствующим спонсированием, которое они могут позволить для своего проекта.
А есть друзьяшки которые сидят на кормушке зп и называется это кубло core team (по факту что-то типо манагеров), и боятся что их пидорнут за ненадобностью и придётся реально работать а не сраться в твиттере за донаты и разрушать сообщество ебанатским поведением.
Алсо, главарь этой шайки об этом выразился так: >they've also taken steps to marginalize the core team. and some other dirty shit I won't say rn. Видимо, это амазон туда кончей вроде ashley williams набирает.
>>2290488 Был случай. Кто-то сделал пулреквест с оптимизацией, в комментариях написали "проверьте всё получше, так как добавляется ансейф блок", вроде как проверили и в итоге запушили, а через год нашли багулю и цве.
>>2290595 Нет, там с деньгами пролбемы нет, почекай спонсоров. А судя по тому что ashley williams ещё там, скорее всего это колесо генотьбы сделало поворот.
Насколько раст подходит для разработки под винду? 1) Без проблем. 2) Были небольшие затыки в некоторых либах. 3) Лучше писать пока под линуксом. Ну или свой вариант.
>>2290933 Смотря что под этим понимать. Если делать простой софт средствами раста и не спускаться вниз — всё ок. Если спускаться на уровень системных апи — будешь трахаться с кодировками (как и на всех нативных и не только языках под шиндой) и прочие радости работы с шиндой.
Вопросы по применимости Раста в эмбеддеде: 1) Насколько идиоматично core-подмножество относительно стандартного раста, в частности, передача ошибок? Не повторится ли плюсовой пиздец, где в std минное поле из эксепшнов, а ворочать сырую память в С-стиле ведёт к избытку ручных непроверяемых кастов и вообще по стандарту UB, с вырождением фактически в отдельный С/С++ язык? 2) Насколько сложно воспроизвести на Расте объявление в коде и расстановку в итоговом бинаре вроде такого: main.c: [code] ... struct __attribute__((packed, section ("ext_adc"))) { uint32_t sps; uint8_t gain; uint16_t data; } ext_adc_struct; ... [/code] linker.ld: [code] ... ext_adc (RW) ORIGIN = 0x00001100, LENGTH = 0x00000007 [/code]
>>2291297>>2291299 Спасибо, выглядит не так уж и страшно. На самом деле, я на Расте ещё ничего не писал, но в свете того что его предварительно одобрили для модулей ядра линукса интересно самому оценить пригодность, и стоит ли учить его уже сейчас. Похоже, ему не хватает для перехода всего двух вещей: начального импульса, чтобы писать одновременно и на Расте, и поддерживать интероп с уже написанным на С, и стабилизации стандарта, я так понял, core пока что официально не закончен.
>>2290933 > Насколько раст подходит для разработки под винду? пишу кроссплатформу, проблем нет, если не будешь спускаться на уровень системных либ, то ничего не заметишь
>>2291384 >и поддерживать интероп с уже написанным на С FFI вроде на отличном уровне с Си, и на средненьком с С++. В любом случае он может в LTO с с/с++. (Если у тебя есть статическая либа написанная на этих языках, он не только ее может прилинковать но и функции от туда выдирать и вставлять в свои участки кода inline'инг)
Я так понял чтобы подключить файл надо использовать mod filename;
Почему не сделали подключение сразу через use? Как-то просто странно выглядит, как будто мы цепляем внешние либы через use (я понимаю, что это просто алиас имен), а свои мало того что use да еще и mod.
Я, наверное, просто что-то не уловил или просто так задизайнили?
Слушал очередной подстаст, там народ говорит что все никак в расте не могут прийти к концепции гуёв. Мол дефолтный мир гуев имеет массу циклических ссылок друг на друга, а это в свою очередь херова ложиться на парадигму раста.
>>2291652 >там народ говорит что все никак в расте не могут прийти к концепции гуёв Либо хуйню несут, либо ты что-то явно не то услышал. Что за подкаст-то?
>Мол дефолтный мир гуев имеет массу циклических ссылок друг на друга Что ещё за дефолтный мир такой? Как напишешь — так и будет, блять.
>Так пришли к чему-то? Есть чисто растовые гуи, есть байндинги разного качества.
Но в целом раст для гуя — это оверкилл. Даже большие гуи вроде блендера можно написать на питухоне и всё будет ок работать. Если разработчики самой либы рисующей гуй не обосрутся.
>>2291664 > Но в целом раст для гуя — это оверкилл одна из типичных фраз из сборника школоты
либа для гуя пишется прекрасно один раз на нормальном языке, а конфигурация настраивается или тыканьем параметров в json или прикручивается слегка дающий логику скриптовый язык поверх, например, Lua (ну или петухон шобы модно-молодежно)
Я правильно понимаю, что в обоих случаях выхлоп одинаковый: 1) что заводим одну мутабельную переменную и потом изменяем ее значение по ходу 2) что каждый раз заводим новую переменную под любое изменение
>>2292846 >какой язык у тебя там будет строить дерево формочек — вообще похуй Ну не совсем. Помню я сидел в QTox'е, весь такой обмазанный безопасностью, а потом услышал что его обновить надо. Потому что у вас видите-ли такое: https://www.cvedetails.com/cve/CVE-2018-19873/ И как-то мне гадко на душе стало, неприятно так...
>>2293871 >>2293880 Выходы тут - да, получаются одни. Но вот на практике в проектах есть ли варианты к какому стилю лучше стремиться? Типа, что при ограниченном стеке на текущей платформе предпочитать одну мутабельную переменную или, что для теоретически большей безопасности создавать меньшее количество мутабельных переменных и каждый раз для таких простых типов завести обычную новую переменную... или вообще писать как БГ на душу положит, не задумываясь о таком
>>2294619 >Но вот на практике в проектах есть ли варианты к какому стилю лучше стремиться? Зависит от качества компилятора. Если он такое говнище, что не может оптимизировать даже подобное (т.е. оптимизации в нём вообще отсутствуют, работает просто как транслятор в асм) — может и стоит.
Любой компилятор на базе LLVM это говно свернёт ещё задолго до этапа генерации кода (https://godbolt.org/z/Ea5PEv8de), так что можешь с чистой совестью >писать как БГ на душу положит, не задумываясь о таком
>>2294900 Накати geth эфир, возьми крейт web3 для раста, попробуй сделать что-то типа этого https://etherscan.io/ например по адресу холдера найти все транзакции с ним, или транзакции у определенного токена. Для начала этого хватит, весело и увлекательно Еще нужно где-то пару Тб свободного места и обязательно SSD а то заебешься
>>2292793 ranger тупит не из-за гуя на ncurses, а из-за того, что оно работает в один поток и там очень много странной и тяжёлой логики (типа конвертации изображений в другой формат imagemagick, рендера html консольными браузерами или рендера всяких пдфок, а если отключить превьюшки всего, оно почти не тупит). Если начать работать с превьюшками в отдельном потоке, тупняка станет куда меньше
Посмотрел тут видос как пилится веб проект. Ппц, столько телодвижений чтобы круд сделать, да даже сервис передать. И при этом сервисы все на Arc и еще какое-то <dyn...> (хз что это, но звучит как рантаймовый костыль).
При этом олды помнят, что раст изначально задумывался как Го - асинхронным сразу (и вроде был ГЦ), а теперь там вообще ничего путного не осталось для прикладного уровня, а эти асинки погоняемые авейтами, та еще хрень (а могли вроде как в гошечке сделать).
Столько говностраданий чтобы получит производительность веб-сервиса на уровне джавы, шарпа или го.
Есть предположение, что типичный двачер — это сочетание шизоидного и тревожного расстройства личности. Экономика усложняется с каждым годом. Мир усложняется. Если много лет назад мужчины в основном рычали, двигали тазобедренным суставом и охотились, то сейчас появилось много сидячей, компьютерной, удалённой работы. Для успеха нужно много лет потратить на образование и самообразование, убить молодость и социализацию, чтобы потом ты стал хорошим специалистом, хорошо владел английским, ковырял баги в дебаггере, месил мьютексы и семафоры, обмазываясь многопоточностью и асинхронностью, мигал лампочками на STM32, каждый день самостоятельно учился чему-то новому и загребал доллары, вписался в экономику XXI века. Что в итоге?
У инцела шизоидное расстройство. Он — церебротоник ("мозговитый"). Высокий IQ, интроверт, линуксоид. Много ресурсов тратит на мышление, калории сжигаются, он всегда уставший, апатичный. Ускоренный обмен веществ. Логик. Рационал. Не развита эмоциональность. Сух, зануден. Душнила (душный человек). Не способен адекватно рассказать о своих хобби, интересах, потому что они сложные наподобие "запилить свой процессор на FPGA своей архитектуры и микроархитектуры, а потом для него компилятор написать". Когда начинает рассуждать про монады и моноиды, Haskell и Erlang, тянки разбегаются, затыкая уши.
У инцела тревожное расстройство вследствие воспитания в однополой семье "мать плюс бабушка". У Дениса Бурхаева было ещё хуже: мать + бабка + сестра матери, они втроём пытались его воспитать даже не образцовым пионером, а образцовой пионеркой. Поскольку двачер потратил молодость на умственное, а не физическое развитие, да ещё и мать с бабкой стращали его, дрессировали и запугивали, то получился результат, как на картинке 1. Рост — средний по популяции, астеник, есть дефицит массы тела, одна кожа да кости. Драться не умеет
Ебало представили? Инцелошиза прям из экрана течёт. Он наверное дрочил пока это писал.
Таким людям просто не нужно общаться с быдлом. После окончания школы это несложно. Ну и опционально творожность полечить таблетками, если уж прям кроет.
Есть какое-то нормальное решение для мини-оркестратора?
Задача-минимум - чтобы при своем старте одна программа стартовала несколько других в фоне, а при завешении точно так же завершала эти несколько других. Мониторинг состояния и перезапуск при падении не обязательны.
Не, я могу что-то подобное родить и сам, но наверняка есть готовые решения...
impl View for FrameView<'_> трейт требует статик этого бы не произошло, если бы вместо передачи во фрейм ссылки на буфер, фрейм использовал свой. как в расте выделить буфер фиксированного размера в рантайме? да не инициализированный буфер юзать опасно, но мне нужен . так понимаю надо делать vec::with_capacity? а потом передавать референс в read? и подразумевается, что реаллокаций не будет?
>>2300232 > Ну чел явно хочет абстрактной фабрики синглтонов и развесистого фреймворка же, кек.
Нет, я как раз ищу максмально простое решение без вагона зависимостей Мой хэлловорлд и так уже разросся до 500 крейтов, ебать... А функционала толком и нет
>>2300232 >Научись мысли лучше выражать, или код сразу кидай, прочитал раз 5 — нихуя не понятно Ну так я специально так написал. Один хуй сделал как и до этого делал. через макрос для вектора. Чтение в вектор всё равно не меняет его размер.
>>2294619 На практике второй вариант это идиоматический Раст. А еще идиоматичнее убрать b и вернуть выражение напрямую. Иммутабельность по дефолту, мутабельность только если без нее никак. В хорошо написанном Раст коде очень редко когда видишь mut.
Олсо, в Расте обьявление "переменных" это не совсем то, что в дефолтных языках вроде JS или Питухона. Их нужно рассматривать больше как не переменные, а просто обозначения у кто держит ownership значения, и shadowing это не что-то плохое как во многих других языках. Например, у меня на работе есть такой код (примерно):
``` let svg = createSvg(a, b); let svg = applyXslt(svg); let svg = correctBoundaries(svg); ```
То есть по сути идет простая композиция функций, просто в Расте нет возможности ее покрасивей написать без обьявления переменной.
Уверен, более опытные растоманы смогут сказать официальными терминами о чем я говорю.
>Олсо, в Расте обьявление "переменных" это не совсем то, что в дефолтных языках Меня вообще удивляет что это часто пишут не как "объявление" а как "связывание" (биндинг). А левую часть называют паттерном. Настолько часто что я даже не уверен теперь можно ли вообще использовать словосочетание "объявление переменной" в Rust.
>let svg = createSvg(a, b); >let svg = applyXslt(svg); >let svg = correctBoundaries(svg); >в Расте нет возможности ее покрасивей написать без обьявления переменной.
Не уверен что ты имеешь ввиду, но можно сделать impl Svg и запихать туда все эти функции как методы. Тогда получится let svg = createSvg(a, b).applyXslt(svg).correctBoundaries(svg);
let (oh, woe, is, me) = ("the", "Turbofish", "remains", "undefeated"); let _: (bool, bool) = (oh<woe, is>(me)); ///// let _: (bool, bool) = ("the"<"Turbofish", "remains">("undefeated")); ///// let l = "the" < "Turbofish"; let r = "remains" > ("undefeated"); let _: (bool, bool) = (l, r);
>>2297619 Там не логика тупит, а неисправимое питухонство. Сначала тупит, но несильно, а потом начинает тупить мощно, без всяких причин, даже в идле. Типичная бесконтрольная помойка работающая непредсказуемо плохо.5
>>2301578 Потому что хардкорный embedded пишут на сях (и даже не на плюсах). Если такое писать, то вероятно, на расте будет один сплошной ансейв без стандартной либы.
Около системное пишут на сях и плюсах.
А для прикладного уровня, он слишком много требует чем дает (см тесты производительности, всякие джавы и шарпы вровень почти идут, в шарпах вообще многие узкие места на сях написаны). Раст слишком много накладывает оверхеда на программиста в прикладном уровне (С++ тоже), такой оверхед там нафиг не нужен. Самое забавно то, что достигая уровня приложений джавы или шарпа, тебе придется обмазыватьcя Arc, что по сути костыльная сборка мусора. Ну и вероятно ансейвы тоже будут.
Что там в играх уровне ААА, я хз, но вероятно все равно проще накатить С++ ибо тупо либ больше и на проще сделать тяп-ляп и в продакшен. Если ты инди разраб, шарфа с юнити хватит с головой.
Насколько я понял, раст получил первый хайп, когда у него была асинхронная работа как у го "подкапотом". Но они его выпили и он превратился в еще один обычный ЯП.
Так же, есть мнение, что раст поломанный язык. То есть, вся его парадигма владения укладывается только на продукты уровня хеллоу ворда, утилит линукса и прочей мелкой радости. А во всем реально сложном придется прибегать к ансейвам и сборки мусора (rc/arc).
Так же, есть мнение, что языки без исключение непригодны вообще для работы в проектах миллиониках (на прикладном уровне). Ну, то есть, когда у тебя 10К строк кода ты еще можешь ручками потыкать и понять в каком контексте стектрейса упала твоя функция, а когда у тебя плавающая (случайная) ошибка, которая падает в функции, которая дергается в разных местах 10.000 раз, тут ты принтами не отдебажишь, нужен стектрейс чтобы понять в каком из 10.000 случаев упала эта функция.
>>2302123 Не толстил, взвешивал перед тем как потратить усилия на раст. Пытался читать исходники. Не зашел мне, как для прикладной макаке. Возможно в будущем станет как-то лучше. Но я больше надеюсь появиться некий язык со встроенной асинхронщиной (как в го), чтобы не дрочить эти async await и не делить мир разработки на асинхронный и не асинхронный (пускай может сборка мусора отключается через unsafe, а так, в принцепи, value type за глаза хватает чтобы меньше аллоцировать память, на прикладном уровне).
Может для системщика это звучит наивно, но просто мой взгляд.
>>2302108 >Потому что хардкорный embedded пишут на сях (и даже не на плюсах). Если такое писать, то вероятно, на расте будет один сплошной ансейв без стандартной либы. Ансейф обязан быть только в обвязках обращений с вводом-выводом (что бай дезайн не безопасно). А это всего лишь мизерная часть. >Скорость На пикреле. Используя идиоматичный Rust такая же как у Си и С++. Когда допишут бэкенд GCC (написание спонсируется) возможно станет еще быстрее. Считается что LLVM хуже оптимизирован. >Самое забавно то, что достигая уровня приложений джавы или шарпа, тебе придется обмазыватьcя Arc, что по сути костыльная сборка мусора. Арк нужен только при специфичной многопоточности - изменяемого асинхронного разделения ресурса. При этом является обычным подсчетом ссылок (без сборщика мусора, как в Яве или Шарпе). >Ну и вероятно ансейвы тоже будут. Они не обязательны в этом примере, не хочешь - не надо. Safe Rust - Тьюринг-полный язык. >Что там в играх уровне ААА, я хз, но вероятно все равно проще накатить С++ ибо тупо либ больше и на проще сделать тяп-ляп и в продакшен. Если ты инди разраб, шарфа с юнити хватит с головой. Я считаю что Rust совсем не подходит для написания игр. Возможно только IO/разбор пользовательского ввода к ним, так как обеспечивает безопасность. >Насколько я понял, раст получил первый хайп, когда у него была асинхронная работа как у го "подкапотом". Но они его выпили и он превратился в еще один обычный ЯП. Инфа неверная. До 2014 года (до версии 1.0 если не ошибаюсь) в Rust были грин-треды как в Го и сборщик мусора. Кстати, Rust единственный на сегодня язык который обеспечивает безопасность от гонки по данным и отлавливает 100% таких ошибок при компиляции. >Так же, есть мнение, что раст поломанный язык. То есть, вся его парадигма владения укладывается только на продукты уровня хеллоу ворда, утилит линукса и прочей мелкой радости. А во всем реально сложном придется прибегать к ансейвам и сборки мусора (rc/arc). Сборки мусорка как я уже указал нет, есть подсчет ссылок которого не избежать ни в одном языке программирования. Это самая легкая версия обеспечения непротиворечивого мутабельного асинхронного (многопоточного) доступа к ресурсу. Ансейвы могут пригодиться для оптимизации работы некоторых алгоритмов - при использовании циклических структур данных (но необязательны). Они нужны при доступе к функциям из библиотек других языков программирования (т.н. FFI). Если использовался не идиоматичный Rust вкупе с большим количеством трейтов, дженериков и ссылок придется иногда поставить unsafe (но лучше все-же переписать как положено если есть возможность). >Так же, есть мнение, что языки без исключение непригодны вообще для работы в проектах миллиониках (на прикладном уровне). Ну, то есть, когда у тебя 10К строк кода ты еще можешь ручками потыкать и понять в каком контексте стектрейса упала твоя функция, а когда у тебя плавающая (случайная) ошибка, которая падает в функции, которая дергается в разных местах 10.000 раз, тут ты принтами не отдебажишь, нужен стектрейс чтобы понять в каком из 10.000 случаев упала эта функция. Стектрейсы есть, но они не на экспешенах работают - таким же образом как работают отладчики. Просто получают коллстэк момента вызова. Исключения считаются вредными в 2022, современные ЯП пишут без них т.к. в большинстве ситуаций они не отличаются от паник приложения - не выполняют свою основную функцию возобновления работы программы после исключительной ситуации. Поскольку в большинстве случаев не позволяют восстановить программу в каком-либо вменяемом, рабочем состоянии. Чтобы использовать их правильно нужно очень аккуратно писать логику и сильно подстраиваться.
>>2302108 Бесполезно спорить, только время покажет. Мания переписывания всего и вся у сообщества скоро закончится, а вот сколько корпорации эту херню пиарить будут, вот это интересно.
>>2302218 >подсчет ссылок которого не избежать ни в одном языке программирования. Это самая легкая версия
и самая уебищный подход, который в люом не хелло-ворлд приложухе приводит к утечкам памяти, с которыми без поллитры не разберешься и все это параллельно восхваляемой "безопасности"
>>2302108 >Ну, то есть, когда у тебя 10К строк кода ты еще можешь ручками потыкать rust-lang 1.78 млн. redox 1.33 млн. diem 300 тыс. tikv 300 тыс. Veloren 200 тыс.
>>2302283 Приведи пример пожалуйста, я просто не профессор. Когда объект выходит за скоуп рефкаунтер уменьшится. Где тут возможность для утечки?
>>2302295 Мемори лик не решается ни в одном языке программирования. Странно было бы этого ожидать от Rust. Можно сравнить такое требование с требованием поиска компилятором возможных бесконечных циклов. Это неразрешимая задача.
Вот пример fn main() -> Result<(), Error> { let leak = Vec::with_capacity(take_n_from_input()?); loop { / Program main loop ... / }
в основном проблема с циклическими зависимостями, без которых весьма проблематично бойтись в не-хелло-ворлде
memory leak решается в любом языке программирования с нормальным сборщиком мусора.
я тоже не профессор, но, к примеру, питонщики последние годы очень жалеют, что завезли в питон счетчик ссылок, от механизма которого теперь зависит куча библиотек и теперь от него не избавиться. это приносит огромную головную боль - мешает закатить многопоточность, так как добавление на них мьютексов просаживает производительность и мешает сделать основной сборщик мусора более эффективным
>>2302355 >в основном проблема с циклическими зависимостями, без которых весьма проблематично бойтись в не-хелло-ворлде Действительно, есть такое, спасибо. С другой стороны разрешающий эту проблему механизм в сборщиках мусора выглядит как еще одно усложнение рантайма.
Там где совсем тяжко становится можно прибегнуть к методу языка Ada - аренам.
В языке со сборкой мусора можно совершить утечку памяти. Вот тут показано >>2302334 Она не будет отличаться. Тоже создаешь объекты, затем запускаешь бесконечный рабочий цикл программы. Объекты висят до конца работы программы и не используются - это по определению является утечкой памяти.
>>2302218 >Просто получают коллстэк момента вызова. Исключения считаются вредными в 2022 Кем? Хипстерам которые пишут компилятор?
У тебя магическая ошибка на проде. Спонтанное исключение, которое пишется в лог со стектрейсом, вместо простого лога, что функция "foo не смогла" (и такие точно будут).
И что теперь, ты будешь оборачивать в панику или явно запрашивать стектрейс и потом заливать в прод, чтобы просто хотя бы локализовать ошибку (понять сначала в каком контексте вызовов произошла ошибка).
Блин, сейчас не семидесятые, мы не пишем программы в 1000 срок.
>>2302304 Так я про это и говорю. Язык уже используется на миллионы строк и без вменяемых исключений будет сложно, но конечно можно (способных у нас много).
>>2302377 GC GC рознь. Я так пишу чтобы не отпугнуть новичков, которые подумают что в Rust это якобы так же медленно как и в языке с полноценным сборщиком мусора. С "остановкой мира" при освобождении памяти, и выводом циклических зависимостей о которых анон написал.
>>2302386 >У тебя магическая ошибка на проде Приведи пример который нельзя переписать также на Result.
Кроме OOM (который критичен только для системного программирования. Драйверы, там, ядра. Хотя и с этим сейчас решают - Линус сказал что без этого Rust в ядро не попадет)
>>2302376 >Объекты висят до конца работы программы и не используются - это по определению является утечкой памяти. Нет, утечкой памяти является выделенная память, к которой нельзя получить уже доступ. Насрать в память и потом не использовать или использовать позже, или использовал, но перестал - это просто проблема оптимизации. Тут нет ключевого понятия "утечка".
>>2302404 >Я так пишу чтобы не отпугнуть новичков Очередная ошибка тупого маркетинга. Людей надо подготавливать к правде, а не смягчать её или прятать. Лучше он узнает как есть и примет решения, чем потом словит фрустрацию и возненавидит за обман.
То есть, можно прям открыто написать, что существует проблема множественного владения и решается она только вот сборкой, но это сборка такая, а не как СтопЗеВорд.
>Такие проблемы сборщика мусора кстати подвигли Discord переписать свое приложение с Go на Rust. Компания хайпят себя средствами малых сообществ, которые разносят их лейбл как фанатики. Сейчас бы в 2022 до сих пор верить в этот маркетинговый маневр. Что и как там написано мы никогда не узнаем. Может там очередной микросервис, который завтра на ноду перепишут, потому что программитов легче найти. Или же там го был написан так, что тормозил, хз, но объективно это очередно буллшит истории успеха.
>>2302404 > И это при том, что сборщик мусора Go считается одним из самых совершенных. Лол, они там в 12 или 15 версии, тупо забили на гц и тупо переписали (сдвинули рычаг) на частое срабатывания (там еще эти умные слова типа латенсети и прочее). В общем, они тупо взяли и разменяли память, на процессорного время (очень часто срабатывание). Когда в жабьих мирах ты можешь выбрать, как часто дергать ГЦ с "Stop the World", тут просто всех поставили перед фактов и все приложение стали жрать на 10-20% проца (от мы офигели).
>>2302406 Приложение может восстановится. Например упало при http запросе, зачем ронять сервак. Во вторых это нужно чтобы записать в лог сразу с стектрейсом, что позволяет понять -когда падало, -что падало -и где именно падало.
У клиента раз в месяц происходит странная ошибка, данные записывают в документ некорректно. Ты же умный разработчик, ты ведешь логи. И просишь клиента прислать логи программы. Там написано, что упала функция foo, типа там какой-то null (None) прилетел. Ты запускаешь, у тебя не падает. Что делать то? Надо понять при каких условиях это происходит. Но функция вызывается 10.000 раз в 10.000 разных местах. Что делать? Ты оборачиваешь в панику, отдаешь клиенту и ждешь месяц.
Через месяц приходит ответ и ты видишь, что в определенном стекевызовов, сервис отрабатывает некоретно (потому что клиент делал редкие манипуляции, о которых ты даже не ожидал и вообще не знал). Фиксишь проблему за 1 минуту, решения которой стоило месяц. Заходишь на форум и пишешь как исключения и стекстрейсы ненужны.
>>2302450 >Что вас сюда всех тянет так? Это самый безопасный тред. Ошибка буллшитного маркетинга. Ты наслушаешься сладостей, а потом начинаешь копать и натыкаешься на суровую правду. Фрустрация, ощущения обмана - ты начинаешь ненавидит язык, вместо простого игнора. Вот такие последствия агрессивного маркетинга, как ты хотел?
Я не вижу ошибок маркетинга, а вижу одного шизика, который называет rc сборкой мусора и срет из треда в тред. Не понравилось — съеби, без тебя разберёмся.
- вопли о безопасной работе с памятью vs без rc (который изначально error prone) + вопли о безопасной работе с памятью vs без rc (который изначально error prone) вообще никуда в полноценном приложении
Ну вот писал простую программу с внешним крейтом. При запуске программа крашнулась без сообщений. В дебаггере определил, что крашится в момент входа в функцию внешнего крейта. Чекнул исходники, там куча ассертов. Возможно ещё перенаправил стандартные файловые дескрипторы процесса, поэтому нет сообщений о панике. Насчёт проблемы остановки, такая хуйня чекается пруверами, и в ATS такая возможность есть. Также в атс есть линейные и зависимые типы. Там есть безопасная арифметика указателей и прочие байтоёбские игрища. Встраивание сишки проще, чем в расте.
>>2302478 Создатели Rust целились в С++, неудивительно что сложно получилось. Вместо того чтобы орать ВСЕ ЭТО БУЛЛШИТ. Укажи что конкретно буллшит, и желательно еще указать как бы ты сам хотел видеть решение проблемы. Тогда будет шанс что услышат и запилят, если это что-то стоящее внимания.
>>2302536 >Почему вам именно эксепшен хэндлинг надо? Потому что чел 10 раз написал — ему похуй зерокост там или хуйкост, он хочет как в шарпах и джавах языках — упало — вот тебе стектрейс, причём symbolicated (хуй знает как это на русский перевести), а не залупу с адресами после стрипа бинарника.
>>2302346 это база, я кстати не смог прочитать это говно (не образец, а язык) какого хуя функция возвращает Ptr, там берется result = mem.len() последнее выражение в функции result И ОНО ВОЗВРАЩАЕТ ПТР
>>2302531 >Ну вот писал простую программу с внешним крейтом. При запуске программа крашнулась без сообщений. В дебаггере определил, что крашится в момент входа в функцию внешнего крейта. Чекнул исходники, там куча ассертов. Возможно ещё перенаправил стандартные файловые дескрипторы процесса, поэтому нет сообщений о панике. Как тут проблема языка? Я тебе таких крейтов сто штук в день могу налепить. Не суй в рот непонятно что, не разобравшись. >Насчёт проблемы остановки, такая хуйня чекается пруверами, и в ATS такая возможность есть. Не чекается пруверами проблема остановки, она неразрешима в общем случае. > Также в атс есть линейные и зависимые типы. Там есть безопасная арифметика указателей и прочие байтоёбские игрища. Встраивание сишки проще, чем в расте. Но он вышел позже Rust, когда он уже был на волне. И снискал поддержку мозиллы в развитии экосистемы. Без которой уже ни кто не хочет браться за язык для написания чего-то реального, только в исследовательских целях. Увы. Есть еще такой момент золотой середины - не переборщить с фичами иначе это оттолкнет народ. Часто жалуются на Rust что он слишком сложен для приходящих с динамически-типизированных языков. Создатели явно указали что целились при дизайне в недовольных Крестовиков (а не удрученных скоростью исполнения Хаскеллистов).
>>2302531 Сейчас по серьезной переработке С есть проекты двух типов. 1. Безопасность за счет тесной интеграции программной и аппаратной части, + суперсет языка С. CHERI 2. Субсет языка С. >>2302567 ЕБАТЬ он жирный, пиздец. Я не в глаза ебусь, я просто не растер. Ты скажи, он это чтобы потролить сделал?
>>2302568 >Ты скажи, он это чтобы потролить сделал? >The Most Memory Safe Buffer Overflow in Rust! Нет, блять, он на полном серьёзе высрал эту кучу говна. Вот с этого ещё подливы выдавил — https://rustrecoveryfoundation.neocities.org.
Такс значит что происходит Создает пустой вектор чаров. Пушит 15 пробелов, buffer = 0. Пушит "password\0", password = 15. Пушит 15 пробелов, отбрасывается возврат 24. А дальше хуета какая-то, реально говнище. Специально написал какой-то свой менеджер памяти блядь и переписал в нем чета. Я так понимаю, у вас есть альтернативы его read_line_into_buffer()?
>>2302554 Так он неправильный strip делает. Ему надо с флагом -d Мой хеллоуворлд (и стандартная библиотека) с полным стрипом 314кб а с сохранением дебаг информации 375кб.
>>2302568 Сейчас по серьезной переработке С есть один-единственный проект - сам С, развиваемый комитетом. И он просто очень неспешно добавляет в опциональную часть стандарта новые плюшки, вроде потоков и мютексов.
С - это как ебаный топор: - свою задачу выполняет на 120%; - в рамках своей задачи идеален по эргономике - ни добавить, ни убрать; - им хуярил твой дед, им будут хуярить твои внуки; - одно неверное движение и ты остался без ноги.
Раст больше напоминает мультитул с алиэкспресса: - прорезиненная непонятным пластиком рукоять осыпается на морозе и липнет в жару; - инструменты мешают друг другу; - некоторые вообще не открываются или недофрезерованы; - основная заявленная киллер-фича - ручная фреза, но никто так и не разобрался, как ее запустить, а продавец на все вопросы шлет смайлики и закрывает тикеты; - держать его можно только двумя руками - и похуй, что ты хотел просто поточить карандаш.
Не, выглядит интересно. Стильно, модно, молодежно. Иногда даже прикольно и удобно. Но явно не то, что может завоевать массы.
У меня есть претензии и по существу, но их писать дольше и скучно. Когда-нибудь потом.
>>2302603 > потоков и мютексов C11, больше вроде бы ничего такого потом не делали. Ну я посматриваю за С23, чета там дичь, не видел кстати (изменений у) потоков, мьтексов; лямбды передумали вводить. Удобные штуки для препроцессора, тип bool часть языка О_О, какие-то бафы printf(), функции для защиты от целочисленных UB - в общем мелочи, этого мало.
Перспективно статическими анализаторами заниматься, проверки везде прикручивать, вот, __FORTIFY_SOURCE=3 скоро будет в gcc, все такое. Но это не стандарт, это просто в теории полезно.
>>2302603 > У меня есть претензии и по существу В принципе мне достаточно инфлюенса от этого, чтобы не учить раст. Я просто начитался буклетов про него, где вкратце про эти борроу чекеры, семантики владения и все такое, прямо интересно стало.
>>2302617 А, ну еще (unsigned)? _BigInt(N) прикиньте, можно результат от SHA256 положить в один интежер, а не в буфер, потом его поксорить с таким же результатом так : a ^ b, а не bxor(a, b, SHA256_SZ);
>>2302607 Всегда проигрываю, когда домашнее фп макаки впервые видят реальный продуктовый код. Либо ты костылешь и пишешь все ручками сам, либо плавно натягиваешь готовую абстракцию над абстракцией.
У меня даже на процедурке петпроект уходил за 10-30 вложенности. Если писала целая команда, думаю за сотню наворотили точно.
В этом ITT треде байтослесари сознаются, что с самого рождения опускаются на дно чана с говном и не покидают его до конца жизни. Любые формализмы, логические системы, концепции, идеи, правила проектирования, да и просто хорошего тона, чувство вкуса — все это для байтослесаря чуждо, он пытается убедить себя, что всего этого не существует в реальном мире.
Лаба1, обертки над обертками, вот я жизнь повидал, у нас в армейке/на зоне и не такое было, а ты теоретик лаборант говна не нюхавший, в реальной жизни все иначе, вот у меня на заводе кудах-тах-тах! — кричит он, наворачивая очередной черпак дерьма, жадно причмокивая.
>>2302563 >Как тут проблема языка это было к слову о паниках при ошибке. здесь или ещё спрашивал, почему box не возвращает result например, послали нахуй, типа нинужно, а линуса послушали. подгорело с такого дизайна либ Хотя в расте, вроде, вместо box юзали тильду ~, а потом убрали.
>Не чекается пруверами проблема остановки её же не существует для языков не полных по тьюрингу. типа кока, агды и т.д.
>>2302829 > Любые формализмы, логические системы, концепции, идеи, правила проектирования Петухан, твои паттерны проектирования на собес за 200 это не не формализмы и не логичекие системы.
>>2302861 Я вообще неофит и мимошел, но в чем прикол ФП, если под капотом выполняется простыня императивного кода? Чем это отличается от написанной функции?
>>2302951 > прикол в том, что тебя это ебать не должно. это называется абстракция. Присоебиняюсь. А любой, кто что-то на это гавкнет - пусть молча проходит в ассемблеротред.
>>2302912 Причем здесь то, что под капотом? В Хаскелле тоже под капотом машинный код.
Язык программирования для человека в первую очередь. Для абстракций, кооперации с другими разработчиками, удобного чтения, поддержки, расширения. ФП взамен на некоторые ограничения дает свои преимущества.
А то что под капотом вообще значения не имеет. Офк когда речь идет не о критических местах, где важна производительность, там уже да, можно пожертвовать поддержкой ради ебли указателями и имеративным грязным кодом.
Чел, вот именно поэтому С - язык системного программирования последние 50 лет, и еще на 50 лет вперед им останется. Rust, тащемта, неплохой язык, но им надо вектор и методологию развития пересмотреть, и тогда он взлетит.
У Раста глобально две основные проблемы: дичайший false advertising и базарная разработка в ее худшем виде.
Первая проблема лично меня вводит в полнейшее недоумение. Раст почему-то упорно рекламируют как язык системного программирования, хотя он для этого а) никогда не предназначался и поэтому б) подходит как мокрый валенок для забивания гвоздей.
В Расте даже с первого взгляда видно очень много высокоуровневых абстракций, которые во-первых жрут ресурсы, а во-вторых ведут себя под капотом непонятно как, скрывая кучу тонкостей и нюансов от программиста.
Более того, многие из этих абстракций еще и не откручиваются толком. no_std в стабильном (!) компиляторе был поломан шесть (!!) лет это ко второй проблеме, кстати, тоже относится, а собрать что-нибудь сложнее fn _start() { loop {} } вообще не получится - нужно портировать core под целевую платформу, что есть задача весьма нетривиальная. Для сравнения: чтобы использовать все фичи языка C, не нужно ничего, кроме собственно компилятора C.
Если же танцуя с бубном и принося в жертву девственниц часть абстракций все-таки попытаться открутить, то внезапно окажется, что мы получили программу на почти чистом С, но с синтаксисом джаваскрипта. И 100% unsafe в каждой строчке. Стоило оно того? Да, потом на базе этого можно построить безопасный интерфейс, но...
И самое главное, я категорически не понимаю _зачем_ это делают. Раст отлично подходит для написания сложных высокопроизводительных сетевых многопоточных программ - неудивительно, учитывая тот факт, что главным драйвером его развития был и остается веб-браузер. Иными словами, Раст - конкурент C# / Java / Go, позволяющий добиться по сравнению с ними бОльшей производительности и предсказуемости, и при этом еще и меньшего потребления памяти ценой чуть более высокого порога вхождения и небольшого увеличения времени разработки что очень актуально в наше время затянувшегося дефицита полупроводников и в целом кризиса пролупроводниковой микроэлектроники. Но его никак нельзя сравнивать с C++ и тем более с С. Не системный это ЯП ни разу. То, что люди умудряются писать на нем ОС, дрова и прошивки - ну, так и на JS умудряются, что с того?
Рекламируйте Раст правильно - и от него будет не оторваться.
Что до второй проблемы... Раст разрабатывается сообществом по базарной модели. Демократия, открытость, голос каждого важен, все дела.
На словах вроде бы заебись, а по факту получается ситуация из басни про лебедя, рака и щуку: единое представление о проекте отсутствует как класс, каждый тянет в свою сторону и при этом никто не хочет брать на себя ответственность.
Баги вместо того, чтобы фикситься, приобретают статус мемов, которыми отвечают забредшим в issue на гитхабе или на форум. Баг с no_std шесть лет обсуждали, как исправить. Спасибо хоть исправили. Не с первой попытки, правда.
Обсуждения критически важных фич продолжаются годами. На материалах комментов к некоторым дискуссиям пара аспирантов себе диссертации могут написать, при этом ни строчки кода в компилятор ни единая блядь не добавит.
В коммьюнити уже по-моему отдельный вид онанизма - кто напишет более красивый RFC, на основе которого другие онанисты потом будут писать - нет, вовсе не код - другие RFC на ту же тему.
По той же причине язык и компилятор представляют собой дикое лоскутное одеяло, на которое без слез и поллитры не взглянешь. Уж на что плюсы клеймили за то, что они все подряд к себе тащат и не всегда это выходит последовательно и идеоматично, но Раст ИМХО переплюнул вообще все ЯП на свете в этом плане. Почему, блядь, например:
- iter и into_iter - as_ref и as_mut - as_ptr и as_mut_ptr
называются по-разному, если семантически они параллельны?! Вопрос "хули вы там обсуждаете годами, если на выходе вот такое" вообще задавать смысла нет - некому на него ответить.
В других проектах подобное решается либо узким советом избранных, как в плюсах, либо вообще единолично, как было до этого с питоном и все еще есть с ядром Линукс. Да, обсуждения и вклад более чем приветствуются, но в ситуации, когда необходимо принять решение, его есть кому принять. В коммьюнити Раста решения принимать некому.
Отличный пример, почему прямая демократия никогда не будет работать, кстати.
Без исправления этих двух проблем ИМХО Раст так никогда и не созреет, как язык, оставшись фактически очень прикольной концепцией и уделом любителей хайпануь.
Не хотел ведь писать... Ну пусть будет, для следующих поколений юнош бледных со взглядом горящим.
>>2303042 Раст с стд такой же по скорости, как и С. Нет причины "откручивать абстракции", ими как раз и нужно пользоваться, ведь они лоу-кост (бред про "жрут ресурсы").
>>2303042 >Раст - конкурент C# / Java Там такое чудо нафиг не нужно, что пишут в промышленном программирование байтодрочу и не снилось. Эта область давно обросла такими потребностями, что уже все равно когда ты там соберешь память, главное чтобы за неделю она у тебя не фрагментировась.
Демократии тут вообще нет, так как нет выбора управляющих. Суть демократии это не голосование фичь, а возможность смены руководство, которое и будет принимать решение. Хорошее руководство естественно нужно, но проблема как выбрать хорошее руководство? И как сменить руководство, если оно вдруг плохое? И вот как раз выборы эту проблему решают. забавно что выросло поколение, которые не понимают такие простые основы
>>2303059 Я тут недавно наткнулся на серию статей "Learn Rust the Dangerous Way".
Вроде прикольная идея: чувак берет хорошо оптимизированную программу на С и постепенно превращает ее в программу на идеоматичном Расте, попутно показывая, что производительность не теряется а даже совсем наоборот.
Я читал и прям радовался - ну надо же как все красиво и правильно!
Вот программа, переписанная "в лоб", она чуть отстает от сишного оригинала.
Вот чуть допиленная и избавленная от unsafe версия, она уже почти на равных.
А вот итоговый вариант, и он даже быстрее оригинала!
"Прям сказка какая-то", - подумал я. И решил проверить.
И не зря.
По факту версия, переписанная "в лоб" с кучей unsafe оказалась самой быстрой, но даже она отставала от сишного оригинала почти в два раза (а вовсе не на 30%, заявленных в статьях).
По мере же приведения к более "православному" виду программа становилась все медленнее и медленнее.
Итоговая канонiчная версия отставала от сишной уже в три раза.
Я игрался с оптимизациями, пробовал разные версии компиляторов GCC, CLang и Rust, собирал и запускал на разных процессорах - без толку. Тщательно оптимизированная сишная программа рвала растоподелие как Тузик - грелку.
Вопреки всему тому, что было написано в статьях.
Ну и как после такого вообще доверять сообществу раста?..
Сейчас знакомому надо было утилитку-скриптик по парсингу конфига роутера сделать. Сначала хотел на питонах, потом подумал что еще пол дня объяснять как все эти интерпретаторы да jvm ставить. Решил модно и молодежно накатить на расте и приятно удивился, чтобы установить надо от винды 6 гигов билдера С++ скачать - вы там совсем охерели??
>>2303259 Чекнул и охренел, там какой-то монстр в виде жабьих фрейворков. Мне же не ракету запутить, а exe файл сделать. потом мне еще объяснять как через pip пакеты поставить?
Блядь какие же дегенераты в этом итт треде. Один пишет утилитки-скриптики на языке для промышленно-системного программирования, другой пишет стены текста называя rc сборкой мусора, пиздец ебаный. Что за пиздец тут происходит нахуй?
>>2303296 Сбор мусора хто тред этого) ваша единственная гордость это статья восьмилетней давности как неосиляторы го переписали свою парашу на раст Пойми это как раз язык для хобби, он не нужен нигде, тупа хайп
>>2303296 В основном тут шитпостит шарпошиз, и я треда так 2 уже заебался с ним сраться и удалился. Отличается стенами текста про какую-то недостежимость, лгбт, врущий маркетинг и прочую хуйню и малафью. Вот оно — >>2302108 Алсо, в какой-то момент заебал половину борды и подвергся остракизму с выпидориванием из тредов боевыми картиночками вместо ответов — результат терапии можно увидеть тут >>2302804>>2302813
Ещё иногда залетает фп-шиз, одним-двумя сообщениями поясняющий что весь тред — тупые пидорасы-байтойобы, не секущие в его божественном фп — и сливающийся. Вот оно — >>2302829
>>2303255 >чтобы установить надо от винды 6 гигов билдера С++ скачать Это, кстати, один из главных форсов шарпошиза. Кто ещё на винде итт будет сидеть, кроме гейдевов у которых оно и так установлено, блять?
>>2303305 Десктопный линукс настолько ущербный, что лучше бы помалкивал. даже спустя 15 лет хер без костылей там посидишь, всегда, всегда нужно будет с чем-то ипаться
>>2303302 >шарпошиз Пока на растах думают как лучше переписать асинки и еще больше тормознуть и так медленное развитие инфраструктуры языка, в нормальных яп завезли чудный хотрелоад, который позволяет делать визуал как избалованный хипстер. Да да, теперь можно часами играться со шрифтами.
>>2303573 >>2303581 Лол, а вам что нужно? Те кто уже в теме особо не пиздят, ибо дела делают. Ну и в других местах общаются, в чатиках, в ирках там, но точно не на помойной борде.
>>2303297 >неосиляторы го переписали свою парашу на раст Чего бля? Я этого goвнокод научился читать пройдя по-быстрому тур го за вечер, он простой как мясорубка, а вот с растом только через несколько месяцев более менее начал понимать что к чему. Шёл бы ты отсюда вкатун
>>2304728 Дак это дело в том что синтаксис помойный) на го он простой да, но у нас нет встроенной функции сделать все хорошо, надо самому думать Чтоб ты понял (хотя я сосниваюсь что ты сможешь): голанг это кисть и краски, а раст это раскраска по номерам. То есть дебсы учат бесконечный список функций заранее написаных и потом пытаются складывать из них что-то.
Аноны, есть одна JSON-структура, внутри которой, кроме всего прочего есть и список. Как бы мне проитерироваться по этому списку? Юзаю `json` https://docs.rs/json/latest/json/index.html . Преобразую строку в JSON, затем выбираю нужный ключ(под которым лежит список) а дальше хуй. Как преобразовать получаемое значение из JSON в нормальный итерируемый списочек?
>>2312524 Я только что прочитал про Cell, и вот как я понял. Ты когда описываешь, скажем, структуру. Не можешь указать модифицируемое поле: struct Point { x: f32, y: mut f32, // Так вроде нельзя } Но если ты хочешь чтобы поле было модифицируемо, даже когда экземпляр структуры не создан mut'абельным тут и пригождается Cell. Как ограничение мутабельности короче.
Почему в С/С++ не работает принцип - выделил память, тут же найди место где её освободить?
Ну? то есть, в языках с ГЦ есть файловые дескрипторы, которые ты выделяешь и чуть ли не с младенчества учат - сразу писать код закрытия. В го даже есть defer. Так почему в С++ нет правила при выделение ресурсов сразу обозначать место их освобождения (по сути, память нам нужна только в определенных контекстах программы)?
>>2312805 Ну вот у нас есть 3 контекста 1. Глобальные контекст (на весь процесс/поток) 2. Контекст одного запроса/события/сценария 3. Контекст одного блока/условия/цикла/функции.
Я всегда знаю где надо освободить память. Других мест не будет никогда же? (просто 3 вариант должен создавать контекст автоматически средствами языка и тогда просто при объявление памяти нужно будет указывать контекст (если не указанно то это контекст блока).
>>2312753 Может я и ошибаюсь, но вроде отличие в том, что Cell владеет. А &mut только указывает на уже существующее.
То есть беря мутабельную ссылку на уже существующий объект, ты можешь ее потом дропнуть и взять эксклюзивную ссылку. А создавая Cell, и передавая туда объект, ты по сути его муваешь внутрь Cell.
>>2312808 Для того чтобы такое построить нужно на стадии компиляции знать когда поток исполнения в этот контекст до конца программы больше не вернется. Чтобы можно было со спокойной совестью освободить память. Посчитать это не такая уж тривиальная задача.
>>2312805 > Потому что ты можешь не знать, когда и где тебе надо будет память освобождать. Почему, она всегда освобождается либо в статическом месте, известном на этапе компиляции (по скоупам) или в жестком месте, где поставил программист или в рантайме на вызов какого-либо события. Поэтому можно проверять чтобы хотя бы один из этих вариантов для каждого выделения памяти есть.
>>2312524 Cell — это костыль, который иногда мешает оптимизациям. И вопрос стоит не в том, зачем нужен &mut, а в том, зачем нужен Cell и что он может, чего не может &mut.
Но если ты хочешь ответ именно на твой вопрос, то &mut нужен для оптимизаций операций по уникальной ссылке, и чтобы реально мутить всякое, потому что Cell на самом деле не даёт мутабельности без Default::default() или клонирования.
>>2312952 >Cell — это костыль, который иногда мешает оптимизациям. Это ты на SO нашел? Я тоже там был, но когда начал разбирать почему конкретно он может помешать, понял что &mut в том же примере будет мешать точно также как и Cell.
>>2313386 Как видишь, не даёт, ибо тебе всё равно приходится иметь &mut на одиннадцатой строчке.
>>2313255 Нет, не на SO, а потому что уникальная ссылка и указатель — разные вещи, и потому что компилятор имеет разные UB для этих разных вещей, и правила для уникальной ссылки строже, а потому и компилятор лучше оптимизирует &mut. UnsafeCell и все производные от него (в этот список входит и Cell, если что), специально говорят компилятору, что даже если ты владеешь ссылкой на эту срань, она может измениться, в отличие от любой структуры без UnsafeCell внутри. Так понятно?
Какие перспективы вообще у ржавчины? Работаю в сфере БЧ разработки и в силу популярности соланы/полькадота крайне форсируется изучение ржвачины помимо основного стека. Вот и стоит ли вообще время на это тратить на случай, если я захочу уйти из БЧ?
>>2313622 >Как видишь, не даёт, ибо тебе всё равно приходится иметь &mut на одиннадцатой строчке. Наверно я тебя просто не понял, потому как это мутабельная ссылка на значение из Cell без клонирования.
>>2313622 >Нет, не на SO, а потому что уникальная ссылка и указатель — разные вещи... На SO было подробней чем у тебя, с указанием конкретных причин просадок https://stackoverflow.com/questions/55168119/what-costs-are-incurred-when-using-cellt-as-opposed-to-just-t. Только когда я начал переводить чтобы указать тому челу, что деградация перформанса будет, понял что нет причин у компилятора потерять значимую информацию при оптимизации. там 1 - указание что всегда требуется копирование (но это можно обойти добавив mut к T) 2 - Cell нарушает алиасинг. Но так и &mut делает то же самое, не понятно к чему тогда тут претензия. Если с такой стороны посмотреть, то это полный аналог &mut
>>2313729 >2 - Cell нарушает алиасинг. Но так и &mut делает то же самое, не понятно к чему тогда тут претензия. Чушь написал, &mut не нарушает алиасинг в safe расте.
У него на SO так - когда компилятор видит &T он может применить некоторые оптимизации, которые невозможно провернуть с Cell из-за мутабельности. Получается что и &mut тоже такие оптимизации запрещает? Сравниваем-то не с &T
И все-таки Раст не совершенный (для меня) пока язык. Есть еще куда rustи.
Все чаще замечаю значения, которые могли бы вычисляться на стадии компиляции в тех и других крейтах. Вот пример Regex::new(r"/(\d+)$").unwrap() зачем тут unwrap, если значение можно (в теории) вычислить на стадии компиляции? Много таких мест встречается.
Говорят Zig преуспел в вычислениях на стадии компиляции.
>>2315895 в теории можно всё, на практике же в расте пока крайне кастрированный const-eval который находится на уровне ворочания RFC и пары PoC типа impl const Trait или <T: ~const Trait>
даже const_panic, стабилизированный в 1.57, мог бы позволить unwrap'ать в const-контексте, но там обосрались с const-дропом и const-деструктуризацией, поэтому пока паникуй сырыми строками и не выёбывайся
>>2315895 Нет, нельзя. И не только потому что возвращает Result, ибо строка может быть невалидной, а потому что у регекса внутри полный пиздец, хашмапы-хуяпы и куча всякой фигни, которую в компайл тайме никак не сделать.
Присутствие unwrap'ов и прочих динамико-проверок идет против парадигмы раст о повышенной безопасности кода. Когда можно было сломаться на стадии компиляции, у вас в рантайме падение. Тяжело мечтать о присутствии на рынке критикал систем, когда у вас такое.
>>2316593 Зря ты сагрился, я вообще о плюсах и си не думал когда писал. Мне на тех языках сидеть не надо слава Богу. Просто на мой взгляд приоритеты при оптимизации Раста сдвинуты не туда, лучшая оптимизация - это когда значение уже вычислено. А если это еще и галочек поставит в основную нишу Раст (программирование с усиленными гарантиями), так вообще замечательно.
>>2316420 Че ноешь то? Ассемблерные вставки засунули уже. А ты про unwrap ноешь. Язык не безопасен уже которую версию. Пидорасит от релиза к релизу с высокой скоростью. Побороли ошибки с указателями - наделали тысячи новых
>>2316672 Ассемблерные вставки не делают его небезопасным в безопасном контексте (поскольку в нем они не предусмотрены). Похоже ты тролль местный, т.к. очень уж слабый вброс. Даже новички типо меня знают о разграничении safe и unsafe
>>2317061 Мне непонятно какого размера твоя константа получится, ведь ты абстрагировался от конкретной структуры. Но при этом хочешь создать константу конкретного размера. Может попробовать указатели подключить? Извини если чушь написал.
Есть внешняя функция которая возвращает mut Т Как бы так запихнуть в lazy_static чтобы я потом мог передавать по всей программе этот mut T? У меня что-то не выходит
>>2317567 Есть внешняя функция которая возвращает PTR mut Т Как бы так запихнуть в lazy_static чтобы я потом мог передавать по всей программе этот PTR mut T? У меня что-то не выходит
>>2303042 >а собрать что-нибудь сложнее fn _start() { loop {} } вообще не получится - нужно портировать core под целевую платформу, что есть задача весьма нетривиальная. Так ведь нет, не надо портировать. Все для чего LLVM скомпилирует бинарь можно использовать с core. Это только std-либа использует libc, ее нужно под целевую платформу переписывать (не std-либу, а libc).
>очень много высокоуровневых абстракций, которые во-первых жрут ресурсы, Там где происходит жор ресурсов об этом явно сказано в Rust book. Из языковых конструкций это только dyn-трейты (как и виртуальные функции в С++).
>ведут себя под капотом непонятно как, скрывая кучу тонкостей и нюансов от программиста. В этом и стояла цель, написать как можно больше (но не слишком) общепринятых и часто используемых абстракций без ущерба производительности. То есть такую абстракцию, которую если бы ты сам идеально написал она бы жрала столько же ресурсов. Сможешь лучше - добро пожаловать разработчики ЯПов!
>Но его никак нельзя сравнивать с C++ и тем более с С. Не системный это ЯП ни разу. Ты никогда не поймешь прелести Rust пока не признаешь что мизерное число людей на планете способны писать код без CVE по памяти (таких уязвимостей >70% в кодовых базах Гугл, Амазон и Майкрософт). Но писать код надо, и хорошо бы иметь инструменты, которые помогают писать быстрый и безопасный код. А если таких нет, то хотя бы разделять безопасный и небезопасный (Rust отодвигает границу safe так далеко для системных ЯПов, как позволяет сегодняшний Computer Science. Взамен уничтожая совместимость с Си/С++).
Я согласен что с Си его сравнивать не надо. Хоть русскоговорящее сообщество его почему-то именно с Си сравнивает. Он задумывался и писался как замена С++.
>жалобы на медленную разработку языка программирования Когда на самом деле быстрее чем в раст мало где. Люди жалуются что не успевают за языком. Так что это скорее другая проблема - слишком быстрой разработки и кучи разных фич за несколько лет. К счастью темпы замедляются, уже не знаю с чем это связано. Может развал Мозиллы.
>- iter и into_iter Явное владение. На это жаловаться грех. То что должно было стать частью С++ изначально, пришло только в последующих стандартах в нашлепочной форме. Первое (iter) дает тебе ссылки на объекты по которым ты итерируешься. Второе (into_iter) сообщает что ты хочешь переместить/копировать (в сущности принимать во владение) объекты за итератором. Альтернатива скрыла бы от программиста основную задачу (ради решения которой раст для новичков стал сложней) - суть ее в том что я хочу знать когда я перемещаю/копирую туда-сюда объекты в памяти, а когда просто обращаюсь к какому-то объекту в памяти где-то там. Это хлеб и соль системного ЯП, так программист понимает что у него происходит со скоростью выполнения программы, и "что там по памяти". Понять когда она уменьшится очередной копией. Там же где другие языки просто копируют объекты - получается чисто прикладной ЯП с облегченной семантикой в ущерб производительности программы. (Можно еще упомянуть что в раст существует Cow (clone-on-write) которым можно передать кому-то неизменяемый объект, но позволить его копировать при необходимости изменить объект, или получить во владение. Да, это могло быть реализовано скрытой оберткой над каждым составным типом, но Раст - системный)
>- as_ref и as_mut >- as_ptr и as_mut_ptr Тут не понятно. Если это вопрос почему нет единого трейта вместо AsRef и AsMut, то это в основном потому что на принимающей стороне пришлось бы указывать все лайфтаймы. Если вопрос почему уникальность ссылки должна быть показана явно, то по этому поводу прошло обсуждение (не в пользу мембера кор тимы) https://old.reddit.com/r/rust/comments/25i544/babysteps_focusing_on_ownership_or_removing_let/ Это одна из причин почему язык так популярен у программистов-системников (не бизнесменов). Они его реально сами создали. Захотели безопасный и быстрый язык на замену крестам.
>А в других проектах... Хорошо что есть ЯП которые от народа и для народа.
>И самое главное, я категорически не понимаю _зачем_ это делают. Раст отлично подходит для написания сложных высокопроизводительных сетевых многопоточных программ - неудивительно, учитывая тот факт, что главным драйвером его развития был и остается веб-браузер. Иными словами, Раст - конкурент C# / Java / Go У каждого из них сборщик мусора. А ваши предложения тянут Раст именно в ту сторону. Зачем пытаться сделать из него то, что уже есть во многих экземплярах. Все эти языки занимают одну нишу. Ну, может быть Го скоро к ним подтянется. Я вижу как он начинает вбирать абстракции. Интересная задумка - набрать побольше начинающих программистов, а затем с ними вырастить новую Java и С#. Весьма оригинально.
>>2303308 Исключения со временем оказались избыточны в оверхеде при низкой фактической полезности. Из ооп в раст нет только наследования состояния все остальные головы гидры остались нетронуты - инкапсуляция, полиморфизм, наследование поведения. От самого ООП успешно отходят все современные ЯП - >>2302304
>>2319643 Неплохо. Но я б сказал что все это автоматически выучивается когда ты работаешь над реальным проектом. Начал учить Раст почти год назад, повезло попасть на работе в новый проект. Со временем сам выучиваешь все комбинаторы функторов (Option, Result), функции над итераторами, работу со строками.
Но неплохой подбор, действительно 80% функций часто используются, некоторые из них супер важные, но к сожалению спрятаны внутри доков среди функций попроще, те же map, and_then, iter/into_iter.
Почему новички жалуются что растбук начинает "не с начала". Чего там не хватает полному новичку чтобы понять? Может запилить предисловие к растбуку, полному ночивчку чтобы главы были понятней.. не думаю что это прям супер сложно.
Чет глянул количество вакух по этому вашему русту, а их там по пальцам одной руки пересчитать можно. Это после пыняперации так или всегда было? Получается перспектив у данного языка в ЭТОЙ стране никаких нет?
>>2321493 >>2321020 Быстрее растяжимое понятие, быстрее писать ++i, а не i++, только из-за этого люди чаще всего не парятся.
Самые времязатратные вещи на фронте это работа с dom и запросы на сервер, на фоне этого остальные вещи смотрятся несущественно, да и непонятно, действительно ли такой быстрее, потому что между js и wasm всегда будет бутылочное горлышко, общающееся через json. На фронте особо вычислений диких и нет никогда, специальные случаи типо фотошопов онлайн, редакторов видео онлайн и распределенных вычислений как раз и решаются wasm, но не пересоном же всего фреймворка туда, лол
Короче максимально странно звучит, и это мы еще не начинали про то, насколько там инфраструктура есть, типа стейт менеджеров и т.д.
>>2321521 Блин, ну очевидно что это не сильверная пуля, говорю же, в некоторых аппах (вот как раз те фотошопы и видеоредакторы) может пригодится.
>стейт менеджер Типа для Раст разработчика сложно свой редакс написать за полчаса. Хотя я уверен, что либы все есть или скоро появятся.
Сейчас такие фронты, что тупо лагает всё из-за хуевых ререндеров, даже если особых вычислений нет. Хуевые ререндеры на Расте (асме) будут быстрее, вот и всё.
>>2321539 >Сейчас такие фронты, что тупо лагает всё из-за хуевых ререндеров, даже если особых вычислений нет. Хуевые ререндеры на Расте (асме) будут быстрее, вот и всё.
Как реакт разработчик со стажем в 4 года могу сказать, что это дело в недостаточных скилах, особенно касательно БАЗЫ. Очень печальная ситуация, но к сожалению не фиксится тем, чтобы перегнать тех же разработчиков на wasm фреймворк на расте, заставляя писать собственный стейт менеджер.
Мне на техсобезе ни один июнь не рассказал нахуя в редаксе нужна иммутабельность при изменении стейта, а ты говоришь свой написать)
>>2321563 >Мне на техсобезе ни один июнь не рассказал нахуя в редаксе нужна иммутабельность при изменении стейта И зачем она там? Разве этот редакс не под JS (однопоток)? Извините за оффтоп
>>2321563 >Мне на техсобезе ни один июнь не рассказал нахуя в редаксе нужна иммутабельность при изменении стейта, а ты говоришь свой написать) Низачем, просто так решили разработчики редакса, когда придумывали этот кусок говна. А ты какой ответ ожидаешь услышать, вот чисто интересно? Наверняка какую-нибудь кашу, вроде "иммутабельность это ФП, а ФП это круто, позволяет писать чистый код, спасает от проблем со стейтом, дает работать асинхронно(в жсе лол), лечит от запоров"?
>>2319643 >>2320459 Годно, неделю назад начал изучать раст, после 14 лет на с++ немного по началу путался между этими рефцелами и референсами, но щас вроде стал понемногу разбираться. Начал изучать раст с того, что решил написать свой видеосервер, который будет принимать видеопотоки из вне, сохранять их всовывая свою метадату и ретранслировать их дальше. Как бы такой видео-прокси сервер. Начал с того, что написал необходимую обертку на сишными ffmpeg функциями в раст, заодно попутно разобрался как ffi работает, кстати хочу сказать очень удобно, без лишнего гемора. Сейчас пишу свой формат контейнера для сжатых видео пакетов, разбираюсь дальше, на расте писать конечно намного приятней чем на с++.
А я очередной менеджер процессов пытаюсь. Попутно понимаю что программирование это не мое. Слишком много времени трачу впустую, долго обдумываю даже простейшие действия.
>>2322760 >>2322763 Когда при изменении стейта вычисляется, какие его части поменялись, а какие нет, чтобы выслать ивенты об обновлении стейта подписчикам, объекты сравниваются по ссылке, а не по значению, соответственно ивент не придет. Ну и не только на самом деле, если мутировать стейт, а в жиэсе это бывает как раз два, то поведение становится совсем загадочным.
Вообще правило реакта и жиэса в целом - видишь какую-то неведомую хуйню, проверяй на мутирование
Читаю rust by example. На моменте создания связанного списка вообще нихуя не понял
fn len(&self) -> u32 { __match *self { ____Cons(_, ref tail) => 1 + tail.len(), ____Nil => 0 __} } Cons(_, ref tail) откуда такая конструкция взялась, что она указывает на конец списка? Конкретно меня сам tail интересует
>>2320585 Эта страна не то чтобы когда-то была передовой в айти, пчел. А за бугром на пересчёт этих вакансий тебе просто на 1 руку больше потребуется, так что вкатываться в раст есть смысл только если тебе нравится, каких-то карьерных преимуществ он тебе не даст. Разве что если тебя рандомно не найдут на гитхабе и не схантят в какой нибудь криптостартап.
>>2320810 >Похоже не пердолинг ради пердолинга This. Ну хочется фронтендерам на нормальном языке пописать хотя бы в петпроджектах, че.
Как думаете, есть смысл схоронять с ютуба видосы с растконф? Какое там соотношение сигнал-шум?
Хотел стренжлуп выкачать, да чет на один нормальный доклад десять гомофеминегров. Пейперсвилав наверное можно скачать, хотя там половина хуевые записи на тостер. Кложуртв целиком качать наверное тоже смысла нет (да и там не все видосы, годнота раскидана по 10 каналам разных конференций), отдельно презентации кудряша сохранил.
Доставьте какой-нибудь годный плейлист с маст-си презенташками, что ли.
Как написать в трейтах и структурах такое: Есть Человек (Имя, Возраст) Он Работник - Программист или Менеджер У Программиста есть Клавиатура, у Менеджера Бэджик (наоборот запрещено) Программист Кодит, Менеджер Управляет любой Человек может Пернуть.
Желательно со всеми возможностями будущего расширения кода и данных. Например удобно добавлять вещи работникам, или расширять поведение на любом уровне (человек, работник и т.д.) чтобы не получилось так что надо в 200 местах что-то переписывать если у тебя много видов работников, вещей, или поведение на каком-то уровне добавилось.
Т.е. просто прошу идиоматичный пример на Расте. Гуглил, нашел только общие описание. А надо что-то конкретное чтобы потом самому писать и другим показать. Спасибо.
>Желательно со всеми возможностями будущего расширения кода и данных. Ну вот есть работник — берёшь и добавляешь ему вещь. Если вещей потенциально дохуя — ну не зашивай типы на них и всё будет гибко как ты хочешь.
>чтобы не получилось так что надо в 200 местах что-то переписывать Как напишешь — так, блять, и будет. Ещё раз — всё зависит от того, как композицию типов составишь, пчел. Если обосрался и сделал всё не енамах — всегда можешь что-то придумать отрефакторить и больше так не делать, и, например, вытащить общее поле через Deref, как я с пуком в этом примере. Хотя там оно и нахуй не нужно.
>>2339137 Спасибо, я примерно так себе это и представлял в голове. Только Deref не ожидал, удобно. Но все равно если например Работник это еще и Налогоплательщик то Deref только для Человек будет, а в Налогоплательщик уже не сделать? Получится если зависимостей много - работник.налогоплательщик.фнс.ндфл.рассчитать() В принципе терпеть это можно, но когда я вчера думал над тем как закодить, у меня тоже получился enum Профессия, а работать() impl-ом Если профессий 10 штук то метод работать будет распаковывать на 10 возможных вариантов каждый раз когда надо поработать. Это заметно медленней чем в языках с ООП где Программист это просто наследник Работника. По сути такая самодельная динамическая диспетчеризация. Можно ли с этим бороться?
>>2339163 >Но все равно если например Работник это еще и Налогоплательщик то Deref Нет, я же написал — лучший юзкейс это когда у тебя куча енамов с одним полем.
>Получится если зависимостей много - работник.налогоплательщик.фнс.ндфл.рассчитать() Какой уебанский пример, я бы даже на ООП языке за такую иерархию отпиздил, лол. Налогоплательщик — отдельный трейт для работника, с функцией посчитать_налоги(&self, фнс, ндфл) -> НалоговаяДекларация.
>Это заметно медленней чем в языках с ООП где Программист это просто наследник Работника. Только у тебя в голове. На практике: 1) Динамик диспатч ломает нахуй все оптимизации доступные при AOT компиляции, от инлайнинга до dead code ellimination без JIT это говно вообще хуй оптимизируешь; 2) Матч в большинстве случаев будет компилироваться в jump table и по скорости работает как доступ к элементу массива, а даже если не оптимизирует — вероятность попадания в кэш всегда будет выше; 3) Благодаря динамик диспатчу у тебя будет куча индиректов — на каждый обсёр бранчпредиктора процессор будет тратить время на прогулку по памяти вместо работы; 4) Чтобы понимать, можно ли кастить тип А к типу Б — придётся таскать с собой ещё кучу метаинфы, походы за которой будут повторять пункт 3. Медленнее оно может быть разве что если у тебя будет жутко жирный матч, который будет руинить кэш — но в таком случае частично перестанет быть верным только 3-й пункт.
Если тебе лично приходится писать меньше кода — это не значит что код будет работать быстрее, лол.
> Можно ли с этим бороться? Можешь почитать как разработчики LLVM боролись с динамик диспатчем в плюсах, но релевантно для всех компилируемых языков — https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html Спойлер: свели всё к тем же енамам и проверкой руками. Как в расте, только с кучей костылей.
Объясните кто-нибудь, почему Рист так хуёво работает под виндой? Требует какие-то зависимости от C++, крейты вообще почему-то (У меня) ставить отказывается. А на линуксе - всё заебись. Почему так? С чем связан такой пиздец?
>>2339960 Чел, ты из какого года капчуешь? В крестах уже давно никто таким не пользуется, когда есть шаблоны и концепты. А RTTI на помойку выкинут, его нахуй выключить можно.
Сап, Анон! Недавно начал изучать сей божественный язык, надеюсь не пожалею о своем выборе и надеюсь, что у вас здесь тёпло-ламповая атмосфера. Если есть что сказать новичку, выкладывай! (Но это не первый мой язык) Тред пока не читал...
>>2341910 Братик, я как раз вчера мучался, всё устанавливал, правда у меня была проблема в линкере. В общем, в моем случае нужно было накатить Visual Studio Build Tools + MSVC 142 в опциях, хоть у тебя и другой стектрейс, но вдруг эта инфа как-то поможет. Добра. >>2342652 в растап кстати как раз указывает при установке чего именно не хватает
>>2342809 > Мань, лет через 10 свистни а лучше в хуй прямо сейчсс, мб кто нибудь затащит в проект. STL уже на них написан, проблемы легасидебилов не важны. > Так я и пишу что пердолятся чтобы его выкинуть Одним параметром выключается в компиляторе. > Выключать его ещё лет 30 минимум будешь, с таким-то количеством легаси, манька. Каким таким? В легаси его в 99% случаев не используют, в нормальных проектах рантайм рефлексия по дэфолту запрещёна, так же как и эксепшены.
>>2351997 > Их проблемы == твои проблемы, маня. > Код компилятор переписывает? Какой код, мань? В легаси пишут на "си с классами", там нет никакого кода, использующего RTTI. Ты совсем ёбнулся? > хром и ещё полторы программы? Проще составить список где это используется - выяснится что это почти всегда опенсорс-высер одного студента. Когда нужна рантайм рефлексия - пишут свой RTTI с блекжеком и шлюхами. Если ты захочешь спросить зачем же он вообще нужен и почему с ним ебутся в компиляторах - потому что обратная совместимость, про которую в расте никто и не слышал.
>>2352262 >Какой код, мань? Студень, съеби в плюсотред уже, заебал со своим любимым гнойником.
>там нет никакого кода, использующего RTTI А мой опыт говорит так не бывает с любой фичей в языке.
> потому что обратная совместимость Да, маня, правильно. И если какую-то хуитку в языке (особенно таком старом как плюсы) поменять — сломается больше кода чем ты высрешь за всю свою жизнь.
нет трейтов с асинх-методами (вместо них не-зирокост #[async_trait])
нет асинх-замыканий (вместо них изъёбки с замыканием, возвращающим impl Future), а значит
нет асинх-комбинаторов (map, and_then, unwrap_or_else, - соси в асинх-контексте)
нет взаимозаменяемости рантаймов, а значит, большинство либ рантаймо-зависимы (либа может работать с tokio и не работать с async-std/actix-rt/smol/...)
нет асинх-дропа
на что надеяться в ближайшее время? где-нибудь через минимум полгода подгонят асинх-трейты, которые нельзя будет засунуть в Box<dyn AsyncTrait> а в остальном наслаждайся фантазиями в официальном бложике
>>2286737 (OP) Бля, начал пользоваться ебучим текстовым редактором VS Code вместо IDE, как же горит. Как сделать чтоб при наведении на код показывалась инфа что это? Какой тип у переменной, сигнатура методов и т.п. Этим же невозможно пользоваться, когда у тебя строгая типизация, а в коде на одного типа нет. Даже хуй угадаешь что new() возвращает - там может быть контейнер вокруг типа, блять. Можно сделать как-то по-человечески? Ещё и протухший плагин раста висит выше раст-аналайзера в списке плагинов, пиздец интуитивно.
>>2353357 Пиздец кал. Я вот почитал бложики, там реализации просто ахуеть насколько костыльные. Типа проверяющего в цикле экзекутора на "блокированность" и "степень прогресса", который сам блокируется между проверками, даже страшно представить какие там задержки при засыпании/просыпании тасков, наверное даже выше чем у уснувшего системного потока. А ещё абсолютно все бенчмарки у этих петухов на веб-серверах, как будто в ГОвно попал, а не системный язык.
>>2355304 > только Не только. В embedded как раз полно асинхронщины. Особенно для критичного оборудования, которое должно в реальном времени получать данные из разных датчиков и принимать решения. Другое дело, что rust особо пока не тащат в embedded. Сырой.
>>2356148 Всё это работает только если код добавлен в дерево модулей. Пиздец как удобно. Мне этот функционал нужен когда я пишу код, а не когда уже написал его. Ни в одной IDE нет таких как тут костылей.
>>2356159 В VS или JetBrains так. Там IDE работает когда я пишут любую строку кода, а не только когда уже готовый модуль указал в виде зависимости в другом. Мне же подсветка нужна чтоб во время написания кода смотреть на неё, а не после.
>>2356160 >а не только когда уже готовый модуль указал в виде зависимости в другом ну вопрос очевиден, что собственно мешает тебе его указать? как тебе раст аналайзер должен что то подсвечивать если по факту этот файл в твой проект не входит
Недавно решил обмазаться системным программированием. Из опыта имеется только 2 семестра кодирования на крестах и полгода разработки на c#. Начинать с раста хорошая идея? На работе советуют играться с плюсами.
>>2358906 Миру требуется просто современный С++, но все клепают очередную отсебятину, которая убивает язык полностью. Слышал что и в zig есть такое, вроде там чет не компилиться если лишний файл в сборке или еще что-то, не помню.
Пока языки делают художники, которые "так видят", а не инженеры, мы будем грызть тугой С++.
Сап, аноны. Есть один нубский вопрос, нагуглить что-то не получается.
В общем, в Расте как я понял, любят обмазываться Enum'ами. Ну и я тоже решил обмазаться.
Суть в чём, допустим мы объявили Enum с параметрами enum SomeType{ ... SomeType::Integer(i32); ... } let i = SomeType::Integer(25); Но я не могу понять, как "вытащить" сам int из энама? Вроде тип определен и казалось бы очевидно, что должен быть простой способ так сделать, иначе не понятно, нахуйа хранить что-то в Енамах, если не можешь извлечь потом значения.
В Result и Option есть метод unwrap, а как быть со своим энамом? МОжет какой-то метод нужно реализовать... Подскажите, потерялся...
>>2359740 ты для начала должен проверить, какой у тебя именно подтип енама: let e = SomeType::Integer(25); match e { SomeType::Integer(i) => println!("{i} - целое") SomeType::Huinteger(i) => println!("{i} - хуелое") _ => println!("пошёл нахуй вообще) // да, ты обязан обработать все возможные варианты энама }
>>2359750 либо укороченная запись: if let SomeType::Integer(i) = e { //именно в таком порядке ... } else { //обрабатываешь остальные случаи, на которые насрать ... //или вообще не обрабатываешь, если насрать капитально }
>>2359750 ладно, спс, похоже проще не получится сделать, вообще полную хрень выдумал, хотел ещё enum разных типов распарсить, инты и стринги, но понял, что так лучше не делать... ведь нужно в компайл-тайме выводить типы, плохая затея...
>>2359589 1) Делать в современности еще один язык не "конкурентно френдли" это тупость. После выпуска го, мы думали, мол, сейчас пойдут пачками асинхронные языки, но с вменяемым дизайном. Но увы, люди продолжают писать синхронное говно. Даже асинк/авэй накладывают лишний оверхед, а без рантайма это все та еще жопа. Забавно, но вроде так себя раст и позиционировал до релиза, ну хипстота не смогла и выпилила (и до сих пор нормально не допилят).
2) Владение туфта. Это все прикольно пока ты пишешь утилитки, типа grep, но серьезное программирование сразу же скатиться до Arc, а это вообще примитивное GC.
3) Тебе говорят про безопасность, но даже в стандартной либе куча unsafe. В ембедед ты сможешь только без стандартной либы. Да вообще, любое около системная разработка приведет тебя к unsafe. Как и с владением - тут просто посали на лицо.
3) Упоротый местами дизайн. Тут тебе в лицо говорят про безопасность и тут же рассказывают про затенение. Очередное - я художник, я так вижу (многие попугаи еще разносят это как преимущество, блин, присвоение вместо равенства уже десятками лет не можем победить, а тут прям руками затенение ввели, гуманитарии).
Ну еще куча там говна, которого я уже не вспомню. Самое забавное, что без хейтеров тред не живет вообще. А треды на зекаче, это основной показатель популярности языка, не иначе.
>>2360394 >без хейтеров тред не живет вообще СРАЛЕВАЛИ ЗАСРАЛИ ТРЕД @ (ЛЮДИ УШЛИ) @ СРАЛЕВАЛИ НА МИНУТКУ ПРЕКРАТИЛИ СРАТЬ @ (НИКОГО НЕТ) @ "ВИДИТЕ, БЕЗ СРАНЬЯ ЖИЗНИ НЕТ, ДАВАЙТЕ НАСРЕМ ЕЩЕ БОЛЬШЕ"
>>2360394 > серьезное программирование сразу же скатиться до Arc используй unsafe > любое около системная разработка приведет тебя к unsafe используй Arc > затенение лучшее что случалось на земле, только цпп макаки могут быть против этого ну у них в целом мышление особенное
>>2360407 >(ЛЮДИ УШЛИ) Ты сейчас на ноль поделил, кроме хейтеров и лулзов тут ничего не было. В го было так же, но неожиданно это говнище заняло нишу и выстрлело, потому что асинхронное программирование, которое бесплатно для программиста в плане мозгозатрат, это, неожиданно, "серебряная пуля" и может вытащить даже убогий дизайн языка. Что есть у раста? Ничего. Идея владения работает только в плане хелло-ворда, а дальше ансейф или сборка мусора (зеро-кост-буллшитинг).
>>2361064 Забавно, но настоящим плюсовикам а не ограниченным из сети с синдромом недостатка внимания и особенно сишникам, им вообще пофиг на все эти потужные попытки спасти всех плюсовиков очередным убийцей С++. Там давно уже образовался отдельный устойчивый мирок, отделенный от хайп потугов хипстоты и трансгендерных квази-программистов.
А я? Я как раз тот хер, которому иногда нужно погрузить на дно и пописать на неуправляемом языке и мне больно писать на С++, но замены ему так и нет, а хипстота в очередной раз пилит не инструмент, а йобу, чтобы тупо продавать свое ебало в экран и кабанчику.
>>2361069 >хайп потугов хипстоты и трансгендерных квази-программистов >хипстота в очередной раз пилит не инструмент, а йобу, чтобы тупо продавать свое ебало в экран и кабанчику это хипстота сейчас тут, в этой комнтате?
>>2361064 Нет, это шарпошиз. Которого я таки призвал боевой пикчей выше, кекус.
Узнать можно по этим тейкам которые у этого долбоёба не меняются 126-й тред подряд: >>2360394 >но серьезное программирование сразу же скатиться до Arc, а это вообще примитивное GC >Тут тебе в лицо говорят про безопасность и тут же рассказывают про затенение. >Даже асинк/авэй накладывают лишний оверхед, а без рантайма это все та еще жопа.
>>2360415 >только цпп макаки могут быть против этого Ну нет, ещё питушки с хуйлевел язычков иногда очень уверенные в себе бывают, как этот например.
>>2360509 >Вся суть раста - используй ансейф или сборку мусора. Долбоёбик, это суть любого языка.
>>2361359 >>2361359 >это хипстота сейчас тут, в этой комнтате? Эта хипстота пилит сейчас не хилые гонорары себе, пока ты сидишь в загоне и на серьезных щах думаешь, что тебе выкатили нормальный продукт. Уже сам факт, что многие части этой хрени пилятся годами и не могут быть доведена до ума, говорит о целях сего пузыря.
Каково осознавать, что ты лишь разменная макака для затянувшего стартапа, из которого пытаются максимум высосать себе профитов? Вот серьезно, анон, все эти скандалы с "менеджерами" и вечно "около-бета" структуры проекта (слышал хотят вот асинки сейчас переписать, лол), тебе еще не показала, что это тупо попильный пузырь, аля стартапы из 10, только в больших масштабах и крупней кабанчиков?
>>2361439 >Узнать можно по этим тейкам Которые в хламину разносят весь тот буллшит попильного пузыря.
>Долбоёбик, это суть любого языка Как раз таки и нет, вероятно, именно поэтому раст теперь пытаются натянуть не сишникам, а прикладным программистам на трубе есть доклад, где чел реально затирает про то, что большие прикладные программы - это уже системное программирование.
>Нет, это шарпошиз Способность везде видеть одного и того же чела (хотя тут и правда мало народу), лишь доказывает тот факт, что только такие ограниченные как ты, могут годами жрать попильный пузырь и быть миньоном ЛГБТ разводил (ранее хипстоты).
Я вместе с тобой следил за этими языками и раст, из них, до сих пор полу-сырая говнина, которую пытаются натянуть везде. И натянули бы, но кривая обучения экспериментальной парадигмы владения, требует реальных усилий, от чего язык любимый всеми много лет, но нефига никто не пишет, когда тот же го всех бесит, но по количеству звезд догоняет и обгоняет топ языки, даже твой проприетарный говно-шарп).
>>2361471 Забавно, но на первой странице топа, до сих пор весят клоны консольных утилит Лет 6 назад, я тоже с этого проиграл, но понимал новизну языка, а сейчас это прям реально забавно.
Лол, одно то, как в этом языке называются примитивные типы и какие используются кейворды уже говорит об уровне авторов. u8, u16, fn, impl, etc. Я пытался примерно так писать в 7 классе на паскале, еще и в одну строчку все и без отступов. Аналогично и с обилием <>. Да, когда впервые узнал про дженерики, это прикольно, нравится везде их совать и соответственно когда в коде много угловых скобок. В целом же у rust кода около нулевая читаемость, особенно из-за постоянного использования unwrap.
Это должен быть просто улучшенный, насколько это возможно - СИ. Любые плюшки тупо приведут к жирному рантайму.
Но для успешного языка в 2022 нужно (по приоритетности, вплоть до маня фантазий) - Дешевая в плане разработки асинхронность, или подключаемая бесплатная с корутинами. - Пакетный менеджер (именно через вендоринг, чтобы и через 10 лет собрал из папки) - Модульность, раз есть пакетный менеджер. - Детерминирование поведение везде, вплоть до ембеддед. - Дженерики. - Кросскомпиляция. - Какой-то сахар для ручной работы с памятью, структурами (как в го достаточно). - Улучшенный препроцессор или возможность подключения мета-программирования. - Язык "для всего" с модульным рантаймом. Начиная от отсуствие вообще (или минимального), заканчивая возможностью подключить такой рантайм который имеет ГЦ или даже рефлексию, для прикладных нужд. - Долгая разработка и максимальная заморозка синтаксиса. То есть, нужно развивать инструменты, а не дрочить на синтаксис. Вот добавили веб сервер в стандартную либу, пускай он будет всегда востребованным и конкурентно пригодным, а не положили болт и спорить как нам сделать язык еще лучше. Больше сил на инструменты, а не синтаксис (только реально нужное, где у других зашло и проверенно временем). - Минимум отсебятины, это не рисование картин, это инженерный инструмент.
Ну и в целом средний программист не тупой, не нужно пытаться языком его ограничить, это признак ограниченного мышление инженера.
>>2361471 >Которые в хламину разносят весь тот буллшит попильного пузыря. Потому что ты скозал? Ты настолько всех заебал, что с тобой даже никто не спорит, лол.
>Как раз таки и нет Ну давай, показывай язык с ручным управлением памятью без ансейфа.
>и быть миньоном ЛГБТ разводил (ранее хипстоты). Кто о чём, а латентный шарпошиз о своих любимых пидорах. Быть пидором — это ок, просто прими себя уже.
>>2361562 Все еще помнять десятые и как мохнатая хипстота разводила на бабосы бизнес. Это был локальный бум доткомов, кабанчики захотели в айтишечку и давали полную свободу, естественно мохная хипстота их наказывала. Так как около ИТ-журналисты чаще тырят новости из-за бугра, ни кто так и не расследовал это локальное явление, но у многих закрепился этот феномен в голове.
Просто когда хипстота сосет бабос с крупной компании, это не так заметно, можно дуть пузырь долго и весело развиваться, а когда местный кабанчик бездельников кормил, это ощущается в более короткий период и ярко.
>>2361650 >Ну давай, показывай язык с ручным управлением памятью без ансейфа. Ну, С, С++, никакого там ансейва нет. Придумал себе ограничение и потом пытаться этим превозмогать.
В этом, кстати, весь буллшит, ансейв в расте везде, даже в стандартной либе, я уже молчу о подтягиваемых либах и обертках вокруг Си. То есть ансейв у тебя везде даже, вероятно, в хеллоуворде. Это как умножение на ноль, любое место где он есть, делает сразу и твой код ансейвом.
>>2361534 > Ну и в целом средний программист не тупой, не нужно пытаться языком его ограничить, это признак ограниченного мышление инженера.
Всё программирование всегда развивалось в сторону ограничений. Из дикого ассемблера мы пришли в менее дикий С, где уже не так просто писать в рандомные регистры всякую хуйню. Из си мы пришли в С++, где появились классы, и возможность ещё больше ограничить разработчика. Оттуда мы плавно переходим в сишарподжавы, где у нас ограничили возможность свободно работать с памятью, и обязали разделять наш код на классы. И всё это время, параллельно развивается функциональщина, где ограничений ещё больше, начиная от иммутабельности и системы типов всяких хаскеллей, и заканчивая завтипами какого-нибудь Идриса.
Короче, всё программирование это сплошные ограничения. И это прекрасно, потому что чем сложнее обойти ограничения, тем сложнее мамкиным виртуозам и «инженерам» делать нечитаемую и неподдерживаемую хуйню.
>>2361731 >Из си мы пришли в С++, где появились классы, и возможность ещё больше ограничить разработчика. Как? С++ полжизни пытался сохранить совместимость с Си, как он его ограничил?
>Оттуда мы плавно переходим в сишарподжавы, где у нас ограничили возможность свободно работать с памятью Это же повышение абстракции, за цену производительности, а не ограничение программиста. Типа мы решаем прикладные задачи и контроль памяти нам нафиг не нужен. Как аналогия, либо ты головкой диска управляешь и пишешь в сектора руками, либо на тебе абстракцию в виде файла.
>параллельно развивается функциональщина Она всегда была и жила параллельно, просто ФП лапша пригодна лишь для маня фантазий, а не для промышленного программирования. Взяли нужное, на остальном пофиг. Те же нуллабл типы в котлине и шарпе, куда практичнее опшинов, которые тупо обертка.
Например в го есть ограничение за неиспользуемую переменную, компилятор мог бы ее выпилить сам, но каким-то хером бьем по рукам разраба, по приколу. Точка с запятой, неожиданно может тоже стать опциональной, незачем дрессировать программиста. В неуправляемом системном языке мне нужен контроль над памятью в ручную, для этого я его и выбрал.
>>2361700 >Ну, С, С++, никакого там ансейва нет. Там оно без кейворда — вообще весь код.
>Придумал себе ограничение и потом пытаться этим превозмогать. Ограничение у тебя в твоём зумерском мозге, пчел.
>любое место где он есть, делает сразу и твой код ансейвом Ту часть, в которой он есть, а не всю.
>>2361745 >Как? С++ полжизни пытался сохранить совместимость с Си, как он его ограничил? Он же написал — возможность ограничить.
>Те же нуллабл типы в котлине и шарпе, куда практичнее опшинов И в чём же это заключается? В том, что нормальную систему типов на говно из 2000-х уже не натянуть?
>которые тупо обертка. Хуя, макака поняла что такое монада, какая редкость.
>>2361759 >Там оно без кейворда — вообще весь код. Ввели кейворд и он теперь пронизывает весь раст, лол.
>Ограничение у тебя в твоём зумерском мозге, пчел. Пук
>Ту часть, в которой он есть, а не всю. Л - логика. Вся вера в раст быстро уходит после сигфолта. Но виноват, конечно, один из тысячи ансейвов, не твоих, главное, так заказчику и скажу.
Когда нет доминирующих фреймворков, типа, джанги, cocoa, то получается полная ебала. Каждый лепит то, что хочет и в итоге либо 3 калеки - пользователя фреймворка есть, либо он вообще нахуй ненужон. А силы бы могли в нужное русло направить. Например дизель. Соглы?
>>2362442 Зачем? Ведь это же ОГРАНИЧЕНИЕ творческого мышления РАЗРАБОТЧИКА! Ведь так хорошо, когда ИНЖЕНЕР ничем не ограничен, он же не дурак. Сам сделает все, зачем ему эти ОГРАНИЧЕНИЯ фреймворков?
>>2362456 А кто запрещает, хочешь пили, вон в жабе есть спринг и еще пару топ решений, а все остальное тухлое художественная херня, которое берешь на свой страх и риск. Но если бы была стандартизация, то спринг не был чуть быстрее джанги, а как ASP.NET давал на клыка неуправляемым языкам.
>>2361534 >Ну и в целом средний программист не тупой, не нужно пытаться языком его ограничить, это признак ограниченного мышление инженера.
Зачем говорить от себя, если можно рассказать цифрами про тех программистов которые хорошие, а не средние: (Понимаю что всем надоело, но я не устану это постить, пока вы не перестанете мне про хороших программистов бездоказательно рассказывать.)
The Slammer worm from 2003 was a buffer overflow (out-of-bounds write). So was WannaCry. The Trident exploit against iPhones used three different memory safety vulnerabilities (two use-after-frees and an out-of-bounds read). HeartBleed was a memory safety problem (out-of-bounds read). Stagefright on Android too (out-of-bounds writes). The Ghost vulnerability in glibc? You betcha (out-of-bounds write).
Мне кажется дико кайфовая штука. Фреймворк для десктопных приложений с бэком на расте и фронтом не через хромиум, а через браузер встроенный в систему.
Как Электрон, но не говно. Или всё таки говно? Меня бесят долгая загрузка и большой размер приложений на Электроне. У Таури загрузка чуть-чуть быстрее, и значительно меньше вес приложений. https://github.com/Elanis/web-to-desktop-framework-comparison Но всё равно это блоут.
Я дизайнер с небольшим опытом веб-разработки. Начал заниматься разработкой приложений на Таури чтобы сделать приложения для себя и возможно потом выпустить их в опенсорс. Работать с Таури очень просто и весело, мне нравится. Особенно круто то, что можно очень легко сделать приложение из существующего веб-проекта, буквально в пару действий и строк. Ещё возможно в будущем приложения для Таури можно будет выпустить для Android/IOS.
Я думаю, что у Таури есть всё для того, чтобы заменить Электрон, и это уже огромный шаг вперед. Но если сравнивать его с другими инструментами для разработки приложений, то хуй знает.
>>2362790 Кстати, было бы здорово найти тут людей, которые тоже занимаются разработкой на Таури, хотят попробовать, или просто знают Раст, и могут помочь. Я достаточно тупой и мне Раст сложно дается, потому что нет знакомых у которых можно попросить помощи. Можем сделать что-то вместе, я могу помочь вам с дизайном.
>>2362732 Хорошо, но почему тогда раст не популярен? Ему уже 16 лет, а крупных коммерческих проектов на нем нет. Да и для 16-ти лет разработки он слишком сырой. Такое ощущение, что его пилят ради того, чтобы пилить.
>>2362820 >Хорошо, но почему тогда раст не популярен? Какой популярности ты ждёшь от узкопрофильного языка? Как у шарпа или плюсов? Ну такой не будет никогда.
> Ему уже 16 лет В его текущем виде — 7.
>а крупных коммерческих проектов на нем нет Потому что ты опять скозал?
Шведский нацист-наркоман, создатель SerenityOS, вместе с другом из Rust Core Team, делают форк раста - Jakt, чтобы переписать на нем ОС, потому что калокресты это лишняя головная боль.
>>2363395 Это, конечно, очередная перделка, с llvm сейчас только ленивый свой яп не пишет, но все же, как работает этот мозг художника? Типа вот, точка с запятой - моветон, хорошо, уберем. И тут же добавляют полнотекстовое слово function, лол.
И за что! ПРОСТО ЗА ЧТО двоеточие после типа, ну IDE даже подсвечивает, если трудно с восприятием? Никакой вообще практичности, просто фаняться, я художник я так вижу (а то что потом пол жизни как на пианино играть по клавиатуре это пох).
>>2363534 Читабельность языка это основное требование в их дизайне. Код должно быть легко распарсить и человеком (включая без IDE и подсветки синтаксиса), и семантическим анализатором, и какие-то части условным grep/sed/awk, если припрет. Никому не нужен новый Perl или APL. И касается это как семантики, так и синтаксиса. мимо
>>2363570 То есть, они реально считают, что полные ключевые слова добавляют читабельности? Они жабу видели??
Тогда я уверен, что скоро снова появиться поколение людей, которые будут делать язык с уклонном на реальный английский язык. Я пережил, когда "зумеры" открыли noSQL, но второй кобол я уже боюсь представить
>>2364028 Может мой ответ покажется неожиданным, посмотрел интервью Страуструпа у Лекса Фридмана и призадумался. Такой дядька хороший, всю жизнь этому посвятил, столько лет полировали плюсы, проводили всяческие оптимизации, и тут вырисовываются какие-то кренделя со своей киллер фичей владения \заимствования и думают, что захватят мир? А вот хуй им. Лично мне С, С++ и Раст не очень из-за читабельности, кому-то наоборот >>2363792 , опять же важна область применения, но если выбирать из этих трёх, выбор очевиден. Может Раст и поприятнее и чуть дружелюбнее, но сыроват + если уж ты любишь байтоёбствовать, то можно как-то и без утечек памяти научиться писать.
>>2364116 Чет в цпп ветке совсем упоротые сидят. Да я если честно фо фан занялся растом, хотел простенькую приложеньку для десктопа сделать, в итоге завяз где-то в дебрях и был несколько демотивирован. А так системные языки не очень приятны, ну в плане каждодневной работы... кровь из глаз от всяких конструкций вида *&<нувыпоняли. Но может быть это ошибка, может раст велик, люди ещё не поняли этого (на самом деле овердохуя где используют, но это не значит что антон сможет найти работу где-нибудь в постснг), а так весело, чо.
>>2364116 Сейчас бы ругать язык с ручным управлением памяти, а не идиотский дизайн железа или же бизнес процессы.
Писать без ошибок на неуправляемом языке возможно, но сопоставимо дорого для бизнеса. Неожиданно, но есть конторы, где даже юнит тесты не пишут, ибо бизнес он такой.
Но вопрос нужен ли раст бизнесу? Для ембеддед он слишком жирный, а без стд кусок говна, так что там сишечка навсегда. Для прикладных вообще нет потребности совокупляться с околосистемным уровнем и трахать память, зачем вот жабисту или шарперу твое владение или 6 видов строк, когда оптимизированные сервера на VM на сотую процента медленней серверов на неуправляемых языках.
Я сначала думал, что они просрали рынок, когда выпилили конкурентность, но в реале там вообще скорее всего попильный язык для стрижки кабанчиков высоко помета.
>>2364404 >не на системных языках пишут Соглы, зачем усложнять себе жизнь.
А какие области применения видите у системных языков? Мне вот ещё интересна тема потоковых видео-аудио, возможно для таких дел стоило бы байтоебствовать...
>>2364404 >но я просто написал что безопасно и без утечек памяти писать невозможно А я тебе сказал, что это возможно, но это дорогой трудо-ресурс. Зачем тебе вообще раст, если ты контекст пасты потерял за абзац текста?
>>2365107 В этом вся проблема агрессивного маркетинга, он привлекает только таких вот шизов, которые не могут даже сформировать свою мысль, но уже хотят писать на расте.
Жаба, шарп и прочее мусорное говно сильно тормозят из за этого мусора, поэтому на мусоре программы не пишут - никакие, ни системы, ни приложения пользователя не пишут, а пишут только бизнес-процессы для корпоративных серверов, где много бабла и много серверов, которые можно добавить если тормозит, да и вообще нам на риалтайм похуй, везде задержки и поебать. А в системе и особенно в приложениях пользователя важна отзывчивость в реальном времени, чтобы все действия человека откликались сразу, без лагов и работали ровно без статтеров. Такие "мелочи" по меркам бизнес-процессов, чрезвычайно важны для системы и пользователя. Поэтому, сколько бы миллиардные машины говнопиара и одебиливания не впаривали веб-говно и крочий кал, его хоть и жрут, но всё равно ненавидят. Одно слово "электрон" и все уже плюются.
>>2365207 Не стоит так обобщать, где именно важна отзывчивость, какую проблему ты решаешь, где узкие места, с которыми по-твоему не справятся языки с GC? Вообще расту надо отдать должное, во-первых у них интересная книжка на сайте, многие вещи касательно памяти хорошо описывают между делом, да и вот к примеру теперь задумался об оптимизации GC непосредственно в коде, пару фишек подсмотрел. Короче, GC это не такой большой оверхед, если покопаться. Понимаю, что для перфекционистов, которые дрочат на перфоманс, даже такой проёб это ад, но опытные ребята всегда отталкиваются от задачи, чего и вам советую.
>>2365221 >где именно важна отзывчивость, какую проблему ты решаешь Это не проблема, это сами программы как они есть. Я пользуюсь разными приложениями и среди них есть пара на шарпе и одно на джаве. Все программы - как программы, а эти видно что тормозят, и запускаются медленно, и перерисовываются медленно всё какое-то заторможенное, на подсознательном уровне противно. Хотя, если замерять секундомером, вряд ли увидишь разницу, но человек не секундомер, лагающее дерьмо - видно, оно постоянно действует на нервы уничтожая комфорт пользования, это мерзкий дефективный интерфейс пользователя. Одно и то же банальное окошко на сях (и тому подобном) или на динамикодрисне, как небо и земля.
>>2365221 Что такое Сборщик Мусора? Это такая программа, висящая в фоне параллельно твоей программе, которая ебет твою программу в хвост и в гриву как ей там вздумается. Что это вообще за дерьмо, алё, гараж? Слышь, это уже не программа получается, с скрипт. Ты пишешь типа пожелания, которые отправляются в нёх-машину, которая там типа их выполняет и вообще хуй пойми чем занимается, может майнит. Это не программирование никакое, чел. Программа, это когда ты пишешь, и компьютер выполняет ЧТО ТЫ НАПИСАЛ, а не вертит нёх-машину от чужого дяди. Это скриптинг, макакинг, программирование 1С.
>>2302404 >Discord А ещё они на элексир с фениксом все переписывали, такое ощущение, что там просто реализуют хотелки главного тимлида потрогать языки в масштабах продакшена.
В общем, гайс, всё отменяется, язык реально хорош. Это как хорошее вино, нужно время чтобы распробовать, чтобы вкус раскрылся, возможно потом будет похмелье, пару дней, и вот когда оно проходит, ты понимаешь что не можешь не выпить этот прелестный напиток. Или это как знаете, новый вкус мороженного от любимого производителя, дайте ему время, почувствуйте как оно тает на языке.. да, это определенно клубничный вкус, со сливками. Ну а вообще, по крайней мере от раста не воняет говном мамонта, как от других языков, что согласитесь не мало. В общем, продолжаем разбираться в этом чудесном языке. Всем потокобезопасности в этом чате.
Насколько раст применим в обычных бекендерских задачах? На проекте появилось требование переписать один из жрущих сервисов а в последствии и большую часть проекта с питона на что-то более производительное, выбор пал на раст и го. Почитал треды на разных ресурсах, очень много постов с подчеркиванием системности языка и большим количеством низкоуровневых операций, на которые тратится больше времени чем на написание бизнес логики. Есть ли тут аноны, которые успешно пишут веб на расте? Какие ощущения от этого?
Если надо чтоб работало - переписывай на го, если надо ебать мозги кабану бесконечным раздуванием сроков, а потом оставить перед выбором: остаться с неподдерживаемым кодом либо платить тебе дохуя денег - тогда переписывай на раст.
>>2366440 >>2366568 Если надо чтоб работало - оставляй как есть на питоне, если надо ебать мозги кабану бесконечным раздуванием сроков, а потом оставить перед выбором: остаться с неподдерживаемым кодом либо платить тебе дохуя денег - тогда переписывай на го.
>>2366797 >оставляй как есть на питоне Однопоточная говнина, которая тормозит даже при итерации цикла. Если нужно нормальное приложение, которое не будет жрать память планками, бери го. Не жри все эти асинки, авэйты, промисы и прочие костыли асинхронного программирования. Сейчас, когда ядер больше чем извилин у среднего веб разработчика, нахер не нужны синхронные языки. Да, дизайн языка говно, но другого люди не осилили, кроме откровенной экзотики
>>2371147 Есть такие слова: "при накоплении определенного объема количества, оно переходит в качество" "всё хорошо в меру"
Не обязательно ударяться в крайности если ты не школьник-максималист, достаточно не переходить ту границу, когда программирование срывается в макакинг. Хорошим примером является С++, совершенно чудесный язвк, позволяющий как писать нормальные программы си-стайл, так и пердеть макакиным говном js-стайл, со всеми этими stl, лямбдами и тому подобной дрянью. Вот где-то по-серединке и проходит эта роковая граница срыва, перехода количества в качество.
>>2371191 В контексте сказанного же. Не вырывай слова из контекста, это не имеет смысла.
И дополню, под "количеством" имелось в виду количество абстракций. Абстракции сначала помогают, избавиться от машинных кодов, потом от громоздкого ассемблера, потом сделать си удобнее., но вот наступает момент, когда вместо помощи программированию, абстракции "захватывают власть" становясь самим программирование. Зменяется менталитет программиста на уже другой, и то что он пишет, уже совсем не то что раньше было, и отношение другое, всё другое.
>>2371252 > В контексте сказанного же. йеп, вот прям в твоём контексте я тебе наверное раскрою секрет, но в плюсах не зеро кост абстракшенс нихуя, собственно по этой причине С до сих пор жив
>>2373422 И ведь конечно, даже после того как он сам признался, что в чате, где большинство русские, выставив ник реж русню, он не считает что не прав и все свалят на злых русских
Хочу изучать rust, но пугает, что там все захватили всякие транспидоры, фемки и прочие sjw/lgbt/blm-щики, которые ведут сообщество к пропасти. Успокойте меня, у раста есть надежда на будущее?