Организация Rust Foundation опубликовала статистику, в соответствии с которой из 127 тысяч значительных пакетов, представленных в каталоге crates.io, более 24 тысяч (19.11%) используют ключевое слово "unsafe" для отключения проверок безопасной работы с памятью. 34.35% пакетов совершают прямые вызовы функций из других crate-пакетов, в которых используется режим "unsafe"...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61251
> Для выявления проблем в коде, выполняемом в режиме "unsafe", проектом развивается интерпретатор MiriМонстр разрастается. Почему бы просто не использовать последние стандарты C++? Зачем использовать язык с таким заковыристым синтаксисом, который к тому же не жизнеспособен в реальной практике и приходится аж интерпретатор вкорячивать для проверок?
Настолько нежизнеспособен, что вовсю используется в ядре, драйверах, gui, софте, ага.
Что-то не припомню рабочих драйверов на расте. Были пробные, да. Софт на расте тоже не встречал. Не привередлив, ставлю что полезно. А, вспомнил, firefox использую.
Некоторые вещи, типа https://github.com/ogham/exa очень даже ничего.
Если бы вы не написали, не узнал что существует такая утилита. А это значит что меня устраивает ls и острой нужды искать альтернативу не было. Есть что-то уникальное и полезное на расте, не клон существующего?
https://gitlab.com/liferooter/textpiecesАналога этой не знаю. Разве cyberchef, но это вебапп. Ну и куча экстеншинов для VSCode.
Мб еще это, в попытках "отвязаться" от regex101. Но она еще сыровата:
https://flathub.org/apps/com.felipekinoshita.WildcardМеня ls тоже устраивает, но присматриваюсь тем не менее. Как, например, недавно съехал с docker на podman.
Видел аналог на гошке причем с в разы большим функционалом
Не поделитесь, я бы съехал.
> Видел аналог на гошке причем с в разы большим функционаломНе все функции пересекаются но в целом вроде оно
> https://gitlab.com/liferooter/textpiecesЯ в молодости такую штуку на сишечке писал.
91.2% Rust, 1.1% Python. Зачем ложка дёгтя в бочке мёда?
А вы много знаете каких-то совершенно новых направлений для написания софта, что бы не считать этот софт "клоном"? Сейчас что угодно на любом языке можно назвать "клоном" более старой реализации на другом языке.И даже если вам предоставить "не-клон", то естественно окажется, что вы вообще такое не используете и никто из ваших знакомых не использует. А значит это что-то незначительное и "не-нужно".
Только unmaintained, use fork - а в остальном да-да...
Asahi Linux, драйвер для Apple GPU на расте https://github.com/AsahiLinux/linux/tree/gpu/rust-wip/driver...
В main не принят.
Ты спрашивал про рабочие. Вытаскивать из рукава новые аргументы не получится.
Это был не контраргумент, а заметка.
Тут можно съехидничать и поинтересоваться про рабочие драйвера написанные не аутичными транскошкодевочками.Потому что без характерного расстройства, coding socks и adhd medication Rust не даётся.
Впрочем, за asahi спасибо им и респект.
Rustdesk, alacritty, ripgrep.
> Софт на расте тоже не встречал. Не привередлив, ставлю что полезноhttps://github.com/postgresml/pgcat
На замену PgBouncer весьма небесполезная штуковина
хрустдеск норм, хоть я и противник хруста, но только из-за фанатиков
Справедливости ради, а не защиты раста для, есть прекраснейшая софтина, не клон, vector величается https://vector.dev/
В этом списке не хватает InfluxDB v3, которую полностью переписали на расте
https://github.com/influxdata/influxdbВот уж где суровый бизнес.
>что вовсю используется в ядре, драйверахВовсю в учебном драйвере.
ripgrep'же!!! Да, это аналог, но очень годный и популярный аналог.
И правда, почему бы не использовать C++, когда доступна альтернатива, пусть даже это раст? Зачем использовать язык с таким заковыристым синтаксисом, который хоть и крайне жизнеспособен, но которым больно пользоваться?
Новые стандарты не больно использовать.
Из них выкинули <>*&::?
Вы серьёзно? В rust с этим гораздо хуже.
И раст не альтернатива плюсам. Раст более функциональный и синтаксис отличается. Вот карбон может быть альтернативой, но его в реальности пока нет.
раст - компилируемый в натив язык без сборки мусора. может легко испольтзоватьмя без стандартной библиртеки.
так что это вполне себе альтернатива и С и С++.или как ты вообще понимаешь слово "альтернатива" ?
> который к тому же не жизнеспособен в реальной практикеВы лжете или заблуждаетесь. Почитайте отчеты разработчиков нативной системщины андроида. Там уже много на расте написано и им нравится результат. А Ларс Бергстром, технический директор Google, вообще пару месяцев назад выдал: "Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++". Причем не только разработка, а и сопровождение и апдейты разработанного. Зачем же писать на в два раза менее эффективном для разработки языке? Только потому что ты знаешь плюсы, а на расте ты не можешь, потому что у тебя лапк..., то бишь, синтаксис?
> Вы лжете или заблуждаетесь.А третьего не дано.
Это та маленькая инди компания, которая разработала язык Go, автор которого признался, что язык создавали для [не очень способных]? Я бы не стал прислушиваться к мнению гугла в каком-либо вопросе. У яндекса и то лучше получаются инновации в последнее время. А они не особо на расте пишут. Но это не аргумент.
> которая разработала язык Go, автор которого признался, что язык создавали для [не очень способных]?Эх, если бы сишку когда-то тоже делали с учётом того, что 99% пишущих на ней будут не очень способны [уложиться в выделенную область памяти]?
Эта сишка называется паскаль
Вот лучше бы кстати вместо Rust сделали бы адекватное переосмысление Pascal под LLVM и с учётом многопоточности, параллелизма и асинхронности. Был бы и приятный язык, который мог бы занять определенную нишу, а также вернул бы себе статус языка для студентов вместо Python, что вообще преступление преподавать первым языком.
Сделай, сорцы LLVM открыты и общедоступны на халяву, это не RedHat какой-нибудь.
Лучше бы в rust полноценные контракты сделали и получили очередной "Язык АДА". Зато без всяких там unsafe, всё доказательно и по феншую.
Назовите инновации яндекса, которые действительно инновации, а не тупое повторение за гуглом "зато по-нашему"? Хоть что-то они вообще сами сделали или придумали, а не тупо скопировали или купили готовую команду?Т.е. я знаю что у них разные эксперименты есть, но все что им принесло реальные доходы/рост, они тупо повторили, увидев что это уже приносит доходы гуглу (и в паре случаев другой иностранной компании), и по проторенной дорожке, по возможности пытаясь закрыть доступ к исходным инновациям на российский рынок, они копировали или покупали готовое и представляли как "технологии яндекса".
Сравните тупость ответов нейронки гугла и качество алисы и нейро. И яндекс запустил нейро поиск раньше гугла. Есть ли у гугла в браузере перевод видео? Или хотя бы картинок? А в яндексе есть.
Оба хуже.
Внезапно по мнению компании мелкософт виндовс лучшая ОС, а C# лучший язык. Также внезапно у гугла любое упоминание дарта, го, раста все делает лучше.
На деле все конечно иначе.
> по мнению компании мелкософтТо ли дело мнение опеннетных экспертов, да?
Видишь ли, в отличие от местных комментаторов, Майкрософт с Гуглом реально пишут софт, и делают это десятками лет.
> Майкрософт с Гуглом реально пишут софтШутка сделала мой день.
А что не так?
Посмотри сколько пользователей винды, посмотри сколько пользователей андроида, посмотери сколько юзербейз у хрома.
Да именно они пишут код для людей, а не для агрессивоного меньшенства прдоликов.И да, ядро линукса пишут гугл и майкрософт, тоже.
> выдал: "Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++". Причем не только разработка, а и сопровождение и апдейты разработанного.Может быть, им приходится чаще исправлять написанное, чем сишникам или плюсовикам, вот вам и два?
> "Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++".Это просто эффект новизны. В команде rust, поди, реальных спецов набирают, кому интересен ЯП. А в C++ за давностью лет уже и трансгендеров полно и чернокожих женщин согласно нормативам.
> А Ларс Бергстром, технический директор Google, вообще пару месяцев назад выдал: "Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++"Щас бы слушать техдиректоров без знания внутренней кухни...
> Почему бы просто не использовать последние стандарты C++?
> Зачем использовать язык с таким заковыристым синтаксисомСами спросили, сами ответили.
Что конкретно не так с синтаксисом Раста? Вы серьёзно ставите его в противовес синтаксису плюсов? Как по мне, самый типичный и не неизуродованный c-like
За let надо просто расстреливать. Драйвер, а там: let, let, let. 100 лет и будет парсить. Торвальдс не просто такой kernel code style для С придумал идя даже на риск проблем из-за отсутствующих фигурных скобок. Лишь бы сократить размер исходников и время парсинга/препроцессинга. И тут Раст со своим синтаксисом от Visual Ba(sic!). Ну удачи, чё.
> За let надо просто расстреливать. Драйвер, а там: let, let, let. 100Эээ... Это вся заковыристость? Ожидал увидеть что-то про лайфтаймы. Я рассматриваю синтаксис в первую очередь с позиции читающего. Компилятор на других этапах гораздо больше времени тратит, это экономия на спичках.
То ли дело const struct foobar *foo
>И тут Раст со своим синтаксисом от Visual Ba(sic!).От OCaml, кстати код на OCaml весьма компактный и читабельный, но раст это не смог унаследовать, как-раз сиобразность помешала.
>>И тут Раст со своим синтаксисом от Visual Ba(sic!).
> От OCaml, кстати код на OCaml весьма компактный и читабельный, но раст
> это не смог унаследовать, как-раз сиобразность помешала.Сейчас бы сравнивать синтаксис языка с gc с языком без.
>Сейчас бы сравнивать синтаксис языка с gc с языком без.Ну здрасте, присутствие или отсутствие скобок никак от GC не зависит.
>синтаксисом от Visual Ba(sic!)Палитесь. Все функциональные языки смотрят на вас с непониманием. А Окамл даже как-то по злому.
> За let надо просто расстреливать. Драйвер, а там: let, let, let. 100
> лет и будет парсить. Торвальдс не просто такой kernel code style
> для С придумал идя даже на риск проблем из-за отсутствующих фигурных
> скобок. Лишь бы сократить размер исходников и время парсинга/препроцессинга. И тут
> Раст со своим синтаксисом от Visual Ba(sic!). Ну удачи, чё.В чем проблема с let?
Этот язык поддерживается корпоратами чтобы сдерживать развитие опенсорса. Если куча софта будет написана на десятке языков, ты никогда не сможешь нормально всё это поддерживать. Да даже собрать из исходников всё это будет нетривиальной задачей.
Вот язык впихивают в ядро Линукс - зачем? А чтобы ядро теперь компилировалось одним лишь LLVM, сводя на нет все прежние усилия по поддержке нескольких компиляторов и кроссплатформы.
И теперь люди из проекта GCC работают не покладая рук, чтобы запилить поддержку Раста, вместо того, чтобы самый лучший компилятор на Земле выдавал ещё более быстрый и корректный код.
> А чтобы ядро теперь компилировалось одним лишь LLVM, сводя на нет все прежние усилия по поддержке нескольких компиляторов и кроссплатформы.Избавились от гнутого вендорлока.
звучит как "умный дурак"
> звучит как "умный дурак"Нет. У гнутиков реально был вендерлок на гцц из-за гнутых экстеншенов в лучших традиция ЕЕЕ мелкософта.
И пришлось потратить тысячи человекочасов чтобы это все овно поддержать в LLVM.
Зато сейчас можно собирать ядра и без использования гну-рака, чем занимается напр. гугл.
У них и link exception в своё время был, что доставляло не меньше. Людям пришлось особо наглому бородатому Соловьеву от IT дать по рогам и придумать LGPL чтобы такой фигни больше не творилось.
> У гнутиков реально был вендерлок на гцц из-за гнутых экстеншенов в лучших традиция ЕЕЕ мелкософта.ну зачем так жирно? так говорите, будто EULA лучше :)
> ну зачем так жирно?А где жирно-то?
Вспомните почему в бсд отказались от gcc, почему эпл внезапно решила потратить деньги на спонсирование ллвм.
И почему потом появился GCC Runtime Library Exception.
Это такая же копирастия и ЕЕЕ, только в гнутой обертке.> так говорите, будто EULA лучше :)
Вы что-то слышали о теореме г-на Эскобара?
Что ЕУЛА, что гнурак ограничивают тебя. Только еула тебе позволяет заработать на хлеб с маслом)))
Я ни в коем случае не поддерживаю вендорлок в любом виде, но ты тупо перевираешь чужие слова.
Ты можешь собрать ядро любым компилятором сишки, поддерживающим стандарт C11 (на него перешли с C89 начиная с ядра 5.18) или только гнутым? Если можешь, то вендорлока и в самом деле нет, если не можешь - он есть.
> Если куча софта будет написана на десятке языков, ты никогда не сможешь нормально всё это поддерживать.Внезапно, куча софта уже написана сильно больше, чем на десятке языков. Даже того, который прямо поддерживается и продвигается FSF.
> Этот язык поддерживается корпоратами чтобы сдерживать развитие опенсорсаА сишочка поддерживается корпорациями чтобы внедрять бесконечные дырени и бэкдоры, правильно?
Как страшно жить - кругом одни заговоры корпоратов! А то, что 95% этого опенсорса пишется этими самими корпоратами - это мы тактично опустим, да?
Ни один язык в мире (Pascal, D, Lisp, Java, C#) настолько рьяно не пропихивались евангелистами как это дело происходит с Rust.
> Ни один язык в мире (Pascal, D, Lisp, Java, C#) настолько рьяно
> не пропихивались евангелистами как это дело происходит с Rust.Когда проталкивались Lisp, Pascal и Java интернета или совсем или толком не было, но даже в учебниках лиспа соловьем пели про язык искусственного и интеллекта, а ява очень сильно рекламировалась даже в непрофильной прессе. А вот с C# евангелисты уже бегали не хуже чем с растом, можно и сейчас полистать километровые срачи на ixbt или rsdn. Ну и злобные функциональщики в свое время не менее (а скорее более если вспомнить Луговского и подобных) рьяно продвигали, другое дело что там был гораздо меньший отклик (положительный) в массах чем у раста.
> Когда проталкивались Lisp, Pascal и Java интернета или совсем или толком не было, но даже в учебниках лиспа соловьем пели про язык искусственного и интеллекта,То что интернета почти не было это не важно.
Народ просто покупал журналы посвященные компутерам, а срались почтовых рассылках.
Для лиспа даже делали отдельное железо вида "лисп-машины" и рассказывали что это просто идеальный компутер специального назначения. Но в итоге они отправились в музеи.> Ну и злобные функциональщики в свое время не менее (а скорее более если вспомнить Луговского и подобных) рьяно продвигали, другое дело что там был гораздо меньший отклик (положительный) в массах чем у раста.
У раста прог вхождения гораздо ниже - просто читаешь растбук и слушаешь что говорит компилятор.
А для функцианальщины начинаются монады, теория категорий, функторы и прочий матан.
При этом выхлоп от раста виден практически сразу - просто смотришь в ьагтрекер и фильтруешь сколько ошибок по памяти.
А на том же хаскеле теоретически можно писать идеальные программы, а практически не получается.
> А чтобы ядро теперь компилировалось одним лишь LLVM, сводя на нет все прежние усилия по поддержке нескольких компиляторов и кроссплатформы.Oh, my sweet summer child... Ты в курсе, что ядро без расширений GNU не собирается?
они уже давно все портированы в шланг
Но собрать ядро clang'ом... clang'ом собрать ядро... ты все еще не можешь, да? И каким-нибудь icc - тоже, ойнед? Ох, "это же ДРУГОЕ!", правда?
а есть на это причина?
да же tcc можно ядро собрыть ))
было ао крайней мере
> И каким-нибудь icc - тоже, ойнед?Эльбрус же. Альт и прочие дистры.
Я собирал. И не только шлангом. И не только под х86. Расширяйте проф. кругозор, полезно.
> Я собирал. И не только шлангом. И не только под х86. Расширяйте
> проф. кругозор, полезно.Ну, отстал от жизни - бывает. Про android знал, но думал, что дальше google'а оно она как.
Такие вы смешные, поколение мемов. Ядро пингвина шлангом собрать, как так! На Яндекс практикуме не учат! Страшно, вырубай! Вот netbsd под vax с документацией и исходниками наперевес собирать вот это был челенж) А тут мема подходящего не нашел - и всё! Ступор!
Потому корпоративная система экономически эффективна и развита лучше, чем анархия OpenSource.
Причин много:
• Слабая экосистема. Cargo, rustdoc и mdbook кладут на лопатки костыльные варианты этих инструментов для C++
• Низкоуровневое управление памятью, что чревато всегда человеческим фактором. В Rust больше средств, чтобы не шмальнуть в ногу
• Zero-cost abstractions в C++ почти нет, хотя Rust этим славится
• Безопасный код, который генерируется уже в ассемблере. В C++ полагается лишь на динамический анализ
• Миграция крупнейших компаний на Rust и увядание поддержки ими C++
> CargoЗа стягивание зависимостей автоматом из инета нужно не гладить по голове.
А конец C++ предрекали java, go и вот теперь rust.
Ну так и Java, и golang выдавили C++ из своих ниш. Не правда ли?
Они и раст выдавили. Раст это маргинальщина.
>> Cargo
> За стягивание зависимостей автоматом из инета нужно не гладить по голове.Можно не стягивать, а просто рядом положить в проект.
Докажите математически безопасность кода, получающего на вход поток данных со свойством неопределённости во времени.
Выдыхай.
фаззингом :)
> Cargo, rustdoc и mdbook кладут на лопатки костыльные варианты этих инструментов для C++Это всё антипраттерны проекториования и наглядные иллюстрации как делать не нужно. Из положительного разве что попробовали с самого начала озаботиться коробочными решениями, но получилось ужасно и теперь этот ужас стандарт в rust.
А может просто анонимный эксперт не разбирается в проектировании. Или такого быть не может в принципе?
То есть для тебя аргумент приобретает силу только тогда, когда его выскажет некто с "большим именем и званием"?
Не, мы на слово верим любому здешнему анониму и что линуксов на десктопе 146% (на некоторых сразу несколько штук стоит), и что они лично переводят на него по 100500 корпораций и стран ежедневно - просто злые майкрософтовцы в полночь всё на место возвращают, и что этот самый линукс сообщество в свободное время чисто ради развлечения пишут, а корпы где-то в сторонке стоят и изо всех сил процессу мешают и в аналогичные байки.
> Почему бы просто не использовать последние стандарты C++?Потому что проникновение рептилоидов ещё не настолько велико.
Рептилоиды сделали так что современные программисты не умеют писать на Си и Срр, тон на пайтоне.
> Почему бы просто не использовать последние стандарты C++?Как же умиляет это "просто" от местных экспкртов. Вот никто не додумался до такого очевидного и легкого решения всех проблем, как "просто писать без ошибок".
Если уж сравнивать по монстроузности, то большего монстра, чем C++, из сколь-либо популярных языков найти сложно.Весь смысл unsafe в том, чтобы его использовать ограниченно там, где без него никак, и эти места тщательно осмотреть и оттестировать - например, в врапперах стандартных библиотек или системных вызовов. И, судя по отчёту, именно там unsafe преимущественно и используется. Внезапно.
Кто там тщательно смотрит? И что такое тщательно? И почему ансейф не используют ограничено новость почитай. Зачем вообще вы эти лозунги транслируют они же ничего не значат.
> И почему ансейф не используют ограничено новость почитай.В смысле "не используют ограничено"?
В статье прямо сказано:
"в большинстве случаев использование "unsafe" обусловлено вызовом кода, написанного на других языках или обращения к библиотекам на С/C++"Т.е оно используется для ffi, где из кодов на c/c++ может прилететь все что угодно.
А это именно то, где оно и должно использоваться.
Да ладно, "не жизнеспособен"! Вполне норм. RipGrep использую очень часто. Отлично работает. Пробовал Rust и на задачах из spoj.com - тоже всё хорошо.
Что не так с обычным грепом? Или боишься сам себя взломать во время грепа? Это просто смешно.
> Что не так с обычным грепом?Обычный греп тормозной.
На лоре были сравнения грепа, RipGrep и какой-то на плюсах.
Там греп был днищем по сравнению и с одним, и с другим.Тут скорее вопрос - зачем пользоваться грепом, если есть более эффективные решения, пусть и не на расте?
Потому что диды пользовались?))
Не очень если честно понятно, что вам такого grep'ать приходится так, чтобы эта разница в производительности имела значение.
> Не очень если честно понятно, что вам такого grep'ать приходится так, чтобы эта разница в производительности имела значение.Напр. пару сотен гигов логов прогрепать, а потом передать дальше на обработку. Вполне распространенный кейс. Понятно, что это не типичная задача для одмина и тем более для юзера, но там разница вполне чувствуется.
С другой стороный - назовите причины использовать grep вместе RipGrep.
>> Не очень если честно понятно, что вам такого grep'ать приходится так, чтобы эта разница в производительности имела значение.
> Напр. пару сотен гигов логов прогрепать, а потом передать дальше на обработку.
> Вполне распространенный кейс. Понятно, что это не типичная задача для одмина
> и тем более для юзера, но там разница вполне чувствуется.
> С другой стороный - назовите причины использовать grep вместе RipGrep.Так на пару сотен гигов логов - эластик\грейлог\локи\черт-в-ступе нужен. Если их локально грепать приходится - скорее всего уже в консерватории что-то не так, не?
> Если их локально грепать приходится - скорее всего уже в консерватории что-то не так, не?Разумеется. Но не всегда есть возможность менять что-то в консерватории.
А на вопрос про "причины использовать grep вместе RipGrep" так и не ответили(((
>> Если их локально грепать приходится - скорее всего уже в консерватории что-то не так, не?
> Разумеется. Но не всегда есть возможность менять что-то в консерватории.
> А на вопрос про "причины использовать grep вместе RipGrep" так и не
> ответили(((Ну, as for me - дохреналлион legacy-скриптов, с которыми таки да, нет возможности что-то менять и нет-нет да и "да" - приходится что-то делать. Ну и традиционный положенный переписаками болт на совместимость флагов командной строки\поведение такого-же-но-лудшего приложения.
В результате зачем делать себе моск особенностями двух программ - если и от одной-то воротит. А так - задачи грепать терабайты логов у меня нет, а grep в системе - по дефолту вполне себе есть, и там, где я его применяю - на разницу в производительности можно плюс-минус положить.
> Что не так с обычным грепом? Или боишься сам себя взломать во
> время грепа? Это просто смешно.Grep --- тормоз. Пока он там будет копошиться, ripgrep уже успевает всё закончить.
если бы это кому-то было нужно то оригинал бы давно уже ускорили
а так... сами понимаете
> если бы это кому-то было нужновсем кому нужно - перешли на ригреп
> то оригинал бы давно уже ускорили
думаю там это не так просто - придется пол-проекта переписать
Почему бы просто не перестать троллить?
> Монстр разрастается. Почему бы просто не использовать последние стандарты C++?Потому что такой же монстр, но гарантий дает меньше. И унаследованные бестолковости си типа "int" неопределенного разера - чинить видимо не собираются.
> Зачем использовать язык с таким заковыристым синтаксисом, который к тому же не жизнеспособен
> в реальной практике и приходится аж интерпретатор вкорячивать для проверок?Это же можно и про C++ сказать - статические анализаторы же есть. Так что чем C++ так уж лучще, даже в последнем стандарте - не понятно.
> И унаследованные бестолковости си типа "int" неопределенного разера - чинить видимо не собираются.Не неопределенного, а платформозависимого размера. Для максимальной производительности самое то. И фиксированного размера типы в плюсах есть.
А для с++ не нужно всякие AddressSanitizer, MemorySanitizer тысячи их. Костыли без которых нельзя понять есть ли ошибки в самом обычном коде. Где в rust без использования unsafe таких ошибок не будет, интерпретатор проверяет режим unsafe.
И уж не про синтаксис говорить про с++. Такое может говорить тот, кто кроме одного языка не может выучить других. Ладно можно ещё поспорить что C синтаксис проще rust, но с++ это просто монстр начиная от стандартной библиотеки и заканчивая шаблонами.
Что ещё раз напоминает, что ничего толкового на чистом безопастном хрусте написать особо так и не получилось. То, что на 1 здравый пакет минимум 4 хелловрота - тоже вполне понятно, даже мало как-то.
Тебя же не смущает, что на высокоурвневом языке ты напрямую сделать условный "int 0x80" для системного вызова не сможешь, и что где-то внутри стандартной библиотеки есть страшно низкоуровневая страшно машинно-специфичная ассемблерная инструкция, непосредственно инициирующая системный вызов?Так и здесь, почему тебя должно смущать, что низкоуровневые библиотеки используют unsafe для интеропа с сишным кодом? Если этот unsafe написан грамотно, то ничего страшного не случится, и изолированный внутри библиотеки unsafe код наружу в пользовательский код не вытечет
>>Если этот unsafe написан грамотно, то ничего страшного не случитсяЕсли на Си и ассемблере писать грамотно, то тоже ничего страшного не случится
Но по загадочным причинам предпочитают ежедневно получать пачку CVE. Это хитрый план такой?
По загадочным причина на русте никто не пишет.
Анекдот про "Папа, а где море?" общеизвестен и пересказывать его тут нет никакой необходимости.
Это недостаток образования и "чистоплотности" в программировании.
Если отрастить крылья, то можно летать.
Понадобятся очень большие крылья и ещё мышцы.
Главное операции взмаха пометить как ансейф и всё заработает. нет.
…и совершенно фантастический метаболизм, чтобы питать всё это.
> Если на Си и ассемблере писать грамотноО том и речь, что сишный код, который выполняется через unsafe, должен быть написан грамотно.
И вот тут самая засада: хруст придуман для тех, кто не может в "написан грамотно", чтобы оградить их от страшного небезопасного unsafe с необходимостью считать границы буферов и т.п.
Так а никто не может.
Ну чего ж поделать, если у вас никто не может.
Учитесь.
У дедов, чьи дырени десятки лет вылавливают миллионы глаз?
На русте полно дыреней написано.
По работе с памятью в safe режиме?) Пруфы в студию.
> Ну чего ж поделать, если у вас никто не может.
> Учитесь.Так а не у кого, никто не может.
Не забывайте добавить "в известном мне кругу".
> Не забывайте добавить "в известном мне кругу".Нет кругов, где умеют. Вообще. На свете нет ни одного сишного проекта больше тысячи строк без багов, вызванных метапрограммированием через порчу памяти. Никто не умеет писать на C, смирись.
Ещё раз, добавляйте "вокруг меня", что-ли.
И тем не менее - все эти проекты прекрасно используются, дыры фиксятся, и т.п.
А вот на хрусте нет ни одного проекта, который бы вот реально прямо сейчас в проде понадобился.
> И тем не менее - все эти проекты прекрасно используются, дыры фиксятсяНу то есть ты признал, что никто на C писать не умеет, хорошо. Теперь ты наконец-то можешь начать осознавать, зачем появился Rust, Zig и прочие.
Ну то есть ты вообще не читатель, я понял. За сим и завязываю.
> Ну то есть ты вообще не читатель, я понял. За сим и
> завязываю.Bawwwwww.
Что же до "зачем" - понятное дело зачем, чтобы тешить ЧСВ переписыванием очередного ls до полурабочего состоянии. Потом всё равно выкинется, но хотя бы работа есть.
> int 0x80Господи, это из какого века к нам пожаловал? Или правильно сказать в каком архиве в Инете это нашел?
Говорят, на рассвете линукса существовала такая архитектура — x86. Ещё говорят, что она была тридцатидвухбитная (не знаю, верить или нет). Так вот, в ней система вызывалась через int 0x80.И по сей день некоторые верят, что так она и вызывается. Причём всегда и везде.
Забавно. Из срача в срач перед вами мечут бисер, постоянно приводят в пример серьезные проекты, а вам или "проекты не той системы" или "это хелловрот" или почему-то ненужное вам переписывание забагованного старого копролита или просто лично вам не нужное ПО, а раз вам ненужное - значит не нужное никому. Бог подаст, тролль.
> постоянно приводят в пример серьезные проектыНо не приводят же. Где?
Ну вот я лично посмотрю (уже) все ссылки и буду использовать эти утилитки.
Серьёзные проекты на хрусте? Где?
Уже писал про дико популярный ripgrep.
Была вроде утилита echo переписанная расте, и вроде еще ls переписали
Хрен бы с ним с ls, тут influxdb целиком переписали
Прокси от Cloudflare
Драйвер от Асаши.
Несмотря на то, что а апстрим пока не приняли, он прешл сертификацию Кроноса и им пользуется Торвальдс лично.
Даже благодарности писал, что на своем макбуке может нормально использовать.
lkml.iu.edu/hypermail/linux/kernel/2207.3/07437.htmlOn a personal note, the most interesting part here is that I did the
release (and am writing this) on an arm64 laptop. It's something I've
been waiting for for a _loong_ time, and it's finally reality, thanks
to the Asahi team. We've had arm64 hardware around running Linux for a
long time, but none of it has really been usable as a development
platform until nowА еще можно перечислять долго, RustVMM, Pingora, COSMIC, Hickory, ....
но зачем перед тобой метать биссер?
Целый! Вау!
И то не нужен никому, кроме собственно пытающегося это пописывать.
> И то не нужен никому, кроме собственно пытающегося это пописывать.Почти никому.
Кроме какого-то васяна Linus Torvalds, но хз кто это вообще такой...
Поэтому да, вообще никому))
Вау. Целый 1 человек на весь мир. Независимо от пола, возраста и статуса.
Ты сначала сам попробуй написать серьёзный проект, потом сможешь быть экспердом на опеннете.
Какой еще "режим" unsafe, что курят авторы? я могу пометить функцию "unsafe" даже не затрагивая работу с памятью или вызов ffi небезопасных фич, просто от того, чтобы напомнить пользователю "почитай коммент перед вызовом этой функции, оно может сломать мое апи" и все. я могу использовать такой подход для реализации других специализированных оберток, или даже тестов более оно ничего не меняет.
Прочитайте дальше заголовка. Там написано о том какой unsafe, что подразумевали авторы и где именно этот unsafe использовался.
я все детально прочитал,
авторы просто посчитали количество слов "unsafe", привели примеры его использования и назвали его "режимом", а то, что unsafe fn my_fan(b: usize) -> usize { b+1 } это абсолют safe код их не волнует.. дичь
Прочитайте ещё раз:
> более 24 тысяч (19.11%) используют ключевое слово "unsafe" для включения возможностей, допускающих небезопасную работу с памятьюЭто явно не похоже на "просто посчитали unsafe и отдельно привели пример".
именно посчитали ключевое слово "unsafe", также советую почитать и оригинал.
> Most of these Unsafe Rust uses are calls into existing third-party non-Rust language code or libraries, such as C or C++.
> The canonical way to distribute Rust code is through a package called a crate [5]. As of May 2024, there are about 145,000 crates; of which, approximately 127,000 contain significant code. Of those 127,000 crates, 24,362 make use of the unsafe keyword, which is 19.11% of all crates. And 34.35% make a direct function call into another crate that uses the unsafe keyword. [6] Nearly 20% of all crates have at least one instance of the unsafe keyword, a non-trivial number.вот все ваши цифры
как насчёт переполнения ?
Исправили уже несколько лет назад.
а потом такие как Вы рассказывают про дырявую сишку
Вы пометили код, как unsafe, и завтра _другой человек_ таки вкорячит в него что-то реально unsafe, не привлекая внимания санитаров
> Вы пометили код, как unsafe, и завтра _другой человек_ таки вкорячит в
> него что-то реально unsafe, не привлекая внимания санитаровИ? Что изменится?
Во-первых, это изменение тоже должно пройти ревью и ответить на вопросы ʼа зачем?ʼ
Если в проекте этого не происхоит, то это не проблема языка, а управления проектом.
Вон ХЗ ломанули и в офф репу добавили бекдоров.Во-вторых, плохой код все равно останется внутри unsafe блока.
Т.е достаточно поискать в проекте слово unsafe и ты найдешь все куски кода, которые нужно проверить в первую очередь.
80.89% кода с crates.io не использует unsafe напрямую, а 64.65% — даже косвенно. Стало быть факты говорят, что бóльшая часть кода на раст безопасна в рамках гарантий языка. Для столь сложного и амбициозного проекта, которому и десяти лет не исполнилось это солидное достижение. Иные языки за срок в пять раз больший даже на йоту не придвинулись к такому положению дел. Браво, Раст!
язык начали делать в 2006, а в 2012 уже были первые рабочие статьи о нем.
Основную фичу раста - ownership/borrowing запилили за 3 года, с 2010 по 2013. Так что считай за три года они похоронили всех конкурентов умом Нико Матсакиса, раз уж ты за точность подсчётов.
в расте больше фич чем просто"ownership/borrowing", даже самый простой Arc+RwLock в то время уже был.
Собственно, именно благодаря этим костылям Ржу и не хотят использовать! Вместо программирования предлагают ВРУЧНУЮ (в 21 веке!!) бегать по каждому указателю и всё проверять. (на сцену выходит Лавров и говорит знаменитую фразу)
Я тоже так могу. Получается, что каждый третий проект на расте зависит от небезопасного кода.
Нет, не можешь, как ты сам же и продемонстрировал. Посмотри в текст новости, увидишь как надо было.
Пять из шести игравших в русскую рулетку подтверждают её полную безопасность
>Для столь сложного и амбициозного проектаЧто из этих крейтов является сложным и амбициозным? Очередной стотысячный хеллоуврот?
Ты можешь нас всех удивить и заткнуть за пояс, приведя свою статистику по «хеллоуврот» на crates.io. Достаточно лишь встать с дивана.
> 80.89% кода с crates.io не использует unsafe напрямую, а 64.65% — даже80.89% _пакетов_
В этой статистике пакет из десяти строчек и пакет из десяти тысяч строчек приравнены друг к другу.
Не волнуйся, все пакеты «из десяти тысяч строчек» используют unsafe.
> Не волнуйся, все пакеты «из десяти тысяч строчек» используют unsafe.Я не говорил, что волнуюсь.
Более того, я в этом не сомневаюсь.
Но статистика - чудесная штука: четыре хелловорлда из десяти строк каждый не используют unsafe, и они составляют подавляющее «большинство кода» при этом методе подсчёта.
Статистика действительно чудесная штука. Например, ты мог бы привести свою и показать как именно коррелирует количество unsafe и размер пакета документов а crates.io. Но вместо этого ты оставил коммент на опеннете.
> 64.65% — даже косвенноЭто столько nostd что-ли?
> из 127 тысяч значительных пакетов, представленных в каталоге crates.io, более 24 тысяч (19.11%) используют ключевое слово "unsafe" для включения возможностей, допускающих небезопасную работу с памятью в отдельных блоках кодаИнтересно другое: есть ли хоть какая-то практическая польза от пакетов, в которых unsafe нет, или это сплошь школьные helloworld?
Польза есть. Подсчёт был по самым популярным в использовании пакетам. Если люди их загружают, то они им полезны.
глупцы! вынипанимаете! это другое!
unsafe в rust'е безопаснее же, чем си и плюсы!
</sarcasm>
По крайней мере "опасная зона" отмечена в коде.
Что мешает делать в C++ так же?
Не осилили.
C++.
Ничего, так все и делают. Если код на с++ то это опасная зона.
Компилятор C++. В нём весь код - usafe
Rust использует llvm, а он тоже на плюсах.
Так если в llvm будет утечка памяти и т.д., ничего страшного, его взламывать компилятор бессмысленно, а вот если там будет логическая ошибка и сгенерит что то не то, вот тут и раст не поможет
> взламывать компилятор бессмысленно,Заменить компилер/линкер чтоб они все трояны генерили
и распространяли от имени жертвы? Это мечта всех хацкеров!
Да, и можно почитать каких усилий стоило разработчикам ЛЛВМа сделать свои кода надежными.
opennet.ru/opennews/art.shtml?num=60707- 2.4 млн строк кода охват кодовой базы, вовлечённой в fuzzing-тестирование
- число применяемых для проверки fuzzing-движков увеличено с 12 до 15
Ты же не думаешь, что все эти тесты получились бесплатно)Причем "12 новых проблем, из которых 8 были вызваны ошибками".
Т.е остался последний бастион, о который можно еще очень долго долбиться.
И это обычно пишут люди у которых комп без ECC памяти.
> По крайней мере "опасная зона" отмечена в коде.Однако проявление unsafe не ограничено помеченным участком кода. Если где-то твоей кодой базе есть unsafe, это значит проблема может вылезти в любом месте программы, если в этом unsafe блоке делается что-то не то. Формально нельзя считать ни одну программу safe в таком математическом плане, если они использует std например.
Уже было кинулся кидать ссылку на статью другу плюсовику...но почитав совсем не впечатлило.Вывод из цифр скорее нейтрально-положительный.
> Уже было кинулся кидать ссылку на статью другу плюсовикуА с какой целью, если не секрет?
Потроллить? Склонить к переходу на новый язык? Показать что "раст ненужон"?> Вывод из цифр скорее нейтрально-положительный.
Скорее положительный, говорит о том, что в большинстве случаем unsafe используется так как задумывался.
ps про зиг комментов давно не было, или ты его забросил?
Я на нём код пишу, а не комментарии строчу)))Сейчас у меня основной язык - чистый С. И Zig ложится на него идеально.
Буду активно использовать, но в hobby/side/open-source. На работе он, естественно, не используется.
Всё вместе. И потролить (он не любит Rust, постоянно его принижает т.к. сам плюсовик).И "раст ненужон" и т.п. Склонять бесполезно - на С++ работы в сотни, если не в тысячи раз больше сейчас. Как говорится, "за деньги - да".
Я Rust не люблю. Но вот проекты на нём мне очень нравятся и я их активно использую. Поэтому для уже Rust "нужон", не как для программиста, а как для потребителя. Чего только стоит typst, nushell, helix, zed.
А по поводу Zig...ну вот Miri это и есть Debug режим Zig, условно говоря (как минимум в будущем), которые будет отлавливать все ошибки. Rust как мы видим unsafe проверить не может.
> Debug режим Zig, условно говоря (как минимум в будущем), которые будет отлавливать все ошибки. Rust как мы видим unsafe проверить не может.Хм... почитал про этот Debug режим. Не очень понял как он будет отлавливать "все ошибки".
Но обратил внимание, что его можно выключить для блоков.
Safety checks can be disabled on a per-block basis with @setDebugSafety.
Что-то это мне напоминает 🤔
Что-то, что на 'Un' начинается и 'safe' заканчивается)
Так разницу чувствуешь? Его нужно отключать в конкретном участке кода (для максимальной производительности)...что-то это напоминает, не правда ли? Rust))))А проверять он может всё теоретически, что можно проверить в runtime. Т.е. double free, leak memory и т.д. и т.п. То, что умеет валгринд, то что умеет miri.
Ведь мири что делает? Запускает код Rust в runtime, потому что Rust не умеет и не может сделать большинство проверок без запускуа - в compile time.
> что-то это напоминает, не правда ли? Rust))))Да, очень напоминает.
Наверное создателям раста приятно видеть как другие языки используют их идеи.
И тут речь не только про zig, но, кажется моджо, тоже.> А проверять он может всё теоретически, что можно проверить в runtime. Т.е. double free, leak memory и т.д. и т.п. То, что умеет валгринд, то что умеет miri.
Ну, из положительного, когда я смотрел доку zig в последний раз, то у них "At runtime crashes with the message" для UBшек было гораздо меньше.
С другой стороны - раздел Memory до сих по в TODO:> Ведь мири что делает? Запускает код Rust в runtime, потому что Rust не умеет и не может сделать большинство проверок без запускуа - в compile time.
Не, большинство проверок Раст проводит таки в compile time, все что планировались.
Возможно в будущем наработки Мири просто перенесут в компилятор, а может и нет, тк это не соответствует идее проерять при компиляции.p.s. zig все еще умеет такой фокус или это уже подправили?
var helloZig = try allocator.dupe(u8, "Is zig sucs?");
allocator.free(helloZig);
std.debug.print("{s}\n", .{helloZig});
p.s.2 плейграунд как-то совсем не работает(
>Rust как мы видим unsafe проверить не можетЧто значит "unsafe проверить не может"? Блок unsafe вовсе не означает "твори любую дичь". Список разрешений ограничен пятью пунктами, всё остальное проверяется компилятором как обычно.
> Что значит "unsafe проверить не может"? Блок unsafe вовсе не означает "твори любую дичь".Не обращай внимание, это Витюшка.
Он тут уже блистаз познаниями Раста, рассказывая про классы и прочую дичь.
Еще он же заливал про то что раст "А что, Rust находит все классы ошибок?"
opennet.ru/openforum/vsluhforumID3/132453.html#182В общем персонаж забавный, пишет на js, но рассказывал про свою уникальную задачу, когда "несколько потоков одновременно пользуют один кусок памяти"
> Список разрешений ограничен пятью пунктами, всё остальное проверяется компилятором как обычно.
Доку читать не барское дело.
Это значит что проверки в компайл тайм строго ограничены по своим возможностям. Вне зависимости от технологий, подходов, языка, фич и т.п.Т.е. если ещё проще - их недостаточно поэтому пилят MIRI
Всего 20% растовиков пишут код не руками, а ногой, гммм, результат скорее положительный.
В смысле они отстрелили себе ногу, и за это им оторвали, наконец, руки?
В каждом пятом пакете? На мой взгляд, все это крайне показательно... так или иначе, все упирается в квалификацию программиста и тут раст ничего не изменил.
А кто-то говорил, что изменит? Где такая цель зафиксирована, в каком документе? Цель - безопасная работа с памятью в safe коде. И всё.
Когда же выйдет официальный компилятор от Microsoft Rust.Net?
Погодите немного. Расширения придумают, чтобы код несовместим был ни чем, кроме офтопика (к сожалению, других примеров MS не предоставило). Тогда и выйдет.
Обезопасят все платформы кроме микрософта от этого язычка.
Но ведь во имя добра и свободы же, почитай "Право читать".
Вся эта безопасность, встроенная в новомодный язык, отучит программистов думать головой. И когда она откажет или её научатся обходить, сериал про терминаторов перестанет быть фантастикой...
По такой же логике ремни безопасности и подушки отучают водителей думать головой. Да и вообще паровой двигатель был вершиной, когда водители вовсю головой думали. Аварий среди 10 автомобилей было 0%, а уж какие умелые были гонщики!
Хахаха! А типа они сейчас думать умеют?
Посмотри на последние уязвимости от лучшых пограммистов
opennet.ru/opennews/art.shtml?num=61229
"Просто решили длины массива подкрутить на ходу, а потом запутались"А можно вспомнить эпичный калище от дидов
"Уязвимости в библиотеках X.Org, две из которых присутствуют с 1988 года"
opennet.ru/opennews/art.shtml?num=59906Или это
opennet.ru/opennews/art.shtml?num=59867
Split строки это настолько сложная штука, что в каждом проекте приходится пилисть велосипеды.В общем эмпирическое правило "СИшники овнячат. Овнячат всегда"
Для безопасного программирования следует использовать SPARK: https://en.wikipedia.org/wiki/SPARK_(programming_language)
и Ada на которой Spark основан
> и Ada на которой Spark основани все это в Solaris
AdaCore переметнулась к Rust'у - выпустила GNAT Pro for Rust.
https://www.adacore.com/gnatpro-rust
и стала серебряным спонсором фонда Rust. Такие дела.
Oh No! Anyway
Хотя для кого-то это вошло бы в "топ-10 аниме предательств"))
Будет смешно если в спарк будут удачные идеи из раста перетягивать.
Ошибки никогда не должны замалчиваться.
Если они не замалчиваются явно.Дзен Питона.
"Можно сделать защиту от дурака, но только не от изобретательного" (пословица про Rust)
> Для выявления проблем в коде, выполняемом в контексте "unsafe", проектом развивается интерпретатор Miri, позволяющий определять обращения вне границ буферовЖдём тулзы, которая будет формально доказывать корректность unsafe кода. Лучше не только unsafe, а вообще. Чтоб можно было бы написать в реализации Vec, что len <= size, и что ptr.is_null() => size == 0, и получить формальное доказательство того, что эти инварианты не нарушаются. Причём по всей кодобазе, а не только по коду slice.rs, потому что у Vec есть unsafe метод from_parts.
Все эти интерпретаторы, тесты и проч, вообще не убеждают в корректности, только формальные методы, только хардкор.
Coq уже написали.
А кто проверит сам coq код валидации. Кроме того написать код на coq для чего не элементарного не так просто. Более того всем известно что в реальных проектах основные ошибки происходят на стыке систем с интеграцией, а не в обычных алгоритмах, которые легко покрываются юнит-тестами.
и тем не менее, лично я всё равно выбираю Раст, а не С++!
А лично я выбирают Cи!
Выбираю язык D , остальные могут только подворовывать с языка одновременно дебаггера
F# и Хаскель смотрят на вас как вы сами знаете на что.
как на гуру
Вот про дебаггер не распарсил.
О, кстати, а есть где русскоязычная тусовка по D, живая? А то что-то поисковики не очень информированы.
В телеге
Ссылка если что на дланг.ру есть
> я всё равно выбираю РастТеперь понятно, почему язычок программирования (rust) и марка пива (The Rust) называются одинаково.
Кстати, "РасТ" (RasT) - еще одна марка пива.
20/80 - правило Парето в действии
Вот честное слово, дался всем этот синтаксис! Язык, если это не Brainfuck и подобные, не может быть нежизнеспособен из-за синтаксиса. Это вообще последнее, к чему можно придираться в языке. Уж насмотрелись всяких синтаксисов, казалось бы. Даже на Перле все когда-то писали, а уж противоестественнее синтаксис придумать трудно, одна конструкция die-unless -- бессмертный шедевр, рождённый под грибами.Идеи Раста интересные, привыкать только сложно к ним. И насколько они взлетят, это вопрос. И не переразрастётся ли язык. Но пока очень даже живёт.
А то, что unsafe используется -- так вроде весьма дозированно, так, в сущности, и надо, 99% кода [условно] безопасно, 1% явно опасного аккуратно помечен.
> дался всем этот синтаксис!Если нормальных агрументов не осталось, то приходиться "докапываться до орфографии".
Но я вполне допускаю, что местная си-ылита, которая смогла осилить только C99, уже просто не в состоянии выучить что-то новое.
А тут на горизонте маячит перспектива быть замененым молодыми програм мерами и быть отправленным работать дворником.
Естественно они агрятся.
Если у раста нет нормальным достижений надо докапываться до сишки. Это всегда так убого смотрится.Может вместо докапывания до сишки просто напишите нормального софта на расте? Тогда ни у кого не будет вопросов. Вон на го просто переписано и написано уже все что угодно. А по безопасности работы с памятью го делает раст на несколько порядков.
> Если у раста нет нормальным достижений надо докапываться до сишки.К сишке нужно было докапываться еще до создания раста. И приводить с++ как отличную замену.
Потому что прошло 40 лет, а писаки на богомерзкой так и не научились не портить память.> А по безопасности работы с памятью го делает раст на несколько порядков.
И тормозит из-за GC примерно на столько же)))
> которая смогла осилитьИспользование тех или иных возможностей зависит от задачи. Глупо гордиться знанием 17 языков в их последних вариантах и не написать ничего путного. С другой стороны, на Кернигане-Ритчи можно сделать эффективные и полезные вещи.
Не пишет никакая "молодая элита" на Русте.Молодая элита пишет на C#, Kotlin, PHP, Javascript.
Rust это какая-то странная niche within a niche.
Может ты покажешь класс и с этим синтаксисом перепишишь фаерфокс на раст?
Да, ничего за 30 лет не изменилось. Та же логика «мой язык лучший», как когда я был частью этого детсада (к сожалению, с той поры прошло очень много лет).К слову, я совсем не Растер. Я с любопытством наблюдаю за данным языком, но большую часть жизни я писал на C++, а начинал в 80-е на C. Современный C++ мне глубоко несимпатичен из-за того, что он нездорово разросся. И если это начинает говорить человек, осиливший шаблоны Александреску и умевший их применять, это очень тревожный звонок. Да, новые тропки в C++ позволяют передвигаться по-новому. Но кучу легаси мусора никуда не деть ещё 100500 лет. Что касается C, то это совершенно гениальный язык, один из лучших, когда-либо созданных, простой, стройный и компактный. Только за 50 лет он немного морально устарел и не соответствует современным задачам и проблемам. В нём, извините, до сих пор торчат уши способов адресации процессоров DEC, которых уже лет тридцать как нет ("*++p1 = *++p2" -- это именно оно, если кто не понимает, оно позволяло некоторые конструкции в условиях, когда оптимизаторы были тупые, перевести в эффективные команды; только сейчас это анахронизм, пусть и давно привычный нам).
При этом ни один нормальный человек (а не школота, доказывающая, что «мой язык лучший») не скажет «C надо выбросить». Никто его пока не выбросит, и долго ещё не выбросит, туда вложены миллионы человеко-лет. Но работа по созданию чего-то нового идти должна. Раст — интересная попытка. Я совсем не уверен, что она будет удачной в том плане, что Раст станет заменой C. Но он позволил попробовать новые принципы написания безопасного кода, в этом качестве он мне симпатичен. Его польза уже в этом. А что будет и как оно приживётся — дело пятидесятое. Это первый язык, в котором я увидел именно новые концепции впервые за много лет. За что честь ему и хвала. Но это совершенно не значит, что он будет так же успешен, как C.
> Да, ничего за 30 лет не изменилось. Та же логика «мой язык лучший», как когда я был частью этого детсада (к сожалению, с той поры прошло очень много лет).Думаю так будет всегда)
> Современный C++ мне глубоко несимпатичен из-за того, что он нездорово разросся. И если это начинает говорить человек, осиливший шаблоны Александреску и умевший их применять, это очень тревожный звонок. Да, новые тропки в C++ позволяют передвигаться по-новому.
А что вы думаете по поводу нововедений? Типа классов-наследников или рекурсивных лямбд?
Ну и всяких самртпойнтерах и прочих фишках управления памятью?> Но кучу легаси мусора никуда не деть ещё 100500 лет.
Отчасти потому что это долго и дорого, отчасти "работает не трогай", отчасти потому что люди не хотят переучиваться (тк это требует немалых усилий)
Если бы С++ решили, на какой-то версии не тянуть обратную совместимость, то могли бы осовременнить язык. Но они сами выбрали тащить этот крест)
Хотя СИ это касается даже в большей степени, тк ядро линукс.> Что касается C, то это совершенно гениальный язык, один из лучших, когда-либо созданных, простой, стройный и компактный.
Был. В самом-самом начале. Потом был период, когда каждый пилил кучи компиляторов, несовместимых друг с другом, а потом это все дружно пилили "стандарт" в котором, чтобы никого не обидеть, оставили кучу дыр типа "разберетесь на месте".
В итоге получается парадоксальная ситуация, что один код, компилируемый двумя компиляторами (а иногда даже одним, но разных версий) выдает разные результаты.> Только за 50 лет он немного морально устарел и не соответствует современным задачам и проблемам.
И к сожалению, многие это не хотят принять.
Отсюда и подобные, хм споры в комментариях.> При этом ни один нормальный человек (а не школота, доказывающая, что «мой язык лучший») не скажет «C надо выбросить». Никто его пока не выбросит, и долго ещё не выбросит, туда вложены миллионы человеко-лет.
Не слышал такого. А вот "давайте заменим самые багованные или критичные части кода, или хотя бы то что можем" - такое слышал часто. (И кстати там не всегда речь шла о Расте)
> Но это совершенно не значит, что он будет так же успешен, как C.Не будет, на 99%.
Т.к если раньше на СИ писали все, от ядра до прикладных приложений, то сейчам прикладное проще и быстрее написать на электроне.
Бизнес ушел на джаву, на винде есть сишарп, на яблочной платформе - свифт.
Просто нишы уже заняты)
А посмотрим, что тут скажешь. Новые фичи C++ как бы и хороши (впрочем, я не тонкий их знаток, это во времена шаблонов Александреску, с появления которых в проде прошло 20+ лет (как идеи -- лет 25), мне было очень интересно, как можно извернуться ещё. Тогда C++ был языком уже большим, но ещё охватываемым нормальным разработчиком прикладного софта, а не только создателями компиляторов C++ (для последних знание стандарта -- работа и навык из предметной области). Теперешний для обычного разработчика практически неподъёмен, люди протаптывают тропки, но не понимаю всей картины. Раньше это было свойственно посредственным разработчикам. Теперь уже и реально хорошие только торят тропки.C стар. Его трудно оптимизировать, он слишком сфокусирован на "как сделать", а не "что сделать", даже эффективный статический контроль очень проблематичен. Но миллионы человеко-лет не выбросить.
А переучиваться -- да, обычно люди не любят. Вообще жизнь не настолько длинная, да и фокус интересов в ней склонен смещаться к более высокоуровневым вещам, чтобы переучиваться регулярно. Например, в какой-то момент может перестать хотеться писать код не потому, что не можешь, а потому, что тебя больше интересует, как взаимодействуют люди в ходе процесса, чем все эти битики. :-) Век разработчика, именно пишущего код, часто недолог. Лет 15-20 после достижения нормального профессионального уровня. Со сменой поколений всё устаканится.
> И если это начинает говорить человек, осиливший шаблоны Александреску и умевший их применять,Ты сильно выдаешь это фразой обыкновенного джуна, ошпарившегося плюсами и начитавшийся книжек. Матерый плюсовик смотрит на "шаблоны Александреску" как на медийную возню. Плюсы хороши, и применять их нужно так, как применял тот же Александреску в своем рабочем коде, а не в своих книжках для малолеток.
> Ты сильно выдаешь это фразой обыкновенного джуна, ошпарившегося плюсами и начитавшийся
> Плюсы хороши, и применять их нужно так, как применял тот же
> Александреску в своем рабочем коде, а не в своих книжках для
> малолеток.Угу, угу, расскажи это разработчикам boost и STL. Видимо, половину их малолетки писали, по твоей-то логике. У этих шаблонов была своя ниша. И в некоторых местах им было не место, а в некоторых это был основной способ сделать кое-какие вещи без потерь производительности. И джуны это не осиливали нормально даже после прочтения книжек, применяли где попало ради эксперимента и рассказывали потом всем, что так ничего не сделать, как ты. Но это именно они не смогли. Реально понять списки типов и область их обоснованного применения (а не воткнуть три шаблона друг в друга неясно зачем) было вполне senior задачей.
>Угу, угу, расскажи это разработчикам boost и STL. Видимо, половину их малолетки писалиДа. Именно половину, именно малолетки. Руки оторвать им за ту половину кода на плюсах, который в бусте и как следствие в stl. Нельзя так на плюсах писать. Именно вот из-за таких плюсы прослыли так, как прослыли среди публики.
> "*++p1 = *++p2" -- это именно оно, если кто не понимает, оно позволяло некоторые конструкции в условиях, когда оптимизаторы были тупые, перевести в эффективные команды; только сейчас это анахронизм, пусть и давно привычный намЭто борьба с компилятором.
> Это борьба с компилятором.А просто компиляторы ещё в 80-е были тупы, как барабан. Нужно было поминутно писать a+a вместо a*2 и a>>1 вместо a/2. И «правильная» форма реально работала быстрее. Но сейчас любой нормальный компилятор оптимизирует лучше, чем человек, когда пишет на ассемблере, и смысла в подобных конструкциях весьма мало. А то это напоминает советские программируемые калькуляторы, на которых для возведения в третью степень использовали ВВЕРХ Fx**2 *, поскольку это работало много лучше и быстрее, чем возведение в произвольную степень. Тогда казалось естественным, а по сути — каменный век.
Какое железо, такая и программа.
> Язык, если это не Brainfuck и подобные, не может быть нежизнеспособен из-за синтаксиса. Это вообще последнее, к чему можно придираться в языке.Если это последнее, то первое, что ли, востребованность? OH SHI~, найден удивительно хороший язык - 1C.
Лучше уж про синтаксис (в котором тоже заложены определённые идеи), чем про жизнеспособность.
>die-unless -- бессмертный шедевр, рождённый под грибами"выйти, если не" - вполне естественная логика.
Под грибами пишут дженерики и прочее метапрограммирование. И попробуй кому сказать, что эта дрочба является исключительно борьбой с типизацией, никакого смысла в ней нет.
>>die-unless -- бессмертный шедевр, рождённый под грибами
> "выйти, если не" - вполне естественная логика.
> Под грибами пишут дженерики и прочее метапрограммирование. И попробуй кому сказать, что
> эта дрочба является исключительно борьбой с типизацией, никакого смысла в ней
> нет.Синтаксическая конструкция для указания негативного условия, вычисляемого до действия, но располагающегося после — это крайне необычно и немного вразрез с традициями большинства языков, привычный к более традиционным решениям взгляд поначалу за это цепляется. Но и это не является проблемой. Именно как пример того, что даже крайне необычные синтаксические конструкции языка не являются бедой. Это ни для кого не проблема и не помешало Перлу быть в своё время популярным. Необычность раста вообще не в синтаксисе, а в непривычной концепции владения.
> Вот честное слово, дался всем этот синтаксис! Язык, если это не Brainfuck
> и подобные, не может быть нежизнеспособен из-за синтаксиса. Это вообще последнее,
> к чему можно придираться в языке.А спорим на лям, что я быстрее изучу, до уровня написания статей про народные танцы этих стран,
болгарский, сербский и испанский языки, чем ты один китайский.А OOП-программирование это вообще не програмирование, а конструктор хотелок для девочек
1 из 1000 ООП-задротов осилит написать ф-цию (q)sort() (без гугла)
А глянь-ка на терминологию: «Синтаксис языка программирования — набор правил, описывающий комбинации символов алфавита, считающиеся правильно структурированной программой (документом) или её фрагментом. Синтаксису языка противопоставляется его семантика.»90% конструкций в современных языках — примерно одни, реальных различий в их сути процентов так 10. Ну да, где-то отступы, где-то фигурные скобочки, где-то ещё непонятно что. И именно это — полная ерунда, она выучивается за считаные часы и просто не может быть проблемой.
Проблемы с освоением Rust — вообще не про синтаксис, а про привыкание к концепции владения, это то, на чём поначалу реально клинит. Действительно ли эта концепция нужна в таком виде, покажет только время и её приживаемость. Возможно, придумают что-то другое и более привычное. А возможно, она всё-таки приживётся (необязательно в самом Rust и в неизменном виде). И вот на это можно посмотреть. Но новые концепции давно нужны, да и всегда их нужно искать, даже понимая, что 99% идей никогда не приживётся.
Про ООП-за....в — прямо прослезился. Но судя по задаче про qsort, ты примерно из моего поколения, небось и узкие места данной сортировки знаешь и способы их обхода. :-) Молодёжь это обычно уже не умеет, как и отлаживаться в ассемблерном окне (про то, чтобы писать самому на чистых ассемблерах, и не говорю, этого и мне лет 20 почти не приходилось, только для микроконтроллеров, и то мало). Но это мы — мамонты, а не они идиоты. Хотя иногда они творят смешные вещи. :-)
> И именно это — полная ерунда, она выучивается за считаные часы и просто не может быть проблемой.Иногда просто по привычке пишешь, а оно ругается. И это некоторых бесит)
> Проблемы с освоением Rust — вообще не про синтаксис, а про привыкание к концепции владения, это то, на чём поначалу реально клинит.
Напоминает старые-добрые времена, когда я решил освоить хаскель, для общего развития.
И новые концепции немного ломали мозг.
Но потом привык, хотя сказать что они стали "нравиться" не могу.> Действительно ли эта концепция нужна в таком виде, покажет только время и её приживаемость. Возможно, придумают что-то другое и более привычное. А возможно, она всё-таки приживётся (необязательно в самом Rust и в неизменном виде).
Она может прижиться даже если будет не идеальной.
Просто внедрять что-то новое будет дольше и дороже.> И вот на это можно посмотреть. Но новые концепции давно нужны, да и всегда их нужно искать, даже понимая, что 99% идей никогда не приживётся.
Довольно необычная философия, для человека который в программировании уже давно.
Обычно за новым и "давайте попробуем" бегут молодые у которых и времени побольше и сил.> Но судя по задаче про qsort, ты примерно из моего поколения, небось и узкие места данной сортировки знаешь и способы их обхода. :-)
Странно, даже лет 10 назад это преподавали в вузах.
Не буду ручаться, что даже половина моих сокурсников вообще что-то помнит с тех лекций, но это уже другой вопрос.
Сомневаюсь, что современная программа так сильно поменялась.> Молодёжь это обычно уже не умеет, как и отлаживаться в ассемблерном окне (про то, чтобы писать самому на чистых ассемблерах, и не говорю, этого и мне лет 20 почти не приходилось, только для микроконтроллеров, и то мало).
Думаю если взять вчерашнего студента, замотивировать его каким-то образом, то он вполне ассемблер освоит.
Другой вопрос, что оно ему может быть совершенно не интересно.> Но это мы — мамонты, а не они идиоты. Хотя иногда они творятсмешные вещи. :-)
О, мы тоже иногда творили смешные вещи.
Зато есть чего рассказать на тему "мои самые большие факапы в программировании" 😁
> Довольно необычная философия, для человека который в программировании уже давно.Обычно за новым и "давайте попробуем" бегут молодые у которых и времени побольше и сил.
Если говорить о том, что бы я выбрал для проекта, который должен жить долго, то я бы выбрал умеренно консервативно. Что-то, что точно не засохнет лет за 10-20.
Но когда люди хотят создавать новые проекты, реализовывать на пробу свежие идеи, это надо поддерживать. Если новое и непроверенное будут пихать в упомянутый долгоживущий проект как основу, я буду мешать. :-) Если в отдельной песочнице и не будет создаваться преждевременная глубокая зависимость от технологии -- вперёд, я только за. Нельзя ничего не менять всю жизнь и нельзя вечно ходить кругами. Метаться за каждой модой тоже, впрочем, нельзя.
Где-то я это уже видела.... А! вот! берем базу языка (например статическую типизацию) и начинаем с ней всеми силами бороться (коSTLи C++). Главное, что ничего нового. На этом и спасибо!
Ну это показательно, 20% библиотек, которые реально делают что-то полезное столь-же "безопасны" как чистые С/C++/Ассемблер. Остальные 80% - никому ненужный мусор, причём тормазнутый из за всяческих проверок в рантайме, поскольку по-другому safe раст просто напросто не работает.К сожалению, над этим остаётся только посмеяться. Ведь растолюбителей аргументами и логикой не переубедить. Для них всё равно раст будет "безопаснее", ну потому что ведь так в описании языка написано, но вот и всё, шах и мат плюсеры.
Ну а для чего тогда раст вообще нужен, если всё равно нужно всё писать в unsafe режиме? - вопрос риторический, те у кого голова на плечах уже давно всё поняли. Ни один проржавевший серьёзно на этот вопрос ответить не может. А может только апеллировать к выбору крупных софтверных контор, которым нужно в промышленных масштабах извергать тонны энтерпрайз гов.. софта :3
В это же время C++ развивается, не заставляя переписывать всё и вся, добавляются фишки для обеспечения безопасности. При этом, в отличии от растолюбов, никто не занимается дутым дилетантством и не пытается обманывать пользователей языка, обещая что "у нас тут всё safe". Вместо этого профессионалы просто пишут код, достаточно времени уделяя его тестированию.
Время идёт, но ничего так толком не изменилось. Проржавевшие всё ещё собираются всё переписать и заменить, но при этом будущее неизменно остаётся за C++
Будущее уже наступило, zig пришёл.
Спокойно, это конец.
"Вместо этого профессионалы просто пишут CVE, достаточно времени уделяя его тестированию чтобы десятки лет никто их не замечал"Исправил, не благодари.
> Ну это показательно, 20% библиотек, которые реально делают что-то полезное столь-же "безопасны" как чистые С/C++/Ассемблер. Остальные 80% - никому ненужный мусор, причём тормазнутый из за всяческих проверок в рантайме, поскольку по-другому safe раст просто напросто не работает.Твоя кекспертность поражает воображение!
Особенно в том как работает безопастность раста.> К сожалению, над этим остаётся только посмеяться. Ведь растолюбителей аргументами и логикой не переубедить. Для них всё равно раст будет "безопаснее", ну потому что ведь так в описании языка написано, но вот и всё, шах и мат плюсеры.
> Ну а для чего тогда раст вообще нужен, если всё равно нужно всё писать в unsafe режиме? - вопрос риторический, те у кого голова на плечах уже давно всё поняли.Типичная манипуляция, argumentum ad populum.
> Ни один проржавевший серьёзно на этот вопрос ответить не может. А может только апеллировать к выбору крупных софтверных контор, которым нужно в промышленных масштабах извергать тонны энтерпрайз гов.. софта :3
Но приведу тебе пример, ну твоего уровня, чтобы даже ты понял.
Люди в доме иногда кушают, это процесс необходимый, солнышком питаться пока не научились.
Но после этого они еще и какают, от этого тоже не избавиться.
Так вот, людит делают это в специально отведенных местах. Ну чтобы какахи не воняли.
Unsafe это как раз про то, чтобы собрать опасный код и повесть на него ярлык "опасно!".
А вот с/с++ники размазывают опасный код по всему проекту, по себе, по другим проетам.
Это можно посмотреть по кол-ву тупейших CVE уровня "не смог сделать сплит строки"> В это же время C++ развивается, не заставляя переписывать всё и вся, добавляются фишки для обеспечения безопасности.
Которые нифига не работают.
Вон попробовали сделать MiraclePtr, но чуда ЧСХ не произошло
opennet.ru/opennews/art.shtml?num=60482> При этом, в отличии от растолюбов, никто не занимается дутым дилетантством и не пытается обманывать пользователей языка, обещая что "у нас тут всё safe".
Опять манипуляция. Ты явно не читал rustbook.
> Вместо этого профессионалы просто пишут код, достаточно времени уделяя его тестированию.
Ты хотел сказать овнокод?
> Время идёт, но ничего так толком не изменилось. Проржавевшие всё ещё собираются всё переписать и заменить, но при этом будущее неизменно остаётся за C++
Вон гугл уже начал замечать, что полюсовики работают спустя рукава
Rust developers at Google are twice as productive as C++ teams
theregister.com/2024/03/31/rust_google_c/Далее они посчитают денежку и выгонят всю эту бесполезную шоблу на мороз.
Unsafe - это не ярлык с пометкой, это инструкция которая реально оключает кучу всего. И какой дурень будет анализировать в твоих простынях кода, где ты там что сделал и зачем.
> Unsafe - это не ярлык с пометкой, это инструкция которая реально оключает кучу всего. И какой дурень будет анализировать в твоих простынях кода, где ты там что сделал и зачем.Чиво? Что значит не будет анализировать?
А если бы код был на любом другом языке, то ты бы тоже сказал "зачем понимать как оно работает"?В любом проекте придется сначала разобраться, потом исправить, а потом пройти тесты, CI/CD.
(Это не касается поделок типа ядра линукс, куда можно отправить патч по почте, который даже не собирается. И всяким Торвальдсам приходится бухтеть
lore.kernel.org/dri-devel/CAHk-=wgPJttFz8yrdpPTN-ypMmDXHOKw9yi1nZSEq+7+tGftZA@mail.gmail.com/ )Если ты добавил unsafe, то на ревью однозначно возникнет вопрос "зачем оно здесь? нельзя ли обойтись без него".
Можно добавить [forbid(unsafe_code)] и запретить использование unsafe вообще.
Любителям c++ желаю всю жизнь писать make портянки и использовать компилляторы которые не совместимы между собой и спустя 3 года до сих пор не поддерживают полностью 20 стандарт
Как любитель Си, да и С++ тоже, хочу заметить: Makefile написанный мной достаточно компактный, плюс работает везде (Linux, Windows, Mac, *BSD) и всегда. В отличии от ваших этих IDE, nmake-ов, cmake-ов и тому подобного. А если где-нибудь в NASA тебя угораздит заикнуться про 20й стандарт, то тебе быстро и доходчиво объяснят что ты ебобо и стандарт, которому меньше 30 лет, - это не стандарт, а поделка школьников))
> Как любитель Си, да и С++ тоже, хочу заметить: Makefile написанный мной достаточно компактный, плюс работает везде (Linux, Windows, Mac, *BSD) и всегда.Значит у тебя просто какой-то хеллоуворлд на перу страничек текста.
> В отличии от ваших этих IDE, nmake-ов, cmake-ов и тому подобного.
Конечно, каменный топор остается надежным, но им почему-то мало кто хочет пользоваться.
Хотя если честно, cmake это тоже окаменелость.
> А если где-нибудь в NASA тебя угораздит заикнуться про 20й стандарт, то тебе быстро и доходчиво объяснят что ты ебобо и стандарт, которому меньше 30 лет, - это не стандарт, а поделка школьников))О, дундука видно издалека!
У них вертолетик на марсе летает под управлением с++ и питона.
(github.com/nasa/fprime)
Так что если им захочется, то запросто будут использовать и раст и джаваскипт.
так ведь он уже долетался - тормознул походу насовсем
> так ведь он уже долетался - тормознул походу насовсемС одной стороны да. С другой - планировалось что он сделать 5 полетов до 90 секунд и на высоты 3-5 метров.
А по факту он налетал больше двух часов за 72 полета и подымался на 24 метра.
Так что вертолетик отработал более чем хорошо)) И это все не на space-grade электронике.
А если использую едиственный компилятор g++? То как-то нет проблемы несовместимости компиляторов. По версиям совместимы снизу вверх.
То рано или поздно борода в костюме антилопы снова решит прикольнуться и издаст указ что всё им компильнутое автоматом становится под его раком, например. Или столь же весёлое мероприятие организует.
Вижу обильное комментирование от поклонников раста. Как минимум равенство, а то и превышение по количеству реплик под новостями.
Тем временем на хедхантере вижу 53 вакансии на раст, из них в Москве 26 (двадцать шесть). Это у которых rust в заголовке. Не "было бы плюсом", "забавно, если вы имели опыт", а именно разработка на расте.
В той же выборке python 1296 вакансий, плюсы 1195, java 2139.Итого: растовик не пригоден к разработке. Он занят комментированием. Ведь это равенство в комментариях надо как-то объяснить. Хорошей недели, колеги.
rust - 9 лет назад 1.0 вышел
go - 14 лет назад 1.0 вышел
flatter - 7 лет назад stable вышел первый
python - 33 года назад stable вышел первый
c++ - 39 лет назад stable вышел первый
c - 52 года назад stable вышел первыйНе разу не предвзятое сравнение у вас конечно, где сравниваете молодой язык и нет, rust корректно сравнивать по популярности только с dart и другими ровесниками
и как можно сравнивать системный язык с dart?
А как можно сравнивать языки которым за 30 лет и язык которому 10 лет не стукнуло?)
> А как можно сравнивать языки которым за 30 лет и язык которому
> 10 лет не стукнуло?)Жаль, что та схема,по которой вы ответили, почти не проходит у разработчиков.При решении проблемы "падает приложение Х" очень трудно ответить "приложение У не падает, работает корректно". Бывает такое: "да, Х упал, ибо У был настроен некорректно". Но тут вы подменили тему, придумали мне тезис и его азартно опровергли. Вы не разработчик.
Как раз таки вы в своём ответе подменили тему, в ответе моём а, вы пишите б не связанное с ним (A это что кодовая база уже написанная важна, стабильность и инфраструктура важна, да и не кто не будет пересаживаться раньше времени на пока ещё молодой язык, меняются стек очень не охотно в проектах, если это не ts на js или в таком духе). Ну, деньги за написание кода я получаю? Получаю, чем я не разработчик тогда?)p.s: На C# СЕЙЧАС пишу, вы сами то разработчик раз рассуждаете на эту тему и других критикуете или мимо проходили просто и только hello world писали? Опыт хоть пару лет в программировании или нет?)
Можно было начать с зарплат плюсовиков и этим закончить. (Огромные.)
И? Я, например, знаю контору, где готовы брать сеньоров C++, Java или Python, на соответствую зарплату (5-7K USD, что выше рынка, это в ЮВА), но программировать в итоге на Go. Но они не размещают вакансию на Go (ну то есть тоже может размещают), потому что рынок, мнение HR и прочее такое, что они пишут Python в вакансиях, а дальше предлагают такой вариант, предлагают 2-3 дня поизучать про Go и выполнить простое задание, если интересно, они готовы брать, обучать и будешь Go-программистом.
Хотя это от человека что пишет сейчас только на c# и не работал с rust, но всё же...
> Тем временем на хедхантере вижу 53 вакансии на раст, из них в Москве 26 (двадцать шесть). Это у которых rust в заголовке.Ты ж понимаешь, что далеко не все находятся в москве и вообще в рф?
> Не "было бы плюсом", "забавно, если вы имели опыт", а именно разработка на расте.
> В той же выборке python 1296 вакансий, плюсы 1195, java 2139.Так посмотри еще жаваскипт, пыху и одын-эсс.
Уверен там их будет еще больше.
Но вопрос в другом "а хочешь ли ты пистаь проект на них"> Итого: растовик не пригоден к разработке. Он занят комментированием.
Маrсимально глупый вывов. Сова просто лопнула на глобусе.
> Ведь это равенство в комментариях надо как-то объяснить. Хорошей недели, колеги.
Знаешь, есть такая вещь, Интернет называется.
Которая позволяет человеку с одной половинки земного шара, общаться с людьми с другой.
> В той же выборке python 1296 вакансий, плюсы 1195, java 2139.Это говорит о том, что никто не хочет писать на пайтоне, плюсах и жабе: вот сколько вакансий открыто.
>> В той же выборке python 1296 вакансий, плюсы 1195, java 2139.
> Это говорит о том, что никто не хочет писать на пайтоне, плюсах и жабе: вот сколько вакансий открыто.Ну такое...
Сейчас есть много вакансий "работа на свежем воздухе, от 300к", но очередей не наблюдаю.
Может те проекты на плюсаъ и питоне такие отстойные, что народ никакими коврижками не заманить.
Вакансии публикуют HR'ы, чтобы изображать свою бурную деятельность перед руководством. Но если вакансия быстро закроется, то HR сам останется без работы. Поэтому, в основном эти вакансии липа или потеря времени. Количество публичных вакансии можно смело поделить на 5, а то на 10, это и будет число реально нужных спецов. Хуже HR только журнaлюги.
Маркетологи хуже всех.
> Most of these Unsafe Rust uses are calls into existing third-party non-Rust language code or libraries, such as C or C++. In fact, the crate with the most uses of the unsafe keyword is the Windows crate [7], which allows Rust developers to call into various Windows APIs.В общем unsafe в основном в ffi, ничего страшного короч
>unsafe в основном в ffi, ничего страшногоНу да. Но как же любо смотреть, как корежит от Раста этих бесов плюсистов (двойной крест, как известно, сатанинский символ).
> Ну да. Но как же любо смотреть, как корежит от Раста этих
> бесов плюсистов (двойной крест, как известно, сатанинский символ).Валера, не нагнетай! (с)
Вообще кажется что бомбит больше у сишников, тк ядро, раст, драйвера...
У плосовиков есть огромные ниши типа геймдева (объективно раст для игр не очень удобен) для которых уже написанны тонны движков.
Плюс винда, плюс юзерские приложения.А вот сишку уже даже с микроконтроллеров потихоньку вытесняют.
Сейчас писать на плюсах под какой-то СТМ32 уже вполне норма.
>Вообще кажется что бомбит больше у сишников, тк ядро, раст, драйвера...Ну это странно, потому что Rust, считаю, не является конкурентом Си. Rust больше "играет на поле" C++ — создание больших сложных систем без лишнего оверхеда и с удовлетворительной сопровождаемостью. Вряд ли целесообразно писать простые драйвера на Расте (хотя сама возможность крута). Прямой конкурент Си — скорее Zig.
Я вам больше скажу, в std библиотеке unsafe код xDНо а по другому никак
> Я вам больше скажу, в std библиотеке unsafe код xD
> Но а по другому никакВсе верно.
Но есть разница "у нас unsafe в std" и "у нас unsafe в std и вообще везде"
Маленькая, но очень существенная)
Unsafe нужен, чтобы выйти за грань шаблонного поведения. А то так и будете в границах!
> Unsafe нужен, чтобы выйти за грань шаблонного поведения. А то так и будете в границах!В границах массива?
Ну так это неплохо.Но если ты хочешь выйти из шкафа, то можешь.
Думаю никто из анонимов тебя не осудит.
Шикарное мастерство заготовка
"В каждом пятом пакете на языке Rust используется ключевое слово unsafe"!
Мрак, ужас!А ведь можно было бы написать
> "В четырех из пяти пакетов на языке Rust ключевое слово unsafe не используется"или
> "Ключевое слово unsafe используется только в 20% пакетах на языке Rust"И звучит совсем по-другому)))
>В четырех из пяти пакетов на языке Rust ключевое слово unsafe не используетсяпотому что все они используют пятый пакет, в котором unsafe.
>>В четырех из пяти пакетов на языке Rust ключевое слово unsafe не используется
> потому что все они используют пятый пакет, в котором unsafe.Именно! Поэтому нужно направить взгляд тысячи глаз на этот пакет, проверить его и сделать идеальным.
А не размазывать потенциально уязвимый код ровным слоем по всем проектам.
к сожалению, есть только тысяча ртов