Все это было в Ангуларе, но фронтендерам претят ООП, всякие архитектурные паттерны, принудительная типизация и подобное. Там сейчас тренд такой, от одного слова class плеваться, изобретать костыли поверх функциональщины, а потом гордо пытаться годами чинить то, что изначально работало до "переосмысления". Вот и получается хождение по спирали
Про union знаю, чуть выше как раз в моменте про unsafe его упоминал. Про прикол с енамом не знал. Помнил, что на String и прочих подобных типах всегда выходило одинаково, поэтому отложилось так в голове. Почитаю потом подробнее
К слову, в GAPI, с которыми работаю, очень важно положение данных в памяти, иначе при передаче с CPU на GPU в шейдер мусор приедет вместо данных. Там как раз приходится приседать с паддингами, выравниванием и прочим. Но для wgpu (раст реализации стандарта WebGPU с поддержкой нативных платформ кроме веба, которую использует Mozilla у себя) есть такой вот замечательный проектик, который гарантирует корректное расположение в памяти для произвольных типов данных, причем еще во время сборки. Благодаря чему и получается не думать о лейауте данных в памяти, и такие вот нюансы выветриваются за ненадобностью
Я имел в виду, что там не происходит какого-то выделения памяти под сами эти "объекты", их вообще по сути нет, есть проверки на их значение (которые тоже там во всякое разворачиваются, например в проверку ссылки), но по сути это те данные, которые в них хранишь. То есть, Option<i32> займет ровно 4 байта на i32 внутри него, ничего лишнего там не будет, никакого оверхеда относительно голого указателя и ручных его проверок везде. Несмотря на удобство работы с ним в коде, использование дженерика, общий вид как объекта с методами и тд
Это ключевое отличие от аналогов в других языках, например Optional в Java, который именно отдельный объект со всеми вытекающими (его создание и удаление, оверхед любого объекта в памяти из-за метаданных и тд)
Upd: единственный известный мне язык кроме Rust, где есть такие енамы - это Swift. Они в целом с Rust очень сильно похожи, после Rust я книжку по Swift проглотил за день и пошел писать на нем, когда разок понадобилось, потому что очень сильно смахивает на Rust и Kotlin. И это касается многого, например guard из свифта - это let else из раста. Там целый список можно набрать
Ну и бесплатные абстракции, конечно, на енамах не заканчиваются, там вообще очень многое из удобного во время сборки разворачивается в то, как это пишут сишники
Если скажете, что, мол, надо смотреть на долгосрочное думание про время жизни и всё равно всплывёт, то я скажу, что баги можно и не фиксить, будет автоматически перезапускаться раз в полчаса и никаких проблем.
Ошибка защиты памяти - не равно утечка памяти. Ошибка защиты может происходить когда угодно (а не накапливаться со временем), в зависимости от логики программы, и представлять собой критическую уязвимость безопасности. И от регулярных перезагрузок магически никуда не исчезнет
Upd: еще дополню немного. Конечно всегда можно, условно, забить, сделать тяп-ляп и в прод поскорее, для такого Rust будет мешать, это вообще язык не про прототипирование. Но это тоже чревато, вон Cloudflare разок напоролись на Cloudbleed, принесший кучу убытков, как финансовых, так и репутационных, как раз из-за ошибки памяти. И этого им хватило, чтобы начать массовую миграцию на Rust, с написанием своего решения на замену nginx с обвязкой из си и плюсов, которые у них до этого работали. И кстати, в мире Rust давно уже есть rustls библиотека, полный аналог openssl, но на расте (что и позволило проектам на нем избежать Heartbleed в том числе). Пока жареный петух не клюнет, многие не думают. Но те, кто более дальновидный, решают проблемы заранее
Статистику можно подогнать любую.
А так у меня речь шла про компанию уровня FAANG с офисами в десятках стран мира и десятками (если уже не сотнями) терабайт исходников. Куда уж "реалистичнее". Они что-то, наверное, про сборку большого количества кода с зависимостями понимают. Их решения не всем подойдут, мягко скажем, но работает отлично в рамках компании.
Ну вот Microsoft - это не компания уровня FAANG (или теперь их правильно называть MANGA?)? Или они у себя не смогли в тулинг и поэтому столько уязвимостей? Я понимаю, что иногда хочется отмахнуться от неудобной статистики, но с фактами сложно спорить. И это кстати как раз те компании, которые могут себе позволить написать вообще все свое с нуля, благодаря чему и не столкнуться с проблемами простых смертных)
Вы смотрите на то, как люди пишут на C++, и ужасаетесь, что они это делают не так, как на Rust, и тратят время на другие проблемы. А они смотрят на то, на что они будут тратить время при написании кода на Rust и думают то же самое.
Все есть яд и все есть лекарство. Разница только в дозе. Одно дело, когда сложно писать один конкретный тип вещей (для которых и так уже библиотеки написаны. Не забываем, это не плюсы, тут можно не писать все с нуля каждый раз). И другое - когда у тебя весь язык в этих проблемах, от инклудов и зависимостей до совместимости и стандартной библиотеки
А такие уж они zero cost? Вон в C++ внезапно оказалось, что std::unique_ptr ни разу не zero-cost, хотя казалось бы: обёртка над чистым указателем, которая вызывает delete в деструкторе. Ан нет — ABI мешается. Не стандарт, именно ABI. И, подозреваю, у Rust с ABI должны быть похожие ограничения.
В Rust нет стабильного ABI, частично из-за этого как раз (емнип кстати в C++ тоже нет между компиляторами). Есть только режим сборки в сишную либу и поддержка C ABI, для FFI и подобного. И таки да, есть оптимизации с условной пометкой "может быть", такие как вызов .clone(), который часто оптимизируется в noop, а есть гарантированные оптимизации (например, что Result и Option занимают ровно столько памяти, сколько голые лежащие в них данные, а сами по себе вырезаются на этапе сборки). Благодаря таким гарантиям можно использовать большую часть сахара и не бояться, что что-то просядет.
Например, сторонний инструментcppcheck прекрасно видит проблему без каких-либо дополнительных флагов:
А многие сидят без чекеров или с более тупыми чекерами. Опять же, частный случай, когда используется только то, что нужно - это именно частный случай
И это только данный пример с боровом. Как подобный инструмент будет валидировать время жизни ссылок в сложных случаях вызовов библиотек с кучей фукнций и тд? В Rust я знаю, что там будут лайфтаймы ссылок, по которым уже можно однозначно проверить их время жизни (для чего и были придуманы). А если в языке просто нет этой однозначности?
Ну а если заниматься ещё и динамическим анализом вроде Address Sanitizer/Valgrind, то найдётся абсолютно всё, тут теорема Райса неприменима.
Откуда тогда такое количество глупых багов и уязвимостей-то берется? Видимо далеко не все используют. Ну и опять же, это теплое с мягким, потому что я говорю про проверки времени сборки, а это инструменты для анализа рантайма. Далеко не каждый проект можно тривиально гонять в рантайме по всем возможным случаям, плюс это тоже доп работа и тд. Против того, что гарантирует сам язык
считаем ли мы класс ошибок X настолько критичным, чтобы заставлять программиста доказывать их отсутствие в программе компилятору. С учётом того что и в Rust бывают баги и в компиляторе, и в borrow checker, и в стандартной библиотеке.
99% защита от ошибок все еще лучше, чем 10%. Цифры, очевидно, случайные, но суть думаю ясна. Было исследование университета Ватерлоо по похожему поводу. Исследовали вероятность занесения уязвимости (простые баги не учитывались) новым коммитом в проект на C++ и Rust, в зависимости от опыта разработчиков. В итоге вышло 4% для C++ и 0.06% для Rust в сложном проекте. При этом было примечание, что в проектах на C++ многие уязвимости вносились повторно, уже после их устранения, по мере развития проекта. И 87% уязвимостей в C++ относились к ошибкам памяти, которые как раз и предотвращает Rust. Похожая статистика была и у Microsoft, там было 70% их уязвимостей из-за памяти, и они тоже ссылались на Rust как на решение
там хочется писать много-много некорректного кода для прототипирования, а не рефакторить, чтобы удовлетворить компилятор
Ну это справедливо ровно в той же степени, в какой "в TypeScript хочется писать везде any и не думать о типах". То есть, да, для кого-то это так. Но тогда не было смысла брать такой язык, если не хочешь пользоваться его преимуществами
Кстати, по этой же причине Python может нравится и больше Rust.
Это разные языки для разного класса задач. Никто вроде и не предлагал заменять Python на Rust, это, чаще всего, не имеет смысла. К слову, питонисты гораздо лояльнее плюсистов относятся к Rust, для них это возможность писать критические по производительности и безопасности секции не на C++. Как пример - pydantic, ruff и другие тулзы и либы для питона написаны на Rust под капотом, равно как огромное количество либ до этого писали на C++. Для этого в Rust есть библиотека PyO3, обеспечивающая двустороннее взаимодействие с питоном. И я нередко слышал от питонистов, что им Rust был гораздо проще C++ при освоении для такого круга задач (написания библиотек под питон), отчасти благодаря удобству тулинга, отчасти как раз благодаря надежности, знанию, что ты вот попарился с кодом, зато потом он заработает и не придется погружаться в ад UB и приколов конкретного плюсового компилятора
Ну и я не считаю, что разница Rust vs C++ настолько кардинальна, как Rust vs Python или C++ vs Python. В первом случае это, можно сказать, прямые конкуренты, во втором это языки совсем разного уровня
Можете пояснить? Кажется, что там полностью убраны проверки при разыменовании указателей, например. А это самое страшное.
unsafe Rust дает только следующие послабления:
Разыменование голого указателя
Вызов другого unsafe кода
Доступ к мутабельным статик переменным
Реализация unsafe трейта (аналог интерфейсов из Java, C# и других языков)
Доступ к полям union
Borrow checker, проверка жизни ссылок, RAII повсеместное и остальные проверки языка все остаются на месте. unsafe создан для обращения к железу, к библиотекам на других языках (которые по определению unsafe, поскольку Rust не может их проверить), к API операционных систем и подобным внешним вещам, безопасность которых мы не можем гарантировать
В некоторых компаниях ровно так и происходит, никакого "реального мира". И платят хорошо.
Опять же, частный случай. Сегодня у вас все самописное и в шоколаде, а завтра надо тащить зависимость с нечитаемыми исходниками, утыканными UB, которую не сбилдить просто так современным компилятором и тд. Или всё-всё писать с нуля под себя, до каждой библиотеки? А что будет, если человек уволится и уйдет в другую компанию, где все не так? Единичные позитивные случаи не исключают общей проблемы
Возьмем пример Unreal Engine. Огромный проект на C и C++, почти 80 миллионов строк очень сложного кода, поддержка проприетарных платформ (консолей) и тд. И что в итоге? Пришлось делать свою систему сборки, полностью выбросить STL (как они написали, из-за проблем со стабильностью и кроссплатформерностью), пилить свою рефлексию и макросы, и вообще по сути сделать Unreal C++. И при билде движка скачивается несколько десятков гигабайт зависимостей, которые, я уверен, далеко не все следуют этим вот "правилам идеального мира"
Буквально позавчера видел баг на Rust, когда кодом деньги списывались, а нужное действие не совершалось. Сделано было случайно.
Ни один язык не предотвращает баги полностью, поскольку ни один язык не может валидировать алгоритмы в отношении бизнес-логики. Я говорю же про конкретные проблемы и классы ошибок, которые в Rust просто невозможны. Например, дедлоки и утечки памяти возможны даже в safe Rust, от этого тоже ни один язык не спасает (если вообще поддерживает многопоток). Но Rust предотвращает многие причины их возникновения, пусть и не все. И вот это уже и важно, и ценно
Люди пишут на Си и C++ с удовольствием и не парятся про какое-то там UB, несоответствие стандарту и прочая, прочая, прочая
А потом набирают вот такую статистику по уязвимостям, получают плавающие баги и прочие радости. Опять же, можно закрыть глаза на проблемы, сочтя, что слишком муторно писать так, чтобы их гарантированно не было (см. Typescript vs Javascript). Но мы вроде не об этом говорили
И таки я уже второй раз слышу, что тулинг под плюсы может быть шикарным, лучше Rust, и писать там можно с удовольствием. Допустим, что там где-то за закрытыми дверьми у кого-то сделано удобно. Но это не значит, что у всех так хорошо. Часть тулинга Rust просто не имеет популярных аналогов, часть имеет, но они вообще не общеприняты. Да и кроме тулинга, это просто чудесное сочетание полупустой стандартной библиотеки и жуткой боли при использовании сторонних библиотек.
Я когда начал изучать GAPI, штудировал многие книги на плюсах, потому как по Rust, ввиду новизны, информации по такой нишевой сфере было мало. И я просто регулярно ужасался, как для абсолютно идентичного результата плюсовики вынуждены мучаться на ровном месте, потому что то либ нет, то они с махровым сишным апи, вокруг которого надо танцевать, то билдить с бубном и танцами у костра нужно...
как контрибьюторы Postgres начали Rust использовать в своём проекте
Очень многие начали. Cloudflare целиком на Rust переписались, в исходниках Android его уже столько же, сколько C, AWS несколько сервисов целиком переписали и не останавливаются (и сделали Firecracker целиком на нем, опенсорс менеджер микровиртуалок, на котором работают Lambda и Fargate), с голенга многие тоже переписываются. Я могу дать полный список известных мне проектов, там от MESA до Figma, Vercel и части бэка npm.js репозитория. И под спутники пишут на нем, и новые проекты от мала до велика (от Tauri, который по сути Electron здорового человека, и Embassy, который embedded просто и быстро, до Western Digital, которые платформу обработки данных на 5 петабайт в день на нем пилят). Но возможности спрятать под спойлер я тут не вижу, а еще больше засорять коммент не хочется.
Не поэтому, а потому что Rust ставит программисту очень много ограничений ради той самой безопасности. Нужны ли эти ограничения — вот тут расхождение мнений.
Это говорит обычно здравое меньшинство. И я согласен, что тут есть вкусовщина. Но большинство просто плюется слюнями и ненавидит язык за сам факт его существования. В первую очередь плюсисты и гошники, ибо Rust в основном с ними конкурирует (с первыми в системщине и высокопроизводительных программах, со вторыми - в простом и высокопроизводительном бэкенде, который еще и намного быстрее гошного).
Тут еще играет роль то, что Rust позволяет не спускаться до совсем низкого уровня (пусть он конечно и сам по себе ниже большинства языков). В языке очень много так называемых zero cost abstractions, которые можно использовать как сахар, не боясь отстрелить себе лишние миллисекунды. Даже в embedded разработке на Rust легко можно увидеть дженерики, трейты и их реализации, операции над итераторами (аналог Stream API из Java), и прочие атрибуты высокоуровневой разработки, которые обычно у железа не встретишь вообще (отчасти потому что под железки часто кастом компиляторы си или плюсов, которые многое тупо не умеют)
Про токсичность коммьюнити кстати. Да, разработчики на Rust, включая меня, очень любят его упоминать и рассказывать о его плюсах. Но я не считаю это токсичностью, максимум пиаром, поскольку это распространение технологии и перечисление вещей, которые там действительно есть. Конечно, если человек не умеет нормально общаться - это другой случай, но такое все же гораздо реже происходит. При этом я сижу в куче айтишных чатов с тысячами участников по разным языкам, и не раз наблюдал, как в Rust чат залетают шальные разработчики на C++ и Go и начинают поливать Rust и всех причастных помоями, просто потому что. И с ними пытаются как-то еще адекватно разговаривать. А в C++ чате наоборот, даже без упоминания Rust регулярная грызня между собой, то какая система сборки лучше, то еще что, с попытками обосрать оппонента, а не привести аргументы (при упоминании же Rust там вообще взрыв происходит). И в целом, я бы сказал, что Rust коммьюнити часто с чрезмерным энтузиазмом его продвигает (сам грешен), тогда как C++ коммьюнити по большей части состоит из "да не нужон он нам, этот ваш ынтернет" и элитизма, поливая грязью все "несерьезные" языки и бросаясь с шашкой на любые попытки привнести удобство или безопасность ("это все для криворуких, настоящим программистам нормально и без системы сборки")
Повысить уровень предупреждений можно, но до Rust ещё очень, очень, очень далеко
Я чуть дополню этот пункт, с вашего позволения
Основная разница тут в том, что какими флагами и анализаторами не обмазывайся, если сам язык не дает им необходимой информации, то они не смогут обнаружить ошибку. Пример - лайфтаймы (время жизни) ссылок в Rust. Там они явные. Если они не очевидны компилятору, то их надо явно указывать, как раз чтобы он мог их проверить и гарантировать, что не будет ошибок при обращении. Так же и с боровом (borrow checker)
Вот у меня есть пример небольшой
#include <iostream>
#include <vector>
int main() {
std::vector<int> testVector{0, 1, 2, 3};
const int &vecRef = testVector[0];
for (int i = 4; i < 10000; i++) {
testVector.push_back(i);
}
std::cout << vecRef << std::endl;
return 0;
}
Этот код я собирал gcc и clang на Линуксе, с флагами -W -Wall -Wextra -Werror. И отдельно проверял вариант без оптимизации и вариант с -O3. Всего получилось 4 бинарника (по 1 на каждый компилятор и по 1 на каждый вариант оптимизации). Так вот, после запуска каждый бинарник мне выдал абсолютно разное число, и все они были порядка миллиардов.
Этот код собрался без единого предупреждения или ошибки, несмотря на все флаги. И при этом он выдает что попало, вообще не то, что могло задумываться разработчиком. Как я понимаю, это потому что при расширении вектора он переезжает в новую область памяти, побольше, а ссылка начинает указывать на мусор.
Если можно как-то еще повысить уровень обнаружения ошибок, буду рад услышать о нем, все же на С++ я писал последний раз очень давно, мог что-то упустить. Но такую простую вещь надо искать так, что по первым 5 ссылкам в гугле не найти, то это тоже говорит об удобстве разработки на языке.
fn main() {
let mut test_vector: Vec<i32> = vec![0, 1, 2, 3];
let vec_ref: &i32 = &test_vector[0];
for i in 4..10000 {
test_vector.push(i);
}
println!("{}", vec_ref);
}
Я специально сделал чуть более многословно, можно было типы у переменных не указывать, потому что они однозначно выводятся. Но пусть будет так, для исключения непонимания.
Этот код не собирается. Со следующей ошибкой:
error[E0502]: cannot borrow `test_vector` as mutable because it is also borrowed as immutable
--> src\main.rs:6:9
|
3 | let vec_ref: &i32 = &test_vector[0];
| ----------- immutable borrow occurs here
...
6 | test_vector.push(i);
| ^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here
...
9 | println!("{}", vec_ref);
| ------- immutable borrow later used here
То есть, язык нам еще на этапе сборки дает по рукам и не позволяет получить мертвую ссылку (в данном случае благодаря борову, но с лайфтаймами в других ситуациях было бы аналогично). Причем, если вырезать ее вывод на экран, то код запустится, потому что она будет неиспользованной, а значит целиком вырежется при сборке. Но как только ее больше нельзя вырезать - она порождает ошибку.
И таких примеров полно. Safe Rust гарантирует невозможность двойного освобождения, дедлока из-за забывчивости отпустить мьютекс после использования (сам дедлок возможен, но по другим причинам), отсутствие обращений по мертвым ссылкам и висячим указателям, невозможность случайного обращения к несинхронизированным данным в многопотоке и много чего еще. И далеко не все из этого списка можно накрутить костылями на другие языки, потому что они просто не дают этим костылям информации для выявления данных ошибок. И да, как уже упоминали, даже unsafe Rust не значит "как в С", там все еще полно проверок, просто они ослаблены
Как сказала одна разработчица на С++, написавшая свой игровой движок с нуля для собственного использования, когда начала трогать Rust:
Как выглядит опасный код на Rust: unsafe fn
Как выглядит опасный код на C++: int main
Конечно, можно отмахнуться стандартным "вы же профессионалы, пишите сразу без ошибок, и все будет хорошо". Что автор статьи и попытался кстати сделать своим "просто тестируйте код". Но мы все же живем в реальном мире и должны знать, что это не работает, никогда. И советы уровня "доктор, я сломал ногу в двух местах - больше не ходите в эти места" не должен применяться, если речь идет хоть о какой-то объективности
Про совершенно другой уровень тулинга, экосистемы и тд уже говорилось. Конечно, можно окуклиться в своем мире, где все на концептах и код пишут только как надо, все на единой системе сборки, есть генерация доки, модули вместо инклудов и прочие пони и радуги. Но рано или поздно придется выйти в реальный мир, а там десять несовместимых систем сборки + еще миллион самописных под каждый проект (я довольно часто слышу от плюсовиков высказывания типа "ни одна система сборки не будет лучше той, что я напишу для себя"), код на дефайнах дефайнов вместо функций целиком и зависимость имеет инструкцию для сборки уровня "надо вот такие 3 библиотеки из 80-х, для которых уже даже исходников нет".
В VCPKG и Conan, двух известных мне пакетниках для плюсов, суммарно на данный момент чуть более 4000 пакетов. На crates.io (глобальный репозиторий Cargo пакетов у Rust) сейчас более 145000 пакетов доступно. Это разница уже не в разы, это на порядки. Конечно, тоже частый аргумент - якобы это все просто мусором завалено, реальных библиотек там единицы. Но это можно сказать вообще про любой глобальный публичный репозиторий любого языка, и это не мешает там появляться сотням и тысячам очень крутых проектов, которые никогда бы не родились, если бы надо было пройти через огонь, воду и медные трубы ради публикации своего детища. Все хорошие экосистемы типа Java живут на доступности и простоте, а не на десяти замках
Про embedded тоже можно сказать, что по-умолчанию, если не отключать ничего, то Rust отслеживает вылеты за границы массива и самоубивается до того, как реально полезет в память и попытается ее попортить. И на микроконтроллерах без защиты памяти это вполне может спасти многое.
И в целом, Rust - это про безопасность "по-умолчанию". Можно сделать гадости, как на любом языке. Но они будут сделаны намеренно. Зато не случится проблемы, если ты что-то забыл, не заметил и тд. Самый дефолтный вариант - самый стабильный и безопасный. Вот если хочешь странного, тогда да, тогда уже надо прикладывать усилия, таким образом думать, таким образом исключая многие возможности нагадить случайно.
Можно еще про стандартную библиотеку упомянуть, где у C++ нет ни базовых вещей типа сплита строки, ни нормальной работы с сетью даже (когда Wi-Fi сейчас даже в самых дешевых микроконтроллерах есть), а Rust ее очень активно развивает и тащит в том числе и наработки Google по C++ (SwissTable как std реализация HashMap, например), можно еще много что сказать. Но это уже по сути отдельный холивар будет, я и так увлекся
В общем, я очень давно ушел с С++ на Java, а примерно года полтора назад стал параллельно с основной работой на высоконагруженном Java бэке осваивать Rust и применять его в домашних проектах (и бэкенд, и домашний embedded проект). И это прям вернуло мне веру в то, что на низкоуровневых языках и в железной и системной разработке можно не страдать. Начал вот embedded проект домашний, начал GAPI голые осваивать, системные штуки писать. Раньше думал, что это все было больно, потому что сферы такие. А оказалось, что просто язык не тот был. И многие старые разработчики на C++ это тоже понимают и уходят (даже знакомый сишник/плюсист с 35 годами стажа, начинавший еще на голом асме и писавший все это время критические системы, пусть сначала и поплевался с непривычки, но теперь втянулся и постоянно возмущается, почему не могли ту или иную удобную штуку в плюсы утащить). А многие воспринимают это в штыки, ибо как так, наконец появился конкурент, надо срочно обосрать. У нас в СНГ это еще заметнее, ибо пока на Западе огромные именитые проекты перекатывают на Rust с плюсов и голенга и вбухивают миллиарды в новые на нём, у нас до сих пор массово менталитет "да не нужон этот ваш ынтернет"
Ключевая разница в том, что старый плагин был опенсорсным и ставился на любую JB IDE, а новый закрытый (емнип) и ставится только в платные версии. Это сделано, чтобы сгонять народ покупать RustRover или другие платные продукты (IDEA Ultimate, CLion и тд), не позволяя писать на Rust на бесплатном коммьюнити издании
А потом выясняется, что и у xz один мейнтейнер с подвала десятилетие на себе тянет проект, и у openssl двое независимых. Собственно, заявление от них как раз и было, когда уязвимость в openssl нашли, что они перерабатывают много лет за спасибо и два бутерброда над проектом. Который почти все корпорации мира просто берут и юзают, ничего не отдавая взамен, а потом удивляются, что там баг случился.
Я уверен, что если поискать, то таких примеров полно. Просто никого не волнует, что там кто-то в соло упахивается над популярным проектом, пока все работает. Только при критических багах и уязвимостях вдруг выясняется
Это все пробуется до того, как решают перейти на другой язык. Те же Cloudflare писали все свое, выжимали максимум из языка, но все равно голенга было недостаточно. А после перехода на раст это решилось, причем не только по чистым rps, но и по latency
И это только один пример. Дискорд тоже сказали, что у них самая наивная реализация на расте оказалась быстрее супероптимизированной гошной
Дропбокс сказали, что переход был «одним из лучших принятых ими решений»
В общем, реальные кейсы реальных продуктов показывают вполне четкую картину
Только почему-то в реальной жизни это работает в обратную сторону, и компании после переноса своего прода с Go на Rust наблюдают 60% прироста в скорости (Cloudflare, Discord и прочие, и это только те, кто сказал об этом публично и был достаточно популярен, чтобы это заметили).
В целом тут не очень оптимально бенч для раста сделан, как минимум один sqlx чего стоит
А еще бы требовали денег, замедляли пк, раздражали попапами, майнили на моем компе без возможности длительного отключения и тд. Замена вероятности получить довольно редкий вирус на гарантию получить очень раздражающий вирус здесь и сейчас (с приставкой анти-) далеко не для всех будет выходом.
Ну и лично от себя скажу, что у меня фаерволл стоит на роутере, роль которого играет настроенная руками малинка на линуксе. И ни у меня, ни у семьи за долгие годы жизни без антивири не было ни одного вируса. Даже пока еще виндой пользовались и на линукс окончательно не перешли
Даже если вам так приспичило майнить, не советую юзать зашитое в нортон. Комиссия 15%. У обычных майнеров 0.5-1%, если что. Компания не просто так его пропихивает и включает, если выключили)
Многое из важного для юзеров опущено. Например Avast регулярно спамит попапами, а Norton зашили в свой антивирус майнер вполне официально, чтобы "юзеры зарабатывали" (по факту они дерут комиссию в 10 раз больше остальных майнеров, а при отключении функции любое обновление включает ее обратно)
Лучше просто иметь мозг, тогда никакой антивирь не нужен)
Да не, эта система с нодами у них со времен Царя Гороха. Я в Еву играл 5 лет и с самого старта в 2016 году помню про это узнал. И даже старички с 15-летним стажем говорили, что почти всегда так было
А бэк у них тривиальный. Лютая двадцатилетняя лапша на питоне ("POS code" стал уже грустным мемом), дико лагающая. И сервер представляет собой кластер из кучи нод, между которыми игроки переключаются при проходе в гиперворота, использовании джампдрайва, порталов и тд
Кстати сервер игрового чата один и отдельный от игрового. Поэтому он нередко отваливался, когда сам игровой сервер продолжал работать и играть было можно, но без чата)
Все их проблемы уже вряд ли лишатся, ибо компания и изнутри, и снаружи, на полных парах летит в бездну. А жаль, почти 20 лет такую уникальную игру держали на плаву и с адекватным онлайном
Ну я условно сказал, да. Та же Jita перманентно висит на выделенной ноде, например. Плюс у них есть некоторое количество резервных нод, которые они присовывают заранее куда надо, если знают о предстоящем сражении. Там же есть на сайте кнопочка "рассказать разрабам, что мы хотим крупно подраться". Специально, чтобы они заранее подсуетились и туда нод подкинули
Все это было в Ангуларе, но фронтендерам претят ООП, всякие архитектурные паттерны, принудительная типизация и подобное. Там сейчас тренд такой, от одного слова class плеваться, изобретать костыли поверх функциональщины, а потом гордо пытаться годами чинить то, что изначально работало до "переосмысления". Вот и получается хождение по спирали
Про union знаю, чуть выше как раз в моменте про unsafe его упоминал. Про прикол с енамом не знал. Помнил, что на
Stringи прочих подобных типах всегда выходило одинаково, поэтому отложилось так в голове. Почитаю потом подробнееК слову, в GAPI, с которыми работаю, очень важно положение данных в памяти, иначе при передаче с CPU на GPU в шейдер мусор приедет вместо данных. Там как раз приходится приседать с паддингами, выравниванием и прочим. Но для wgpu (раст реализации стандарта WebGPU с поддержкой нативных платформ кроме веба, которую использует Mozilla у себя) есть такой вот замечательный проектик, который гарантирует корректное расположение в памяти для произвольных типов данных, причем еще во время сборки. Благодаря чему и получается не думать о лейауте данных в памяти, и такие вот нюансы выветриваются за ненадобностью
Я имел в виду, что там не происходит какого-то выделения памяти под сами эти "объекты", их вообще по сути нет, есть проверки на их значение (которые тоже там во всякое разворачиваются, например в проверку ссылки), но по сути это те данные, которые в них хранишь. То есть,
Option<i32>займет ровно 4 байта наi32внутри него, ничего лишнего там не будет, никакого оверхеда относительно голого указателя и ручных его проверок везде. Несмотря на удобство работы с ним в коде, использование дженерика, общий вид как объекта с методами и тдЭто ключевое отличие от аналогов в других языках, например
Optionalв Java, который именно отдельный объект со всеми вытекающими (его создание и удаление, оверхед любого объекта в памяти из-за метаданных и тд)Upd: единственный известный мне язык кроме Rust, где есть такие енамы - это Swift. Они в целом с Rust очень сильно похожи, после Rust я книжку по Swift проглотил за день и пошел писать на нем, когда разок понадобилось, потому что очень сильно смахивает на Rust и Kotlin. И это касается многого, например
guardиз свифта - этоlet elseиз раста. Там целый список можно набратьНу и бесплатные абстракции, конечно, на енамах не заканчиваются, там вообще очень многое из удобного во время сборки разворачивается в то, как это пишут сишники
Ошибка защиты памяти - не равно утечка памяти. Ошибка защиты может происходить когда угодно (а не накапливаться со временем), в зависимости от логики программы, и представлять собой критическую уязвимость безопасности. И от регулярных перезагрузок магически никуда не исчезнет
Upd: еще дополню немного. Конечно всегда можно, условно, забить, сделать тяп-ляп и в прод поскорее, для такого Rust будет мешать, это вообще язык не про прототипирование. Но это тоже чревато, вон Cloudflare разок напоролись на Cloudbleed, принесший кучу убытков, как финансовых, так и репутационных, как раз из-за ошибки памяти. И этого им хватило, чтобы начать массовую миграцию на Rust, с написанием своего решения на замену nginx с обвязкой из си и плюсов, которые у них до этого работали. И кстати, в мире Rust давно уже есть rustls библиотека, полный аналог openssl, но на расте (что и позволило проектам на нем избежать Heartbleed в том числе). Пока жареный петух не клюнет, многие не думают. Но те, кто более дальновидный, решают проблемы заранее
Ну вот Microsoft - это не компания уровня FAANG (или теперь их правильно называть MANGA?)? Или они у себя не смогли в тулинг и поэтому столько уязвимостей? Я понимаю, что иногда хочется отмахнуться от неудобной статистики, но с фактами сложно спорить. И это кстати как раз те компании, которые могут себе позволить написать вообще все свое с нуля, благодаря чему и не столкнуться с проблемами простых смертных)
Все есть яд и все есть лекарство. Разница только в дозе. Одно дело, когда сложно писать один конкретный тип вещей (для которых и так уже библиотеки написаны. Не забываем, это не плюсы, тут можно не писать все с нуля каждый раз). И другое - когда у тебя весь язык в этих проблемах, от инклудов и зависимостей до совместимости и стандартной библиотеки
В Rust нет стабильного ABI, частично из-за этого как раз (емнип кстати в C++ тоже нет между компиляторами). Есть только режим сборки в сишную либу и поддержка C ABI, для FFI и подобного. И таки да, есть оптимизации с условной пометкой "может быть", такие как вызов
.clone(), который часто оптимизируется в noop, а есть гарантированные оптимизации (например, что Result и Option занимают ровно столько памяти, сколько голые лежащие в них данные, а сами по себе вырезаются на этапе сборки). Благодаря таким гарантиям можно использовать большую часть сахара и не бояться, что что-то просядет.А многие сидят без чекеров или с более тупыми чекерами. Опять же, частный случай, когда используется только то, что нужно - это именно частный случай
И это только данный пример с боровом. Как подобный инструмент будет валидировать время жизни ссылок в сложных случаях вызовов библиотек с кучей фукнций и тд? В Rust я знаю, что там будут лайфтаймы ссылок, по которым уже можно однозначно проверить их время жизни (для чего и были придуманы). А если в языке просто нет этой однозначности?
Откуда тогда такое количество глупых багов и уязвимостей-то берется? Видимо далеко не все используют. Ну и опять же, это теплое с мягким, потому что я говорю про проверки времени сборки, а это инструменты для анализа рантайма. Далеко не каждый проект можно тривиально гонять в рантайме по всем возможным случаям, плюс это тоже доп работа и тд. Против того, что гарантирует сам язык
99% защита от ошибок все еще лучше, чем 10%. Цифры, очевидно, случайные, но суть думаю ясна. Было исследование университета Ватерлоо по похожему поводу. Исследовали вероятность занесения уязвимости (простые баги не учитывались) новым коммитом в проект на C++ и Rust, в зависимости от опыта разработчиков. В итоге вышло 4% для C++ и 0.06% для Rust в сложном проекте. При этом было примечание, что в проектах на C++ многие уязвимости вносились повторно, уже после их устранения, по мере развития проекта. И 87% уязвимостей в C++ относились к ошибкам памяти, которые как раз и предотвращает Rust. Похожая статистика была и у Microsoft, там было 70% их уязвимостей из-за памяти, и они тоже ссылались на Rust как на решение
Ну это справедливо ровно в той же степени, в какой "в TypeScript хочется писать везде any и не думать о типах". То есть, да, для кого-то это так. Но тогда не было смысла брать такой язык, если не хочешь пользоваться его преимуществами
Это разные языки для разного класса задач. Никто вроде и не предлагал заменять Python на Rust, это, чаще всего, не имеет смысла. К слову, питонисты гораздо лояльнее плюсистов относятся к Rust, для них это возможность писать критические по производительности и безопасности секции не на C++. Как пример - pydantic, ruff и другие тулзы и либы для питона написаны на Rust под капотом, равно как огромное количество либ до этого писали на C++. Для этого в Rust есть библиотека PyO3, обеспечивающая двустороннее взаимодействие с питоном. И я нередко слышал от питонистов, что им Rust был гораздо проще C++ при освоении для такого круга задач (написания библиотек под питон), отчасти благодаря удобству тулинга, отчасти как раз благодаря надежности, знанию, что ты вот попарился с кодом, зато потом он заработает и не придется погружаться в ад UB и приколов конкретного плюсового компилятора
Ну и я не считаю, что разница Rust vs C++ настолько кардинальна, как Rust vs Python или C++ vs Python. В первом случае это, можно сказать, прямые конкуренты, во втором это языки совсем разного уровня
unsafe Rust дает только следующие послабления:
Разыменование голого указателя
Вызов другого unsafe кода
Доступ к мутабельным статик переменным
Реализация unsafe трейта (аналог интерфейсов из Java, C# и других языков)
Доступ к полям union
Borrow checker, проверка жизни ссылок, RAII повсеместное и остальные проверки языка все остаются на месте. unsafe создан для обращения к железу, к библиотекам на других языках (которые по определению unsafe, поскольку Rust не может их проверить), к API операционных систем и подобным внешним вещам, безопасность которых мы не можем гарантировать
Опять же, частный случай. Сегодня у вас все самописное и в шоколаде, а завтра надо тащить зависимость с нечитаемыми исходниками, утыканными UB, которую не сбилдить просто так современным компилятором и тд. Или всё-всё писать с нуля под себя, до каждой библиотеки? А что будет, если человек уволится и уйдет в другую компанию, где все не так? Единичные позитивные случаи не исключают общей проблемы
Возьмем пример Unreal Engine. Огромный проект на C и C++, почти 80 миллионов строк очень сложного кода, поддержка проприетарных платформ (консолей) и тд. И что в итоге? Пришлось делать свою систему сборки, полностью выбросить STL (как они написали, из-за проблем со стабильностью и кроссплатформерностью), пилить свою рефлексию и макросы, и вообще по сути сделать Unreal C++. И при билде движка скачивается несколько десятков гигабайт зависимостей, которые, я уверен, далеко не все следуют этим вот "правилам идеального мира"
Ни один язык не предотвращает баги полностью, поскольку ни один язык не может валидировать алгоритмы в отношении бизнес-логики. Я говорю же про конкретные проблемы и классы ошибок, которые в Rust просто невозможны. Например, дедлоки и утечки памяти возможны даже в safe Rust, от этого тоже ни один язык не спасает (если вообще поддерживает многопоток). Но Rust предотвращает многие причины их возникновения, пусть и не все. И вот это уже и важно, и ценно
А потом набирают вот такую статистику по уязвимостям, получают плавающие баги и прочие радости. Опять же, можно закрыть глаза на проблемы, сочтя, что слишком муторно писать так, чтобы их гарантированно не было (см. Typescript vs Javascript). Но мы вроде не об этом говорили
И таки я уже второй раз слышу, что тулинг под плюсы может быть шикарным, лучше Rust, и писать там можно с удовольствием. Допустим, что там где-то за закрытыми дверьми у кого-то сделано удобно. Но это не значит, что у всех так хорошо. Часть тулинга Rust просто не имеет популярных аналогов, часть имеет, но они вообще не общеприняты. Да и кроме тулинга, это просто чудесное сочетание полупустой стандартной библиотеки и жуткой боли при использовании сторонних библиотек.
Я когда начал изучать GAPI, штудировал многие книги на плюсах, потому как по Rust, ввиду новизны, информации по такой нишевой сфере было мало. И я просто регулярно ужасался, как для абсолютно идентичного результата плюсовики вынуждены мучаться на ровном месте, потому что то либ нет, то они с махровым сишным апи, вокруг которого надо танцевать, то билдить с бубном и танцами у костра нужно...
Очень многие начали. Cloudflare целиком на Rust переписались, в исходниках Android его уже столько же, сколько C, AWS несколько сервисов целиком переписали и не останавливаются (и сделали Firecracker целиком на нем, опенсорс менеджер микровиртуалок, на котором работают Lambda и Fargate), с голенга многие тоже переписываются. Я могу дать полный список известных мне проектов, там от MESA до Figma, Vercel и части бэка npm.js репозитория. И под спутники пишут на нем, и новые проекты от мала до велика (от Tauri, который по сути Electron здорового человека, и Embassy, который embedded просто и быстро, до Western Digital, которые платформу обработки данных на 5 петабайт в день на нем пилят). Но возможности спрятать под спойлер я тут не вижу, а еще больше засорять коммент не хочется.
Это говорит обычно здравое меньшинство. И я согласен, что тут есть вкусовщина. Но большинство просто плюется слюнями и ненавидит язык за сам факт его существования. В первую очередь плюсисты и гошники, ибо Rust в основном с ними конкурирует (с первыми в системщине и высокопроизводительных программах, со вторыми - в простом и высокопроизводительном бэкенде, который еще и намного быстрее гошного).
Тут еще играет роль то, что Rust позволяет не спускаться до совсем низкого уровня (пусть он конечно и сам по себе ниже большинства языков). В языке очень много так называемых zero cost abstractions, которые можно использовать как сахар, не боясь отстрелить себе лишние миллисекунды. Даже в embedded разработке на Rust легко можно увидеть дженерики, трейты и их реализации, операции над итераторами (аналог Stream API из Java), и прочие атрибуты высокоуровневой разработки, которые обычно у железа не встретишь вообще (отчасти потому что под железки часто кастом компиляторы си или плюсов, которые многое тупо не умеют)
Upd: опечатки
Про токсичность коммьюнити кстати. Да, разработчики на Rust, включая меня, очень любят его упоминать и рассказывать о его плюсах. Но я не считаю это токсичностью, максимум пиаром, поскольку это распространение технологии и перечисление вещей, которые там действительно есть. Конечно, если человек не умеет нормально общаться - это другой случай, но такое все же гораздо реже происходит. При этом я сижу в куче айтишных чатов с тысячами участников по разным языкам, и не раз наблюдал, как в Rust чат залетают шальные разработчики на C++ и Go и начинают поливать Rust и всех причастных помоями, просто потому что. И с ними пытаются как-то еще адекватно разговаривать. А в C++ чате наоборот, даже без упоминания Rust регулярная грызня между собой, то какая система сборки лучше, то еще что, с попытками обосрать оппонента, а не привести аргументы (при упоминании же Rust там вообще взрыв происходит). И в целом, я бы сказал, что Rust коммьюнити часто с чрезмерным энтузиазмом его продвигает (сам грешен), тогда как C++ коммьюнити по большей части состоит из "да не нужон он нам, этот ваш ынтернет" и элитизма, поливая грязью все "несерьезные" языки и бросаясь с шашкой на любые попытки привнести удобство или безопасность ("это все для криворуких, настоящим программистам нормально и без системы сборки")
Я чуть дополню этот пункт, с вашего позволения
Основная разница тут в том, что какими флагами и анализаторами не обмазывайся, если сам язык не дает им необходимой информации, то они не смогут обнаружить ошибку. Пример - лайфтаймы (время жизни) ссылок в Rust. Там они явные. Если они не очевидны компилятору, то их надо явно указывать, как раз чтобы он мог их проверить и гарантировать, что не будет ошибок при обращении. Так же и с боровом (borrow checker)
Вот у меня есть пример небольшой
Этот код я собирал gcc и clang на Линуксе, с флагами
-W -Wall -Wextra -Werror. И отдельно проверял вариант без оптимизации и вариант с-O3. Всего получилось 4 бинарника (по 1 на каждый компилятор и по 1 на каждый вариант оптимизации). Так вот, после запуска каждый бинарник мне выдал абсолютно разное число, и все они были порядка миллиардов.Этот код собрался без единого предупреждения или ошибки, несмотря на все флаги. И при этом он выдает что попало, вообще не то, что могло задумываться разработчиком. Как я понимаю, это потому что при расширении вектора он переезжает в новую область памяти, побольше, а ссылка начинает указывать на мусор.
Если можно как-то еще повысить уровень обнаружения ошибок, буду рад услышать о нем, все же на С++ я писал последний раз очень давно, мог что-то упустить. Но такую простую вещь надо искать так, что по первым 5 ссылкам в гугле не найти, то это тоже говорит об удобстве разработки на языке.
Я специально сделал чуть более многословно, можно было типы у переменных не указывать, потому что они однозначно выводятся. Но пусть будет так, для исключения непонимания.
Этот код не собирается. Со следующей ошибкой:
То есть, язык нам еще на этапе сборки дает по рукам и не позволяет получить мертвую ссылку (в данном случае благодаря борову, но с лайфтаймами в других ситуациях было бы аналогично). Причем, если вырезать ее вывод на экран, то код запустится, потому что она будет неиспользованной, а значит целиком вырежется при сборке. Но как только ее больше нельзя вырезать - она порождает ошибку.
И таких примеров полно. Safe Rust гарантирует невозможность двойного освобождения, дедлока из-за забывчивости отпустить мьютекс после использования (сам дедлок возможен, но по другим причинам), отсутствие обращений по мертвым ссылкам и висячим указателям, невозможность случайного обращения к несинхронизированным данным в многопотоке и много чего еще. И далеко не все из этого списка можно накрутить костылями на другие языки, потому что они просто не дают этим костылям информации для выявления данных ошибок. И да, как уже упоминали, даже unsafe Rust не значит "как в С", там все еще полно проверок, просто они ослаблены
Как сказала одна разработчица на С++, написавшая свой игровой движок с нуля для собственного использования, когда начала трогать Rust:
И это конечно шутка, но в каждой шутке есть доля боли. Особенно если вспомнить замечательные примеры на C++, когда даже однозначно недостижимый кусок кода внезапно выполнялся или когда в gcc критические плавающие баги, ломающие вещественные вычисления на куче платформ, по 30 лет висели без исправления (в исходном комментарии тоже была ссылка на эту статью, но решил чуть подробнее упомянуть)
Конечно, можно отмахнуться стандартным "вы же профессионалы, пишите сразу без ошибок, и все будет хорошо". Что автор статьи и попытался кстати сделать своим "просто тестируйте код". Но мы все же живем в реальном мире и должны знать, что это не работает, никогда. И советы уровня "доктор, я сломал ногу в двух местах - больше не ходите в эти места" не должен применяться, если речь идет хоть о какой-то объективности
Про совершенно другой уровень тулинга, экосистемы и тд уже говорилось. Конечно, можно окуклиться в своем мире, где все на концептах и код пишут только как надо, все на единой системе сборки, есть генерация доки, модули вместо инклудов и прочие пони и радуги. Но рано или поздно придется выйти в реальный мир, а там десять несовместимых систем сборки + еще миллион самописных под каждый проект (я довольно часто слышу от плюсовиков высказывания типа "ни одна система сборки не будет лучше той, что я напишу для себя"), код на дефайнах дефайнов вместо функций целиком и зависимость имеет инструкцию для сборки уровня "надо вот такие 3 библиотеки из 80-х, для которых уже даже исходников нет".
В VCPKG и Conan, двух известных мне пакетниках для плюсов, суммарно на данный момент чуть более 4000 пакетов. На crates.io (глобальный репозиторий Cargo пакетов у Rust) сейчас более 145000 пакетов доступно. Это разница уже не в разы, это на порядки. Конечно, тоже частый аргумент - якобы это все просто мусором завалено, реальных библиотек там единицы. Но это можно сказать вообще про любой глобальный публичный репозиторий любого языка, и это не мешает там появляться сотням и тысячам очень крутых проектов, которые никогда бы не родились, если бы надо было пройти через огонь, воду и медные трубы ради публикации своего детища. Все хорошие экосистемы типа Java живут на доступности и простоте, а не на десяти замках
Про embedded тоже можно сказать, что по-умолчанию, если не отключать ничего, то Rust отслеживает вылеты за границы массива и самоубивается до того, как реально полезет в память и попытается ее попортить. И на микроконтроллерах без защиты памяти это вполне может спасти многое.
И в целом, Rust - это про безопасность "по-умолчанию". Можно сделать гадости, как на любом языке. Но они будут сделаны намеренно. Зато не случится проблемы, если ты что-то забыл, не заметил и тд. Самый дефолтный вариант - самый стабильный и безопасный. Вот если хочешь странного, тогда да, тогда уже надо прикладывать усилия, таким образом думать, таким образом исключая многие возможности нагадить случайно.
Можно еще про стандартную библиотеку упомянуть, где у C++ нет ни базовых вещей типа сплита строки, ни нормальной работы с сетью даже (когда Wi-Fi сейчас даже в самых дешевых микроконтроллерах есть), а Rust ее очень активно развивает и тащит в том числе и наработки Google по C++ (SwissTable как std реализация HashMap, например), можно еще много что сказать. Но это уже по сути отдельный холивар будет, я и так увлекся
В общем, я очень давно ушел с С++ на Java, а примерно года полтора назад стал параллельно с основной работой на высоконагруженном Java бэке осваивать Rust и применять его в домашних проектах (и бэкенд, и домашний embedded проект). И это прям вернуло мне веру в то, что на низкоуровневых языках и в железной и системной разработке можно не страдать. Начал вот embedded проект домашний, начал GAPI голые осваивать, системные штуки писать. Раньше думал, что это все было больно, потому что сферы такие. А оказалось, что просто язык не тот был. И многие старые разработчики на C++ это тоже понимают и уходят (даже знакомый сишник/плюсист с 35 годами стажа, начинавший еще на голом асме и писавший все это время критические системы, пусть сначала и поплевался с непривычки, но теперь втянулся и постоянно возмущается, почему не могли ту или иную удобную штуку в плюсы утащить). А многие воспринимают это в штыки, ибо как так, наконец появился конкурент, надо срочно обосрать. У нас в СНГ это еще заметнее, ибо пока на Западе огромные именитые проекты перекатывают на Rust с плюсов и голенга и вбухивают миллиарды в новые на нём, у нас до сих пор массово менталитет "да не нужон этот ваш ынтернет"
Ключевая разница в том, что старый плагин был опенсорсным и ставился на любую JB IDE, а новый закрытый (емнип) и ставится только в платные версии. Это сделано, чтобы сгонять народ покупать RustRover или другие платные продукты (IDEA Ultimate, CLion и тд), не позволяя писать на Rust на бесплатном коммьюнити издании
А потом выясняется, что и у xz один мейнтейнер с подвала десятилетие на себе тянет проект, и у openssl двое независимых. Собственно, заявление от них как раз и было, когда уязвимость в openssl нашли, что они перерабатывают много лет за спасибо и два бутерброда над проектом. Который почти все корпорации мира просто берут и юзают, ничего не отдавая взамен, а потом удивляются, что там баг случился.
Я уверен, что если поискать, то таких примеров полно. Просто никого не волнует, что там кто-то в соло упахивается над популярным проектом, пока все работает. Только при критических багах и уязвимостях вдруг выясняется
Это все пробуется до того, как решают перейти на другой язык. Те же Cloudflare писали все свое, выжимали максимум из языка, но все равно голенга было недостаточно. А после перехода на раст это решилось, причем не только по чистым rps, но и по latency
И это только один пример. Дискорд тоже сказали, что у них самая наивная реализация на расте оказалась быстрее супероптимизированной гошной
Дропбокс сказали, что переход был «одним из лучших принятых ими решений»
В общем, реальные кейсы реальных продуктов показывают вполне четкую картину
Upd: опечатка в цитате
Только почему-то в реальной жизни это работает в обратную сторону, и компании после переноса своего прода с Go на Rust наблюдают 60% прироста в скорости (Cloudflare, Discord и прочие, и это только те, кто сказал об этом публично и был достаточно популярен, чтобы это заметили).
В целом тут не очень оптимально бенч для раста сделан, как минимум один sqlx чего стоит
Мб на досуге покручу код, если время будет
Отбой, заметил сейчас его в списке, первый раз просмотрел его
В рядах поисковых движков есть еще Meilisearch. Пока потупее Эластика, но сильно проще и оптимизированнее, для более мелких проектов может подойти
В день? В час? В месяц?
Так много вопросов и так мало ответов
Собственно, Firefox уже давно только так и авторизует пользователей
Poco X3 Pro, Android 12, пашет как часы
А еще бы требовали денег, замедляли пк, раздражали попапами, майнили на моем компе без возможности длительного отключения и тд. Замена вероятности получить довольно редкий вирус на гарантию получить очень раздражающий вирус здесь и сейчас (с приставкой анти-) далеко не для всех будет выходом.
Ну и лично от себя скажу, что у меня фаерволл стоит на роутере, роль которого играет настроенная руками малинка на линуксе. И ни у меня, ни у семьи за долгие годы жизни без антивири не было ни одного вируса. Даже пока еще виндой пользовались и на линукс окончательно не перешли
https://habr.com/ru/company/itsumma/news/t/599487/
Даже если вам так приспичило майнить, не советую юзать зашитое в нортон. Комиссия 15%. У обычных майнеров 0.5-1%, если что. Компания не просто так его пропихивает и включает, если выключили)
Многое из важного для юзеров опущено. Например Avast регулярно спамит попапами, а Norton зашили в свой антивирус майнер вполне официально, чтобы "юзеры зарабатывали" (по факту они дерут комиссию в 10 раз больше остальных майнеров, а при отключении функции любое обновление включает ее обратно)
Лучше просто иметь мозг, тогда никакой антивирь не нужен)
Да не, эта система с нодами у них со времен Царя Гороха. Я в Еву играл 5 лет и с самого старта в 2016 году помню про это узнал. И даже старички с 15-летним стажем говорили, что почти всегда так было
А бэк у них тривиальный. Лютая двадцатилетняя лапша на питоне ("POS code" стал уже грустным мемом), дико лагающая. И сервер представляет собой кластер из кучи нод, между которыми игроки переключаются при проходе в гиперворота, использовании джампдрайва, порталов и тд
Кстати сервер игрового чата один и отдельный от игрового. Поэтому он нередко отваливался, когда сам игровой сервер продолжал работать и играть было можно, но без чата)
Все их проблемы уже вряд ли лишатся, ибо компания и изнутри, и снаружи, на полных парах летит в бездну. А жаль, почти 20 лет такую уникальную игру держали на плаву и с адекватным онлайном
Ну я условно сказал, да. Та же Jita перманентно висит на выделенной ноде, например. Плюс у них есть некоторое количество резервных нод, которые они присовывают заранее куда надо, если знают о предстоящем сражении. Там же есть на сайте кнопочка "рассказать разрабам, что мы хотим крупно подраться". Специально, чтобы они заранее подсуетились и туда нод подкинули