Здравствуйте, ArtDenis, Вы писали:
AD>В этом как раз и состоит смысл рантайм проверок на наличие гонок в коде. Просто если он используется уж слишком часто, это возможно означает, что что-то пошло не так и надо ещё раз окинуть взглядом архитектуру
Ну сорян, любая попытка сделать хоть какую-то гибкость приводит именно к такому вот
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
S>Видимо кто-то считает, что Rust достаточно высокоуровневый, чтобы на нем удобно было и сайты клепать.
Чувак, ты похоже, как и большинство, оторван от реальности в том, что касается Rust. Чтобы ты понимал, на Rust примерно сколько же веб фреймворков и настолько же хорошо спроектированных и используемых, как и на GoLang (в том числе и с довольно длительной историей). Т.е. если тебе нужен быстро работающий сайт, который смогут реализовать студенты-третьекуры — ты берешь Go. Если же у тебя разработчики чуть более квалифицированные и им довольно быстро надоедает примитивный язык с самой убогой обработкой ошибок с диким количеством однообразного кода — тогда берут Rust. В результате он занимает нишу в вебе, которая раньше была эксклюзивно для Go.
А вообще, если отбросить стереотипы (с которыми относятся к Rust и JS), то Rust — это как C++, только удобнее и с пакетным менеджером. Поэтому любой разработчик на Rust легко может использовать любые пакеты без плясок вокруг кастомной системы сборки и 3-х разных пакетных менеджеров.
В результате, если, кончено, не мешают заморочки, то новый софт в нише C++ (и частично Go) пишется на Rust. А C++ остался для legacy и особо замороченных типлидов, которые слишком упертые, чтобы понять, что C++ через лет 5 станет маргинальщиной. Ну и пусть, кто не поймет — вымрет естественным способом.
Резюмирую. На Rust уже сейчас много разного софта, потому что он как C++, только удобнее и в нем есть пакетный менеджер. C++ — legacy. Ниша быстрого веба делится между Go и Rust. У Rust есть много странностей, но они есть и у C++, а разница только в том, что странности C++ всем привычные. Из неприятных моментов:
стереотипное отношение к Rust (но это на практике ни на что не влияет),
Rust у работодателей еще не очень популярен. Но это исправляется постепенно, потому что люди без заморочек становятся теми, кто принимает решения, а работодателю обычно пофиг, на чем ты пишешь, лишь бы задачу решил. Поэтому постепенно появляются работодатели, предлагающие разработку на Rust.
Здравствуйте, Reset, Вы писали:
R>В результате, если, кончено, не мешают заморочки, то новый софт в нише C++ (и частично Go) пишется на Rust. А C++ остался для legacy и особо замороченных типлидов, которые слишком упертые, чтобы понять, что C++ через лет 5 станет маргинальщиной. Ну и пусть, кто не поймет — вымрет естественным способом.
Ок. А на macOS (если вы продвинутый представитель человечества) — есть инструменты Rust? С++ инструменты есть.
Далее. Можно ли писать десктопные приложения и какие фреймворки для этого? Есть ли поддержка кросс-платформы как у QT (можно скомпилить для Win, macOS, Lin)?
Далее. Есть ли поддержка работы с OpenGL, есть ли примеры?
Здравствуйте, T4r4sB, Вы писали:
TB>У меня этот borrow_mut блин везде. Потому что Rc<RefCell<>> просто блин везде. Даже вот элементарно прокинуть хоть какой-то контекст в каллбак — всё, пихай Rc<RefCell> потому что любая попытка захватить нормальную ссылку приведёт к невозможности что-то ещё делать с объектом в другом коде.
Это возможно просто неправильная архитектура. ) А может и нормальная — отсюда не видно. ))) Зависит от задачи. Если у тебя там данные, ссылка на которые захватывается (замыканием) коллбеком, реально постоянно создаются/уничтожаются в памяти, то это правильная архитектура. Если же нет, то вместо Rc<RefCell<>> на самом деле должно было быть &'static mut.
Вообще тут можно легко смотреть по аналогии с C++. Rc<RefCell<>> должно быть в коде в тех местах, где в C++ был бы shared_ptr (которого кстати обычно стараются избегать). И не более того!
У меня в одном приложение тоже по началу (возможно ещё по неопытности в Rust) были кругом borrow_mut. А потом я взглянул повнимательнее на то, что у меня там хранится и понял, что это глобальная сущность, используемая в одном потоке, так что все эти средства просто бесполезный синтаксический мусор в данном случае. В итоге поменял в коде по сути одну точку и далее весь этот borrow мусор сам вычистился из кода.
R>>В результате, если, кончено, не мешают заморочки, то новый софт в нише C++ (и частично Go) пишется на Rust. А C++ остался для legacy и особо замороченных типлидов, которые слишком упертые, чтобы понять, что C++ через лет 5 станет маргинальщиной. Ну и пусть, кто не поймет — вымрет естественным способом.
S>Ок. А на macOS (если вы продвинутый представитель человечества) — есть инструменты Rust? С++ инструменты есть.
Как я понял — есть. Да и не может быть по другому, слишком много разработчиков фанатеют от MAC.
S>Далее. Можно ли писать десктопные приложения и какие фреймворки для этого? Есть ли поддержка кросс-платформы как у QT (можно скомпилить для Win, macOS, Lin)?
С графикой, как я понимаю, все примерно как в Go, т.е. никак.
S>Далее. Есть ли поддержка работы с OpenGL, есть ли примеры?
Интеграция с C-шными библиотеками есть в любом языке. В Rust, как я понимаю, это делается довольно просто. Наверняка, кто-то сделал какой-нибудь crate (пакет).
Здравствуйте, kaa.python, Вы писали:
KP>у Rust тот же LLVM под капотом и Rust по определению не может быть более экономичным с точки зрения потребления энергии чем Clang.
При чём здесь Clang? Это же компилятор.
Более экономичным по определению он может быть, например, там, где он избавляется от vtable и, как следствие, от "лишнего" разыменования указателя при вызове метода. Это если сравнивать с плюсами. Если сравнивать с чистым Си, то код на Rust на несколько процентов медленнее, но это ожидаемо — добавляются кое-какие рантайм проверки.
Здравствуйте, T4r4sB, Вы писали:
TB>Но это капля в море, а рантайм-проверки прожирают перфоманс в хлам.
Можно чуть подробнее о рантайм-проверках, прожирающих перформанс?
В Rust вроде как идёт упор как раз на проверки на этапе компиляции, в идеале — с zero-cost abstractions.
Здравствуйте, T4r4sB, Вы писали:
TB>Ну сорян, любая попытка сделать хоть какую-то гибкость приводит именно к такому вот
А можете пример какой-нибудь привести?
Кода на Rust'е я за последние пару лет успел написать немало, но чтоб мне хоть раз понадобился borrow_mut() я так сходу вообще не припомню. Вот Arc<Mutex<...>> полно, да.
Здравствуйте, vsb, Вы писали:
vsb>Я считаю, что это пример экошизы. Из разряда дня земли.
Смысл посыла в том, что при использовании Rust'а для тех же задач якобы требуется меньше процессорной мощности.
Я не берусь судить правда это или нет, но вот смысл в этом как раз на поверхности — для CPU-heavy задач может потребоваться меньше серверов. И это в первую очередь экономия денег на процессорные мощности и уже во-вторую — экология и всё такое.
То, что далеко не все задачи CPU-heavy, а в реальности многие сервисы ожидают событий ввода/вывода и более требовательны к памяти, чем к CPU — это понятно.
Здравствуйте, Shmj, Вы писали:
S>Ок. А на macOS (если вы продвинутый представитель человечества) — есть инструменты Rust? С++ инструменты есть.
Да. Всё есть, всё удобно, всё работает.
S>Далее. Можно ли писать десктопные приложения и какие фреймворки для этого? Есть ли поддержка кросс-платформы как у QT (можно скомпилить для Win, macOS, Lin)?
Что-то есть. Насколько оно юзабельное — я пока не понял. Предполагаю, что пока не настолько всё отшлифованное, как для C++, но видно, что процесс идёт.
Я эксперименту ради пробовал нарисовать GUI на Rust на своей Ruspberri Pi, но оно не заработало из-за того что выбранный мною фреймворк (gtk4) для отрисовки требует каких-то там Vulkan, а на Ruspberri Pi драйверы видео ещё не поддерживают этот API. Ну или что-то в этом духе. Тут я не специалист, обычно занимаюсь сетевыми сервисами, а в GUI полез пощупать в свободное от работы время. Думал, что GTK4 должен быть свежим и продвинутым, но он оказался слишком свежим для моей Ruspberri Pi.
S>Далее. Есть ли поддержка работы с OpenGL, есть ли примеры?
Да, это всё есть. Примеров в инете полно, хотя сам я пока не пробовал. Мне интересен сейчас обычный GUI, а не трёхмерная графика.
Здравствуйте, Artem Korneev, Вы писали:
S>>Далее. Можно ли писать десктопные приложения и какие фреймворки для этого? Есть ли поддержка кросс-платформы как у QT (можно скомпилить для Win, macOS, Lin)?
AK>Что-то есть. Насколько оно юзабельное — я пока не понял. Предполагаю, что пока не настолько всё отшлифованное, как для C++, но видно, что процесс идёт.
Вот в том то и дело... А сколько еще всего, что так сразу и не вспомнишь...
И еще вопрос. Rust компилится в нейтивный язык? Без всяких вирт. машин, прослоек и пр.? Т.е. если я захочу написать свою ОС с нуля и использовать Rust — то не нужно тащить среду или еще что, чтобы все работало?
Здравствуйте, Shmj, Вы писали:
AK>>Что-то есть. Насколько оно юзабельное — я пока не понял. Предполагаю, что пока не настолько всё отшлифованное, как для C++, но видно, что процесс идёт. S>Вот в том то и дело... А сколько еще всего, что так сразу и не вспомнишь...
Rust это в большей степени системный язык. Но насколько я понимаю, для десктопа уже всё давно есть, просто менее отшлифованное, чем для сетевых сервисов.
Пользоваться, в принципе, уже можно — на гитхабах уже хватает каких-то GUI-велосипедов на Rust'е. Ещё пару лет и будет, наверное, удобно.
Там каких-либо фундаментальных-то проблем нет, можно в принципе взять любую С или С++ библиотеку и использовать, сделав обёртку к нужным функциям на Rust. Работать-то будет, только будет выглядеть как кривой велосипед. А вот чтоб всё это удобно ложилось на идеологию Rust'а — тут нужно потратить время и написать нормальную библиотеку. Но пока похоже, что большинство компаний, использующих Rust, заинтересованы в написании системного софта. Поэтому для системного софта всё отполировано, а для GUI ещё хватает шероховатостей.
S>И еще вопрос. Rust компилится в нейтивный язык?
В машинный код. Да.
S> если я захочу написать свою ОС с нуля и использовать Rust — то не нужно тащить среду или еще что, чтобы все работало?
Да. Даже есть уже какая-то OS, написанная на Rust — тут.
Но мне более интересно то, что Rust предлагают использовать в исходниках Linux. Это более многообещающая отрасль. Пока там какие-то детали обсуждают с прошлого сентября, но процесс идёт, похоже что они договорятся.
Здравствуйте, Shmj, Вы писали:
S>Далее. Можно ли писать десктопные приложения и какие фреймворки для этого?
Это больной вопрос у раста. Есть много биндингов к гуишным либам и есть много своих либ на чистом расте и всё это можно использовать. Но нету либ, в которых всё-всё есть и всё "вылизано" и можно сказать, что это дефакто стандарт для гуя. Хотя есть претенденты на это есть, например https://www.gtk.org/docs/language-bindings/rust Видимо язык пока слишком молодой, чтобы для него успели написать что-то большое и монструозное в плане гуя ))
Здравствуйте, ArtDenis, Вы писали:
DE>>Если сильно надо, то можно использовать as_ptr — проверок не будет. Тут в теме ещё про массивы проскакивало — на всякий случай, для них есть get_unchecked.
AD>Зачем использовать unsafe? Тогда весь смысл rust-а теряется.
Нет, не теряется. Есть смысл минимизировать использование ансейф и заворачивать в безопасные снаружи абстракции, но вообще это нормальная часть языка. С таким же успехом можно спрашивать зачем использовать "сырые" указатели в С++, ведь есть unique_ptr и shared_ptr.
Здравствуйте, ArtDenis, Вы писали:
AD>Конечно. Раст — это как с++, только без стероидов и без синдрома Бога у пограммиста, потому что компилятор бъёт по пальцам не даёт портить память.
Мне кажется, у разработчиков на Rust синдром Бога должен быть сильно более ярко выраженным. Всё же это уникальный язык, где разработчик вынужден выполнять работу компилятора по доказательству валидности времени жизни объекта
Здравствуйте, DarkEld3r, Вы писали:
DE>Нет, не теряется. Есть смысл минимизировать использование ансейф и заворачивать в безопасные снаружи абстракции, но вообще это нормальная часть языка.
Ну так речь идёт об обычном клиентском коде, а не о библиотечном, как я понял. Действительно стандартная либа раста — сплошной ансейф ради скорости.
Здравствуйте, kaa.python, Вы писали:
KP>Мне кажется, у разработчиков на Rust синдром Бога должен быть сильно более ярко выраженным. Всё же это уникальный язык, где разработчик вынужден выполнять работу компилятора по доказательству валидности времени жизни объекта
Именно! Растоманы только делают вид, что смиренно склоняют головы перед компилятором. А на самом деле они БОГИ БОГОВ! И это тайна, если что )
Здравствуйте, T4r4sB, Вы писали:
DE>>RefCell? Если сильно надо, то можно использовать as_ptr — проверок не будет. Тут в теме ещё про массивы проскакивало — на всякий случай, для них есть get_unchecked.
TB>А, то есть грязь с ансейфом.
А как иначе-то? Все unchecked методы тоже ансейф. Это ведь способ сказать компилятору "я лучше знаю".
Можно разве что использовать более мощную систему типов (зависимые типы) чтобы выразить необходимые условия, но у этого подхода свои сложности. И что характерно, в языках с доказательствами есть свой "ансейф" (вроде believe_me в идрисе).
Здравствуйте, Shmj, Вы писали:
S>Ок. А на macOS (если вы продвинутый представитель человечества) — есть инструменты Rust? С++ инструменты есть.
Что именно под инструментами подразумевается? ИДЕ? Тогда есть: хоть идея/CLion с официальным плагином от джетбрейнс, хоть vscode + rust-analyzer (language server).
Форматтер кода, линтер и прочие вспомогательные штуки идут из коробки на всех платформах.
S>Далее. Можно ли писать десктопные приложения и какие фреймворки для этого?
Тут всё плохо. Есть попытки создания библиотек/фреймворков, но они, в основном сырые. Подробнее можно посмотреть вот тут: https://www.areweguiyet.com/
S>Далее. Есть ли поддержка работы с OpenGL, есть ли примеры?
