ЯЗЫК ПРОГРАММИРОВАНИЯ RUST УПРОЩАЕТ РАЗРАБОТКУ БОЛЕЕ БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ЧТО ЕЩЕ ПРЕДСТОИТ СДЕЛАТЬ?
Допустим, вы пишете почтовый клиент на С++. Ваше новое приложение будет применяться на рабочей станции, ежедневно используемой несколькими разными людьми. Но где-то по ходу дела вами была допущена ошибка. Работники, посылая друг другу специально изготовленное сообщение, могут вызвать переполнение буфера в памяти приложения и отправлять команды, позволяющие извлекать письма из почтовых ящиков других пользователей.
Такой баг с переполнением буфера – классический образец проблемы с памятью, а проблемы с памятью – одни из наиболее типичных при разработке программного обеспечения. Около 70% всех проблем с безопасностью, устраненных в продуктах Microsoft в период с 2004 по 2018 год, были связаны именно с памятью, как следует из презентации Мэтта Миллера из Центра реагирования на вопросы безопасности компании Microsoft, который рассматривает все проблемы безопасности, передаваемые в компанию.
Безопасность памяти – гигантская проблема. Операционные системы должны гарантировать, что в веб-приложениях не будет происходить взаимных утечек данных. Веб-браузер должен обеспечить, что веб-приложение, открытое в одной вкладке, не сможет заграбастать данные из другой вкладки. На облачных платформах необходимо сделать так, чтобы ни один пользователь не мог считывать данные другого пользователя.
“Безопасность памяти – проблема не только техническая, но и социальная,” – считает Джошуа Аас, исполнительный директор «Internet Security Research Group». - “из-за проблем с памятью получается не просто сбоящее программное обеспечение. Из-за них могут обрушиваться сервисы, которыми люди зарабатывают себе на жизнь или при помощи которых находят работу. Бреши в безопасности могут лишать нас приватности. Программы можно и следует писать более качественно.
В октябре 2020 года компания Internet Security Research Group запустила программу Prossimo, цель которой – продвигать безопасность памяти в Интернете. До сих пор одна из их ключевых инициатив связана с использованием языка программирования Rust, исходный код которого был открыт компанией Mozilla в 2010 году. На языке Rust гораздо легче писать код, безопасный с точки зрения памяти.
C, C++ и другие языки программирования, не требующие от разработчиков специально писать код для управления памятью программы, считаются «небезопасными для памяти», поскольку даже мелкие баги могут приводить к проблемам с безопасностью памяти. «Как бы ни были талантливы ваши разработчики, они все равно будут допускать ошибки», - говорит Аас, – «лучшие команды в мире, где работают самые компетентные системные программисты, то и дело допускают ошибки в области безопасности памяти. Просто посмотрите планируемые патчи безопасности практически для любого крупного проекта – и примеров найдется сколько угодно».
По словам Лоры Томпсон, вице-президента по инженерии в компании Fastly, занимающейся пограничными облачными вычислениями, «писать на С – все равно, что делать хирургию на мозге без помощи ассистента».
Давно было показано, что, когда пишешь программы на языках, безопасных с точки зрения памяти, устраняется целый класс уязвимостей из области безопасности. Тем не менее, код на C и C++ все еще повсюду. Операционные системы, сетевое программное обеспечение, веб-браузеры и аппаратные драйверы традиционно пишут на C или его объектно-ориентированном наследнике C++. С чем бы вы ни работали, Android, iOS, Windows, Linux или Mac, под капотом у них будет масса C/C++, несмотря на то, что во многих приложениях для них используются языки, обеспечивающие безопасность памяти – например, C#, Java и Swift.
На то есть причины. C и C++ быстрые. Надежные. Программисты уже умеют ими пользоваться, на них написаны тысячи свободно распространяемых библиотек, а также для них есть компиляторы, работающие практически с любым мыслимым чипсетом.
Prossimo фокусируется на безопасности памяти в целом, а не только на Rust. Но именно Rust, как никакой другой язык, наиболее в силах изменить статус-кво, сложившийся в системном программировании.
"Rust – это первый из множества новых языков, вошедших в практику примерно за 20 последних лет, действительно хорошо справляющийся с теми вещами, с которыми нам ранее многое не удавалось на C или ассемблере," – говорит генеральный технический директор Fastly Тайлер Мак-Маллен. – «Он очень производителен по части памяти, и у него убедительная система типов, позволяющая выражать высокоуровневые концепции на низкоуровневом языке». Плюс он хорошо взаимодействует с другими языками, способными работать на множестве платформ, от встраиваемых систем до серверов.
Причем, Rust усваивается. Он был признан “самым любимым” языком программирования в рамках опроса разработчиков, проведенного на Stack Overflow в 2021 году – пятый год подряд с тех пор, как вышел на первое место. Тем временем, он становится все популярнее в самых разных областях, от научных вычислений до проектов с открытым исходным кодом, например, Deno, это новая серверная JavaScript-платформа, созданная Райаном Далем, создателем Node.js.
В этом году Mozilla передала курирование Rust фонду Rust – это коалиция, основанная Amazon Web Services, Facebook, Google, Huawei, Microsoft и Mozilla. Это признак, что главные тяжеловесы нашей индустрии всерьез прочат Rust большое будущее.
Например, в Facebook более 100 разработчиков занимаются языком Rust, есть среди них и контрибьюторы, внесшие вклад в ядро языка. Facebook не отказывается и от других языков, но Rust используется в проектах по всей компании, в том числе, в блокчейне Diem, при разработке языка программирования Move и новой версии инструмента Buck. “Одна из основных целей, с которыми мы вступили в этот фонд – работать с другими его замечательными участниками, а также с сообществом Rust. Так мы поможем поддержке Rust еще эффективнее справляться с их отличной работой, чтобы Rust превратился в мейнстримовый язык системного программирования и не только,” – говорит Джоэл Марси, отстаивающий интересы свободной разработки в Facebook и входящий в совет директоров фонда Rust.
В настоящее время многие компании пользуются Rust, чтобы повысить безопасность своих облачных платформ; среди них - Amazon Web Services, Cloudflare, Fastly и Microsoft Azure.
"Еще пару лет назад меня эта идея не цепляла," - говорит Мак-Маллен. Но команда Fastly, работающая с WebAssembly, попросила выполнить пару проектов с использованием Rust, и Мак-Маллен был впечатлен как производительностью, так и безопасностью этого языка. Теперь Rust – ключевой элемент стека компании. "В принципе, все новое, что у нас сейчас делается на бекенде, написано на Rust," – говорит Томсон, - "Все вычислительные сервисы, при помощи которых наши клиенты запускают код, построены на основе Rust."
Цель, по словам Мак-Маллена – обеспечить безопасность памяти в масштабах всей плоскости данных. «Это среда такого рода, где нельзя доверять всем подряд», - говорит он, - «нельзя доверять входящему трафику, нельзя доверять коду, работающему на серверах. Если писать на таком языке как Rust, то проще обходиться без такого доверия».
AWS использует Rust в сетевых стеках многих своих сервисов, в том числе, EC2, S3 и CloudFront, сообщает Шейн Миллер, глава команды Rust Platform в Amazon Web Services. Облачная платформа построена в основном на базе свободно распространяемой контейнерно-ориентированной системы виртуализации Firecracker, написанной на Rust, а также на базе контейнерной операционной системы Bottlerocket, сделанной на основе Linux. "Rust быстро приобрел принципиальное значение для предоставления инфраструктуры в тех масштабах, с которыми работает AWS," – говорит Миллер.
Разрабатывать с нуля языки, обеспечивающие безопасность памяти – уже неплохо для начала. Но, чтобы привить безопасность памяти в масштабах всего Интернета, также потребуется рефакторинг старого программного обеспечения. Одна из самых амбициозных инициатив, связанных с Rust – добавление поддержки Rust под Linux, причем, это начинание пока не одобрил Линус Торвальдс, сообщивший ZDnet, что, когда речь идет о Rust, он предпочитает «посидеть и подождать».
Тем временем команда по адаптации Rust под Linux работает над тем, чтобы подружить Rust с ядром. Например, в стандартной библиотеке Rust предполагается, что при выделениях памяти никогда не возвращаются ошибки – данная концепция известна под названием «безупречное выделение». Если выделить память не удается, то процессы сразу завершаются. Загвоздка в том, что из-за этого могут возникать паники ядра – иными словами, операционная система полностью застопоривается в ответ на фатальную (с ее точки зрения) ошибку. Это плохая новость, если вы параллельно гоняете несколько рабочих нагрузок. Команда Rust под Linux, спонсируемая Google, недавно смогла обойти эту проблему при помощи собственноручно созданной Rust-библиотеки, но руководитель этого проекта Мигель Охеда надеется, что эта проблема будет устранена на более высоком уровне, в рамках самого языка Rust. «Мы уже начали этот процесс, и некоторые изменения уже приняты на уровне ядра», - написал он в почтовой рассылке по разработке ядра.
Если (и когда) Rust под Linux будет добавлен в ядро, это будет первый прецедент, когда в ядре Linux будет официально поддерживаться какой-либо язык кроме C или ассемблера, говорит разработчик ядра Грег Кроа-Хартман.
Linux – не единственная операционная система, в которой используется Rust. В 2019 году Адам Бёрч из команды разработчиков, развивающих в Microsoft систему Hyper-V, анонсировал у себя в блоге, что переписывает на Rust низкоуровневый системный компонент из базы кода Windows, но не сказал, какой именно. «Хотя проект пока не завершен, могу сказать, что опыт работы с Rust в целом положительный. Это хороший выбор для тех, кто хочет избежать распространенных ошибок, таких, что часто приводят к уязвимостям в базах кода на C++».
Все на Rust
Если вы решили сами попрактиковаться с Rust, то в сообществе предлагаются разнообразные ресурсы для изучения языка. Но предупреждаю: притом, насколько фанаты Rust любят этот язык, кривая обучения на этом языке очень крутая по сравнению с такими кривыми в других современных языках. «Разработчики сравнивают изучение Rust с вегетарианской диетой», - говорит Миллер, - «когда поймешь язык, он начинает нравиться, но обучение может получиться изнурительным. Поэтому я всегда стараюсь превратить брокколи в брауни. Чтобы учиться было классно».
Чтобы справиться с этой проблемой, Amazon Web Services приглашает на работу экспертов-преподавателей компьютерных наук, которые могли бы рассказать, как устроен этот язык. Некоторые приемы вполне тривиальны – например, добавить примеров кода в документацию. Есть и более сложные, которые, как рассчитывает компания, можно будет привнести в Rust – например, переосмыслить его компиляторы.
Но даже самым большим фанатам Rust до сих пор сложно представить, что на этом языке когда-нибудь будет переписан весь код, небезопасный с точки зрения памяти. Пройдет много времени, прежде, чем старый код выйдет из употребления, особенно, если он уже хорошо работает. Так, по оценке Томсона Рейтерса, в мире до сих пор в реальных сценариях используется около 220 миллиардов строк на COBOL, древнем языке, истоки которого восходят к концу 1950-х. Они обеспечивают работу около 43% банковских систем и 95% операций в банкоматах. Кроме того, в бизнес-приложениях во всем мире по-прежнему обычен Fortran.
Несмотря на это, не весь старый код на C/C++ требуется переписывать. «Мы не пытаемся взяться за тысячи проектов», - говорит Аас. – «Мы сосредоточились на критически важных компонентах, которыми пользуется практически каждый. Я говорю о веб-серверах, ядрах, TLS, DNS, NTP — базовом волокне, из которого сплетен Интернет».
«Бывает, что программу можно заменять компонент за компонентом», - объясняет Аас, - «можно заменить небезопасную с точки зрения памяти библиотеку на безопасную и постепенно повысить безопасность памяти в рамках всего приложения».
Отличный пример этого – работа Prossimo с программой Curl. Curl написана в основном на C, но Prossimo поддержала инициативу по добавлению в нее поддержки Rust-библиотек для поддержки сетевых технологий TLS и HTTP. Таким образом, можно использовать Rust для тех частей приложения, которые краешком затрагивают сеть, но не переписывать Curl целиком. Библиотеки на основе Rust не используются в Curl по умолчанию, но все, кому они кажутся предпочтительными, могут их включить. «Надеемся, что модули, безопасные для памяти, будут тестироваться, совершенствоваться, пока, наконец, не станут использоваться по умолчанию во всех крупных дистрибутивах Linux," – говорит Аас.
При этом есть способы изолировать в песочнице код, небезопасный для памяти, чтобы минимизировать связанные с ним риски. Например, в Fastly большая часть компонентов, основанных на C/C++, используется в среде исполнения WebAssembly, основанной на Rust. «Такой аккуратный способ перевести весь этот софт на Rust», - говорит Мак-Маллен.
Конечно же, нельзя устранить всех багов, в том числе, уязвимостей безопасности. Но совершенно реально избавиться от огромного класса проблем, связанных с небезопасностью памяти, просто подобрав подходящий язык. Rust становится все популярнее, поскольку этот язык не просто производительный, но и мощный, и открытый, и благодаря нему Интернет становится безопаснее для каждого.
Комментарии (111)
ozkriff
18.10.2021 11:05+7В оригинальном блоге первое предложение капсом смотрится нормально из-за особенностей оформления, но на хабре как-то неуместно. Превьюшки так вообще на агрессивный спам сразу похожи.
pexey40317
18.10.2021 11:53Несмотря на все преимущества Rust мне его синтаксис не нравится. Не идеи, именно синтаксис. И я очень жду когда выйдет стабильная версия языка Vlang. Язык намного проще и красивее, а идеи те же. Безопасное управление памятью и быстрое выполнение кода (если верить автору, то на уровне С т.е. немного быстрее Rust).
DarkEld3r
18.10.2021 12:23+4быстрое выполнение кода (если верить автору, то на уровне С т.е. немного быстрее Rust).
Чудес не бывает: если безопасность обеспечивается обязательными рантайм проверками (а язык обещает "Bounds checking"), то за это придётся платить производительностью. Плюс, если я правильно понял, то для объектов, время жизни которых нельзя вывести статически, используется сборщик мусора. Это может и практичный подход, но не очень в духе С. В расте большая часть "мусора" в синтаксисе как раз из-за лайфтаймов, а если нас устраивает сборка мусора, то можно взять другой язык.
Ещё про дженерики не совсем понял: получается, что они работают как шаблоны в С++? То есть, ограничения на тип выводятся из того как он используется? Если да, то это, на первый взгляд, позволяет облегчить синтаксис, но потом появляются штуки вроде
enable_ifи концептов. Не уверен, что финальный результат проще чем растовые дженерики.pexey40317
18.10.2021 12:36-1Подобно Rust, Vlang использует типы значений и строковые буферы для управления памятью, но не выполняет сборку мусора. Не знаю откуда Вы взяли про сборку мусора (возможно где то такое используется пока не вышла стабильная версия).
К сожалению с C++ дженереки уже не помню. Язык по простоте находится между Go и Python.DarkEld3r
18.10.2021 12:48+3Не знаю откуда Вы взяли про сборку мусора
Дык, прям на главной странице языка написано:Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC.
Подобно Rust, Vlang использует типы значений и строковые буферы для управления памятью
Это и в С++ прекрасно работает. Самое интересное начинается когда появляются ссылки.Язык по простоте находится между Go и Python.
В Go дженерики вот-вот должны завести и я бы сказал, что сложность языка после этого вырастет. В питоне они не нужны, но там своих хитростей хватает.
snuk182
18.10.2021 15:19я бы сказал, что сложность языка после этого вырастет
Камон, концепт генериков в гошке простой как двери. Сложность языка конечно вырастет в относительных значениях, но в абсолютных даже джависты (а уж тем более шарписты) будут поплевываться от примитивности. В конце концов, дженерики давно пора включить в стандарт любого программирования вообще, если этого еще не произошло.
Да и Rust, Go и Python инструменты, очень мягко говоря, разные.
codefun
18.10.2021 17:12Rust по-моему посложнее и Go и Python. Может его адаптируют для системных задач вполне, только пройдут годы для миграции с С++, мне кажется лет 10
mustitz
18.10.2021 16:10Я не думаю, что bounds checking такая большая проблема. Ну напиши unsafe там где это влияет на производительность.
Про GC... Ну на главной странице я как раз прочитал
> Rust is blazingly fast and memory-efficient: with no runtime or garbage collector, it can power performance-critical services, run on embedded devices, and easily integrate with other languages.DarkEld3r
18.10.2021 17:21+2Про GC… Ну на главной странице я как раз прочитал
В моём комментарии речь была не о расте, а о V.
Ну напиши unsafe там где это влияет на производительность.
И это тоже. Напомню контекст:
Безопасное управление памятью и быстрое выполнение кода (если верить автору, то на уровне С т.е. немного быстрее Rust).
Тут или мы добавляем дополнительные проверки или жертвуем безопасностью. Можно ещё статически доказывать (зависимые типы и вот это всё), но это тоже вариант не для всех.
Если что подход раста меня в этом плане вполне устраивает.
AnthonyMikh
18.10.2021 23:02+3vlang не работает. И не работает по совершенно простой причине: автор и не планирует завершать язык хоть когда-то, он хочет сохранять его вечной альфой и получать деньги на то, чтобы его якобы разрабатывать и продолжать кормить обещаниями.
PsyHaSTe
20.10.2021 20:36+7Каждый раз когда мне говорят что у раста хреновый синтаксис я предлагаю человеку озвучить какие улучшения он бы сделал и что стоит сделать иначе. И тут в редких случаях человек предлагает синтаксис ещё хуже, чем был. Но чаще человек просто предлагает убирать куски языка типа "нафиг лайфтаймы", и тогда становится понятно, что человек вообще не понимает, зачем это и почему.
А то так можно сказать что все статически компилируемые языки по сравнению с питоном имеют отвратный ситнаксис. Какие-то static/class/int/… — что за ерунда. Питон прекрасно без них обходится!
0xd34df00d
20.10.2021 23:12+1Каждый раз когда мне говорят что у раста хреновый синтаксис я предлагаю человеку озвучить какие улучшения он бы сделал и что стоит сделать иначе.
Сделать синтаксис переменных лайфтаймов в прямом смысле более симметричным — одинарный незакрытый
'ломает мой визуальный парсер. Да, кDataKindsу меня та же претензия.
mustitz
18.10.2021 16:03+1Мне непонятно, почему в статье про Rust основной упор делается на управлению памятью. Эту проблему частично решают языки с автоматическим управлением памяти, санитайзеры, чекеры и т. д. Как по мне, гораздо более важно то, что Rust решает большой пласт проблем конкурентного программирования.
К недостаткам Rust я бы отметил, что его концепция плохо ложиться на списочные структуры данных: какой-нить алгоритм танцующих связей будет выглядеть на Rust просто ужасно :)snuk182
18.10.2021 16:41Потому что в Rust управление памятью автоматическое на уровне компилятора, а не рантайма. В рантайме на память не тратится ни такта, если не используется куча, и тратится не более, чем в плюсах, если куча есть.
какой-нить алгоритм танцующих связей будет выглядеть на Rust просто ужасно
Нормально оно будет выглядеть. Только не забывать, что в случае кольцевых ссылок модет случиться легальная утечка памяти, и за этим надо следить отдельно.
mustitz
18.10.2021 16:59Вот попробуй реализовать на досуге, там каждый объект находится в двух двусвязных циклических списках, плюс используется хак, что если объект был только что удалён из списка, то можно его быстро вставить назад двумя операциями... И всё это очень сильно противоречит тому, что на объект может быть только одна мутабельная ссылка.
А утечек памяти там не будет, потому что все объекты можно выделить один раз в векторе каком-нить. Меняются только связи между ними. Так что скорее всего в данном случае лучше хранить не ссылки, а индексы элементов, чтобы хоть как-то легло.snuk182
18.10.2021 17:17Ну то есть задача не решается в лоб хранением ссылок, только и всего.
Точнее, хранить ссылки можно, если используется куча. А она использоваться будет по любому, если количество элементов вариабельно или не известно.
Siborgium
19.10.2021 11:06>Ну то есть задача не решается в лоб хранением ссылок, только и всего.
Задача решается либо через умные указатели, привносящие оверхэд, либо через обычные, вынуждающие либо покрывать unsafe каждое разыменование, либо вообще все обернуть в unsafe -- но в чем тогда смысл unsafe?
>Точнее, хранить ссылки можно, если используется куча.
Не совсем так. Хранить ссылки можно, если владение всеми элементами принадлежит кому-то еще, и время их жизни гарантированно превышает время существования списков, где они хранятся. Это сильное требование.
snuk182
19.10.2021 11:28+1через обычные, вынуждающие либо покрывать unsafe каждое разыменование, либо вообще все обернуть в unsafe
Берите дальше - если цель реализации алгоритма полезное использование хранимых данных (читай - доступ извне), а не просто реализация, unsafe там откровенно навредит.
Не совсем так. Хранить ссылки можно, если владение всеми элементами принадлежит кому-то еще, и время их жизни гарантированно превышает время существования списков, где они хранятся. Это сильное требование.
Невозможное при практическом, а не академическом использовании, если быть честным.
freecoder_xx
19.10.2021 13:04+3но в чем тогда смысл unsafe?
Не забывайте, что unsafe - это полноправный элемент языка Rust. Смысл в том, что ваша небезопасная реализация с указателями будет изолирована внутри вашего модуля и наружу будет торчать только safe-интерфейс. Именно так и именно для этого и используется unsafe.
Siborgium
19.10.2021 14:41-1Я пишу:
>либо вообще все обернуть в unsafe -- но в чем тогда смысл unsafe?
Вы отвечаете:
>>но в чем тогда смысл unsafe?
>Смысл в том, что ваша небезопасная реализация с указателями будет изолирована внутри вашего модуля и наружу будет торчать только safe-интерфейс.
Нет. Если все обернуть в unsafe, то наружу будет торчать модификатор
unsafe. С тем же успехом можно на С/С++ писать функции, вставляя слово unsafe в название.Если же вы имеете в виду обертку наподобие
fn foo() { unsafe { ... } }то такая обертка бессмысленна, так как не выделяет действительно небезопасных мест, наоборот, усложняя исследование функции на предмет ошибок при работе с unsafe-операциями.
freecoder_xx
19.10.2021 16:46+2Судя по всему вы просто не понимаете, как используется unsafe в Rust. Посмотрите реализацию чего-нибудь в стандартной библиотеке, там во многих местах используется unsafe, скрытый за безопасным внешним API.
Siborgium
19.10.2021 17:10-2Судя по всему вы просто не понимаете, как используется unsafe в Rust
Пожалуйста, отвечайте по делу. Я понимаю, как используется unsafe в Rust, и я регулярно пишу код на Rust. В своем комментарии я рассмотрел оба варианта применения unsafe в данном контексте, в ответ я получил... несостоятельную критику и переход на личности, мягко говоря.
freecoder_xx
19.10.2021 16:48+1Нет. Если все обернуть в unsafe, то наружу будет торчать модификатор
unsafe. С тем же успехом можно на С/С++ писать функции, вставляя слово unsafe в название.Видимо вы имеете ввиду, что ваш unsafe используется во внешнем публичном API. Но вопрос: зачем так делать? Такое нужно только для низкоуровневых системных функций, которые небезопасны по призванию.
Siborgium
19.10.2021 17:13Видимо вы имеете ввиду, что ваш unsafe используется во внешнем публичном API.
Да, я рассматриваю именно такой случай в цитируемом контексте.
Но вопрос: зачем так делать?
Такое нужно только для низкоуровневых системных функций, которые небезопасны по призванию.
Вы сами ответили на свой вопрос. Вы считаете, что на Rust нельзя писать низкоуровневые системные функции? Или вы считаете, что написание низкоуровневых системных функций на Rust не является валидным юзкейсом для обсуждения?
Более того, unsafe нужен не только для "низкоуровневых системных" функций, а для всего, что может выходить за рамки Safe Rust по тем или иным причинам, например, производительности ради -- и это вполне может быть достаточно высокоуровневая логика.
freecoder_xx
20.10.2021 14:49+1unsafe во внешнем API нужен только системным функциям. Изначально речь шла о списочных структурах данных и хитрых алгоритмах на них. Я сказал, что можно использовать unsafe, но нужно сделать к нему безопасный внешний API. Только и всего, так в Rust делается часто. Необходимости использовать unsafe в API тут нет.
technic93
20.10.2021 02:24наружу будет торчать только safe-интерфейс.
Ха, главный вопрос, можно ли это сделать? Если наружу торчят итераторы по двусвязному списку или ещё что-то, - то не просто. А если надо два итератора таких? В итоге, гипотетически unsafe может протекать очень глубоко наверх пока интерфейс не сведётся к чему-то примитивному.
freecoder_xx
20.10.2021 14:52Может быть, но на практике обычно удается локализовать unsafe. В том числе и для итераторов. Мне сложно представить ситуацию, когда это сделать нельзя или слишком накладно. Если у вас есть пример, то хотелось бы на него взглянуть.
technic93
20.10.2021 15:32+2К сожалению примера нету, ну и в расте чаще идут по пути - сделаем арену и дальше будет по индексам обращаться, чтобы если что - просто упало. Единственный интересный пример, который я помню это про бинарное дерево в std. Конечно сам BTreeMap имеет сейф интерфейс, но вот в реализации была попытка сделать меньше ансейфа. И там довольно всё запутанно мне показалось при первом прочтении, может со второго раза зайдёт. Так что предполагаю что связные списки и деревья это большая проблема.
Ещё когда-то давно не могли придумать как сделать иерархию компонентов UI, но там выкрутились в итоге реактивным подходом. Вообщем хотелось бы больше видеть примеров про использование лайфтаймов в ситуациях сложнее чем слайс векторов, вместо рекламных статей с нулевой инофрмацией.
technic93
21.10.2021 02:18Что то ссылка умерла. Возможно хабра эффект. Упс.
Ждите новость что русские хакеры атаковали страничку университета.
PsyHaSTe
21.10.2021 12:04Ну да, а чем арена плоха? В разных языках есть разные способы смоделировать одно и то же, в расте вот арена, потому что прямые ссылки фигово работают. Но индекс в арене слабо отличается от адреса в памяти, поэтому не вижу принципиальной проблемы. В худшем случае все работает так же как в плюсах, с теми же проблемами. В лучшем всё же есть некоторые положительные моменты.
technic93
22.10.2021 03:08Это пример о том что "нельзя локализовать ансейф". Доступ по индексу это рантайм проверка, что не круто в контексте обсуждения борроу чекера.
ShadowTheAge
25.10.2021 16:48+3Ну как минимум арена плоха тем что после того как она раскочегарилась ее обратно не "закочегарить" даже если число живых объектов уменьшилось на порядки, потому что по ней рандомно разбросаны живые объекты. Ну или придется реализовывать локальный garbage collector
А это в свою очередь плохо тем что абстракция "арена" протекает повышенным потреблением памяти.
Siborgium
19.10.2021 11:08>Только не забывать, что в случае кольцевых ссылок модет случиться легальная утечка памяти, и за этим надо следить отдельно.
К сожалению, "легальность" утечки памяти ничем не улучшает ситуацию и не облегчает задачу тем, кто будет заниматься отладкой и профилированием программы с целью исправления утечки.
snuk182
19.10.2021 11:32Интересно, линтеры (clippy) уже умеют такое отлавливать?
ИМХО кольцевые ссылки на рефселах в Rust уже должны входить в набор обязательных проверок при написании кода, и заодно при собеседовании. Как согласование `equals()` / `hashCode()` в Java.
IGR2014
18.10.2021 18:49Пожалуйста, уважаемые представители других языков, хватит хоронить C++. Он нам очень нравится и мы соблюдаем все меры предосторожности используя последние стандарты и умные указатели, а не C-style casts и подобную бесовщину!
AnthonyMikh
18.10.2021 23:06+4И как современный C++ поможет мне тут?
lrrr11
19.10.2021 07:06-2подобные ошибки прекрасно ловятся санитайзерами, никакой проблемы тут нет.
AnthonyMikh
19.10.2021 13:07+1Да? И каким же, например? И, кстати, вы сами-то санитайзеры используете?
lrrr11
19.10.2021 13:36-4ой, а вы не знаете, каким? Ну в принципе не удивительно, частое явление среди растоманов.
Попросите вежливо, тогда подскажу :)
technic93
20.10.2021 03:13Сделать -fsanitize=address вместе с detect_stack_use_after_return=1. Но это надо будет запускать программу с проблемным кодом (не путать санитайзеры и статические анализаторы).
AnthonyMikh
20.10.2021 15:38+5Благодарю. А теперь вспомним две вещи:
- Санитайзинг — суть те же тесты, и потому имеют те же слабости: санитайзеры могут показать, что программа сломана, но совершенно не могут показать её безошибочность, и санитайзеры покажут проблему только в том случае, если исполнение зашло в проблемную ветку кода, то есть покрытие путей исполнения для эффективной детекции ошибок должно быть достаточно высоким, а писать тесты никто особо не любит.
- Повисшие ссылки (а string_view семантически ссылкой и является) являются в C++ неопределённым поведением, потому компилятор может преобразовать программу, исходя из невозможности этого неопределённого поведения. Таким образом, санитайзер будет тестировать не ту программу, что написал программист, а ту, которую сгенерировал компилятор, и их поведение может отличаться. В худшем случае компилятор может вообще убрать проблемный путь исполнения, который мы пытаемся поймать санитайзерами.
kb31
21.10.2021 21:54а string_view семантически ссылкой и является
Когда вы ссылаетесь на UB, странно использовать семантический смысл. string_view это связка указателя и целочисленной переменной. С точки зрения стандарта это принципиально разные вещи.
Повисшие ссылки являются в C++ неопределённым поведением
Опять же, в нашем случае - указатели. Но так или иначе, неопределенное поведение возникает не в вакууме, а при доступе к dangling pointer. Все это четко прописано в стандарте в разделе 6.7.3.
потому компилятор может преобразовать программу, исходя из невозможности этого неопределённого поведения
Из пояснения выше - в моменте возврата dangling pointer - не может. Санитайзер отлично справится с задачей.
А еще, справедливости ради, такое должно ловится даже не санитайзерами, а SCA. В GCC инструмент явно не доделан. А даже если по итогу он не сможет ловить вложенные кейсы - он и не претендует на сколь-либо серьезный статус SCA.
Предвкушая ваш вопрос о "сами то используете": в коммерческой разработке? Конечно. Во многих проектах без SCA заказчик не станет с вами работать, а в по-настоящему серьезных проектах, код не имеет ни шанса пройти сертификацию.
PsyHaSTe
22.10.2021 10:42Все это четко прописано в стандарте в разделе 6.7.3.
Спасибо, мне стало легче) Особенно вспоминая ту нарезку с конференции, когда в зале нашли членов комитета С++, показали сниппет кода и попросили сказать, какое поведение определяет стандарт. Ну и конечно, мнения разделились)
PsyHaSTe
22.10.2021 11:30Видос с чуваками из комитета не нашел, но нашел видос с конфой с челиками которые книжки пишут:
kb31
19.10.2021 08:34Чем ваш пример принципиально отличается от возврата локальной переменной по ссылке, тем что варнинг не отработал? Так сделайте статичную ссылку на локальный объект, верните ее. Или верните shared_ptr от this вместо enable_shared_from_this.
shortest концептуально невалиден так же, как и cut_prefix, и C++ тут мимо проходил, это вопрос дизайна собственного кода и понимания языка, с которым работаешь.
И тут -Wlifetime не обязан спасать, лишь помогать в тривиальных случаях. Но если акцент именно на нем, то может хотя бы релиза фичи дождаться?
AnthonyMikh
19.10.2021 13:11+2Чем ваш пример принципиально отличается от возврата локальной переменной по ссылке, тем что варнинг не отработал?
Тем, что в example_should_ok возврата локальной переменной по ссылке таки нет.
shortest концептуально невалиден так же, как и cut_prefix, и C++ тут мимо проходил, это вопрос дизайна собственного кода и понимания языка, с которым работаешь.
Так, а вот про это можно поподробнее? Вроде бы string_view как раз сделали для того, чтобы не копировать строки лишний раз. И с самими этими функциями проблем нет, они возникают на месте применения.
И тут -Wlifetime не обязан спасать, лишь помогать в тривиальных случаях. Но если акцент именно на нем, то может хотя бы релиза фичи дождаться?
Ну так в более простом случае он таки действительно помогает, но с ложно-положительным срабатыванием.
kb31
21.10.2021 12:35>Вроде бы string_view как раз сделали для того, чтобы не копировать строки лишний раз.
И снова ошибаетесь, почитайте proposal для string_view, буквально первый раздел. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3921.html
Мы действительно можем получить некоторый range строки, который, разумеется, будет non-owning. И мы действительно можем использовать этот функционал локально или применяя ООП.
А теперь вернемся к вашему примеру и вашим функциям.
Возврат вообще чего-либо non-owning из семантически чистой функции - грубая ошибка дизайна. По этой же причине невалидны обе ваши функции, и по этой же причине уместно сравнение с возвратом локальной переменной по ссылке.
Должен ли компилятор наказывать за такое? Было бы неплохо, но, надеюсь, не нужно пояснять, почему он не обязан этого делать.
Иными словами, еще раз: язык тут не причем. Хотя, в каком-то смысле, вину C++ может увидеть в том, что у многих сложилось впечатление, что он с течением лет превращается в ту доминирующую группу языков, где можно писать код не используя мозг.
0xd34df00d
21.10.2021 19:49+5Должен ли компилятор наказывать за такое? Было бы неплохо, но, надеюсь, не нужно пояснять, почему он не обязан этого делать.
Компилятор вообще ничего не обязан делать, но чем больше ошибок компилятор предотвращает, тем лучше.
где можно писать код не используя мозг
Это влияет только для проектов уровня хелловорлда. Для проектов побольше даже самые мозговитые люди делают ошибки — ну, просто потому, что все детали удержать в памяти человека невозможно.
kb31
21.10.2021 21:32-1>Компилятор вообще ничего не обязан делать, но чем больше ошибок компилятор предотвращает, тем лучше.
Ну как же, компилятор обязан делать то, что явно указано в стандарте. Но раз вы возражаете, разверну свою банальную идею про отсутствие обязательства предотвращения таких ошибок: если нет тривиального способа обнаружить ошибку, обязанность, возложенная на компилятор потенциально существенно усложнит имплементацию. По этой причине большая часть диагностик имплементируется на уровне "так можно но нельзя", и примерно по той же причине стандарт С11 - модульный.
>Это влияет только для проектов уровня хелловорлда. Для проектов побольше даже самые мозговитые люди делают ошибки — ну, просто потому, что все детали удержать в памяти человека невозможно.
Тут я немного некорректно выразился. Мозг нужен везде, и разница в компетенции даже для разработчиков на питоне может серьезно повлиять на количесто и критичность ошибок.
Я имел в виду то, что есть языки, которые не требуют глубокого понимания матчасти. Как правило, все сводится к степени высокоуровневости языка.
С++ становится все более высокоуровневым с новыми стандартами, вероятность отстрелить себе ногу действительно сильно уменьшается (те же умные указатели или аллокаторы как яркий пример), но вместе с этим язык продолжает развиваться и в "плюсовую" сторону - memory models, execution policies, и тот же string_view можно отнести сюда. У кого-то здесь есть более удачная идея для дизайна string_view? Поделитесь! Очень интересно послушать (не сарказм)Если человек не способен распознать, где нельзя возвращать string_view, ему следует его избегать, а возможно избегать C++ вообще. И это не плохо, ведь есть же Rust!
P.S. в более или менее крупных проектах на C++, существуют safety guidelines (не путать с coding style). Их задача во многом состоит именно в том, чтобы защитить разработчика от C++. И они действительно строгим образом трейсятся с помощью различных SCA инструментов.
Так что в конечном итоге все подобные тезисы в том или ином виде сводятся к "я разыменовал nullptr и у меня segfault. давайте сделаем язык с безусловной превентивной проверкой на nullptr для всех указателей".0xd34df00d
21.10.2021 21:48+3Ну как же, компилятор обязан делать то, что явно указано в стандарте.
Я говорил о компиляторах в общем, не только конкретно плюсов. Есть языки и без ISO-стандартов, в конце концов.
Но даже если рассматривать только плюсы, то ваше высказывание, учитывая количество NDR'ов в стандарте, получается довольно слабым: есть огроменная куча ошибок, которую компилятор совершенно не обязан диагностировать.
Я имел в виду то, что есть языки, которые не требуют глубокого понимания матчасти. Как правило, все сводится к степени высокоуровневости языка.
Какой именно матчасти? Машины Тьюринга, на которой построена вся эта императивщина? Нет. Деталей архитектуры современных процессоров, на которых всё это выполняется? Нет. Деталей какой-нибудь сепарационной логики, которая используется для описания мутабельных процессов? Снова нет. Тогда какой матчасти? А, ну да, задрачивания талмуда под названием «стандарт C++».
Лично я понял, что эта матчасть непознаваема, и переключился на что попроще (ну там, формальные доказательства, завтипы, вот это всё). Если для вас талмуд познаваем — снимаю шляпу, вы редкий человек. Я таких до сего дня не встречал нигде, ни в интернете, ни в фаангах, ни в плюсовых трейдинговых тусовках.
У кого-то здесь есть более удачная идея для дизайна string_view? Поделитесь! Очень интересно послушать (не сарказм)
В рамках возможностей, даваемых системой типов плюсов — нет.
И это не плохо, ведь есть же Rust!
Именно, про то и речь. Только вопрос: зачем тогда C++, кроме «у нас уже есть легаси-код на плюсах» и «я C++ вроде
знаюотносительно успешно использую, а другие языки мне изучать лень»?Так что в конечном итоге все подобные тезисы в том или ином виде сводятся к "я разыменовал nullptr и у меня segfault. давайте сделаем язык с безусловной превентивной проверкой на nullptr для всех указателей".
Почему бы не сделать язык без
nullptrвообще, кроме, возможно, FFI в C?kb31
21.10.2021 22:17Какой именно матчасти?
С которой работаете. Разного уровня. Но не надо утрировать и спускаться туда, что едва может пригодится. В данном случае контекстом была функция и "владение" объектом.
Если вы будете работать с многопоточностью, вам придется погружаться в матчасть concurrency и модели памяти.
Высоконагруженные системы или рендеринг - во многих случаях аллокаторы и снова модели памяти.зачем тогда C++
В общем-то это ответ и на остальные вопросы, и естественно, это лишь мое видение:
С++ это зрелый, проверенный временем (и гигантским количеством кода) язык, для которого существует не только гора библиотек, но и огромное количество методологий, инструментов, гайдлайнов, и прочих смежных практик. С рынком все обстоит сложнее, и я тут экспертное мнение выразить не могу.
Если по вашему это все тоже легаси, а легаси это плохо - а у вас есть уверенность, что Rust тот же во всем лучше? Перепишут на него весь софт, драйвера, да и ОС заодно. Но где-то в середине процесса поймут, что он все же не так хорош, есть идеи получше, и нужен новый язык.
Вообразите, что получится?
ИМХО, пусть удачные языки развиваются и набирают обороты, а время покажет нужное направление. 10 лет - чудовищно молодой возраст для языка, чтобы бросится переписывать на него все, что можно.0xd34df00d
21.10.2021 22:58+3С которой работаете. Разного уровня. Но не надо утрировать и спускаться туда, что едва может пригодится. В данном случае контекстом была функция и "владение" объектом.
Но это снова специфика плюсов, верно?
проверенный временем (и гигантским количеством кода) язык
Время проверяет только возможность писать что-то на языке. Оно не проверяет оптимальность этого решения.
Если по вашему это все тоже легаси, а легаси это плохо — а у вас есть уверенность, что Rust тот же во всем лучше? Перепишут на него [...]
Я нигде не говорил, что надо на расте что-то имеющееся переписывать. Речь только о новых проектах, не более.
kb31
22.10.2021 00:10Но это снова специфика плюсов, верно?
Если вы про "владение" объектом, у RAII своя специфика, но на этом уникальность заканчивается. Все остальное тоже лишь частично специфично для плюсов. Концепции примитивов синхронизации или размер кэшлайна, например, вообще к языку отношения не имеют.
Но в плюсах подобные знания, по моим наблюдениям, требуются гораздо чаще, чем в других "популярных" языках.Время проверяет только возможность писать что-то на языке. Оно не проверяет оптимальность этого решения.
Речь не об оптимальности, а о целесообразности.
Я нигде не говорил, что надо на расте что-то имеющееся переписывать. Речь только о новых проектах, не более.
Это говорил автор статьи. Раз вы топите за Rust в этой дискуссии, я решил что вы и с текстом статьи согласны :)
0xd34df00d
22.10.2021 22:14+3Все остальное тоже лишь частично специфично для плюсов.
Только в обсуждаемом примере именно специфика плюсов. Плюсовых времён жизни, плюсовых диагностик от компилятора (и их отсутствия), и так далее.
Концепции примитивов синхронизации или размер кэшлайна, например, вообще к языку отношения не имеют.
Но в плюсах подобные знания, по моим наблюдениям, требуются гораздо чаще, чем в других "популярных" языках.По личному опыту написания кода, где важны примитивы синхронизации, кешлайны и прочие низкоуровневые детали — плюсы пытаются абстрагировать это в попытках покрыть наибольшее количество систем, и получается плохо (например,
alignas(64)совершенно не обязан выровнять ваш тип по границе в 64 байта, поэтому у вас в кешлайне может быть больше одного объекта и может возникнуть false sharing и лишний контеншн в многопоточных приложениях).Блин, да даже в хаскеле несложно попросить компилятор преобразовать array of structs в struct of arrays — как мне это сделать в плюсах, кроме как ручками?
Да и подавляющее большинство UB в моей практике было связано не с особенностями низкоуровневых деталей машины, а с неправильной интерпретацией стандарта.
Речь не об оптимальности, а о целесообразности.
Целесообразность тем более не может быть проверена временем в условиях развивающегося мира.
Раз вы топите за Rust в этой дискуссии, я решил что вы и с текстом статьи согласны :)
Я не топлю за раст, мне раст не нравится, я вообще считаю, что в подавляющем большинстве случаев растовские +10-30% низкоуровневого перфа по умолчанию по сравнению с теми языками, за которые я топлю, не нужны, и выигрыш эффективнее получить на высоком уровне, дизайном, архитектурой и алгоритмикой.
technic93
21.10.2021 22:03Возврат вообще чего-либо non-owning из семантически чистой функции
Кто такая cемантически чистая функция?
kb31
21.10.2021 22:38Из функции, которая семантически является чистой.
0xd34df00d
21.10.2021 22:56+1auto id(auto x) { return x; }— очевидно чистая функция, и она будет возвращать что-то non-owning, если ей передать что-то non-owning. Ошибкой дизайна я бы это не называл.kb31
21.10.2021 23:56Дизайн возникает от юзкейсов. Если вам может потребоваться сделать
return id(&local_variable);- да, это ошибка дизайна.В примере AnthonyMikh именно такой пример и приведен
technic93
22.10.2021 03:05+2Я думаю дело в том что у нас не id в примере, а произвольная функция, и про то что ей разрешено делать с точки зрения владения или ссылок в темплейте не написано.
0xd34df00d
22.10.2021 22:21+3Окей, а
class PersonView { std::string_view name; public: std::string_view get_name() const { return name; } };ошибка дизайна?
ИМХО — нет, ведь достаточно, чтобы то, на что ссылается этот
name, жило дольше, чемPerson. Вот бы был какой-то консистентный способ рассуждать о временах жизни и хотя бы проверять автоматически их корректность…И нет, это не придуманный пример — код, который
mmapил файл на несколько сот гигабайт, парсил его оглавление и создавал кучу такихPerson-подобных объектов, ссылавшихся на нужные кусочки этого файла, при обращении к которым ОС лениво подгружала соответствующие части файла, а также выгружала обратно давно неиспользуемые куски (что позволяло работать с файлом сильно больше доступного объёма оперативки без переизобретения менеджера памяти внутри приложения), я писал лично. Как раз та самая низкоуровневость, о которой вы пишете в соседнем комментарии.
freecoder_xx
19.10.2021 13:13+2Rust возник из критики C++ и претендует на его нишу. Так что вашу просьбу удовлетворить не получится, прекратить критиковать плюсы для него равносильно остановке в развитии.
freecoder_xx
19.10.2021 17:04+2И в этом нет ничего плохого. Плюсы тоже критикуют Rust, например, за урезанные возможности.
Antervis
18.10.2021 20:12+2Какая-то очередная супер шаблонная статья про Rust:
Шаг 1: заходим сразу с террора. Рассказываем о том, к каким страшным последствиям могут привести ошибки памяти. На одном-двух абстрактных примерах, никакой конкретики. Забываем упомянуть про степень готовности языка для разработки критически важных систем.
Шаг 2: ссылаемся на исследование майкрософтом своей легаси кодобазы, написанной преимущественно на си и доисторическом стандарте плюсов.
Шаг 3: пишем какой rust быстрый и безопасный. Быстрый в сравнении с языками с GC и автоматическим управлением, безопасный относительно языков с ручным. Далее нечетные шаги пропускаются, т.к. они лишь повторяют этот пункт
Шаг 4: Два предложения про сабж статьи
Шаг 6*: Пишем какой с++ плохой, ведь управлять памятью надо вручную. Про последние 10 лет развития плюсов не упоминаем, несмотря на то, что расту официально всего 6.
Шаг 8-14: цитируем тщательно избранных апологетов. Можно миксануть мнение кого-то авторитетного, в этом случае - Линуса Торвальдса, который говорит не торопиться с растом
Шаг 16: рассуждаем о том, как хочется всё переписать, и как после переписывания на раст в программах точно не останется прям ни единого бага, и как много надо переписывать, и поэтому надо начинать сразу с самых корневых модулей.
Шаг 18-22: повторяем 8-14
Шаг 24: ловим кучу плюсиков от любителей раста, написавших на нем не более helloworld
Шаг 25: отключаем уведомления чтобы проигнорировать 1000+ комментов срача
ozkriff
18.10.2021 20:20+16Какой-то очередной супер шаблонный комментарий к очередной супер шаблонной статье про Rust.
freecoder_xx
19.10.2021 13:10+2Кажется, что вебу на Rust все-таки быть, по крайней мере его экосистема в эту сторону неплохо развивается.
codefun
19.10.2021 17:23на какую нишу в вебе претендует Rust?
freecoder_xx
20.10.2021 14:53-1На всю )
codefun
20.10.2021 15:28реально на всю? И вместо Javascript?
Касательно серверной ниши, на хабре были статейки (прямо на этом хабе, посвященном Rust) что с асинхронностью в Rust непросто https://habr.com/ru/company/macloud/blog/564812/
Некоторая ниша уже успешно занята Go. При этом Go - специализированный нишевый язык, хорошо заточенный под нишу микросервисов, переболбашивания данных, серверлесс, низкую лейтенси, и может что-то ещё. Чтобы выбить Go из этой ниши, какие факторы должны сыграть? Давайте пока оставим за скобками анализ чисто языковых конструкций, т.к. выбор инструмента это гораздо больше чем наличие системы типов и тд (есть много багов которые никакая система типов не порешает). Rust же - язык общего назначения (хотя скорее системный). Я могу представить какие-то узкие кейсы где Rust может быть лучше, но это будет низкий процент.
Ниша большого интерпрайза занята С# и java. Там где не нужны low latency и то остальное что для Go - это их ниша. У них есть огромное число готовых решений. Иногда джаву выбирают даже тупо потому что клиенты Кафки на других языках не поддерживают нужный спектр фич. Банально? Да, но вот так.
Тут дело в том, что недостаточно просто каких-то прикольных фич в языке. Недостаточно бежать быстро, нужно бежать быстрее чем конкуренты.
Так что я немного уточню вопрос:
1) где, по-вашему, стоит взять Rust вместо Go? Каковы кейсы, критерии
2) тоже самое по сравнению с java/c#
3) тоже самое по сравнению с JSfreecoder_xx
20.10.2021 18:56реально на всю? И вместо Javascript?
Почему нет?
https://yew.rs
https://rustwasm.github.io/wasm-bindgen/web-sysс асинхронностью в Rust непросто
Я уже писал в комментариях к той статье, что с асинхронностью все там нормально.
1) где, по-вашему, стоит взять Rust вместо Go?
Везде. Скорее я могу ответить на вопрос, когда следует брать Go вместо Rust: если вы не имеете опыта работы со статически типизированными языками, то с Python/PHP может оказаться, что быстрее переучитесь на Go, чем на Rust. Если при этом не напрягает наличие сборщика мусора, то можно его брать. Или стоит использовать Go, если там уже есть готовое, что вам нужно, а в Rust еще пока нет. Все. Других оправданных случаев не вижу. Вообще считаю, что Go - это промежуточное звено между скриптовым вебом и вебом на Rust.
2) тоже самое по сравнению с java/c#
Rust, как язык и технология, лучше подходит для решения практически всех задач, которые сейчас решаются с помощью Java. Разве что, может быть, кроме случаев, когда действительно нужна горячая загрузка классов. Но исходя из опыта считаю, что таких случаев очень мало, где без нее никак не обойтись. В остальном писать бекэнды на Rust намного удобнее и продуктивнее, чем на Java. Я их писал, так что прочувствовал это на практике.
Единственная настоящая причина, почему прямо сейчас весь энтерпрайз не перейдет на Rust заключается в том, что экосистема Java на порядок больше и она уже хорошо приспособлена под решение текущих задач. Плюс большой легаси, и в коде, и в опыте, и в программах подготовки разработчиков и пр.
3) тоже самое по сравнению с JS
Совсем без JavaScript сейчас не обойтись в браузере. Но развитие WebAssembly должно вскоре устранить этот недостаток. Я пишу фронт на Rust, и он для меня удобнее, чем JavaScript, практически во всем. Мне вообще страшно вспоминать большие JavaScript-приложения, с которыми я имел дело раньше. Просто какой-то неподконтрольный ужас. С Rust таких проблем нет.
codefun
20.10.2021 20:29+2я понял, вам очень нравится Rust )
я думал как бы мнение-анализ получить, по факту вышел просто обмен предпочтениями.
Из абзаца про Go я смог вычленить пару пунктов
1) cтатическая типизация
2) наличие готовых решений
3) наличие/отсутствие GC
из этих пунктов 2й и 3й могут в общем-то повлиять на выбор, если есть какие-то ультра серьезные требования вроде как в случае Discord. В целом я интересовался юзкейсами наподобие этого, можете ли вы назвать еще какие-нибудьПочему нет?
https://yew.rs
https://rustwasm.github.io/wasm-bindgen/web-sysну самого наличия и существования этих библиотек недостаточно же ))
сейчас идет тенденция на скорость разработки, никто не пытается делать "на века". Играет роль выход на рынок. В лучшем случае после успешного выхода на рынок, некоторые части начинают переписывать. Потому делают на тех инструментах на которых быстрее. Судя по тому что происходит, эта тенденция только усиливается. И в вебе (фронтэнде) лабать нужно очень быстро. Потому даже если на Rust писать и можно, вряд ли это станут делать в большом количестве
я допускаю мысль (в порядке фантазий) что все вдруг озаботятся счетами на AWS и будут смотреть как их обгоняют конкуренты, модернизируя свои системы быстрее, но ставочку я сделаю все же на то что Rust не только не заменит JS на фронтэнде, а скорее JS заменит большую часть кода и на сервере )PsyHaSTe
20.10.2021 21:42Речь не про века а в банальной экономии. "докупим плашек и норм" перестает нормально работать когда за сервера платить начинаешь уже за миллион рублёв в месяц, а разраб который мог бы срезать их количество в разы стоит всего пару сотен.
Архитекторы которым плевать го или раст — нормальные люди и принятие решения вообще в другой плоскости, да, но которые не видят между ними разницы просто профнепригодны. В любом случае раст и го тут не выделяются, может быть выбор хаскель или жс, такое тоже встречал.
И в вебе (фронтэнде) лабать нужно очень быстро. Потому даже если на Rust писать и можно, вряд ли это станут делать в большом количестве
Если речь про кнопки со скругленными углами то скорее да чем нет. Если же речь про какую-нибудь онлайн игрушку желательно с тридэ, то у раста уже есть шансы.
Хотя учитывая сколько обычных сайтов на одну игрушку в распространенность раста в фронтенде я слабо верю.
codefun
20.10.2021 22:52Речь не про века а в банальной экономии. "докупим плашек и норм" перестает нормально работать когда за сервера платить начинаешь уже за миллион рублёв в месяц, а разраб который мог бы срезать их количество в разы стоит всего пару сотен.
Rust начали использовать в AWS точно, но я не помню используют ли они его именно для веб сервисов. По-моему больше используют какраз как системный язык. Google же вполне адаптировал Go. Я думаю что потребление памяти, пропускная способность и задержка у Go незначительно хуже чем у Rust, а вот отсутствие GC усложняет кодирование. Rust же защищает в большинстве случаев от ошибок памяти. От дэдлоков или гонок уже не защищает, верно? Итого выходит что сколько там той безопасности по итогу. Ошибки при кодировании связаны не только с памятью, и нет такой системы типов которая бы защищала от ошибок бизнес-логики. Я бы назвал это когнитивный биасом "переоценка типизации для предотвращения ошибок" (я вижу что некоторые считают что стоит сделать супермощную систему типов, и это будет панацея) Во-всяком случае я не видел исследований которые бы говорили какой процент ошибок памяти в программах на java. Можно конечно утверждать что остальные ошибки в java коде связаны со слабой (по мнению раст-сообщества) системой типов, но думаю это уже было бы ничем не подкрепленным заявлением. При этом Go имеет встроенный тулинг для профайлинга, быстро билдится, а значит ускоряет цикл фидбэка программисту.
Короче я не вижу реально сколько-нибудь несубъективных моментов. Вижу только что Google почему-то вполне адаптировал Go для части вебсервисов, но я не слышал ничего подобного о Rust (может просто не слышал?). Нельзя же полагать что они там в Google все дураки?
лично я со своей колокольни вижу что Rust может быть применен для написания вебсерверов, но для вебсервисов - в 95% это оверкил. Если же говорить чисто о субъективных предпочтениях, то понятно что нормальный архитектор по возможности пытается избегать личной предвзятости в выборе инструментовЕсли же речь про какую-нибудь онлайн игрушку желательно с тридэ, то у раста уже есть шансы
ну зато интересная мысль, чо )
уже за миллион рублёв в месяц, а разраб который мог бы срезать их количество в разы стоит всего пару сотен.
что-то мне подсказывает что не все так просто) Если такие счета, то вряд ли это мелкая система которую перепишут за 1 человеко-месяц. А если взяли более сложный инструмент - получите более высокую стоимость поддержки этого кода (всегда). Сколько будет стоить уже такой разклад? Наверняка выгода-то будет, но спустя время, и надо садиться и считать. А за то время пока кто-то переписывает продукт чтоб сократить биллинг ресурсов - кто-то другой делает новые фичи и имеет потенциал откусить часть рынка
PsyHaSTe
21.10.2021 00:21+2Я думаю что потребление памяти, пропускная способность и задержка у Go незначительно хуже чем у Rust
Citation needed. Получается несколько голословно.
По моему опыту разница существенная.
Rust же защищает в большинстве случаев от ошибок памяти. От дэдлоков или гонок уже не защищает, верно?
И от rm-rf не защищает, да. Но во-первых защищает так же от data race, т.е. накосячить с многопотоком в расте действительно сложно. Во-вторых проблемы с памятью по репортам того же гугла это причина 70%+ багов. Не говоря про проблемы с памятью которые дебажатся неделями вместо того, чтобы быть отловленными компилятором. Это уже PVS не раз рассказывала — если анализатор показывает мало проблем, это не всегда означает что он не нужен, просто люди потратили кратно больше времени, чтобы вычистить всё руками. Насколько это хорошо — оставляю вам решать.
Ошибки при кодировании связаны не только с памятью, и нет такой системы типов которая бы защищала от ошибок бизнес-логики.
И да и нет. В голову конечно залезть программисту компилятор не может и узнать что спека составлена неправильно тоже. Но учитывая все эти "проблемы на миллиард" (которые уже на триллионы наверное пошли) — зачастую всё куда проще, и даже простая невозможность получить ошибку с нуллом это уже кратное уменьшение всех возможных багов. А если ещё и пользоваться возможностями систем типов по полной — то тут и бизнесовые баги можно вылавливать. Но от всех бед конечно не спасет, так что можно заключить, что это дорогая ненужнная игрушка и продолжать кодировать, как завещали предки.
лично я со своей колокольни вижу что Rust может быть применен для написания вебсерверов, но для вебсервисов — в 95% это оверкил. Если же говорить чисто о субъективных предпочтениях, то понятно что нормальный архитектор по возможности пытается избегать личной предвзятости в выборе инструментов
Для вебсерверов раст более чем полезен. Я лично год назад переписывал с шарпа на раст одну штуку. 10 тысяч строк были переписаны за неделю, небольшой сервисок. Снизили нагрузку на порядок, потребление памяти в пару раз. Вполне неплохой результат кмк. Не говорю что на каком-нибудь го было бы хуже, но и не лучше.
что-то мне подсказывает что не все так просто) Если такие счета, то вряд ли это мелкая система которую перепишут за 1 человеко-месяц.
Вы явно недооцениваете сколько инженеров можно добавлять на оптимизацию кода, пока это не станет невыгодным. Понятно, что не все гугл, но даже компании в пару десятков человек сталкиваются с миллиоными счетами на инфраструктуру. Попробуйте узнать, сколько ваша компания тратит на это, возможно это будет сюрпризом.
А за то время пока кто-то переписывает продукт чтоб сократить биллинг ресурсов — кто-то другой делает новые фичи и имеет потенциал откусить часть рынка
Ничего не мешает нанять двух разработчиков, правда?
codefun
21.10.2021 10:36Citation needed. Получается несколько голословно.
По моему опыту разница существенная.
у меня сейчас нет под рукой хороших ссылок, в основном по бэнчмаркам видел что разница небольшая. Мне кажется это логично т.к. в вебсервисах (и особенно микросервисах) чаще io-bound задачи, т.е. вебсервис это не числодробилка.
Если у вас есть какой-то опыт или статейки - пошарьте, расскажите, будет интересно услышать
со своей стороны, вот, может будет интересно
https://go.dev/blog/ismmkeynoteНо во-первых защищает так же от data race, т.е. накосячить с многопотоком в расте действительно сложно.
видимо вы имеете в виду что из-за передачи владения не выйдет поменять. В принципе может и так, но если говорить о гонках вообще - то думаю вряд ли Раст от них защитит (data races - это подмножество race condition).
Кстати, у Go тоже есть анализатор гонок данных, только запускается он отдельно, но ничто не мешает его встроить в какие-то части билд пайплайна на CI/CD
Насчет репортов Гугла и 70% ошибок из-за памяти - этот пласт ошибок актуален больше для языков без GC. В Go тоже можно кое-где накосячить с escape analysis, а в java сделать утечку памяти тоже реально, но в целом ситуация проще. Если сравнивать с языками с GC, тогда нет смысла говорить о защите от ошибок памяти - будем считать что и те и другие решают эту проблему, просто по своему. Расту записываем очко за перформанс, но надо понять какой он именно для веб-сервисов. Выносим за скобки защиту от гонок данных и ошибок памяти, считая что они у Го и Раст примерно те же. Итого, что остается у Раст как преимущество в плане именно защитного программирования? Наверное вы скажете что мощная система типов.А если ещё и пользоваться возможностями систем типов по полной — то тут и бизнесовые баги можно вылавливать.
простой код проще анализировать и видеть в нём ошибки бизнес-логики, и ошибки бизнес-логики проще отлавливать в коде который не засоряет глаза обилием подробностей и неизбежных накладных расходов мозга (интеллектуальных, визуальных - при восприятии) при анализе кода из-за того что код содержит высокое число защитных техник, которые решают лов-левел ошибки (вроде памяти). Т.е. вам кажется что статический анализ может защитить от багов бизнес-логики, а мне кажется что не так уж и сильно и простой для чтения и восприятия код - тоже довольно мощная защита от ошибок бизнес-логики, и как тут проверить кто прав? И то и другое всего лишь умозрительные рассуждения.
Скажем мы в java на нескольких проектах очень активно пользовались даже несколькими стат. анализ тулами, и в конечном итоге отключили их т.к. они приносят очень мало пользы.
Многие советы по написанию кода связаны со снижением давления на восприятие - длина методов, длина файлов, длина строки - всё это направлено на снижение давление и перегруз мозга деталями. Сложный синтаксис и обилие защитных техник - это из той же области. Например простыню простого и дубового кода, в котором вещи делаются просто и прямолинейно, я могу отрефакторить и просто разбить на несколько методов, а вот воспринимать код в котором на каждую строку идет большая интеллектуальная нагрузка мне сложнее. Конечно это дело вкуса, не спорю. Может средние программист на Rust умнее и у него буфер памяти в голове больше, но тогда этот язык будет сложно сделать массовым)Для вебсерверов раст более чем полезен. Я лично год назад переписывал с шарпа на раст одну штуку. 10 тысяч строк были переписаны за неделю, небольшой сервисок. Снизили нагрузку на порядок, потребление памяти в пару раз. Вполне неплохой результат кмк. Не говорю что на каком-нибудь го было бы хуже, но и не лучше.
Интересно, спасибо.
А использовали при этом асинхронный ввод-вывод?Вы явно недооцениваете сколько инженеров можно добавлять на оптимизацию кода, пока это не станет невыгодным. Понятно, что не все гугл, но даже компании в пару десятков человек сталкиваются с миллиоными счетами на инфраструктуру. Попробуйте узнать, сколько ваша компания тратит на это, возможно это будет сюрпризом.
я вполне верю, т.к. видел траты крупных компаний на инфраструктуру. Т.е. сама идея уменьшения биллинга на ресурсы конечно разумная. Просто у Гугла допустим тоже огромные системы, и они вполне неплохо обкатали Го для этого. Тоже как никак опыт.
Кстати насчет трат, мой опыт говорит что прожорливые технологии на серверах бэкэнда это не единственная проблема. Часто сам AWS подсаживает на такие технологии которые дорогие. DynamoDB например очень дорогая.
вот статейка занятная, если лень читать всю, то можете просто вбить "DynamoDB hot shards"
https://segment.com/blog/the-million-dollar-eng-problem/Ничего не мешает нанять двух разработчиков, правда?
та понятно что можно, но нужно учитывать и стоимость поддержки. Более сложная технология (а Раст - такая) - больше стоимость поддержки (а это не 1 месяц, а годы). Я анализирую в основном по тому что прямо сейчас происходит на рынке. Даже крупные компании типа AWS используют Rust только в критических частях инфраструктуры. Если вдруг они начнут переписывать и перепишут всё остальное - тогда это будет повод задуматься.
многовато вышло текста, надеюсь не утомил)PsyHaSTe
21.10.2021 12:27+1у меня сейчас нет под рукой хороших ссылок, в основном по бэнчмаркам видел что разница небольшая. Мне кажется это логично т.к. в вебсервисах (и особенно микросервисах) чаще io-bound задачи, т.е. вебсервис это не числодробилка.
Но бывает и наоборот. Точнее если вы пишете числодробилку то для неё нужно какой-то интерфейс иметь, и обычно это HTTP. Вот типичный пример такого приложения.
Для IO-bound перекладывания SQL в жсоны и наоборот конечно ничего этого не нужно.
видимо вы имеете в виду что из-за передачи владения не выйдет поменять.
Владение не при чем, речь про Send/Sync трейты которые в типах зашивают с чем и как конкретно потокобезопасно можно работать, а с чем и как нельзя.
В принципе может и так, но если говорить о гонках вообще — то думаю вряд ли Раст от них защитит (data races — это подмножество race condition).
А это в принципе нерешаемая задача, потому что гонка всегда может быть в каком-нибудь редисе или БД. Язык может только за себя отвечать.
Насчет репортов Гугла и 70% ошибок из-за памяти — этот пласт ошибок актуален больше для языков без GC.
Так а раст не претендует на языки с ГЦ по сути. Если есть возможность тащит гц — отличо, берем скалу/хаскель и пишем всё ещё в 10 раз безопаснее и быстрее)
Интересно, спасибо.
А использовали при этом асинхронный ввод-вывод?Естественно. Синхронное сетевое IO это деньги на ветер, я такое в принципе в прод не пишу и другим не даю когда ревьювлю.
я вполне верю, т.к. видел траты крупных компаний на инфраструктуру. Т.е. сама идея уменьшения биллинга на ресурсы конечно разумная. Просто у Гугла допустим тоже огромные системы, и они вполне неплохо обкатали Го для этого. Тоже как никак опыт.
Если у вас инфраструктура в миллион раз меньше чем у гугла это все равно заметные тысячи долларов, которые зачастую выгодно сэкономить. Пример выше к слову я приводил про компанию в которой работало всего 10 разработчиков. И все равно оказалось что биллинги за инфру достаточно большие. Да что там, посмотрите какие требования у parler для жалкого мессенджера — там можно полсотни разрабов посадить переписывать и они все окупятся.
та понятно что можно, но нужно учитывать и стоимость поддержки. Более сложная технология (а Раст — такая) — больше стоимость поддержки (а это не 1 месяц, а годы).
Дороже по сравнению с чем? С плюсами нет, с гц — если есть возможность взять гц то нужно его брать и не думать. Но часто возможности нет, и проблемы тут начинаются намного раньше чем при размерах уровня дискорда.
многовато вышло текста, надеюсь не утомил)
0xd34df00d
20.10.2021 19:07+1Какие преимущества там по сравнению с тем же хаскелем?
PsyHaSTe
20.10.2021 21:14+2Можно написать тупой код по гайдлайнам будучи джуном и получить тот же перф, что и сениор хаскеллист, обмазанный анбоксами, шебангами и собственными эффективными интерпретаторами определенных эффектов. Причем зачастую память будет жраться на порядок меньше потому что язык мотивирует отказ от боксов где возможно.
0xd34df00d
20.10.2021 23:33+1ИМХО в подавляющем большинстве веба перф не настолько важен, чтобы сильно заморачиваться по анбоксам и бангпаттернам — оно там и так 95% ждёт переупаковывания жсончиков в БД. А в оставшиеся 5% ты не посадишь джунов.
Зато тот же джун не пойдёт иметь глобальное состояние и прочие прелести безэффектной императивщины — и хотя куча кода в вебе тоже write-only, я склонен считать, что возможность этот код поддерживать и, этсамое, reason о нём, важнее.
PsyHaSTe
21.10.2021 00:27+4Так смысл именно в том, что ты можешь посадить джуна писать код, и если оно растом в целом скомпилировалось, то перформанс решения будет практически оптимальный, не считая алгоритмики конечно.
Просто у нас было решение на ГЦ языке и у нас некоторые компоненты стали выжирать слишком много инстансов. Менеджмент оценил целесообразность решения техдолга и переписывания на что-то более оптимальное. Я переписал пару сервисов на раст и сменил работу. Чтобы допилить мой кусок туда кинули пару джунов, ну и они без каких-либо проблем или отломов вполне прилично дописали, как мне рассказывали.
Зато тот же джун не пойдёт иметь глобальное состояние и прочие прелести безэффектной императивщины — и хотя куча кода в вебе тоже write-only, я склонен считать, что возможность этот код поддерживать и, этсамое, reason о нём, важнее.
В расте тоже нет глобального мутабельного состояния потому что оно компилятором запрещается. Не так все круто как в чистом ФП конечно, но для наших земных нужд вполне норм.
Kelbon
22.10.2021 19:26+2Вся ваша статья является громадной логической ошибкой:
Допустим, вы пишете почтовый клиент на С++ ... баг с переполнением буфера – классический образец проблемы с памятью
Такой баг невозможен в современном С++, никакого управления памятью в С++ на данный момент не требуется, всё работает на принципе RAII и не надо рассказывать что вы об этом не знали. Просто откровенно соврали в первой же строке.
проблем с безопасностью, устраненных в продуктах Microsoft
Выдавание частного случая плохого, устаревшего кода на С(НЕ С++) за общее, логическая ошибка
следует из презентации Мэтта Миллера
считает Джошуа Аас
говорит АасПо словам Лоры Томпсон
директор Fastly Тайлер Мак-Маллен
Бесконечные ссылки на "авторитетов", очередная логическая ошибка
В этом году Mozilla передала курирование Rust фонду Rust – это коалиция, основанная Amazon Web Services, Facebook, Google, Huawei, Microsoft и Mozilla. Это признак, что главные тяжеловесы нашей индустрии всерьез прочат Rust большое будущее.
Организация, во главе которой очень странные люди, а финансирование выглядит полностью фейковым. То есть организация для фасада
Если (и когда) Rust под Linux будет добавлен в ядро, это будет первый прецедент, когда в ядре Linux будет официально поддерживаться какой-либо язык кроме C или ассемблера, говорит разработчик ядра Грег Кроа-Хартман.
Linux – не единственная операционная система, в которой используется Rust
Эти предложения идут в тексте подряд и входят в логическое противоречие
Несмотря на это, не весь старый код на C/C++ требуется переписывать. «Мы не пытаемся взяться за тысячи проектов», - говорит Аас. – «Мы сосредоточились на критически важных компонентах, которыми пользуется практически каждый. Я говорю о веб-серверах, ядрах, TLS, DNS, NTP — базовом волокне, из которого сплетен Интернет».
Замена проверенных десятилетиями использования ключевых модулей на какие то поделки на rust НЕ МОЖЕТ быть полезна никому, кроме маркетолога языка rust, это просто абсурд.
Причем, Rust усваивается. Он был признан “самым любимым” языком программирования в рамках опроса разработчиков, проведенного на Stack Overflow в 2021 году – пятый год подряд с тех пор, как вышел на первое место
Удивительно, как это совпало, что единственный язык у которого есть агрессивный маркетинг с покупкой статей и голосов стал "самым любимым", ведь у других языков просто нет стимулов покупать себе голоса в никому неизвестном конкурсе.
И да, удивительно, но всего 2% людей признавших этот язык "самым любимым" написали на нём хоть 1 программу (слова Бъёрна Страуструпа)0xd34df00d
22.10.2021 22:25+3Такой баг невозможен в современном С++, никакого управления памятью в С++ на данный момент не требуется, всё работает на принципе RAII
Как называется опция компилятора, с которой он отвергнет код без RAII?
Выдавание частного случая плохого, устаревшего кода на С(НЕ С++) за общее
Нет. Мы обсуждаем, насколько реалистично писать код без подобного вида багов на плюсах. То, что у микрософта (и гугла, и прочих) это не получается — это достаточно релевантные экспериментальные данные.
korsetlr473
зачем вы опять пытаетесь на "среднеуровневый" язык где управление указателями и памятью натянуть безопасность? Пишите на C# и забудьте проблемы
amarao
C# всё ещё не решает ряда проблем. Например, если вы модифицируете объект, по которому итерируете, это undefined behavior. Не в том смысле, как промах по указателю, но всё равно undefined (в зависимости от того, "вперёд" или "назад" вы меняете итерируемый объект, ситуация меняется).
Модель ownership в Rust позволяет проговорить ограничения интерфейсов на такие выкрутасы, и вынести проблему с "постмортема 'кто же так делает'" на уровень "не компилируется".
DarkEld3r
Не уверен, что это можно называть undefined behaviour. Правда не смог сходу нагуглить: оно действительно нигде не специфицировано?
roboter
Вообще то вывалится с exception
https://www.google.com/search?client=firefox-b-d&q=c%23+modify+object+in+foreach
beskaravaev
Эксепшен Вы получите при использовании библиотечных коллекций, а вот если интерфейс реализован Ваней из соседнего отдела для какой-то внутренней коллекции, то никаких гарантий. Как Ваня решил, так и будет.
roboter
И где тут undefined behaviour? Тут Vasja defined behaviour!!
amarao
При использовании foreach или при использовании любого итератора любыми
next()-подобными вызовами? Насколько я понимаю, второе требует поддержки на уровне типов, а какой тип нам запрещает использование mut-borrowed значения?roboter
Тут я могу ошибатся.
Foreach создаёт read-only копию, как это дальше работает и где это проверяется я увы не скажу.
beskaravaev
Нет, foreach не создаёт копию. Вся ответственность целиком лежит на плечах конкретного типа.
Flux
Насколько я помню у библиотечных структур есть поле для версии структуры которое инкрементится после каждого изменения коллекции, итератор помнит версию структуры с которой он был создан и кидает исключение если версия поменялась.
Не слишком сложный для понимания и реализации концепт чтобы быть аргументом в пользу другого языка.
0xd34df00d
Но это рантайм-проверки, которые занимают время.
Flux
Да, занимают. Ничтожное время. Одна адресация которая попадёт в кэш и один условный переход который запомнится предсказателем в большинстве случаев.
Это буквально бесплатно на фоне наличия в языке GC, а еще это особенность стандартной библиотеки а не языка. Захотите — напишете полностью иммутабельную библиотеку коллекций.
Пример с коллекциями буквально высосан из пальца — он даже не в первой десятке проблем "языка". Большинство программистов сталкиваются с этим два-три раза при изучении языка и всё.
technic93
и по итогу вместо одной интсрукции получилось три
Flux
Понимаю негодование вашего внутреннего перфекциониста, но это всё ещё на две инструкции больше а не втрое больше инструкций. В языке с GC.
Для задач где действительно нужно считать инструкции есть С/С++.
Antervis
а зачем тогда вообще языки с gc, если считать такты они не предназначены, а дополнительная надежность обеспечивается за счет рантайм проверок, которые на тех же плюсах можно делать в режиме прогона тестов под анализаторами, а не в релизе? Вся цель же в том и состоит, чтобы решать проблемы во время компиляции
0xd34df00d
Вот вы абсолютно правильно пишете:
При этом вы же в предыдущей фразе пишете:
Прогон тестов — это ведь не этап компиляции.
Antervis
моя позиция вполне консистентна с точки зрения вопроса "зачем платить за то, что не приближает к цели?"
На определенном уровне можно позволить себе писать плюсовый код, оценивая его качество по ASM-выхлопу компилятора и бенчмаркам, не углубляясь в написание на ASM.
0xd34df00d
Да, и проверять, что компилятор не решил принять какие-то другие решения по оптимизации, в результате апгрейда или просто малейших изменений кода. Нет, проще просто написать вставку.
0xd34df00d
Вы писали о том, может ли это быть аргументом в пользу другого языка. Пара тактов на точно так же отлично предсказываемое ветвление в случае раста (который имеет некоторые рантайм-проверки) вполне нередко высказывается как аргумент против, поэтому практика показывает, что да, может.
Кстати, нет. Для таких задач подходит только ассемблер, возможно, в виде инлайн-вставок либо в лучшем случае интринсиков, но и там появляются особенности с аллокацией регистров, с тем, что не все интринсики мапятся в инструкции, и так далее.
Chuviks2
Как у вас всё просто то)
AnthonyMikh
На языке со сборщиком мусора и null-ами?
Siborgium
Да. Что-то не так? Go показал, что сборщик мусора и null'ы не являются помехой производительности.
AnthonyMikh
Сборщик мусора является помехой производительности, а null-ы являются помехой корректности.
Siborgium
Статья заангажирована в пользу Rust, что неоднократно отмечается в комментариях. В ней недостаточно конкретики, чтобы утверждать, что устранение пиков связано именно с GC, а не с применением новых алгоритмов и структур данных -- а именно такие оптимизации (пусть и вскользь) упоминаются в ней.
При этом сборщик мусора в Go значительно более примитивен, чем сборщики мусора из коллекции OpenJDK.
Согласен.
Впрочем, могу привести и другие примеры -- D и Nim, другие языки со сборщиками мусора, при этом не страдающие от null'ов.
Antervis
когда автор начал менять параметры GC, проблема начала проявляться иначе, в соответствии с изменениями настроек. Этого вполне достаточно чтобы винить именно GC.
не совсем. Статья "заангажирована" в не в пользу конкретно rust, а против языков с GC, потому что именно он был причиной решаемой проблемы.
freecoder_xx
Часто хочется писать код, который потом можно будет хорошо соптимизировать и сэкономить на количестве серверов.
Или хочется писать легковесные бинари (тут еще может пригодиться Go).
Или хочется пользоваться развитой системой типов, при этом делая небольшую и эффективную программу (и тут Go уже не подходит).
Или хочется писать приложения под WebAssembly.
Или хочется писать клиент и сервер на одном языке.
Или хочется писать модули к другим языкам (Python, PHP, ...).
Или хочется безопасного и предсказуемого параллелизма, без всяких volataile.
Или хочется иметь одну коллекцию модулей и библиотек, которые будут применимы во всех вышеперечисленных случаях.
Конечно, при всем при этом нужна безопасность памяти, и C# тут не применим.