Здравствуйте, ArtDenis, Вы писали:
DE>>Нет, не теряется. Есть смысл минимизировать использование ансейф и заворачивать в безопасные снаружи абстракции, но вообще это нормальная часть языка.
AD>Ну так речь идёт об обычном клиентском коде, а не о библиотечном, как я понял. Действительно стандартная либа раста — сплошной ансейф ради скорости.
Если я правильно понял, то контекст был такой: "как мне убрать _лишние_ проверки" — "вот есть способ" — "фуу, ансейф!". Так вот как иначе-то? Если в "клиентском коде" мы упираемся в такие проверки, то не вижу ничего криминального в том, чтобы использовать ансейф. В идеале, конечно, оставить комментарий зачем оно нужно и обложить тестами.
Здравствуйте, alex_public, Вы писали:
_>Это возможно просто неправильная архитектура. ) А может и нормальная — отсюда не видно. ))) Зависит от задачи. Если у тебя там данные, ссылка на которые захватывается (замыканием) коллбеком, реально постоянно создаются/уничтожаются в памяти, то это правильная архитектура. Если же нет, то вместо Rc<RefCell<>> на самом деле должно было быть &'static mut.
Статик мут? Как вообще это возможно? Глобалки делать мутабельными сложновато. Ну и доступ к этой сущности блокируется на всё потенциальное время жизни калбака.
_>Вообще тут можно легко смотреть по аналогии с C++. Rc<RefCell<>> должно быть в коде в тех местах, где в C++ был бы shared_ptr (которого кстати обычно стараются избегать). И не более того!
Ээээ, нет. В С++ проще сделать юник и много простых указателей на содержимое, потому что ты знаешь хозяина. Доказать это знание борроу-чекеру в общем случае невозможно.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Artem Korneev, Вы писали:
AK>А можете пример какой-нибудь привести? AK>Кода на Rust'е я за последние пару лет успел написать немало, но чтоб мне хоть раз понадобился borrow_mut() я так сходу вообще не припомню. Вот Arc<Mutex<...>> полно, да.
Ну сохранить что-то в каллбаке.
Да или просто движок с полиморфными сущностями. Из-за полиморфности ты не можешь сделать их методы методами самого движка. А так как сущности могут менять друг друга, то общий пул объектов приходится захватывать "по частям", из-за этого пул объектов приходится делать в виде вектор Rc<RefCell<...>>
ПС два года ты писал на работе или для себя? Когда пишешь для себя, то разнообразие ситуаций на порядок выше, чем когда на работе. И когда у тебя не тула типа прочитать-обработать-сохранить, а что-то посложнее, то всё становится весело.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>А иначе — использовать borrow_mut
Я не понимаю, что ты хочешь сказать. Есть "безопасное" (с проверками) апи, есть ансейф (без проверок), где доказательство корректности ложиться на программиста. Оба варианта тебе не нравятся.
TB>И потерять гибкость архитектуры и поиметь бесконечный рефакторинг на каждый чих.
Не вижу прямой связи, ну да ладно. В любом случае, я как раз и говорил, что этот вариант тоже совсем не идеален.
Здравствуйте, DarkEld3r, Вы писали:
DE>Я не понимаю, что ты хочешь сказать. Есть "безопасное" (с проверками) апи, есть ансейф (без проверок), где доказательство корректности ложиться на программиста. Оба варианта тебе не нравятся.
Если использовать ансейф, то нахрена козе баян?
Кстати знаешь, что бывает, если в ансейфе что-то не то сделаешь и случайно сделаешь две мутабельные ссылки на один объект?
DE>Не вижу прямой связи, ну да ладно. В любом случае, я как раз и говорил, что этот вариант тоже совсем не идеален.
Связь в том, что архитектура на рефцеллах не требует сношаться с временем жизни, поэтому ты можешь безболезненно менять порядок создания объектов
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Artem Korneev, Вы писали:
AK>Rust это в большей степени системный язык. Но насколько я понимаю, для десктопа уже всё давно есть, просто менее отшлифованное, чем для сетевых сервисов. AK>Пользоваться, в принципе, уже можно — на гитхабах уже хватает каких-то GUI-велосипедов на Rust'е. Ещё пару лет и будет, наверное, удобно.
Язык — мало. Нужны еще библиотеки и внятная документация с примерами к ним.
А где гарантия, что не появится еще один язык и не победит?
S>>И еще вопрос. Rust компилится в нейтивный язык?
AK>В машинный код. Да.
А много за собой необходимых библиотек тащит для просто чтобы запустилось? Фреймворк или что-то в этом роде нужно?
Здравствуйте, Shmj, Вы писали:
S>А много за собой необходимых библиотек тащит для просто чтобы запустилось? Фреймворк или что-то в этом роде нужно?
Ну я пишу домашний проект, скачал уже довольно жирные либы, типа сериализатор структур в джсоны, короче мегабайта два на релизный екзешник — это норма(
Можно пострипать, будет 500кб, но тогда при падении трассу стека не увидишь. Думаю, тебе будет лучше, если твою юзеры смогут читать трассу и присылать тебе нормальные отчёты.
>Язык — мало. Нужны еще библиотеки и внятная документация с примерами к ним.
А чтоб скачать официальную либу, тебе надо просто прописать одну зависимость в файле сборки. Тебе не надо сношаться с поиском репозитория левой либы, врубаться как она собирается, в каком году она написана, как её подогнать под актуальный стандарт и нет ли в ней УБ которые в те времена никого не парили.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Shmj, Вы писали:
S>А много за собой необходимых библиотек тащит для просто чтобы запустилось? Фреймворк или что-то в этом роде нужно?
Какие либы подцепишь, такие он и добавит в exe-шник. Если ничего не подцепишь, то там будет только твой код. Поэтому в принципе на нём можно писать для микроконтроллеров, но на мой взгляд пока рано.
Здравствуйте, T4r4sB, Вы писали:
TB>Если использовать ансейф, то нахрена козе баян?
Чтобы решить проблему производительности точечно и спрятать её за безопасной абстракцией. И чтобы видеть какому коду надо уделить особенноe внимание.
То есть, ты всё-таки хочешь чтобы было и безопасно и без лишних проверок и писался код просто? Ну так не бывает.
TB>Кстати знаешь, что бывает, если в ансейфе что-то не то сделаешь и случайно сделаешь две мутабельные ссылки на один объект?
S>И еще вопрос. Rust компилится в нейтивный язык? Без всяких вирт. машин, прослоек и пр.? Т.е. если я захочу написать свою ОС с нуля и использовать Rust — то не нужно тащить среду или еще что, чтобы все работало?
Rust как C++ — нативнее некуда, без VM и сборки мусора. Runtime там примерно как в C++.
Сейчас идет активная работа по включению возможности писать на Rust модуля ядра Linux. Уже прошло несколько итераций (4 или 5), внесли некоторые изменения в библиотеку Rust и, возможно, компилятор. Раньше в Rust были какие-то ограничения, кажется, в виде поддержки в runtime чего-то, что для ядра неприемлемо и Panic, когда не надо. Сейчас уже многое исправлено, причем в стабильной версии компилятора и библиотек и теперь Rust близок к тому, чтобы на нем можно было писать модули ядра Linux.
Здравствуйте, Reset, Вы писали:
R>Rust как C++ — нативнее некуда, без VM и сборки мусора. Runtime там примерно как в C++.
R>Сейчас идет активная работа по включению возможности писать на Rust модуля ядра Linux.
а Linux.
Кстати когда будет возможность компилировать екзешники без необходимость трахаться с левыми линкерами? Чтоб в тулчейне было всё, ну либо он сам скачивал что надо.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Reset, Вы писали:
R>С графикой, как я понимаю, все примерно как в Go, т.е. никак.
Всё там нормально с GUI библиотеками, в отличие от того же Go. Причём речь не о банальных биндингах C/C++ библиотек (которые есть в большинстве других языков), а о новых родных библиотеках. Причём есть и под десктоп и под веб (webassembly) и смешанные. С бэкендом и в виде OpenGL/Vulkan и в виде системных API. Короче есть всё и на любой вкус.
Единственно что, большинство из них ещё в активной разработке, так что при обновление версии иногда ломается код и приходится править (правда всегда в лучшую сторону).
Здравствуйте, Artem Korneev, Вы писали:
AK>Кода на Rust'е я за последние пару лет успел написать немало, но чтоб мне хоть раз понадобился borrow_mut() я так сходу вообще не припомню. Вот Arc<Mutex<...>> полно, да.
Кстати говоря, Arc<Mutex<...>> — это весьма тяжеловесная штука, ныряющая в ядро ОС. Поэтому она должна применяться только в том случае, если у тебя программе реально происходит параллельная модификация одного и того же куска памяти из разных потоков.
Лично я в большинстве задач предпочитаю использовать взаимодействие потоков на базе модели акторов (что идеально ложится на идеологию "владения" C++/Rust), так что подобных конструкций в последних проектах вообще не вижу. Хотя вполне могу представить их полезность в определённых специфических задачах (типа параллельных вычислений на одном огромном массиве данных).
Здравствуйте, ArtDenis, Вы писали:
S>>И еще вопрос. Rust компилится в нейтивный язык? Без всяких вирт. машин, прослоек и пр.?
AD>Конечно. Раст — это как с++, только без стероидов и без синдрома Бога у пограммиста, потому что компилятор бъёт по пальцам не даёт портить память.
мы просмотрели пример того, как не надо рекламировать язык
тут рядом Reset правильный заход сделал ("у нас есть печпакетный менеджер")
