Комментарии 112
зачем вы опять пытаетесь на "среднеуровневый" язык где управление указателями и памятью натянуть безопасность? Пишите на C# и забудьте проблемы
C# всё ещё не решает ряда проблем. Например, если вы модифицируете объект, по которому итерируете, это undefined behavior. Не в том смысле, как промах по указателю, но всё равно undefined (в зависимости от того, "вперёд" или "назад" вы меняете итерируемый объект, ситуация меняется).
Модель ownership в Rust позволяет проговорить ограничения интерфейсов на такие выкрутасы, и вынести проблему с "постмортема 'кто же так делает'" на уровень "не компилируется".
Не в том смысле, как промах по указателю, но всё равно undefined (в зависимости от того, "вперёд" или "назад" вы меняете итерируемый объект, ситуация меняется).
Не уверен, что это можно называть undefined behaviour. Правда не смог сходу нагуглить: оно действительно нигде не специфицировано?
Вообще то вывалится с exception
https://www.google.com/search?client=firefox-b-d&q=c%23+modify+object+in+foreach
При использовании foreach или при использовании любого итератора любыми next()-подобными вызовами? Насколько я понимаю, второе требует поддержки на уровне типов, а какой тип нам запрещает использование mut-borrowed значения?
Тут я могу ошибатся.
Foreach создаёт read-only копию, как это дальше работает и где это проверяется я увы не скажу.
Насколько я помню у библиотечных структур есть поле для версии структуры которое инкрементится после каждого изменения коллекции, итератор помнит версию структуры с которой он был создан и кидает исключение если версия поменялась.
Не слишком сложный для понимания и реализации концепт чтобы быть аргументом в пользу другого языка.
Да, занимают. Ничтожное время. Одна адресация которая попадёт в кэш и один условный переход который запомнится предсказателем в большинстве случаев.
Это буквально бесплатно на фоне наличия в языке GC, а еще это особенность стандартной библиотеки а не языка. Захотите — напишете полностью иммутабельную библиотеку коллекций.
Пример с коллекциями буквально высосан из пальца — он даже не в первой десятке проблем "языка". Большинство программистов сталкиваются с этим два-три раза при изучении языка и всё.
и по итогу вместо одной интсрукции получилось три
Понимаю негодование вашего внутреннего перфекциониста, но это всё ещё на две инструкции больше а не втрое больше инструкций. В языке с GC.
Для задач где действительно нужно считать инструкции есть С/С++.
а зачем тогда вообще языки с gc, если считать такты они не предназначены, а дополнительная надежность обеспечивается за счет рантайм проверок, которые на тех же плюсах можно делать в режиме прогона тестов под анализаторами, а не в релизе? Вся цель же в том и состоит, чтобы решать проблемы во время компиляции
Прогон тестов — это ведь не этап компиляции.
моя позиция вполне консистентна с точки зрения вопроса "зачем платить за то, что не приближает к цели?"
Кстати, нет. Для таких задач подходит только ассемблер, возможно, в виде инлайн-вставок либо в лучшем случае интринсиков, но и там появляются особенности с аллокацией регистров, с тем, что не все интринсики мапятся в инструкции, и так далее.
На определенном уровне можно позволить себе писать плюсовый код, оценивая его качество по ASM-выхлопу компилятора и бенчмаркам, не углубляясь в написание на ASM.
Как у вас всё просто то)
На языке со сборщиком мусора и null-ами?
Да. Что-то не так? Go показал, что сборщик мусора и null'ы не являются помехой производительности.
Сборщик мусора является помехой производительности, а null-ы являются помехой корректности.
Сборщик мусора является помехой производительности
Статья заангажирована в пользу Rust, что неоднократно отмечается в комментариях. В ней недостаточно конкретики, чтобы утверждать, что устранение пиков связано именно с GC, а не с применением новых алгоритмов и структур данных -- а именно такие оптимизации (пусть и вскользь) упоминаются в ней.
При этом сборщик мусора в Go значительно более примитивен, чем сборщики мусора из коллекции OpenJDK.
а null-ы являются помехой корректности.
Согласен.
Впрочем, могу привести и другие примеры -- D и Nim, другие языки со сборщиками мусора, при этом не страдающие от null'ов.
В ней недостаточно конкретики, чтобы утверждать, что устранение пиков связано именно с GC
когда автор начал менять параметры GC, проблема начала проявляться иначе, в соответствии с изменениями настроек. Этого вполне достаточно чтобы винить именно GC.
Статья заангажирована в пользу Rust, что неоднократно отмечается в комментариях
не совсем. Статья "заангажирована" в не в пользу конкретно rust, а против языков с GC, потому что именно он был причиной решаемой проблемы.
Часто хочется писать код, который потом можно будет хорошо соптимизировать и сэкономить на количестве серверов.
Или хочется писать легковесные бинари (тут еще может пригодиться Go).
Или хочется пользоваться развитой системой типов, при этом делая небольшую и эффективную программу (и тут Go уже не подходит).
Или хочется писать приложения под WebAssembly.
Или хочется писать клиент и сервер на одном языке.
Или хочется писать модули к другим языкам (Python, PHP, ...).
Или хочется безопасного и предсказуемого параллелизма, без всяких volataile.
Или хочется иметь одну коллекцию модулей и библиотек, которые будут применимы во всех вышеперечисленных случаях.
Конечно, при всем при этом нужна безопасность памяти, и C# тут не применим.
В оригинальном блоге первое предложение капсом смотрится нормально из-за особенностей оформления, но на хабре как-то неуместно. Превьюшки так вообще на агрессивный спам сразу похожи.
быстрое выполнение кода (если верить автору, то на уровне С т.е. немного быстрее Rust).
Чудес не бывает: если безопасность обеспечивается обязательными рантайм проверками (а язык обещает "Bounds checking"), то за это придётся платить производительностью. Плюс, если я правильно понял, то для объектов, время жизни которых нельзя вывести статически, используется сборщик мусора. Это может и практичный подход, но не очень в духе С. В расте большая часть "мусора" в синтаксисе как раз из-за лайфтаймов, а если нас устраивает сборка мусора, то можно взять другой язык.
Ещё про дженерики не совсем понял: получается, что они работают как шаблоны в С++? То есть, ограничения на тип выводятся из того как он используется? Если да, то это, на первый взгляд, позволяет облегчить синтаксис, но потом появляются штуки вроде enable_if и концептов. Не уверен, что финальный результат проще чем растовые дженерики.
Не знаю откуда Вы взяли про сборку мусораДык, прям на главной странице языка написано:
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 дженерики вот-вот должны завести и я бы сказал, что сложность языка после этого вырастет. В питоне они не нужны, но там своих хитростей хватает.
я бы сказал, что сложность языка после этого вырастет
Камон, концепт генериков в гошке простой как двери. Сложность языка конечно вырастет в относительных значениях, но в абсолютных даже джависты (а уж тем более шарписты) будут поплевываться от примитивности. В конце концов, дженерики давно пора включить в стандарт любого программирования вообще, если этого еще не произошло.
Да и Rust, Go и Python инструменты, очень мягко говоря, разные.
Rust по-моему посложнее и Go и Python. Может его адаптируют для системных задач вполне, только пройдут годы для миграции с С++, мне кажется лет 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.
Про GC… Ну на главной странице я как раз прочитал
В моём комментарии речь была не о расте, а о V.
Ну напиши unsafe там где это влияет на производительность.
И это тоже. Напомню контекст:
Безопасное управление памятью и быстрое выполнение кода (если верить автору, то на уровне С т.е. немного быстрее Rust).
Тут или мы добавляем дополнительные проверки или жертвуем безопасностью. Можно ещё статически доказывать (зависимые типы и вот это всё), но это тоже вариант не для всех.
Если что подход раста меня в этом плане вполне устраивает.
vlang не работает. И не работает по совершенно простой причине: автор и не планирует завершать язык хоть когда-то, он хочет сохранять его вечной альфой и получать деньги на то, чтобы его якобы разрабатывать и продолжать кормить обещаниями.
Каждый раз когда мне говорят что у раста хреновый синтаксис я предлагаю человеку озвучить какие улучшения он бы сделал и что стоит сделать иначе. И тут в редких случаях человек предлагает синтаксис ещё хуже, чем был. Но чаще человек просто предлагает убирать куски языка типа "нафиг лайфтаймы", и тогда становится понятно, что человек вообще не понимает, зачем это и почему.
А то так можно сказать что все статически компилируемые языки по сравнению с питоном имеют отвратный ситнаксис. Какие-то static/class/int/… — что за ерунда. Питон прекрасно без них обходится!
Мне непонятно, почему в статье про Rust основной упор делается на управлению памятью. Эту проблему частично решают языки с автоматическим управлением памяти, санитайзеры, чекеры и т. д. Как по мне, гораздо более важно то, что Rust решает большой пласт проблем конкурентного программирования.
К недостаткам Rust я бы отметил, что его концепция плохо ложиться на списочные структуры данных: какой-нить алгоритм танцующих связей будет выглядеть на Rust просто ужасно :)
Потому что в Rust управление памятью автоматическое на уровне компилятора, а не рантайма. В рантайме на память не тратится ни такта, если не используется куча, и тратится не более, чем в плюсах, если куча есть.
какой-нить алгоритм танцующих связей будет выглядеть на Rust просто ужасно
Нормально оно будет выглядеть. Только не забывать, что в случае кольцевых ссылок модет случиться легальная утечка памяти, и за этим надо следить отдельно.
Вот попробуй реализовать на досуге, там каждый объект находится в двух двусвязных циклических списках, плюс используется хак, что если объект был только что удалён из списка, то можно его быстро вставить назад двумя операциями... И всё это очень сильно противоречит тому, что на объект может быть только одна мутабельная ссылка.
А утечек памяти там не будет, потому что все объекты можно выделить один раз в векторе каком-нить. Меняются только связи между ними. Так что скорее всего в данном случае лучше хранить не ссылки, а индексы элементов, чтобы хоть как-то легло.
Ну то есть задача не решается в лоб хранением ссылок, только и всего.
Точнее, хранить ссылки можно, если используется куча. А она использоваться будет по любому, если количество элементов вариабельно или не известно.
>Ну то есть задача не решается в лоб хранением ссылок, только и всего.
Задача решается либо через умные указатели, привносящие оверхэд, либо через обычные, вынуждающие либо покрывать unsafe каждое разыменование, либо вообще все обернуть в unsafe -- но в чем тогда смысл unsafe?
>Точнее, хранить ссылки можно, если используется куча.
Не совсем так. Хранить ссылки можно, если владение всеми элементами принадлежит кому-то еще, и время их жизни гарантированно превышает время существования списков, где они хранятся. Это сильное требование.
через обычные, вынуждающие либо покрывать unsafe каждое разыменование, либо вообще все обернуть в unsafe
Берите дальше - если цель реализации алгоритма полезное использование хранимых данных (читай - доступ извне), а не просто реализация, unsafe там откровенно навредит.
Не совсем так. Хранить ссылки можно, если владение всеми элементами принадлежит кому-то еще, и время их жизни гарантированно превышает время существования списков, где они хранятся. Это сильное требование.
Невозможное при практическом, а не академическом использовании, если быть честным.
но в чем тогда смысл unsafe?
Не забывайте, что unsafe - это полноправный элемент языка Rust. Смысл в том, что ваша небезопасная реализация с указателями будет изолирована внутри вашего модуля и наружу будет торчать только safe-интерфейс. Именно так и именно для этого и используется unsafe.
Я пишу:
>либо вообще все обернуть в unsafe -- но в чем тогда смысл unsafe?
Вы отвечаете:
>>но в чем тогда смысл unsafe?
>Смысл в том, что ваша небезопасная реализация с указателями будет изолирована внутри вашего модуля и наружу будет торчать только safe-интерфейс.
Нет. Если все обернуть в unsafe, то наружу будет торчать модификатор unsafe. С тем же успехом можно на С/С++ писать функции, вставляя слово unsafe в название.
Если же вы имеете в виду обертку наподобие
fn foo() {
unsafe { ... }
}то такая обертка бессмысленна, так как не выделяет действительно небезопасных мест, наоборот, усложняя исследование функции на предмет ошибок при работе с unsafe-операциями.
Судя по всему вы просто не понимаете, как используется unsafe в Rust. Посмотрите реализацию чего-нибудь в стандартной библиотеке, там во многих местах используется unsafe, скрытый за безопасным внешним API.
Судя по всему вы просто не понимаете, как используется unsafe в Rust
Пожалуйста, отвечайте по делу. Я понимаю, как используется unsafe в Rust, и я регулярно пишу код на Rust. В своем комментарии я рассмотрел оба варианта применения unsafe в данном контексте, в ответ я получил... несостоятельную критику и переход на личности, мягко говоря.
Нет. Если все обернуть в unsafe, то наружу будет торчать модификатор
unsafe. С тем же успехом можно на С/С++ писать функции, вставляя слово unsafe в название.
Видимо вы имеете ввиду, что ваш unsafe используется во внешнем публичном API. Но вопрос: зачем так делать? Такое нужно только для низкоуровневых системных функций, которые небезопасны по призванию.
Видимо вы имеете ввиду, что ваш unsafe используется во внешнем публичном API.
Да, я рассматриваю именно такой случай в цитируемом контексте.
Но вопрос: зачем так делать?
Такое нужно только для низкоуровневых системных функций, которые небезопасны по призванию.
Вы сами ответили на свой вопрос. Вы считаете, что на Rust нельзя писать низкоуровневые системные функции? Или вы считаете, что написание низкоуровневых системных функций на Rust не является валидным юзкейсом для обсуждения?
Более того, unsafe нужен не только для "низкоуровневых системных" функций, а для всего, что может выходить за рамки Safe Rust по тем или иным причинам, например, производительности ради -- и это вполне может быть достаточно высокоуровневая логика.
unsafe во внешнем API нужен только системным функциям. Изначально речь шла о списочных структурах данных и хитрых алгоритмах на них. Я сказал, что можно использовать unsafe, но нужно сделать к нему безопасный внешний API. Только и всего, так в Rust делается часто. Необходимости использовать unsafe в API тут нет.
наружу будет торчать только safe-интерфейс.
Ха, главный вопрос, можно ли это сделать? Если наружу торчят итераторы по двусвязному списку или ещё что-то, - то не просто. А если надо два итератора таких? В итоге, гипотетически unsafe может протекать очень глубоко наверх пока интерфейс не сведётся к чему-то примитивному.
Может быть, но на практике обычно удается локализовать unsafe. В том числе и для итераторов. Мне сложно представить ситуацию, когда это сделать нельзя или слишком накладно. Если у вас есть пример, то хотелось бы на него взглянуть.
К сожалению примера нету, ну и в расте чаще идут по пути - сделаем арену и дальше будет по индексам обращаться, чтобы если что - просто упало. Единственный интересный пример, который я помню это про бинарное дерево в std. Конечно сам BTreeMap имеет сейф интерфейс, но вот в реализации была попытка сделать меньше ансейфа. И там довольно всё запутанно мне показалось при первом прочтении, может со второго раза зайдёт. Так что предполагаю что связные списки и деревья это большая проблема.
Ещё когда-то давно не могли придумать как сделать иерархию компонентов UI, но там выкрутились в итоге реактивным подходом. Вообщем хотелось бы больше видеть примеров про использование лайфтаймов в ситуациях сложнее чем слайс векторов, вместо рекламных статей с нулевой инофрмацией.
Что то ссылка умерла. Возможно хабра эффект. Упс. Ждите новость что русские хакеры атаковали страничку университета.
Ну да, а чем арена плоха? В разных языках есть разные способы смоделировать одно и то же, в расте вот арена, потому что прямые ссылки фигово работают. Но индекс в арене слабо отличается от адреса в памяти, поэтому не вижу принципиальной проблемы. В худшем случае все работает так же как в плюсах, с теми же проблемами. В лучшем всё же есть некоторые положительные моменты.
Это пример о том что "нельзя локализовать ансейф". Доступ по индексу это рантайм проверка, что не круто в контексте обсуждения борроу чекера.
Ну как минимум арена плоха тем что после того как она раскочегарилась ее обратно не "закочегарить" даже если число живых объектов уменьшилось на порядки, потому что по ней рандомно разбросаны живые объекты. Ну или придется реализовывать локальный garbage collector
А это в свою очередь плохо тем что абстракция "арена" протекает повышенным потреблением памяти.
>Только не забывать, что в случае кольцевых ссылок модет случиться легальная утечка памяти, и за этим надо следить отдельно.
К сожалению, "легальность" утечки памяти ничем не улучшает ситуацию и не облегчает задачу тем, кто будет заниматься отладкой и профилированием программы с целью исправления утечки.
Пожалуйста, уважаемые представители других языков, хватит хоронить C++. Он нам очень нравится и мы соблюдаем все меры предосторожности используя последние стандарты и умные указатели, а не C-style casts и подобную бесовщину!
И как современный C++ поможет мне тут?
подобные ошибки прекрасно ловятся санитайзерами, никакой проблемы тут нет.
Да? И каким же, например? И, кстати, вы сами-то санитайзеры используете?
ой, а вы не знаете, каким? Ну в принципе не удивительно, частое явление среди растоманов.
Попросите вежливо, тогда подскажу :)
Сделать -fsanitize=address вместе с detect_stack_use_after_return=1. Но это надо будет запускать программу с проблемным кодом (не путать санитайзеры и статические анализаторы).
Благодарю. А теперь вспомним две вещи:
- Санитайзинг — суть те же тесты, и потому имеют те же слабости: санитайзеры могут показать, что программа сломана, но совершенно не могут показать её безошибочность, и санитайзеры покажут проблему только в том случае, если исполнение зашло в проблемную ветку кода, то есть покрытие путей исполнения для эффективной детекции ошибок должно быть достаточно высоким, а писать тесты никто особо не любит.
- Повисшие ссылки (а string_view семантически ссылкой и является) являются в C++ неопределённым поведением, потому компилятор может преобразовать программу, исходя из невозможности этого неопределённого поведения. Таким образом, санитайзер будет тестировать не ту программу, что написал программист, а ту, которую сгенерировал компилятор, и их поведение может отличаться. В худшем случае компилятор может вообще убрать проблемный путь исполнения, который мы пытаемся поймать санитайзерами.
а string_view семантически ссылкой и является
Когда вы ссылаетесь на UB, странно использовать семантический смысл. string_view это связка указателя и целочисленной переменной. С точки зрения стандарта это принципиально разные вещи.
Повисшие ссылки являются в C++ неопределённым поведением
Опять же, в нашем случае - указатели. Но так или иначе, неопределенное поведение возникает не в вакууме, а при доступе к dangling pointer. Все это четко прописано в стандарте в разделе 6.7.3.
потому компилятор может преобразовать программу, исходя из невозможности этого неопределённого поведения
Из пояснения выше - в моменте возврата dangling pointer - не может. Санитайзер отлично справится с задачей.
А еще, справедливости ради, такое должно ловится даже не санитайзерами, а SCA. В GCC инструмент явно не доделан. А даже если по итогу он не сможет ловить вложенные кейсы - он и не претендует на сколь-либо серьезный статус SCA.
Предвкушая ваш вопрос о "сами то используете": в коммерческой разработке? Конечно. Во многих проектах без SCA заказчик не станет с вами работать, а в по-настоящему серьезных проектах, код не имеет ни шанса пройти сертификацию.
Чем ваш пример принципиально отличается от возврата локальной переменной по ссылке, тем что варнинг не отработал? Так сделайте статичную ссылку на локальный объект, верните ее. Или верните shared_ptr от this вместо enable_shared_from_this.
shortest концептуально невалиден так же, как и cut_prefix, и C++ тут мимо проходил, это вопрос дизайна собственного кода и понимания языка, с которым работаешь.
И тут -Wlifetime не обязан спасать, лишь помогать в тривиальных случаях. Но если акцент именно на нем, то может хотя бы релиза фичи дождаться?
Чем ваш пример принципиально отличается от возврата локальной переменной по ссылке, тем что варнинг не отработал?
Тем, что в example_should_ok возврата локальной переменной по ссылке таки нет.
shortest концептуально невалиден так же, как и cut_prefix, и C++ тут мимо проходил, это вопрос дизайна собственного кода и понимания языка, с которым работаешь.
Так, а вот про это можно поподробнее? Вроде бы string_view как раз сделали для того, чтобы не копировать строки лишний раз. И с самими этими функциями проблем нет, они возникают на месте применения.
И тут -Wlifetime не обязан спасать, лишь помогать в тривиальных случаях. Но если акцент именно на нем, то может хотя бы релиза фичи дождаться?
Ну так в более простом случае он таки действительно помогает, но с ложно-положительным срабатыванием.
>Вроде бы string_view как раз сделали для того, чтобы не копировать строки лишний раз.
И снова ошибаетесь, почитайте proposal для string_view, буквально первый раздел. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3921.html
Мы действительно можем получить некоторый range строки, который, разумеется, будет non-owning. И мы действительно можем использовать этот функционал локально или применяя ООП.
А теперь вернемся к вашему примеру и вашим функциям.
Возврат вообще чего-либо non-owning из семантически чистой функции - грубая ошибка дизайна. По этой же причине невалидны обе ваши функции, и по этой же причине уместно сравнение с возвратом локальной переменной по ссылке.
Должен ли компилятор наказывать за такое? Было бы неплохо, но, надеюсь, не нужно пояснять, почему он не обязан этого делать.
Иными словами, еще раз: язык тут не причем. Хотя, в каком-то смысле, вину C++ может увидеть в том, что у многих сложилось впечатление, что он с течением лет превращается в ту доминирующую группу языков, где можно писать код не используя мозг.
>Компилятор вообще ничего не обязан делать, но чем больше ошибок компилятор предотвращает, тем лучше.
Ну как же, компилятор обязан делать то, что явно указано в стандарте. Но раз вы возражаете, разверну свою банальную идею про отсутствие обязательства предотвращения таких ошибок: если нет тривиального способа обнаружить ошибку, обязанность, возложенная на компилятор потенциально существенно усложнит имплементацию. По этой причине большая часть диагностик имплементируется на уровне "так можно но нельзя", и примерно по той же причине стандарт С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 для всех указателей".
Какой именно матчасти?
С которой работаете. Разного уровня. Но не надо утрировать и спускаться туда, что едва может пригодится. В данном случае контекстом была функция и "владение" объектом.
Если вы будете работать с многопоточностью, вам придется погружаться в матчасть concurrency и модели памяти.
Высоконагруженные системы или рендеринг - во многих случаях аллокаторы и снова модели памяти.
зачем тогда C++
В общем-то это ответ и на остальные вопросы, и естественно, это лишь мое видение:
С++ это зрелый, проверенный временем (и гигантским количеством кода) язык, для которого существует не только гора библиотек, но и огромное количество методологий, инструментов, гайдлайнов, и прочих смежных практик. С рынком все обстоит сложнее, и я тут экспертное мнение выразить не могу.
Если по вашему это все тоже легаси, а легаси это плохо - а у вас есть уверенность, что Rust тот же во всем лучше? Перепишут на него весь софт, драйвера, да и ОС заодно. Но где-то в середине процесса поймут, что он все же не так хорош, есть идеи получше, и нужен новый язык.
Вообразите, что получится?
ИМХО, пусть удачные языки развиваются и набирают обороты, а время покажет нужное направление. 10 лет - чудовищно молодой возраст для языка, чтобы бросится переписывать на него все, что можно.
Но это снова специфика плюсов, верно?
Если вы про "владение" объектом, у RAII своя специфика, но на этом уникальность заканчивается. Все остальное тоже лишь частично специфично для плюсов. Концепции примитивов синхронизации или размер кэшлайна, например, вообще к языку отношения не имеют.
Но в плюсах подобные знания, по моим наблюдениям, требуются гораздо чаще, чем в других "популярных" языках.
Время проверяет только возможность писать что-то на языке. Оно не проверяет оптимальность этого решения.
Речь не об оптимальности, а о целесообразности.
Я нигде не говорил, что надо на расте что-то имеющееся переписывать. Речь только о новых проектах, не более.
Это говорил автор статьи. Раз вы топите за Rust в этой дискуссии, я решил что вы и с текстом статьи согласны :)
Концепция владения ресурсом, она и в расте, и везде есть.
Возврат вообще чего-либо non-owning из семантически чистой функции
Кто такая cемантически чистая функция?
Из функции, которая семантически является чистой.
Дизайн возникает от юзкейсов. Если вам может потребоваться сделать return id(&local_variable);- да, это ошибка дизайна.
В примере AnthonyMikh именно такой пример и приведен
Rust возник из критики C++ и претендует на его нишу. Так что вашу просьбу удовлетворить не получится, прекратить критиковать плюсы для него равносильно остановке в развитии.
Какая-то очередная супер шаблонная статья про Rust:
Шаг 1: заходим сразу с террора. Рассказываем о том, к каким страшным последствиям могут привести ошибки памяти. На одном-двух абстрактных примерах, никакой конкретики. Забываем упомянуть про степень готовности языка для разработки критически важных систем.
Шаг 2: ссылаемся на исследование майкрософтом своей легаси кодобазы, написанной преимущественно на си и доисторическом стандарте плюсов.
Шаг 3: пишем какой rust быстрый и безопасный. Быстрый в сравнении с языками с GC и автоматическим управлением, безопасный относительно языков с ручным. Далее нечетные шаги пропускаются, т.к. они лишь повторяют этот пункт
Шаг 4: Два предложения про сабж статьи
Шаг 6*: Пишем какой с++ плохой, ведь управлять памятью надо вручную. Про последние 10 лет развития плюсов не упоминаем, несмотря на то, что расту официально всего 6.
Шаг 8-14: цитируем тщательно избранных апологетов. Можно миксануть мнение кого-то авторитетного, в этом случае - Линуса Торвальдса, который говорит не торопиться с растом
Шаг 16: рассуждаем о том, как хочется всё переписать, и как после переписывания на раст в программах точно не останется прям ни единого бага, и как много надо переписывать, и поэтому надо начинать сразу с самых корневых модулей.
Шаг 18-22: повторяем 8-14
Шаг 24: ловим кучу плюсиков от любителей раста, написавших на нем не более helloworld
Шаг 25: отключаем уведомления чтобы проигнорировать 1000+ комментов срача
Кажется, что вебу на Rust все-таки быть, по крайней мере его экосистема в эту сторону неплохо развивается.
на какую нишу в вебе претендует Rust?
На всю )
реально на всю? И вместо 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) тоже самое по сравнению с JS
реально на всю? И вместо 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 таких проблем нет.
я понял, вам очень нравится 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 заменит большую часть кода и на сервере )
Речь не про века а в банальной экономии. "докупим плашек и норм" перестает нормально работать когда за сервера платить начинаешь уже за миллион рублёв в месяц, а разраб который мог бы срезать их количество в разы стоит всего пару сотен.
Архитекторы которым плевать го или раст — нормальные люди и принятие решения вообще в другой плоскости, да, но которые не видят между ними разницы просто профнепригодны. В любом случае раст и го тут не выделяются, может быть выбор хаскель или жс, такое тоже встречал.
И в вебе (фронтэнде) лабать нужно очень быстро. Потому даже если на Rust писать и можно, вряд ли это станут делать в большом количестве
Если речь про кнопки со скругленными углами то скорее да чем нет. Если же речь про какую-нибудь онлайн игрушку желательно с тридэ, то у раста уже есть шансы.
Хотя учитывая сколько обычных сайтов на одну игрушку в распространенность раста в фронтенде я слабо верю.
Речь не про века а в банальной экономии. "докупим плашек и норм" перестает нормально работать когда за сервера платить начинаешь уже за миллион рублёв в месяц, а разраб который мог бы срезать их количество в разы стоит всего пару сотен.
Rust начали использовать в AWS точно, но я не помню используют ли они его именно для веб сервисов. По-моему больше используют какраз как системный язык. Google же вполне адаптировал Go. Я думаю что потребление памяти, пропускная способность и задержка у Go незначительно хуже чем у Rust, а вот отсутствие GC усложняет кодирование. Rust же защищает в большинстве случаев от ошибок памяти. От дэдлоков или гонок уже не защищает, верно? Итого выходит что сколько там той безопасности по итогу. Ошибки при кодировании связаны не только с памятью, и нет такой системы типов которая бы защищала от ошибок бизнес-логики. Я бы назвал это когнитивный биасом "переоценка типизации для предотвращения ошибок" (я вижу что некоторые считают что стоит сделать супермощную систему типов, и это будет панацея) Во-всяком случае я не видел исследований которые бы говорили какой процент ошибок памяти в программах на java. Можно конечно утверждать что остальные ошибки в java коде связаны со слабой (по мнению раст-сообщества) системой типов, но думаю это уже было бы ничем не подкрепленным заявлением. При этом Go имеет встроенный тулинг для профайлинга, быстро билдится, а значит ускоряет цикл фидбэка программисту.
Короче я не вижу реально сколько-нибудь несубъективных моментов. Вижу только что Google почему-то вполне адаптировал Go для части вебсервисов, но я не слышал ничего подобного о Rust (может просто не слышал?). Нельзя же полагать что они там в Google все дураки?
лично я со своей колокольни вижу что Rust может быть применен для написания вебсерверов, но для вебсервисов - в 95% это оверкил. Если же говорить чисто о субъективных предпочтениях, то понятно что нормальный архитектор по возможности пытается избегать личной предвзятости в выборе инструментов
Если же речь про какую-нибудь онлайн игрушку желательно с тридэ, то у раста уже есть шансы
ну зато интересная мысль, чо )
уже за миллион рублёв в месяц, а разраб который мог бы срезать их количество в разы стоит всего пару сотен.
что-то мне подсказывает что не все так просто) Если такие счета, то вряд ли это мелкая система которую перепишут за 1 человеко-месяц. А если взяли более сложный инструмент - получите более высокую стоимость поддержки этого кода (всегда). Сколько будет стоить уже такой разклад? Наверняка выгода-то будет, но спустя время, и надо садиться и считать. А за то время пока кто-то переписывает продукт чтоб сократить биллинг ресурсов - кто-то другой делает новые фичи и имеет потенциал откусить часть рынка
Я думаю что потребление памяти, пропускная способность и задержка у Go незначительно хуже чем у Rust
Citation needed. Получается несколько голословно.
По моему опыту разница существенная.
Rust же защищает в большинстве случаев от ошибок памяти. От дэдлоков или гонок уже не защищает, верно?
И от rm-rf не защищает, да. Но во-первых защищает так же от data race, т.е. накосячить с многопотоком в расте действительно сложно. Во-вторых проблемы с памятью по репортам того же гугла это причина 70%+ багов. Не говоря про проблемы с памятью которые дебажатся неделями вместо того, чтобы быть отловленными компилятором. Это уже PVS не раз рассказывала — если анализатор показывает мало проблем, это не всегда означает что он не нужен, просто люди потратили кратно больше времени, чтобы вычистить всё руками. Насколько это хорошо — оставляю вам решать.
Ошибки при кодировании связаны не только с памятью, и нет такой системы типов которая бы защищала от ошибок бизнес-логики.
И да и нет. В голову конечно залезть программисту компилятор не может и узнать что спека составлена неправильно тоже. Но учитывая все эти "проблемы на миллиард" (которые уже на триллионы наверное пошли) — зачастую всё куда проще, и даже простая невозможность получить ошибку с нуллом это уже кратное уменьшение всех возможных багов. А если ещё и пользоваться возможностями систем типов по полной — то тут и бизнесовые баги можно вылавливать. Но от всех бед конечно не спасет, так что можно заключить, что это дорогая ненужнная игрушка и продолжать кодировать, как завещали предки.
лично я со своей колокольни вижу что Rust может быть применен для написания вебсерверов, но для вебсервисов — в 95% это оверкил. Если же говорить чисто о субъективных предпочтениях, то понятно что нормальный архитектор по возможности пытается избегать личной предвзятости в выборе инструментов
Для вебсерверов раст более чем полезен. Я лично год назад переписывал с шарпа на раст одну штуку. 10 тысяч строк были переписаны за неделю, небольшой сервисок. Снизили нагрузку на порядок, потребление памяти в пару раз. Вполне неплохой результат кмк. Не говорю что на каком-нибудь го было бы хуже, но и не лучше.
что-то мне подсказывает что не все так просто) Если такие счета, то вряд ли это мелкая система которую перепишут за 1 человеко-месяц.
Вы явно недооцениваете сколько инженеров можно добавлять на оптимизацию кода, пока это не станет невыгодным. Понятно, что не все гугл, но даже компании в пару десятков человек сталкиваются с миллиоными счетами на инфраструктуру. Попробуйте узнать, сколько ваша компания тратит на это, возможно это будет сюрпризом.
А за то время пока кто-то переписывает продукт чтоб сократить биллинг ресурсов — кто-то другой делает новые фичи и имеет потенциал откусить часть рынка
Ничего не мешает нанять двух разработчиков, правда?
Citation 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 только в критических частях инфраструктуры. Если вдруг они начнут переписывать и перепишут всё остальное - тогда это будет повод задуматься.
многовато вышло текста, надеюсь не утомил)
у меня сейчас нет под рукой хороших ссылок, в основном по бэнчмаркам видел что разница небольшая. Мне кажется это логично т.к. в вебсервисах (и особенно микросервисах) чаще io-bound задачи, т.е. вебсервис это не числодробилка.
Но бывает и наоборот. Точнее если вы пишете числодробилку то для неё нужно какой-то интерфейс иметь, и обычно это HTTP. Вот типичный пример такого приложения.
Для IO-bound перекладывания SQL в жсоны и наоборот конечно ничего этого не нужно.
видимо вы имеете в виду что из-за передачи владения не выйдет поменять.
Владение не при чем, речь про Send/Sync трейты которые в типах зашивают с чем и как конкретно потокобезопасно можно работать, а с чем и как нельзя.
В принципе может и так, но если говорить о гонках вообще — то думаю вряд ли Раст от них защитит (data races — это подмножество race condition).
А это в принципе нерешаемая задача, потому что гонка всегда может быть в каком-нибудь редисе или БД. Язык может только за себя отвечать.
Насчет репортов Гугла и 70% ошибок из-за памяти — этот пласт ошибок актуален больше для языков без GC.
Так а раст не претендует на языки с ГЦ по сути. Если есть возможность тащит гц — отличо, берем скалу/хаскель и пишем всё ещё в 10 раз безопаснее и быстрее)
Интересно, спасибо.
А использовали при этом асинхронный ввод-вывод?
Естественно. Синхронное сетевое IO это деньги на ветер, я такое в принципе в прод не пишу и другим не даю когда ревьювлю.
я вполне верю, т.к. видел траты крупных компаний на инфраструктуру. Т.е. сама идея уменьшения биллинга на ресурсы конечно разумная. Просто у Гугла допустим тоже огромные системы, и они вполне неплохо обкатали Го для этого. Тоже как никак опыт.
Если у вас инфраструктура в миллион раз меньше чем у гугла это все равно заметные тысячи долларов, которые зачастую выгодно сэкономить. Пример выше к слову я приводил про компанию в которой работало всего 10 разработчиков. И все равно оказалось что биллинги за инфру достаточно большие. Да что там, посмотрите какие требования у parler для жалкого мессенджера — там можно полсотни разрабов посадить переписывать и они все окупятся.
та понятно что можно, но нужно учитывать и стоимость поддержки. Более сложная технология (а Раст — такая) — больше стоимость поддержки (а это не 1 месяц, а годы).
Дороже по сравнению с чем? С плюсами нет, с гц — если есть возможность взять гц то нужно его брать и не думать. Но часто возможности нет, и проблемы тут начинаются намного раньше чем при размерах уровня дискорда.
многовато вышло текста, надеюсь не утомил)
Можно написать тупой код по гайдлайнам будучи джуном и получить тот же перф, что и сениор хаскеллист, обмазанный анбоксами, шебангами и собственными эффективными интерпретаторами определенных эффектов. Причем зачастую память будет жраться на порядок меньше потому что язык мотивирует отказ от боксов где возможно.
Так смысл именно в том, что ты можешь посадить джуна писать код, и если оно растом в целом скомпилировалось, то перформанс решения будет практически оптимальный, не считая алгоритмики конечно.
Просто у нас было решение на ГЦ языке и у нас некоторые компоненты стали выжирать слишком много инстансов. Менеджмент оценил целесообразность решения техдолга и переписывания на что-то более оптимальное. Я переписал пару сервисов на раст и сменил работу. Чтобы допилить мой кусок туда кинули пару джунов, ну и они без каких-либо проблем или отломов вполне прилично дописали, как мне рассказывали.
Зато тот же джун не пойдёт иметь глобальное состояние и прочие прелести безэффектной императивщины — и хотя куча кода в вебе тоже write-only, я склонен считать, что возможность этот код поддерживать и, этсамое, reason о нём, важнее.
В расте тоже нет глобального мутабельного состояния потому что оно компилятором запрещается. Не так все круто как в чистом ФП конечно, но для наших земных нужд вполне норм.
Вся ваша статья является громадной логической ошибкой:
Допустим, вы пишете почтовый клиент на С++ ... баг с переполнением буфера – классический образец проблемы с памятью
Такой баг невозможен в современном С++, никакого управления памятью в С++ на данный момент не требуется, всё работает на принципе 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 программу (слова Бъёрна Страуструпа)
Как Rust-разработчики делают Веб безопаснее