Здравствуйте, Zhendos, Вы писали:
Z>anonymous class реализуем Observer для некого события, и неявно в соответствии со спецификацией Java захватывает ссылку на Z>Activity, экран переворачивается, Activity пересоздается, ссылка на нее все еще есть (циклическая удаленная Activity на Observer, Z>Observer на Activity), вот и утечка памяти, а Activity может довольно много весить.
А что, в андроиде не mark-n-sweep сборщик? Если несколько объектов циклически ссылаются друг на друга, но никто их живых не ссылается на них, то при очередной сборке они не будут помечены как живые, и соответственно будут убраны сборщиком. Но это если GC похож на то, что на десктопных/серверных рантаймах, тут я про андроид не в курсе.
Здравствуйте, kaa.python, Вы писали:
KP>P.S. мне нравится Rust и его идея, просто никакой серебрянной пули и серьезного выигрыша по сравнению с C++ в безопасности кода нет. А вот Cargo, интерфейсы вместо классов, тесты вместе с исходниками и CSP из коробки и куча других моментов — это да, это несомненные жирные плюсы.
Я к своему огромному удивлению обнаружил, что на Rust довольно легко переписывается мой старый код с Haskell, где были сплошные монады, продолжения, классы типов, суммы-типы и т.п. При этом Rust как платформа предлагает примерно то же, что и C++. Никакого сборщика мусора, почти полное отсутствие системы времени исполнения.
Так что, случись выбирать между Rust и C++, уже знаю свое решение.
Здравствуйте, 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х, и.т.д.
И как бы ты оценил с позиции Java программиста с опытом:
— Преимущества и недостатки выражения абстракций в traits и interfaces
— Скорость разработки
— Абстрактные усилия на поддержку кода. Но условно, допустим запилить определенный функционал на Java 2 дня, тесты писал 1 день, потом 4 раза возвращался пофиксить баги. Как с Rust?
— Ресурсоемкость конечного продукта? Ну там типа Java 4 жирных сервера и падало раз в неделю, Rust — полтора средних сервера и не падает.
Здравствуйте, MT-Wizard, Вы писали:
M>>>Статические анализаторы и C++ дадут тот же эффект, но без необходимости бороться с borrow checker. K>>Зачем бороться? Тема-то хорошая, только надо привыкнуть к этом и начать писать немного по другому. BC меня тоже жутко напрягает, ага.
MW>Borrow checker — одна из немногих причин, по которой я раст никогда не восприму как язык для работы. Я хочу дело делать, а не доказывать компилятору что-то.
А зачем нужен Rust без borrow checker-а? C++ будет по всем параметрам лучше. Если пугает сложность и историческое наследие, возьми D.
Здравствуйте, vsb, Вы писали:
vsb>C++ будет по всем параметрам лучше.
Не по всем.
В C++ есть жесткое деление на использование исключений или не использование. Из-за этого библиотеки/фреймворки, которые используют исключения, не могут применяться в проектах, где исключения под запретом. В обратную сторону тоже не все гладко. Тогда как в Rust-е единообразный подход с Result-ом для ошибок и паниками для всего прочего. Переиспользовать библиотеки заметно проще.
В C++ нет ни алгебраических типов данных, ни паттерн-матчинга.
В Rust-е для кого-то тамошние генерики с трейтами гораздо удобнее и проще, чем плюсовые шаблоны. В частности, в понятности сообщений об ошибках Rust впереди C++.
У Rust-а есть Cargo, у C++ -- зоопарк недоразвитых и конкурирующих инструментов для управления зависимостями и сборкой. Переиспользовать библиотеки в Rust гораздо проще.
Ну и кто-то просто в восторге, что в 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, Вы писали:
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 и не отвечаю за него
Здравствуйте, Иван Дубров, Вы писали:
ИД>Здравствуйте, 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).
Здравствуйте, kaa.python, Вы писали:
KP>Довольно интересная новость из мира виртуализации: Amazon открыл исходные коды платформы виртуализации Firecracker, которая оказалась написана на Rust. С одной стороны, у Amazon было не так уж и много опций для реализации чего-то похожего: Си да Rust, ну может быть C++, хотя это сомнительно по причине относительно громоздкого рантайма. С другой стороны, это еще одна серьезная компания, которая заинтересовалась языком.
Итак, еще одни проект пал под натиском растоманов! На сей раз фатальный недостаток был выявлен в кодовой базе TOR! Отличная новость, т.к. растоманов (и желающих к ним присоедениться) до чертиков, а писать на Си за бесплатно мало кто хочет. Ждем-с более быстрого и активного развития TOR
Усреднённому программисту, особенно в начале карьеры будет трудно.
