Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Zhendos, Вы писали:
Z>>У меня лично как замена C++ для "логики" в новом проекте неплохо "зашел".
KP>Очень любопытно! Что за сфера проекта?
Сфера скажем так близка к "safety-critical system", но ей не является
То есть например предсказуемость времени выполнения желательна, но не обязательна,
поэтому использование например GC в принципе возможно, но лучше без него,
соответствие coding style для "safety-critical system" желательно, но не обязательно и т.д.
KP> Перед выбором Rust на C++17 смотрели?
После ~10 лет использования C++ даже идеи посмотреть на C++XYZ не возникло.
То, чем понравился Rust конечно можно достичь в C++, если нафиг сломать обратную совместимость,
и заставить на новом диалекте переписать кучу уже существующих библиотек,
что конечно невозможно в рамках любого ближайшего будущего стандарта.
Если скажем взять для примера какое-нибудь описание обязательных практик для
"C++ for safety-critical system", то можно прям идти по списку и отмечать:
"это в Rust из коробки", "это в Rust из коробки", например
— использовать элементарные типы только с указанным размером,
в Rust стандартные типы только такие u8,u16, f32, f64, за исключением [ui]size
— никаких "integer promotion" и неявных преобразований, в Rust это ошибка компиляции
— очень ограничено использование препроцессора из-за возможных неочевидных эффектов,
в Rust макросы не могут неявно поменять что-либо в точке использования
и т.д. и т.п.,
плюс удобная, прозрачная, контролируемая обработка ошибок,
контроль компилятора за lifetime, нормальный move, без оставления объектов, которые можно только удалить,
метапрограммирование с помощью плагинов к компилятору,
единая система сборки с удобным включением стороннего кода в проект.
C>>>Впрочем, в итоге получилось неплохо — кода там не так много, так что поле для раздолья было не сильно большое. KP>>Я скорее о том, что как ни силюсь не могу найти серьёзных преимуществ Rust перед C++17. Каналы и Карго не тянут на таковые. Думал, может тут пример такого, ан опять нет, очередной пример "поиграть захотелось". C>Если в коде на Rust не использовать unsafe и не прилагать очень существенных усилий с Arc'ами, то код будет безопасным. Т.е. в нём не будет утечек, use-after-free, переполнений и т.д.
Статические анализаторы и C++ дадут тот же эффект, но без необходимости бороться с borrow checker.
C>Сам язык тоже существенно приятнее С++, просто за счёт того, что в Rust'е нет legacy от С.
Как я и думал, Rust используют те, кому поднадоел C/C++ и захотелось чего-то другого, новенького (ну, а придумывание каких-то преимуществ, это то, что психологи называют "рационализация" или по простому самоубеждение, оправдание).
Здравствуйте, kaa.python, Вы писали:
C>>Если в коде на Rust не использовать unsafe и не прилагать очень существенных усилий с Arc'ами, то код будет безопасным. Т.е. в нём не будет утечек, use-after-free, переполнений и т.д. KP>Так и C++ будет безопасным без голых указателей в обвесе с GSL и санитайзерами. Ну да, немного надо сделать не из коробки, но это же один раз делается
Нет, это надо постоянно писать на специальном диалекте С++ и тщательно за этим следить. В Rust при использовании стандартной библиотеки даётся даже гарантия отсутствия data races.
Здравствуйте, kaa.python, Вы писали:
KP>P.S. мне нравится Rust и его идея, просто никакой серебрянной пули и серьезного выигрыша по сравнению с C++ в безопасности кода нет. А вот Cargo, интерфейсы вместо классов, тесты вместе с исходниками и CSP из коробки и куча других моментов — это да, это несомненные жирные плюсы.
Я к своему огромному удивлению обнаружил, что на Rust довольно легко переписывается мой старый код с Haskell, где были сплошные монады, продолжения, классы типов, суммы-типы и т.п. При этом Rust как платформа предлагает примерно то же, что и C++. Никакого сборщика мусора, почти полное отсутствие системы времени исполнения.
Так что, случись выбирать между Rust и C++, уже знаю свое решение.
Здравствуйте, Masterspline, Вы писали:
C>>Если в коде на Rust не использовать unsafe и не прилагать очень существенных усилий с Arc'ами, то код будет безопасным. Т.е. в нём не будет утечек, use-after-free, переполнений и т.д. M>Статические анализаторы и C++ дадут тот же эффект, но без необходимости бороться с borrow checker.
Не дадут, только в самых простых случаях и при доступности для анализатора всего кода.
Здравствуйте, kaa.python, Вы писали:
C>>Впрочем, в итоге получилось неплохо — кода там не так много, так что поле для раздолья было не сильно большое. KP>Я скорее о том, что как ни силюсь не могу найти серьёзных преимуществ Rust перед C++17. Каналы и Карго не тянут на таковые. Думал, может тут пример такого, ан опять нет, очередной пример "поиграть захотелось".
Если в коде на Rust не использовать unsafe и не прилагать очень существенных усилий с Arc'ами, то код будет безопасным. Т.е. в нём не будет утечек, use-after-free, переполнений и т.д.
Сам язык тоже существенно приятнее С++, просто за счёт того, что в Rust'е нет legacy от С.
Здравствуйте, Pzz, Вы писали:
Pzz>А во-вторых, переусложненность языка создает больше проблем, чем небезопасность, потому что требует неразумного количества интеллектуальных усилий, чтобы себя обслуживать. Не уверен, впрочем, что руст в этом плане так уж фундаментально сильно лучше, чем Ц++.
Намного лучше. В случае с Rust тебе нужно один раз напрячься и доказать компилятору что ты не верблюд.
В случае с С++ тебе нужно постоянно думать, а не верблюд ли ты.
Более того тебе нужно думать, а не верблюд ли твой коллега и те программисты код которых ты скачал с интернета.
В случае с Rust те люди которые написали код докажут что они не верблюды.
То есть разработка на Rust и других языках которые точно знают что код написал не верблюд масштабируется намного лучше чем на С++.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Проще. Только это не даёт гарантий, что ты всё поймал. А это значит, что падение в продакшене только вопрос времени.
Куда более распространенная проблема проблем в продакшн это не утечки/расстрел памяти, кои очень редки в современном мире, а банальные ошибки программирования от которых ни один язык не защищает. Меня не покидает ощущение того, что большинство активно агитирующих за Rust либо наслушалось страшилок про C++ при этом не имея с ним реального опыта, лабо были тяжело травмированы C++98/03. И да, C++98/03 был действительно сильно травмирующим неустойчивую психику языком
P.S. мне нравится Rust и его идея, просто никакой серебрянной пули и серьезного выигрыша по сравнению с C++ в безопасности кода нет. А вот Cargo, интерфейсы вместо классов, тесты вместе с исходниками и CSP из коробки и куча других моментов — это да, это несомненные жирные плюсы.
Здравствуйте, msorc, Вы писали:
M>И как бы ты оценил с позиции Java программиста с опытом:
M>- Преимущества и недостатки выражения абстракций в traits и interfaces
Я прям очень люблю trait objects в Rust, но по несколько извращённым причинам. В Java время от времени возникала задача адаптировать один тип к другому интерфейсу, причём определение типа менять нельзя. Стандартное решение -- классы-обёртки.
В Rust же появляется возможность просто приклеить интерфейс к уже существующему типу, прямо в райнтайме. Статью вот недавно написал: https://habr.com/ru/post/432202/
Rust -- это не ООП язык, абстракции по-другому строятся. Наверное, было два сложных момента, которые входят в противоречие с Rust:
1. Циклические и рекурсивные структуры данных. Когда совсем прижимает, можно использовать так всеми любимую в Rust структуру данных "вектор + индексы". Некрасиво, но жить можно. Плюс, можно поверх навернуть более-менее удобный API, который будет выглядеть как будто у тебя циклическая структура данных.
2. Разделяемые изменяемые ссылки. Собственно, это то, от чего и призван защищать borrow checker (чтобы избавиться от data races), но иногда такое нужно. Разные варианты, можно просто большим молотком бахнуть (`Option<Arc<Mutex<RefCell<T>>>>`). Можно опять же вектор с индексами использовать. Можно удариться в unsafe, если знаешь, как его готовить.
M>- Скорость разработки
Смешанные чувства. Сложно сравнивать. Мне кажется, я стал достаточно эффективен, но на это у меня ушло 6 месяцев. Но тут ещё есть эффект таланта. Как бы так сказать, чтобы сильно не хвастаться... Усреднённому программисту, особенно в начале карьеры будет трудно.
С другой стороны, очень много времени ушло на проектирование конструкций, которые в Java были бы прямо из коробки (например, своего рода reflection). Но абстракному прикладному программисту, возможно, об этом думать не нужно, так как всё уже будет готово.
В целом, я бы сказал, на Java и .NET можно сделать гораздо более эффективно, если правильных людей найти. Но тут такой момент, что на текущий момент усреднённый программист на Rust будет лучше, чем Java-программист.
M>- Абстрактные усилия на поддержку кода. Но условно, допустим запилить определенный функционал на Java 2 дня, тесты писал 1 день, потом 4 раза возвращался пофиксить баги. Как с Rust?
Пока сложно сказать.
Примерно после года разработки я затеял довольно сильный рефакторинг всего и вся и, в общем-то, проходит довольно успешно. Местами код, конечно, ужасный, смесь синей изоленты и соплей, но работает. Те, кто до этого работал на языках с динамической типизацией говорят, что такого рода изменения в Ruby, например, было бы очень сложно сделать. Но с другой стороны, у нас кода-то -- кот наплакал, наверное, тысяч 80 строк рукописных.
M>- Ресурсоемкость конечного продукта? Ну там типа Java 4 жирных сервера и падало раз в неделю, Rust — полтора средних сервера и не падает.
Пока не понятно, мы ещё в фазе когда всё ещё довольно наивно сделано и упирается в СУБД на совершенно глупых запросах (ну и как вишенка на торте, СУБД у нас -- CockroachDB, мы вообще очень смелые... или глупые :D)
В целом, я не считаю, что Rust вдруг магическим образом сделает стандартное энтерпрайзное приложение "быстрым". Но меня все вокруг убеждают, что Java в продакшене -- это ужас-ужас.
Был у меня интересный опыт на одном локальном примере.
Я написал некий конвертер из XML в JSON (в соответствии с требованиями нашей предметной области, там некоторая логика требовалась). Он был в раза в два медленнее Java на некотором абстрактном тесте. При том, что я более чем уверен, что Java вариант никто не оптимизировал (ну, просто общее ощущение от кода -- написано так, как я бы написал первый раз). После оптимизаций -- Rust был в 10 раз быстрее Java (в основном, после того, как я избавился от практически всех выделений строк). При этом код остался вполне читаемым (на мой взгляд), просто структуры данных немного более хитрые.
Но это чисто логика, плюс весьма специфичная задача.
Если подвести итог, я очень рад, что я 100% времени пишу Rust (это была одна из причин смены работы), но я так же безумно рад, что не я принимал решение использовать Rust и не отвечаю за него
Здравствуйте, kaa.python, Вы писали:
KP>Перед выбором Rust на C++17 смотрели?
А что там, изменили сущетсующую семантику ссылок/лайфтаймов в сторону безопасности и проверяемых компилятором гарантий? Нет, в язык просто досыпали новых фич, расширили стандартную библиотеку и уточнили вординг некоторых пунктов Стандарта.
Ядро языка как было слабым, так и осталось. То есть версия C++whatever никогда в принципе не сможет стать окончательным ответом на вопрос «смотреть ли в сторону Rust» или вообще «смотреть ли в сторону».
Здравствуйте, MT-Wizard, Вы писали:
MW>Borrow checker — одна из немногих причин, по которой я раст никогда не восприму как язык для работы. Я хочу дело делать, а не доказывать компилятору что-то.
А как ты узнаешь, что сделал дело, а не протекающий падучий багодром?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, reversecode, Вы писали:
R>а поскольку стреляют себе в ногу чаще новички, то руст получается язык на который можно нанимать новичков за меньшие деньги R>соответственно для бизнеса, попытка решения проблем меньшими затратами
Ну во-первых, не-новичкам тоже удается себе что-нибудь отстрелить. Причем в отличии от новичков, они делают это так старательно, что ногой не отделаешься, приходится целую задницу полностью ампутировать.
А во-вторых, переусложненность языка создает больше проблем, чем небезопасность, потому что требует неразумного количества интеллектуальных усилий, чтобы себя обслуживать. Не уверен, впрочем, что руст в этом плане так уж фундаментально сильно лучше, чем Ц++.
Здравствуйте, vsb, Вы писали:
vsb>C++ будет по всем параметрам лучше.
Не по всем.
В C++ есть жесткое деление на использование исключений или не использование. Из-за этого библиотеки/фреймворки, которые используют исключения, не могут применяться в проектах, где исключения под запретом. В обратную сторону тоже не все гладко. Тогда как в Rust-е единообразный подход с Result-ом для ошибок и паниками для всего прочего. Переиспользовать библиотеки заметно проще.
В C++ нет ни алгебраических типов данных, ни паттерн-матчинга.
В Rust-е для кого-то тамошние генерики с трейтами гораздо удобнее и проще, чем плюсовые шаблоны. В частности, в понятности сообщений об ошибках Rust впереди C++.
У Rust-а есть Cargo, у C++ -- зоопарк недоразвитых и конкурирующих инструментов для управления зависимостями и сборкой. Переиспользовать библиотеки в Rust гораздо проще.
Ну и кто-то просто в восторге, что в Rust-е нет нормального ООП.
Здравствуйте, kaa.python, Вы писали:
KP>Довольно интересная новость из мира виртуализации: Amazon открыл исходные коды платформы виртуализации Firecracker, которая оказалась написана на Rust. С одной стороны, у Amazon было не так уж и много опций для реализации чего-то похожего: Си да Rust, ну может быть C++, хотя это сомнительно по причине относительно громоздкого рантайма. С другой стороны, это еще одна серьезная компания, которая заинтересовалась языком.
KP>Может кто-то рассказать о своем опыте использования Rust в коммерческих проектах? Я пока что разве несколько стартапов с Rust видел
По-моему Rust много кто из крупных по чуть-чуть использует,
фейсбук для разработки своей VCS нанимал, dropbox в своей инфраструктуре использует
и т.д.
У меня лично как замена C++ для "логики" в новом проекте неплохо "зашел".
Здравствуйте, kaa.python, Вы писали:
vsb>>Почему не Go? Вон докер на Go написали же. Что значит громоздкий рантайм и как он помешает? Они же не на микроконтролерах запускают. KP>Уровень ниже чем у Докера, насколько я понимаю из описания. Нужно что-то без VM и способное на железе выполняться.
Это не проблема конкретно Go, на нём можно делать без особого напряжения достаточно низкоуровневый системный код. Firecracker не работает на голом железе, это просто обёртка над KVM в Линуксе. По сути, просто альтернатива qemu.
У Rust преимущество в том, что он более компактный и предсказуемый. Для Firecracker ещё одной из целей ставился жёсткий realtime с доказанными гарантиями, хотя потом на неё слегка забили.
Ну и я знаю команду, которая его писала — им было интересно попробовать Rust. Внутри Амазона они одни из первых его начали использовать.
Здравствуйте, koenig, Вы писали:
K>не флейма ради, но самообразования для K>что вместо каналов?
На мой взгляд равноценной замены ни каналам ни Карго в C++ нет и не будет. Более-менее похожие вещи на каналы (давай не будем разводить дискуссию про то, что CSP и Actor-ы это не одно и то же?) — библиотеки типа SObjectizer. А карго даже сложнее.
Здравствуйте, kaa.python, Вы писали:
KP>Может кто-то рассказать о своем опыте использования Rust в коммерческих проектах? Я пока что разве несколько стартапов с Rust видел, где он скорее по маркетинговым соображениям использовался, так как есть теория, что найти квалифицированного разработчика на Rust проще чем на C++. На первый взгляд разумная теория...
У нас Rust, как основной (по сути, единственный, есть локальные вкрапления библиотек на C/C++) язык для разработки бэкенда. Система -- плюс-минус типичный энтерпрайз[1] (которые обычно на Java пишут). Выбор Rust, на мой взгляд, было весьма и весьма смелым решением, но оценить эффект пока не берусь. Disclaimer: я (бывший) Java-разработчик с 10+ годами опыта с ней.
Стартап, pre-revenue (инвестиций -- на ~$36 млн.), возраст кодовой базы -- примерно полтора года. Я один из первых разработчиков, который, собственно, большую часть этого бэкенда на Rust и написал.
Могу на конкретные вопросы по-отвечать.
По соседству у нас, Dropbox, у них на Rust система синхронизации написана. Если я правильно понимаю, в клиентской части, они как-то презентовали как они это все тестируют.
[1]: Энтерпрайз в смысле: сложная предметная область, огромное количество legacy систем и интеграций с ними, приложение -- API-сервер с бизнес логикой + СУБД, технологии в индустрии примерно из 90х, а если повезло, то и из 2000х, и.т.д.
Здравствуйте, kaa.python, Вы писали:
KP>Довольно интересная новость из мира виртуализации: Amazon открыл исходные коды платформы виртуализации Firecracker, которая оказалась написана на Rust. С одной стороны, у Amazon было не так уж и много опций для реализации чего-то похожего: Си да Rust, ну может быть C++, хотя это сомнительно по причине относительно громоздкого рантайма. С другой стороны, это еще одна серьезная компания, которая заинтересовалась языком.
Итак, еще одни проект пал под натиском растоманов! На сей раз фатальный недостаток был выявлен в кодовой базе TOR! Отличная новость, т.к. растоманов (и желающих к ним присоедениться) до чертиков, а писать на Си за бесплатно мало кто хочет. Ждем-с более быстрого и активного развития TOR
Довольно интересная новость из мира виртуализации: Amazon открыл исходные коды платформы виртуализации Firecracker, которая оказалась написана на Rust. С одной стороны, у Amazon было не так уж и много опций для реализации чего-то похожего: Си да Rust, ну может быть C++, хотя это сомнительно по причине относительно громоздкого рантайма. С другой стороны, это еще одна серьезная компания, которая заинтересовалась языком.
Может кто-то рассказать о своем опыте использования Rust в коммерческих проектах? Я пока что разве несколько стартапов с Rust видел, где он скорее по маркетинговым соображениям использовался, так как есть теория, что найти квалифицированного разработчика на Rust проще чем на C++. На первый взгляд разумная теория...
Здравствуйте, Cyberax, Вы писали:
C>Ну и я знаю команду, которая его писала — им было интересно попробовать Rust. Внутри Амазона они одни из первых его начали использовать.
Так новость хорошо начиналась, а кончилось всё "эту игрушку мы ещё не пробовали". Жалко, ну да ладно.
Здравствуйте, kaa.python, Вы писали:
KP>В общем случае они не проблема.
Это о**енно большая и сложная проблема, люди над её решениями и дизайном бъются годами, пишут пейперы. Escape analysis и всё такое. В Rust понятия ownership, borrowing, lifetime management — довольно нетривиальная тема. А тут на тебе, C++-инженерА могут раз-два и в продакшн. Лолище.
KP>Косяки уровня возврата по ссылке локального объекта легко ловятся статическими анализаторами.
Как статический анализатор заглянет в код скомпилированных сторонних библиотек? Или он вообще запретит принимать ссылки на вход? Или он вообще запретит возвращать ссылки из функций?
Foo& forward_ref(Foo& ref)
{
// Код этой функции компилятору недоступен, если он в third-party-библиотеке.return ref;
}
Foo& bar()
{
Foo local;
return forward_ref(local);
}
— это его скорость развития и акцент на сильно не первостепенные фичи в прикладной разработке.
Его проблема в том, что это очень слабый, невыразительный язык. В других, более продвинутых языках вроде Rust некоторые заведомо некорректные вещи непредставимы, большой класс таких вещей. А в C++ и в версии C++20, C++23, C++35 это не изменится, даже если туда добавят модули, рефлексию, ranges, networking, корутины, you name it.
std::vector<int> v { 1729 };
int const& ref = v[0];
std::cout << "ref: " << ref << std::endl; // ref: 1729int count = 0;
for (; ref == 1729; ++count)
v.emplace_back(1);
std::cout << "count: " << count << std::endl; // count: 1
std::cout << "ref: " << ref << std::endl; // ref: -572662307
// Такое не должно быть представимо в языке: ---------^
Здравствуйте, kaa.python, Вы писали:
KP>Я скорее о том, что как ни силюсь не могу найти серьёзных преимуществ Rust перед C++17. Каналы и Карго не тянут на таковые. Думал, может тут пример такого, ан опять нет, очередной пример "поиграть захотелось".
Я как раз в последнее время с rust играюсь. Раньше только чисто теоретически за ним следил,
сейчас попробовал чуть пописать на уровне hello world, очень понравилось
Вообще сильно торчат везде кусочки OCaml'а. Во многом гибрид С++ и OCaml.
Для меня эти кусочки (да даже только один нормальный pattern matching, который
вряд ли в обозримом будущем на C++ появится) вполне за серьезные преимущества идут.
Хотя язык совсем не функциональный при этом.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Masterspline, Вы писали:
M>>Статические анализаторы и C++ дадут тот же эффект, но без необходимости бороться с borrow checker. K>Зачем бороться? Тема-то хорошая, только надо привыкнуть к этом и начать писать немного по другому. BC меня тоже жутко напрягает, ага.
Borrow checker — одна из немногих причин, по которой я раст никогда не восприму как язык для работы. Я хочу дело делать, а не доказывать компилятору что-то.
Здравствуйте, MT-Wizard, Вы писали:
M>>>Статические анализаторы и C++ дадут тот же эффект, но без необходимости бороться с borrow checker. K>>Зачем бороться? Тема-то хорошая, только надо привыкнуть к этом и начать писать немного по другому. BC меня тоже жутко напрягает, ага.
MW>Borrow checker — одна из немногих причин, по которой я раст никогда не восприму как язык для работы. Я хочу дело делать, а не доказывать компилятору что-то.
А зачем нужен Rust без borrow checker-а? C++ будет по всем параметрам лучше. Если пугает сложность и историческое наследие, возьми D.
Здравствуйте, kaa.python, Вы писали:
KP>Довольно интересная новость из мира виртуализации: Amazon открыл исходные коды платформы виртуализации Firecracker, которая оказалась написана на Rust. С одной стороны, у Amazon было не так уж и много опций для реализации чего-то похожего: Си да Rust, ну может быть C++, хотя это сомнительно по причине относительно громоздкого рантайма. С другой стороны, это еще одна серьезная компания, которая заинтересовалась языком.
Почему не Go? Вон докер на Go написали же. Что значит громоздкий рантайм и как он помешает? Они же не на микроконтролерах запускают.
Здравствуйте, vsb, Вы писали:
vsb>Почему не Go? Вон докер на Go написали же. Что значит громоздкий рантайм и как он помешает? Они же не на микроконтролерах запускают.
Уровень ниже чем у Докера, насколько я понимаю из описания. Нужно что-то без VM и способное на железе выполняться.
Здравствуйте, kaa.python, Вы писали:
C>>Ну и я знаю команду, которая его писала — им было интересно попробовать Rust. Внутри Амазона они одни из первых его начали использовать. KP>Так новость хорошо начиналась, а кончилось всё "эту игрушку мы ещё не пробовали". Жалко, ну да ладно.
Там проект немного NIH'овый. Началось всё с того, что хотели прикрутить Kata Containers от Intel'а. Но у них нашли фатальный недостаток.
Впрочем, в итоге получилось неплохо — кода там не так много, так что поле для раздолья было не сильно большое.
Здравствуйте, Cyberax, Вы писали:
C>Ну и я знаю команду, которая его писала — им было интересно попробовать Rust. Внутри Амазона они одни из первых его начали использовать.
Интересно, а другие основываясь на опыте этой команды пробовали пистаь на Rust?
Здравствуйте, Cyberax, Вы писали:
C>Впрочем, в итоге получилось неплохо — кода там не так много, так что поле для раздолья было не сильно большое.
Я скорее о том, что как ни силюсь не могу найти серьёзных преимуществ Rust перед C++17. Каналы и Карго не тянут на таковые. Думал, может тут пример такого, ан опять нет, очередной пример "поиграть захотелось".
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Cyberax, Вы писали:
C>>Впрочем, в итоге получилось неплохо — кода там не так много, так что поле для раздолья было не сильно большое.
KP>Я скорее о том, что как ни силюсь не могу найти серьёзных преимуществ Rust перед C++17. Каналы и Карго не тянут на таковые. Думал, может тут пример такого, ан опять нет, очередной пример "поиграть захотелось".
преимущество одно, можно наговнокодить и если оно скомпилилось то не упадет
другими словами в русте сложно отстрелить себе ногу
а поскольку стреляют себе в ногу чаще новички, то руст получается язык на который можно нанимать новичков за меньшие деньги
соответственно для бизнеса, попытка решения проблем меньшими затратами
проблема руста в данной логике, не понятно что с поддержкой в дальнейшем проектов написанных на нём
еще момент еще не понятно в каких области технологий можно влезть с рустом, т.е. это еще r&d и бизнес не готов експериментировать
ну т.е. к примеру hft хорошо для руста или нет ? не понятно
то что есть такая одна известная битмайнинг компания которая все с С++ переводит на руст, еще не значит что все хорошо
просто компания минимизирует свои затраты на разработчиков это понятно всем
не понятно насколько переписанное или переписываемое на руст действительно лучше себя проявляет чем то что написано на С++
Здравствуйте, Kernan, Вы писали:
C>>Ну и я знаю команду, которая его писала — им было интересно попробовать Rust. Внутри Амазона они одни из первых его начали использовать. K>Интересно, а другие основываясь на опыте этой команды пробовали пистаь на Rust?
Кто-то пробует, но чего-то крупномасштабного я не видел. Основные языки в Амазоне — это Java, за которой следует с большим отрывом Ruby и Perl. Там Rust сам по себе не нужен.
Насколько я знаю, на Rust смотрит группа, занимающаяся IoT, но не особо оживлённо.
Здравствуйте, Cyberax, Вы писали:
C>Если в коде на Rust не использовать unsafe и не прилагать очень существенных усилий с Arc'ами, то код будет безопасным. Т.е. в нём не будет утечек, use-after-free, переполнений и т.д.
Так и C++ будет безопасным без голых указателей в обвесе с GSL и санитайзерами. Ну да, немного надо сделать не из коробки, но это же один раз делается
Здравствуйте, Qbit86, Вы писали:
Q>И без голых ссылок тогда уж?
В общем случае они не проблема. Косяки уровня возврата по ссылке локального объекта легко ловятся статическими анализаторами. Единственная действительная проблема C++
C>>Впрочем, в итоге получилось неплохо — кода там не так много, так что поле для раздолья было не сильно большое.
KP>Я скорее о том, что как ни силюсь не могу найти серьёзных преимуществ Rust перед C++17. Каналы и Карго не тянут на таковые.
не флейма ради, но самообразования для
что вместо каналов?
Здравствуйте, reversecode, Вы писали:
R>преимущество одно, можно наговнокодить и если оно скомпилилось то не упадет R>другими словами в русте сложно отстрелить себе ногу R>а поскольку стреляют себе в ногу чаще новички, то руст получается язык на который можно нанимать новичков за меньшие деньги R>соответственно для бизнеса, попытка решения проблем меньшими затратами
От unsafe упадёт, от пропущенной паники упадёт (а еще есть настройка, при которой паника сразу роняет программу).
Здравствуйте, vsb, Вы писали:
R>>а поскольку стреляют себе в ногу чаще новички, то руст получается язык на который можно нанимать новичков за меньшие деньги R>>соответственно для бизнеса, попытка решения проблем меньшими затратами
vsb>От unsafe упадёт, от пропущенной паники упадёт (а еще есть настройка, при которой паника сразу роняет программу).
Скорее всего новичок споткнется на кривой обучения и до всего этого просто не дойдет
Здравствуйте, Masterspline, Вы писали:
M>Статические анализаторы и C++ дадут тот же эффект, но без необходимости бороться с borrow checker.
Зачем бороться? Тема-то хорошая, только надо привыкнуть к этом и начать писать немного по другому. BC меня тоже жутко напрягает, ага.
Здравствуйте, kaa.python, Вы писали:
KP>Довольно интересная новость из мира виртуализации: Amazon открыл исходные коды платформы виртуализации Firecracker, которая оказалась написана на Rust. С одной стороны, у Amazon было не так уж и много опций для реализации чего-то похожего: Си да Rust, ну может быть C++, хотя это сомнительно по причине относительно громоздкого рантайма. С другой стороны, это еще одна серьезная компания, которая заинтересовалась языком.
KP>Может кто-то рассказать о своем опыте использования Rust в коммерческих проектах? Я пока что разве несколько стартапов с Rust видел, где он скорее по маркетинговым соображениям использовался, так как есть теория, что найти квалифицированного разработчика на Rust проще чем на C++. На первый взгляд разумная теория...
Здравствуйте, MT-Wizard, Вы писали:
MW>Borrow checker — одна из немногих причин, по которой я раст никогда не восприму как язык для работы. Я хочу дело делать, а не доказывать компилятору что-то.
А если ты объявил переменную ix, а используешь необъявленную xi — это тоже называется "я ещё должен компилятору доказывать, что я не опечатался"?
Здравствуйте, kaa.python, Вы писали:
WH>>А как ты узнаешь, что сделал дело, а не протекающий падучий багодром? KP>Возьмёт ubsan и asan да убедится. Или это сложнее чем с borrow checker-ом бороться?
Проще. Только это не даёт гарантий, что ты всё поймал. А это значит, что падение в продакшене только вопрос времени.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, WolfHound, Вы писали:
WH>>Проще. Только это не даёт гарантий, что ты всё поймал. А это значит, что падение в продакшене только вопрос времени.
KP>Куда более распространенная проблема проблем в продакшн это не утечки/расстрел памяти, кои очень редки в современном мире,
Точно редки? Недавний пример с Java/Android, код с утекающей памятью чуть ли у каждого второго новичка:
anonymous class реализуем Observer для некого события, и неявно в соответствии со спецификацией Java захватывает ссылку на
Activity, экран переворачивается, Activity пересоздается, ссылка на нее все еще есть (циклическая удаленная Activity на Observer,
Observer на Activity), вот и утечка памяти, а Activity может довольно много весить.
В общем-то и в C++ с активным использованием std::shared_ptr такое будет.
KP>P.S. мне нравится Rust и его идея, просто никакой серебрянной пули и серьезного выигрыша по сравнению с C++ в безопасности кода нет.
Опять же возьмем новичка, в C++ передаст куда-нибудь указатель в стороннее API и не прочитает документацию,
а не новичку каждый раз гемор, нужно разбираться кто владеет ресурсом при передаче указателя,
а Rust использовать API неправильно и тут же ошибка компиляции.
Здравствуйте, Zhendos, Вы писали:
Z>anonymous class реализуем Observer для некого события, и неявно в соответствии со спецификацией Java захватывает ссылку на Z>Activity, экран переворачивается, Activity пересоздается, ссылка на нее все еще есть (циклическая удаленная Activity на Observer, Z>Observer на Activity), вот и утечка памяти, а Activity может довольно много весить.
А что, в андроиде не mark-n-sweep сборщик? Если несколько объектов циклически ссылаются друг на друга, но никто их живых не ссылается на них, то при очередной сборке они не будут помечены как живые, и соответственно будут убраны сборщиком. Но это если GC похож на то, что на десктопных/серверных рантаймах, тут я про андроид не в курсе.
И как бы ты оценил с позиции Java программиста с опытом:
— Преимущества и недостатки выражения абстракций в traits и interfaces
— Скорость разработки
— Абстрактные усилия на поддержку кода. Но условно, допустим запилить определенный функционал на Java 2 дня, тесты писал 1 день, потом 4 раза возвращался пофиксить баги. Как с Rust?
— Ресурсоемкость конечного продукта? Ну там типа Java 4 жирных сервера и падало раз в неделю, Rust — полтора средних сервера и не падает.
Здравствуйте, so5team, Вы писали:
vsb>>C++ будет по всем параметрам лучше. S>Не по всем.
Я бы даже сказал что почти по всем хуже.
S>В C++ есть жесткое деление на использование исключений или не использование. Из-за этого библиотеки/фреймворки, которые используют исключения, не могут применяться в проектах, где исключения под запретом. В обратную сторону тоже не все гладко. Тогда как в Rust-е единообразный подход с Result-ом для ошибок и паниками для всего прочего. Переиспользовать библиотеки заметно проще.
Обработку ошибок нужно делать так http://joeduffyblog.com/2016/02/07/the-error-model/
Тогда переключение между быстрыми исключениями и медленными кодами возврата будет ключом компилятора.
S>В C++ нет ни алгебраических типов данных, ни паттерн-матчинга.
Это просто убивает.
S>В Rust-е для кого-то тамошние генерики с трейтами гораздо удобнее и проще, чем плюсовые шаблоны. В частности, в понятности сообщений об ошибках Rust впереди C++.
Так они объективно лучше, когда нужно писать обобщённый код.
А для метапрограммирования там есть макросы.
S>У Rust-а есть Cargo, у C++ -- зоопарк недоразвитых и конкурирующих инструментов для управления зависимостями и сборкой. Переиспользовать библиотеки в Rust гораздо проще.
Это трудно оценить пока не попробуешь.
S>Ну и кто-то просто в восторге, что в Rust-е нет нормального ООП.
Одиночное наследование с виртуальными функциями иногда довольно удобный инструмент.
Но его отсутствие не трудно обойти.
Да и при наличии трейтов оно почти не нужно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Иван Дубров, Вы писали:
ИД>Здравствуйте, msorc, Вы писали:
ИД>2. Разделяемые изменяемые ссылки. Собственно, это то, от чего и призван защищать borrow checker (чтобы избавиться от data races), но иногда такое нужно. Разные варианты, можно просто большим молотком бахнуть (`Option<Arc<Mutex<RefCell<T>>>>`).
А смысл RefCell засовывать внутрь Mutex? Данные внутри `Arc<Mutex<T>>` можно и читать и писать,
масло масленное получается.
M>>- Скорость разработки
ИД>С другой стороны, очень много времени ушло на проектирование конструкций, которые в Java были бы прямо из коробки (например, своего рода reflection). Но абстракному прикладному программисту, возможно, об этом думать не нужно, так как всё уже будет готово.
Здравствуйте, Zhendos, Вы писали:
Z>А смысл RefCell засовывать внутрь Mutex? Данные внутри `Arc<Mutex<T>>` можно и читать и писать, Z>масло масленное получается.
Да, ты прав. Как можешь догадаться, этот вариант мы не используем :D
ИД>>С другой стороны, очень много времени ушло на проектирование конструкций, которые в Java были бы прямо из коробки (например, своего рода reflection). Но абстракному прикладному программисту, возможно, об этом думать не нужно, так как всё уже будет готово.
Z>serde не хватило?
Вот с него на своё и переделываем. Несколько причин, производительность, трудно делать определённые трансформации во время чтения данных, валидации, скорость компиляции (у нас довольно большая модель данных, да ещё и в трёх разных версиях). Плюс, этот reflection не только для сериализации используется, а ещё и для валидации по схеме, вытаскивания данных из модели (по типу JSON Path).
