Rust и экология - Компьютерные священные войны

Здравствуйте, Nuzhny, Вы писали:

N>Пресса пишет, что переписав всё на Rust можно сэкономить до 50% энергии датацентров.
N>Пишут это в контексте C/C++, но пример с энергоэффективность почему-то касается javascript.
N>Но да ладно. Интересно реально ли и за счёт чего он может оказаться энергоэффективнее C/C++. Кто-нибудь видел данные?

Шейн Миллер утверждает, что использование ПО на Rust, лишенное известных проблем его аналогов на C, позволяет сократить объемы энергии, потребляемые центрами обработки данных. С его слов, переход на такое ПО даже по самым пессимистичным прогнозам поможет снизить потребление ЦОДами энергии на 50%.

Я полагаю что это надо так трактовать: на Си боязно, С++ мы не осилили и снежинки их бояццо, но JS и Python любят. А так как снежинки верят что Rust простой и безопасный (гы-гы), то если писать на нем то энергии будет жраццо меньше.

Иначе это ты никак не интерпретируешь, т.к. у Rust тот же LLVM под капотом и Rust по определению не может быть более экономичным с точки зрения потребления энергии чем Clang.

Я считаю, что это пример экошизы. Из разряда дня земли.

Здравствуйте, Nuzhny, Вы писали:

N>Но да ладно. Интересно реально ли и за счёт чего он может оказаться энергоэффективнее C/C++. Кто-нибудь видел данные?

Ясно же, что в общем случае ни за счет чего (какие-нибудь очень частные сценарии могут и придумать), а вот попытка продавить Rust во все щели за счет нагнетания экоистерии дурно пахнет в смысле реальных качеств языка.

внесите в комитет предложение о том что С++ является самым экологически чистым языком

и растоманы пролетят

Здравствуйте, Nuzhny, Вы писали:

N>Но да ладно. Интересно реально ли и за счёт чего он может оказаться энергоэффективнее C/C++. Кто-нибудь видел данные?

Видимо журналисты немного напутали.

Вот вам статистика серверных ЯП: https://w3techs.com/technologies/overview/programming_language

Как видим, да, до сих пор это ненавидимый вами PHP а так же C# и Java. Как известно — все это довольно тормозное.

То что вы пишите систему на C — это не избавляет от того, что сами сайты то все равно на PHP и C# клепают. Вот вам и потеря 50% ресурсов и памяти.

Видимо кто-то считает, что Rust достаточно высокоуровневый, чтобы на нем удобно было и сайты клепать.

Здравствуйте, kaa.python, Вы писали:

KP>Иначе это ты никак не интерпретируешь, т.к. у Rust тот же LLVM под капотом и Rust по определению не может быть более экономичным с точки зрения потребления энергии чем Clang.

У ржавого есть кой-какие оптимизации, которые могут сработать только если переданный указатель не алиасится с другими.
Но это капля в море, а рантайм-проверки прожирают перфоманс в хлам.

Здравствуйте, Nuzhny, Вы писали:

N>Пресса пишет, что переписав всё на Rust можно сэкономить до 50% энергии датацентров.

С жабоскрипта? Да, сравнивал на примере самодельных авторизаторов в AWS, скорость выполнения вырастает где-то вдвое если на питон переписать, и втрое если на го или раст.
Хотя большая часть времени типовой облачной функции всё равно запросы по сети или к базам, так что даже тормознутость жабоскрипта не так важна.
Рантайм для Rust кстати всё ещё полуофициальный — в списке нет, но он на гитхабе awslabs, так что статья несколько преувеличивает

Здравствуйте, Nuzhny, Вы писали:

N>Но да ладно. Интересно реально ли и за счёт чего он может оказаться энергоэффективнее C/C++.

За счёт того, что плюсЫ всех задолбали. Энергия у программистов кончилась, выгорели они.

N>Кто-нибудь видел данные?

Данные состоят в том, что на Rust переписать можно, а на плюсах — нет, руки устанут.

Здравствуйте, T4r4sB, Вы писали:

TB>У ржавого есть кой-какие оптимизации, которые могут сработать только если переданный указатель не алиасится с другими.
TB>Но это капля в море, а рантайм-проверки прожирают перфоманс в хлам.

Насколько я понимаю, оптимизации идут на двух уровнях: фронтэнд (Clang и Rust соответственно) и бэкенд (LLVM в обоих случаях, так что тут паритет). При этом в оптимизацию фронтэнда C++ вложено просто безумное количество ресурсов, чего сказать про Rust никак нельзя. Если предположить что идея Rust более удачная (почему бы и нет?), мы получим что-то более-менее одного уровня, с конкуренцией за 2-3%, но не какую-то заметную не вооружённым взглядом разницу.

Здравствуйте, kaa.python, Вы писали:

KP>Насколько я понимаю, оптимизации идут на двух уровнях: фронтэнд (Clang и Rust соответственно) и бэкенд (LLVM в обоих случаях, так что тут паритет).

Вот обработать атрибут noalias у параметров-указателей — это явно работа бекенда.
Но вот расставить этот атрибут, не боясь что-то поломать — это работа фронтенда. И Раст это может, а С++ нет. Нельзя в С++ ном коде просто взять и расставить noalias.

KP>При этом в оптимизацию фронтэнда C++ вложено просто безумное количество ресурсов, чего сказать про Rust никак нельзя.

Да я б не сказал, что там есть какая-то реальная разница. Ну шаблоны раскрываются во время компиляции, но это оба могут.
А знаменитые УБшечки — это тоже расстановка флагов для бэкенда.

Реальная проблема Раста это неотрубаемые проверки, в том числе в местах, которые С++ и в голову не придёт проверять, и необходимость непрямых индирекций для связей между объектами (через Rc<RefCell<Vec<Rc<RefCell<Object>>>>> либо через хранение индексов)

Здравствуйте, kaa.python, Вы писали:

KP>Насколько я понимаю, оптимизации идут на двух уровнях: фронтэнд (Clang и Rust соответственно) и бэкенд (LLVM в обоих случаях, так что тут паритет). При этом в оптимизацию фронтэнда C++ вложено просто безумное количество ресурсов, чего сказать про Rust никак нельзя. Если предположить что идея Rust более удачная (почему бы и нет?), мы получим что-то более-менее одного уровня, с конкуренцией за 2-3%, но не какую-то заметную не вооружённым взглядом разницу.

У компилятора Rust тот же LLVM внутри, что и у компилятора C++, и все языконезависимые оптимизации у них одинаковые. При этом, с одной стороны, в C++ вколочено гораздо больше денег, а с другой, код на Rust должен быть более analysable, чем на C++. Но вряд ли практическая разница в реальном коде составит более нескольких процентов.

Здравствуйте, Nuzhny, Вы писали:

N>Пресса пишет, что переписав всё на Rust можно сэкономить до 50% энергии датацентров.

А метановые выбросы из кишечников вовлеченных в процесс программистов прессе подсчитала?

N>Пишут это в контексте C/C++, но пример с энергоэффективность почему-то касается javascript.
N>Но да ладно. Интересно реально ли и за счёт чего он может оказаться энергоэффективнее C/C++. Кто-нибудь видел данные?

Реальный код на JS исполняется, в грубом приближении, раза в два медленнее, чем на C/C++. Код на Rust'е, полагаю, мало чем отличается от кода на C/C++.

Здравствуйте, Pzz, Вы писали:

Pzz>Реальный код на JS исполняется, в грубом приближении, раза в два медленнее, чем на C/C++.

В 6.52 раза.

Pzz> Код на Rust'е, полагаю, мало чем отличается от кода на C/C++.

1.03-1.04, там же.

Здравствуйте, netch80, Вы писали:

Pzz>> Код на Rust'е, полагаю, мало чем отличается от кода на C/C++.

N>1.03-1.04, там же.

Там сплошной ансейф что ли?

Здравствуйте, T4r4sB, Вы писали:

N>>1.03-1.04, там же.
TB>Там сплошной ансейф что ли?

Адепты 15 разных способов инициализации массива в С++ всё никак не могут поверить, что в большом масштабе быстродействие у Rust и С++ почти одинаковое, но вот разработка на Rust удобнее. Как так, 20 лет учили Святой Стандарт, головой об клетчатый пол бились — и всё впустую.

Здравствуйте, Слава, Вы писали:

С>Адепты 15 разных способов инициализации массива в С++ всё никак не могут поверить, что в большом масштабе быстродействие у Rust и С++ почти одинаковое, но вот разработка на Rust удобнее. Как так, 20 лет учили Святой Стандарт, головой об клетчатый пол бились — и всё впустую.

Про удобство разработки согласен.
Про скорость — да гонево, неотрубаемые проверки при индексации массива, при обращении к RefCell итд. Только на ансейфе Раст может вытащить. Ну либо это синтетический тест.

Здравствуйте, netch80, Вы писали:

Pzz>>Реальный код на JS исполняется, в грубом приближении, раза в два медленнее, чем на C/C++.

N>В 6.52 раза.

Когда компилятор Go перевели с C на Go, более-менее 1:1, без изменения внутренней архитектуры, скорость упала в 2 раза. Вот это — какой-то осмысленный тест. Но таких тестов, к сожалению, очень мало.

А с синтетическими тестами та беда, что при желании их можно под любой результат подогнать.

Pzz>> Код на Rust'е, полагаю, мало чем отличается от кода на C/C++.

N>1.03-1.04, там же.

Ну, т.е., где-то в шуме.

Здравствуйте, vsb, Вы писали:

vsb>Я считаю, что это пример экошизы. Из разряда дня земли.

Гораздо хуже.

В Часе Земли смысл есть — привлечь внимание. (Считать, что это способ экономии, всё равно, что считать Ice Bucket Challenge способом охладиться в жару).

А вот в экономии энергии путём переписывания на Rust'е…

Здравствуйте, Shtole, Вы писали:

S>В Часе Земли смысл есть — привлечь внимание. (Считать, что это способ экономии, всё равно, что считать Ice Bucket Challenge способом охладиться в жару).
S>А вот в экономии энергии путём переписывания на Rust'е…

Сейчас вот вообще на JS переписывают, много ль в том смысла?

Здравствуйте, Shtole, Вы писали:

vsb>>Я считаю, что это пример экошизы. Из разряда дня земли.

S>Гораздо хуже.

S>В Часе Земли смысл есть — привлечь внимание. (Считать, что это способ экономии, всё равно, что считать Ice Bucket Challenge способом охладиться в жару).

Проблема Часа Земли в том, что резкое понижение потребления легко может привести к авариям в энергосети. И уж точно приводит к незапланированным затратам (ну может уже и планируют под дурачков). В сети нельзя просто так выключить лампочку. Генератор крутится и энергия выделяется и она должна где-то рассеяться. Потихоньку генератор остановится, но это занимает время, для разных электростанций по-разному.

S>А вот в экономии энергии путём переписывания на Rust'е…

Экономия может и будет. Но она будет слишком мала, чтобы на что-то повлиять. Подавляющее большинство того, что может тормозить, уже давно написано на быстрых языках. А какой код будет ждать прихода очередного TCP-пакета, Rust или Python, процессору без разницы, он в любом случае спит.

Я вот только что написал программку, которая перекачивает гигабайты из одного S3-хранилища в другое. Написал на ноде. Потребление процессора у неё во время работы около 1% (думаю, меньше, просто так показывает). Ибо она тупо перекладывает байты из сокета в сокет, а остальное время ждёт, пока придут новые. Ну перепишу я её на расте. И что, будет она потреблять не 1%, а 0.1%. Какая разница, что там, что там копейки.

Ну и конечно никто в реальности не будет переписывать на расте то, что пишется на языках более высокого уровня, так же, как никто не будет слазить с автомобиля, если не ущемлять, а в программировании вроде ущемлять ещё не научились.

Здравствуйте, T4r4sB, Вы писали:

TB>Про скорость — да гонево, неотрубаемые проверки при индексации массива, при обращении к RefCell итд. Только на ансейфе Раст может вытащить. Ну либо это синтетический тест.

В идиоматичном коде компилятор обычно может убрать все или большинство проверок.

Ну и вообще проверки не такие уж и страшные, когда они никогда не срабатывают. Процессор просто их игнорирует и считает дальше. Если сработают — будет медленно. Пока не срабатывают — вообще пофиг, 1 такт это ничто.

Здравствуйте, vsb, Вы писали:

vsb>Ну и вообще проверки не такие уж и страшные, когда они никогда не срабатывают. Процессор просто их игнорирует и считает дальше. Если сработают — будет медленно. Пока не срабатывают — вообще пофиг, 1 такт это ничто.

Ты хочешь сказать, что предсказать ветвлений позволяет тратить 1 такт при виде инструкции перехода, если по ней ни разу не было перехода во вторую ветку? Я просто не очень в теме, потому и спрашиваю

Здравствуйте, T4r4sB, Вы писали:

vsb>>Ну и вообще проверки не такие уж и страшные, когда они никогда не срабатывают. Процессор просто их игнорирует и считает дальше. Если сработают — будет медленно. Пока не срабатывают — вообще пофиг, 1 такт это ничто.

TB>Ты хочешь сказать, что предсказать ветвлений позволяет тратить 1 такт при виде инструкции перехода, если по ней ни разу не было перехода во вторую ветку? Я просто не очень в теме, потому и спрашиваю

Я могу ошибаться, но моё понимание такое, что компилятор может "подсказать" процессору путь, по которому программа пойдёт с большей вероятностью. И ничего тут предсказывать не придётся. Если предсказание было неверное, то конвеер остановится, откатится и тд, но пока оно верное, всё будет быстро. тут немного написали, в gcc для этого есть макрос __builtin_expect

На самом деле современные процессоры содержат в себе всякие эвристики и скорей всего такие вещи даже без подсказок будут выполнять быстро. AMD там чуть-ли не простейшие нейросети засовывает.

Здравствуйте, vsb, Вы писали:

S>>В Часе Земли смысл есть — привлечь внимание. (Считать, что это способ экономии, всё равно, что считать Ice Bucket Challenge способом охладиться в жару).

vsb>Проблема Часа Земли в том, что резкое понижение потребления легко может привести к авариям в энергосети. И уж точно приводит к незапланированным затратам (ну может уже и планируют под дурачков). В сети нельзя просто так выключить лампочку. Генератор крутится и энергия выделяется и она должна где-то рассеяться. Потихоньку генератор остановится, но это занимает время, для разных электростанций по-разному.

Идея Часа Земли не в том, чтобы снизить ж-ж-ж в трансформаторе, а в том, чтобы повысить ж-ж-ж в Интернете. Хотя если подумать, и с Rust'ом, наверно, та же в точности фигня в данном случае

Здравствуйте, T4r4sB, Вы писали:

TB>Реальная проблема Раста это неотрубаемые проверки, в том числе в местах, которые С++ и в голову не придёт проверять

Например?

Здравствуйте, DarkEld3r, Вы писали:

DE>Здравствуйте, T4r4sB, Вы писали:

TB>>Реальная проблема Раста это неотрубаемые проверки, в том числе в местах, которые С++ и в голову не придёт проверять

DE>Например?

borrow_mut

Здравствуйте, T4r4sB, Вы писали:

TB>borrow_mut

Он тоже убирается оптимизатором в некоторых случаях, когда оптимизатор уверен, что флаг заимствования не задействован:

https://godbolt.org/z/bWs95sx7T

Здравствуйте, T4r4sB, Вы писали:

TB>>>Реальная проблема Раста это неотрубаемые проверки, в том числе в местах, которые С++ и в голову не придёт проверять

DE>>Например?

TB>borrow_mut

RefCell? Если сильно надо, то можно использовать as_ptr — проверок не будет. Тут в теме ещё про массивы проскакивало — на всякий случай, для них есть get_unchecked.

Здравствуйте, DarkEld3r, Вы писали:

DE>Если сильно надо, то можно использовать as_ptr — проверок не будет. Тут в теме ещё про массивы проскакивало — на всякий случай, для них есть get_unchecked.

Зачем использовать unsafe? Тогда весь смысл rust-а теряется. Лучше уж родные проверенные плюсы ))

Здравствуйте, ArtDenis, Вы писали:

AD>Зачем использовать unsafe? Тогда весь смысл rust-а теряется. Лучше уж родные проверенные плюсы ))

Вот приделают к Rust верификатор, и можно будет эти проверки из рантайма в принципе убрать.

В то же время в плюсах тоже есть checked доступ к массивам.

Здравствуйте, vsb, Вы писали:

vsb>Я считаю, что это пример экошизы. Из разряда дня земли.

Оплата электроэнергии — чуть ли не основная статья расходов дата-центров. И это не считая затрат на охлаждение. Поэтому это очень выгодно. А не бросаются всё переписывать видимо потому, что это чревато ошибками, что для дата-центра критично.

Здравствуйте, Слава, Вы писали:

С>Вот приделают к Rust верификатор, и можно будет эти проверки из рантайма в принципе убрать.

Причём тут верификатор, если человек предлагает использовать unsafe? А рантайм-проверки в простых случаях и так убираются оптимизатором.

Здравствуйте, DarkEld3r, Вы писали:

DE>RefCell? Если сильно надо, то можно использовать as_ptr — проверок не будет. Тут в теме ещё про массивы проскакивало — на всякий случай, для них есть get_unchecked.

А, то есть грязь с ансейфом.

Здравствуйте, ArtDenis, Вы писали:

AD>Он тоже убирается оптимизатором в некоторых случаях, когда оптимизатор уверен, что флаг заимствования не задействован:
AD>https://godbolt.org/z/bWs95sx7T

Полагаю, что эти случаи — примерно те, в которых и человек изначально не будет городить RefCell.
Речь идёт о более сложных примерах, когда без RefCell не обойтись

Здравствуйте, ArtDenis, Вы писали:

AD>Причём тут верификатор, если человек предлагает использовать unsafe? А рантайм-проверки в простых случаях и так убираются оптимизатором.

В непростых случаях верификатор позволит либо явно убрать рантайм-проверки, когда оптимизатор сам не справляется, либо написать unsafe, который однако же будет верифицированным и безопасным.

Здравствуйте, T4r4sB, Вы писали:

TB>Речь идёт о более сложных примерах, когда без RefCell не обойтись

Согласен. В сложных случаях RefCell добавляет несколько процессорных инструкций. Но всё равно не понятно почему тут обсуждается именно borrow_mut(), потому что его вызовы в реальных среднестатистических программах происходят на порядки реже, чем обращение к элементу массива по индексу, в особенности, если на расте пишут не в стиле раста ))

Здравствуйте, ArtDenis, Вы писали:

AD>Здравствуйте, T4r4sB, Вы писали:

TB>>Речь идёт о более сложных примерах, когда без RefCell не обойтись

AD>Согласен. В сложных случаях RefCell добавляет несколько процессорных инструкций. Но всё равно не понятно почему тут обсуждается именно borrow_mut(), потому что его вызовы в реальных среднестатистических программах происходят на порядки реже, чем обращение к элементу массива по индексу, в особенности, если на расте пишут не в стиле раста ))

У меня этот borrow_mut блин везде. Потому что Rc<RefCell<>> просто блин везде. Даже вот элементарно прокинуть хоть какой-то контекст в каллбак — всё, пихай Rc<RefCell> потому что любая попытка захватить нормальную ссылку приведёт к невозможности что-то ещё делать с объектом в другом коде.
А местами реально доходит до Rc<RefCell<Vec<Rc<RefCell<usize>>>>>

Здравствуйте, ArtDenis, Вы писали:

AD>В этом как раз и состоит смысл рантайм проверок на наличие гонок в коде. Просто если он используется уж слишком часто, это возможно означает, что что-то пошло не так и надо ещё раз окинуть взглядом архитектуру

Ну сорян, любая попытка сделать хоть какую-то гибкость приводит именно к такому вот

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 Видимо язык пока слишком молодой, чтобы для него успели написать что-то большое и монструозное в плане гуя ))

Здравствуйте, Shmj, Вы писали:

S>И еще вопрос. 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, есть ли примеры?

Есть. Например, вот: https://crates.io/crates/glium

Здравствуйте, ArtDenis, Вы писали:

DE>>Нет, не теряется. Есть смысл минимизировать использование ансейф и заворачивать в безопасные снаружи абстракции, но вообще это нормальная часть языка.

AD>Ну так речь идёт об обычном клиентском коде, а не о библиотечном, как я понял. Действительно стандартная либа раста — сплошной ансейф ради скорости.

Если я правильно понял, то контекст был такой: "как мне убрать _лишние_ проверки" — "вот есть способ" — "фуу, ансейф!". Так вот как иначе-то? Если в "клиентском коде" мы упираемся в такие проверки, то не вижу ничего криминального в том, чтобы использовать ансейф. В идеале, конечно, оставить комментарий зачем оно нужно и обложить тестами.

Здравствуйте, alex_public, Вы писали:

_>Это возможно просто неправильная архитектура. ) А может и нормальная — отсюда не видно. ))) Зависит от задачи. Если у тебя там данные, ссылка на которые захватывается (замыканием) коллбеком, реально постоянно создаются/уничтожаются в памяти, то это правильная архитектура. Если же нет, то вместо Rc<RefCell<>> на самом деле должно было быть &'static mut.

Статик мут? Как вообще это возможно? Глобалки делать мутабельными сложновато. Ну и доступ к этой сущности блокируется на всё потенциальное время жизни калбака.

_>Вообще тут можно легко смотреть по аналогии с C++. Rc<RefCell<>> должно быть в коде в тех местах, где в C++ был бы shared_ptr (которого кстати обычно стараются избегать). И не более того!

Ээээ, нет. В С++ проще сделать юник и много простых указателей на содержимое, потому что ты знаешь хозяина. Доказать это знание борроу-чекеру в общем случае невозможно.

Здравствуйте, Artem Korneev, Вы писали:

AK>А можете пример какой-нибудь привести?
AK>Кода на Rust'е я за последние пару лет успел написать немало, но чтоб мне хоть раз понадобился borrow_mut() я так сходу вообще не припомню. Вот Arc<Mutex<...>> полно, да.

Ну сохранить что-то в каллбаке.
Да или просто движок с полиморфными сущностями. Из-за полиморфности ты не можешь сделать их методы методами самого движка. А так как сущности могут менять друг друга, то общий пул объектов приходится захватывать "по частям", из-за этого пул объектов приходится делать в виде вектор Rc<RefCell<...>>
ПС два года ты писал на работе или для себя? Когда пишешь для себя, то разнообразие ситуаций на порядок выше, чем когда на работе. И когда у тебя не тула типа прочитать-обработать-сохранить, а что-то посложнее, то всё становится весело.

Здравствуйте, DarkEld3r, Вы писали:

DE>А как иначе-то?

А иначе — использовать borrow_mut

DE>Можно разве что использовать более мощную систему типов (зависимые типы) чтобы выразить необходимые условия

И потерять гибкость архитектуры и поиметь бесконечный рефакторинг на каждый чих.

Ага-ага, одной рукой сэкономим копейки, а другой будем строить новые электростанции специально для майнинга (https://www.cnbc.com/2021/07/22/elon-musk-its-possible-to-make-extremely-safe-nuclear-plants.html).
Эко-позёры напоминают обжор, напоказ исполняющих низкокалорийную диету, а ночью совершающих лунатическое паломничество к холодильнику

Здравствуйте, T4r4sB, Вы писали:

TB>А иначе — использовать borrow_mut

Я не понимаю, что ты хочешь сказать. Есть "безопасное" (с проверками) апи, есть ансейф (без проверок), где доказательство корректности ложиться на программиста. Оба варианта тебе не нравятся.

TB>И потерять гибкость архитектуры и поиметь бесконечный рефакторинг на каждый чих.

Не вижу прямой связи, ну да ладно. В любом случае, я как раз и говорил, что этот вариант тоже совсем не идеален.

Здравствуйте, DarkEld3r, Вы писали:

DE>Я не понимаю, что ты хочешь сказать. Есть "безопасное" (с проверками) апи, есть ансейф (без проверок), где доказательство корректности ложиться на программиста. Оба варианта тебе не нравятся.

Если использовать ансейф, то нахрена козе баян?
Кстати знаешь, что бывает, если в ансейфе что-то не то сделаешь и случайно сделаешь две мутабельные ссылки на один объект?

DE>Не вижу прямой связи, ну да ладно. В любом случае, я как раз и говорил, что этот вариант тоже совсем не идеален.

Связь в том, что архитектура на рефцеллах не требует сношаться с временем жизни, поэтому ты можешь безболезненно менять порядок создания объектов

Здравствуйте, Artem Korneev, Вы писали:

AK>Rust это в большей степени системный язык. Но насколько я понимаю, для десктопа уже всё давно есть, просто менее отшлифованное, чем для сетевых сервисов.
AK>Пользоваться, в принципе, уже можно — на гитхабах уже хватает каких-то GUI-велосипедов на Rust'е. Ещё пару лет и будет, наверное, удобно.

Язык — мало. Нужны еще библиотеки и внятная документация с примерами к ним.

А где гарантия, что не появится еще один язык и не победит?

S>>И еще вопрос. Rust компилится в нейтивный язык?

AK>В машинный код. Да.

А много за собой необходимых библиотек тащит для просто чтобы запустилось? Фреймворк или что-то в этом роде нужно?

Здравствуйте, Shmj, Вы писали:

S>А много за собой необходимых библиотек тащит для просто чтобы запустилось? Фреймворк или что-то в этом роде нужно?

Ну я пишу домашний проект, скачал уже довольно жирные либы, типа сериализатор структур в джсоны, короче мегабайта два на релизный екзешник — это норма(
Можно пострипать, будет 500кб, но тогда при падении трассу стека не увидишь. Думаю, тебе будет лучше, если твою юзеры смогут читать трассу и присылать тебе нормальные отчёты.

>Язык — мало. Нужны еще библиотеки и внятная документация с примерами к ним.

Да тут С++ по полной отсасывает.
Вот пример доков, такие есть про каждую официальную либу: https://doc.rust-lang.org/std/result/enum.Result.html#method.ok
А официальные либы это не только СТЛ и биндинги к винапи, там спокойно ищется например такое: https://docs.rs/dxf/0.5.0/dxf/

А чтоб скачать официальную либу, тебе надо просто прописать одну зависимость в файле сборки. Тебе не надо сношаться с поиском репозитория левой либы, врубаться как она собирается, в каком году она написана, как её подогнать под актуальный стандарт и нет ли в ней УБ которые в те времена никого не парили.

Здравствуйте, Shmj, Вы писали:

S>А много за собой необходимых библиотек тащит для просто чтобы запустилось? Фреймворк или что-то в этом роде нужно?

Какие либы подцепишь, такие он и добавит в exe-шник. Если ничего не подцепишь, то там будет только твой код. Поэтому в принципе на нём можно писать для микроконтроллеров, но на мой взгляд пока рано.

Здравствуйте, T4r4sB, Вы писали:

TB>Если использовать ансейф, то нахрена козе баян?

Чтобы решить проблему производительности точечно и спрятать её за безопасной абстракцией. И чтобы видеть какому коду надо уделить особенноe внимание.

То есть, ты всё-таки хочешь чтобы было и безопасно и без лишних проверок и писался код просто? Ну так не бывает.

TB>Кстати знаешь, что бывает, если в ансейфе что-то не то сделаешь и случайно сделаешь две мутабельные ссылки на один объект?

Знаю, UB будет.

Здравствуйте, DarkEld3r, Вы писали:

DE>Знаю, UB будет.

Мой любимый вопрос: а на практике к чему это приведёт? Что такое вообще эти UB и зачем их придумали?

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.

Кстати когда будет возможность компилировать екзешники без необходимость трахаться с левыми линкерами? Чтоб в тулчейне было всё, ну либо он сам скачивал что надо.

Здравствуйте, T4r4sB, Вы писали:

TB>Мой любимый вопрос: а на практике к чему это приведёт? Что такое вообще эти UB и зачем их придумали?

Если хочешь какую-то мысль донести, то говори прямо.

Здравствуйте, Reset, Вы писали:

R>С графикой, как я понимаю, все примерно как в Go, т.е. никак.

Всё там нормально с GUI библиотеками, в отличие от того же Go. Причём речь не о банальных биндингах C/C++ библиотек (которые есть в большинстве других языков), а о новых родных библиотеках. Причём есть и под десктоп и под веб (webassembly) и смешанные. С бэкендом и в виде OpenGL/Vulkan и в виде системных API. Короче есть всё и на любой вкус.

Единственно что, большинство из них ещё в активной разработке, так что при обновление версии иногда ломается код и приходится править (правда всегда в лучшую сторону).

Здравствуйте, Artem Korneev, Вы писали:

AK>Кода на Rust'е я за последние пару лет успел написать немало, но чтоб мне хоть раз понадобился borrow_mut() я так сходу вообще не припомню. Вот Arc<Mutex<...>> полно, да.

Кстати говоря, Arc<Mutex<...>> — это весьма тяжеловесная штука, ныряющая в ядро ОС. Поэтому она должна применяться только в том случае, если у тебя программе реально происходит параллельная модификация одного и того же куска памяти из разных потоков.

Лично я в большинстве задач предпочитаю использовать взаимодействие потоков на базе модели акторов (что идеально ложится на идеологию "владения" C++/Rust), так что подобных конструкций в последних проектах вообще не вижу. Хотя вполне могу представить их полезность в определённых специфических задачах (типа параллельных вычислений на одном огромном массиве данных).

Здравствуйте, DarkEld3r, Вы писали:

DE>Если хочешь какую-то мысль донести, то говори прямо.

Ну что плохого будет в реальной программе, если я сделаю две мутабельные ссылки на один объект, а компилятор про это не догадается?

Здравствуйте, ArtDenis, Вы писали:

S>>И еще вопрос. Rust компилится в нейтивный язык? Без всяких вирт. машин, прослоек и пр.?

AD>Конечно. Раст — это как с++, только без стероидов и без синдрома Бога у пограммиста, потому что компилятор бъёт по пальцам не даёт портить память.

мы просмотрели пример того, как не надо рекламировать язык

тут рядом Reset правильный заход сделал ("у нас есть ~~печ~~пакетный менеджер")

Здравствуйте, night beast, Вы писали:

NB>мы просмотрели пример того, как не надо рекламировать язык

В точку!

Здравствуйте, T4r4sB, Вы писали:

_>>Это возможно просто неправильная архитектура. ) А может и нормальная — отсюда не видно. ))) Зависит от задачи. Если у тебя там данные, ссылка на которые захватывается (замыканием) коллбеком, реально постоянно создаются/уничтожаются в памяти, то это правильная архитектура. Если же нет, то вместо Rc<RefCell<>> на самом деле должно было быть &'static mut.
TB>Статик мут? Как вообще это возможно? Глобалки делать мутабельными сложновато.

О да, ужасно сложновато: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak )))

TB>Ну и доступ к этой сущности блокируется на всё потенциальное время жизни калбака.

Если нужно несколько одновременных &'static mut ссылок, то это будет уже строчка unsafe кода. Но плюс его, в сравнение с предлагаемыми тут решениями в том, что это будет ровно одна маленькая unsafe точка в программе. И кстати она не будет нарушать никаких гарантий, т.к. у тебя и так очевидно не многопоточный код (иначе был бы не Rc<RefCell<>>). Просто компилятор этого не знает (и не может знать), а тут ты с помощью этого unsafe говоришь ему об этом. Собственно RefCell в общем то делает тоже самое, но уже через проверки в рантайме... )))

_>>Вообще тут можно легко смотреть по аналогии с C++. Rc<RefCell<>> должно быть в коде в тех местах, где в C++ был бы shared_ptr (которого кстати обычно стараются избегать). И не более того!
TB>Ээээ, нет. В С++ проще сделать юник и много простых указателей на содержимое, потому что ты знаешь хозяина. Доказать это знание борроу-чекеру в общем случае невозможно.

Вот и не стоит засовывать подсчёт ссылок туда, где его не было в C++. Очевидно же, что это означает что в нём нет потребности, а появляется он только от неумения пользоваться другими возможностями языка.

Здравствуйте, alex_public, Вы писали:

_>Если нужно несколько одновременных &'static mut ссылок, то это будет уже строчка unsafe кода. Но плюс его, в сравнение с предлагаемыми тут решениями в том, что это будет ровно одна маленькая unsafe точка в программе.

А знаешь что будет если ты таким образом случайно зафигачишь две мутабельные ссылки на один объект?

_>Вот и не стоит засовывать подсчёт ссылок туда, где его не было в C++. Очевидно же, что это означает что в нём нет потребности, а появляется он только от неумения пользоваться другими возможностями языка.

Расскажи, как без Rc сделать архитектуру юник+обычные указатели. Поинтеры из Раста не предлагать.
Ссылки раскидывать внутри графа не получится. Значит, нужен слабый указатель. А он живёт только в паре с Rc, вот так вот

Здравствуйте, T4r4sB, Вы писали:

DE>>Я не понимаю, что ты хочешь сказать. Есть "безопасное" (с проверками) апи, есть ансейф (без проверок), где доказательство корректности ложиться на программиста. Оба варианта тебе не нравятся.
TB>Если использовать ансейф, то нахрена козе баян?
TB>Кстати знаешь, что бывает, если в ансейфе что-то не то сделаешь и случайно сделаешь две мутабельные ссылки на один объект?

Ох, такое впечатления, что тут собрались не бывшие C++ программисты, а какие-то JS/Python любители, которые воспринимают слова типа "указатель" и т.п. как некую чёрную магию.

В Rust'е всё работает абсолютно точно так же как и в C++ и применимы все те же самые приёмы работы с указателями, ссылками и т.п.. И это всё будут не какие-то грязные хаки, а нормальное программирование — для этого данный язык и задумывался!

Единственная принципиальная разница заключается в том, что все нормальные объекты в Rust являются перемещаемым (кстати как раз за счёт этого он бывает частенько быстрее C/C++), так что стандартные игры с указателями/ссылками напрямую применимы только к глобальным объектам. Однако и для локальных это легко меняется с помощью данной https://doc.rust-lang.org/std/pin/ функциональности, приводящий и локальные объекты к привычному C/C++ поведению.

Далее, стандартное правило компилятора для ссылок (никаких других при наличие одной мутабельной) следует не из какие-то внутренних особенностей языка, а было придумано для помощи в написание корректного кода в тяжёлых внешних условиях (многопоточное программирование и т.п.). Если в твоём коде другая ситуация, то не факт что будет полезным продолжать соблюдать это правило. Но официального способа сказать об этом компилятору нет. Поэтому в таком случае или используют специальные прокладки (типа refcell — полезна если ты на самом деле не уверен в поведение своего кода и хочешь проверить не выкинет ли оно панику) или unsafe вставки.

Здравствуйте, ArtDenis, Вы писали:

S>>А много за собой необходимых библиотек тащит для просто чтобы запустилось? Фреймворк или что-то в этом роде нужно?
AD>Какие либы подцепишь, такие он и добавит в exe-шник. Если ничего не подцепишь, то там будет только твой код. Поэтому в принципе на нём можно писать для микроконтроллеров, но на мой взгляд пока рано.

Какое рано? ))) Там уже несколько лет как самая движуха идёт. )))

Здравствуйте, alex_public, Вы писали:

AD>>Поэтому в принципе на нём можно писать для микроконтроллеров, но на мой взгляд пока рано.

_>Какое рано? ))) Там уже несколько лет как самая движуха идёт. )))

Писать на расте можно, но код на расте по структуре и идеологии будет похож на код на си. И особо не понятно, зачем в данном случае нужен именно раст. Лично мне в расте пока не хватает некоторых фич, чтобы на него перейти для использования при написании прошивок

Здравствуйте, alex_public, Вы писали:

_>Далее, стандартное правило компилятора для ссылок (никаких других при наличие одной мутабельной) следует не из какие-то внутренних особенностей языка, а было придумано для помощи в написание корректного кода в тяжёлых внешних условиях (многопоточное программирование и т.п.). Если в твоём коде другая ситуация, то не факт что будет полезным продолжать соблюдать это правило.

Две мутабельные ссылки на один объект это УБ.
Знаешь ли ты, что такое УБ?
Ну вот ты и попался, поздравляю.
Это правило необходимо даже для однопоточного кода.
Более того, ты поимеешь проблемы даже если у тебя будут две мутабельные ссылки на один инт.

Здравствуйте, T4r4sB, Вы писали:

TB>Кстати когда будет возможность компилировать екзешники без необходимость трахаться с левыми линкерами? Чтоб в тулчейне было всё, ну либо он сам скачивал что надо.

Там дело не в самом линкере (что очевидно не вопрос), а в наличие доступа к системных библиотекам ОС. Т.е. тот же MinGW или PlatformSDK — это не просто gcc или cl+link, а ещё и жирная пачка статических библиотек, покрывающих весь Windows API.

А так, если говорить о просто линкерах, то давно есть родной LLD, который ещё и эффективнее всех остальных. И для многих других платформ (микроконтроллеров, WebAssembly и т.п.) именно он и используется в Rust. Кстати, LLD обычно лежит и в поставке десктопного тулчейна Rust'а.

Здравствуйте, alex_public, Вы писали:

_>Там дело не в самом линкере (что очевидно не вопрос), а в наличие доступа к системных библиотекам ОС. Т.е. тот же MinGW или PlatformSDK — это не просто gcc или cl+link, а ещё и жирная пачка статических библиотек, покрывающих весь Windows API.

Не понял про винапи. Это же всё в дллках, которые с вендой в комплекте. А библиотеки, которые подключают нужную функцию из нужной дллки, они пишутся на самом языке.

_>А так, если говорить о просто линкерах, то давно есть родной LLD, который ещё и эффективнее всех остальных. И для многих других платформ (микроконтроллеров, WebAssembly и т.п.) именно он и используется в Rust. Кстати, LLD обычно лежит и в поставке десктопного тулчейна Rust'а.

Ну под винду выбор либо ставить полтора гигабайта студии, либо трахаться с гнутым тулчейном.

Здравствуйте, T4r4sB, Вы писали:

TB> ... либо трахаться с гнутым тулчейном.

Это как?

Здравствуйте, ArtDenis, Вы писали:

AD>Это как?

Я уже не помню, и боюсь трогать что-то.
Короче когда я ставил таргет -i686-windows-gnu, то там выплывало сообщение в стиле "найди мне минГВ, мне похер где". И я не помню, что я сделал, чтоб оно заработало, может патхи какие-то прописал, потому что у меня так-то был мингв. И когда оно заработало, то я уже не мог выставить таргет -x64-windows-gnu, потому что мингв видимо не тот.

Здравствуйте, T4r4sB, Вы писали:

TB>Короче когда я ставил таргет -i686-windows-gnu, то там выплывало сообщение в стиле "найди мне минГВ, мне похер где". И я не помню, что я сделал, чтоб оно заработало, может патхи какие-то прописал, потому что у меня так-то был мингв. И когда оно заработало, то я уже не мог выставить таргет -x64-windows-gnu, потому что мингв видимо не тот.

В варианте *-windows-gnu в дистрибутив входит линкер от mingw. Ничего дополнительно ставить не надо. Всё просто работает из коробки. PS: Возможно когда-то давно он туда не входил, не знаю.

Здравствуйте, T4r4sB, Вы писали:

_>>Если нужно несколько одновременных &'static mut ссылок, то это будет уже строчка unsafe кода. Но плюс его, в сравнение с предлагаемыми тут решениями в том, что это будет ровно одна маленькая unsafe точка в программе.
TB>А знаешь что будет если ты таким образом случайно зафигачишь две мутабельные ссылки на один объект?

Ничего не будет. В том смысле что всё будет нормально. Правда за это нормально уже будет должен отвечать программист, а не компилятор.

_>>Вот и не стоит засовывать подсчёт ссылок туда, где его не было в C++. Очевидно же, что это означает что в нём нет потребности, а появляется он только от неумения пользоваться другими возможностями языка.
TB>Расскажи, как без Rc сделать архитектуру юник+обычные указатели. Поинтеры из Раста не предлагать.
TB>Ссылки раскидывать внутри графа не получится. Значит, нужен слабый указатель. А он живёт только в паре с Rc, вот так вот

Я пока по описанию не понял твою задачу (непонятно как у тебя там определяются времена жизни). Но уверен что у тебя наблюдается ровно один из двух случаев:
1. У тебя был некорректный C++ код (на самом деле в нём требовались shared_ptr), а Rust заставит тебя написать его корректно (с Rc).
2. У тебя был правильный C++ код (т.е. в задаче на самом деле не нужен подсчёт ссылок), но ты не смог его корректно перенести в Rust из-за не знания языка.

Какой из вариантов верен можно понять только уже из конкретного кода. Но уверен что один из них верен. )))

Здравствуйте, ArtDenis, Вы писали:

AD>В варианте *-windows-gnu в дистрибутив входит линкер от mingw. Ничего дополнительно ставить не надо. Всё просто работает из коробки. PS: Возможно когда-то давно он туда не входил, не знаю.

Ээээ, ну значит я что-то сломал, потому что у меня оно так просто не запустилось. Возможно, сломал я когда заставил собирать именно х32 екзешник

Здравствуйте, alex_public, Вы писали:

_>Ничего не будет. В том смысле что всё будет нормально. Правда за это нормально уже будет должен отвечать программист, а не компилятор.

Ну вот ты и попался. Знаешь, что такое УБ?)
Я могу на довольно конкретных примерах показать, что этим правилом пренебрегать никогда нельзя, даже если у тебя однопоток. Даже если у тебя только примитивные типы.
Да, в С++ можно, в Расте нельзя. Есть кой-какой нюанс, который я ещё на первой странице рассказал про генерацию кода для бэкенда.
Кстати, насколько далеко от СПб живёшь?

_>1. У тебя был некорректный C++ код (на самом деле в нём требовались shared_ptr), а Rust заставит тебя написать его корректно (с Rc).
_>2. У тебя был правильный C++ код (т.е. в задаче на самом деле не нужен подсчёт ссылок), но ты не смог его корректно перенести в Rust из-за не знания языка.

Ну давай, есть граф, его вершины хранятся в юниках, каждая вершина хранит ссылки на другие вершины в виде сырых указателей. Корректна ли эта архитектура? Нет, ведь если мы вытащим юник вершину и грохнем граф, то в вершине будут висячие ссылки. Корректна ли архитектура, если мы запретим вытаскивать вершины и поклянёмся, что вершина будет удаляться только вместе со всеми ведущими на неё ссылками? Да. Можем ли мы это доказать компилятора Раста? Нет, не может.

Здравствуйте, ArtDenis, Вы писали:

_>>Какое рано? ))) Там уже несколько лет как самая движуха идёт. )))
AD>Писать на расте можно, но код на расте по структуре и идеологии будет похож на код на си. И особо не понятно, зачем в данном случае нужен именно раст. Лично мне в расте пока не хватает некоторых фич, чтобы на него перейти для использования при написании прошивок

Что-то ты куда-то не туда смотрел. Лично мне использование этой https://github.com/stm32-rs/stm32-rs штуки нравится намного больше, чем родная библиотека (https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html), не смотря даже на удобный графический Cube (который кстати всё равно удобно использовать, чтобы накидать схему, но уже без генерации кода). Вот в последнем как раз матёрый C с классами, в то время как в Rust возможно красивое программирование на типах. В C++ оно конечно же тоже возможно, но почему-то все общепринятые библиотеки написаны максимально не так. А в Rust только такие и делают.

Здравствуйте, T4r4sB, Вы писали:

_>>Далее, стандартное правило компилятора для ссылок (никаких других при наличие одной мутабельной) следует не из какие-то внутренних особенностей языка, а было придумано для помощи в написание корректного кода в тяжёлых внешних условиях (многопоточное программирование и т.п.). Если в твоём коде другая ситуация, то не факт что будет полезным продолжать соблюдать это правило.
TB>Две мутабельные ссылки на один объект это УБ.
TB>Знаешь ли ты, что такое УБ?
TB>Ну вот ты и попался, поздравляю.
TB>Это правило необходимо даже для однопоточного кода.
TB>Более того, ты поимеешь проблемы даже если у тебя будут две мутабельные ссылки на один инт.

Ну давай, расскажи о том какие будут проблемы. )))

Здравствуйте, alex_public, Вы писали:

_>Ну давай, расскажи о том какие будут проблемы. )))

Сначала скажи, не хочешь ли ты в СПб переехать? Потому что обычно я этими вопросиками гружу потенциальных растаманов на собесах. Слишком много людей хорошо выучило правило про две мутабельные ссылки, но не понимают, зачем оно, и от каково количества разнообразных граблей оно защищает, причём местами геморрой на обход защиты превышает геморрой на поиск бага в аналоге на С++

Здравствуйте, T4r4sB, Вы писали:

_>>Там дело не в самом линкере (что очевидно не вопрос), а в наличие доступа к системных библиотекам ОС. Т.е. тот же MinGW или PlatformSDK — это не просто gcc или cl+link, а ещё и жирная пачка статических библиотек, покрывающих весь Windows API.
TB>Не понял про винапи. Это же всё в дллках, которые с вендой в комплекте. А библиотеки, которые подключают нужную функцию из нужной дллки, они пишутся на самом языке.

Только в C++ нет пакетного менеджера для таких пакетов с библиотеками-заглушкам под ОС АПИ — подразумевается, что они уже лежат в системных путях. Ну и ты же не забыл, что многие Rust библиотеки внутри зависят от C/C++ библиотек и делают их сборку внутри себя?

_>>А так, если говорить о просто линкерах, то давно есть родной LLD, который ещё и эффективнее всех остальных. И для многих других платформ (микроконтроллеров, WebAssembly и т.п.) именно он и используется в Rust. Кстати, LLD обычно лежит и в поставке десктопного тулчейна Rust'а.
TB>Ну под винду выбор либо ставить полтора гигабайта студии, либо трахаться с гнутым тулчейном.

У меня на рабочем компьютере задолго до Rust'а жили и WindowsSDK (студия сама не нужна вообще то) и MinGW. При переходе на Rust я предпочёл вариант с MinGW и ни разу не пожалел об этом.

Здравствуйте, alex_public, Вы писали:

_>Только в C++ нет пакетного менеджера для таких пакетов с библиотеками-заглушкам под ОС АПИ — подразумевается, что они уже лежат в системных путях. Ну и ты же не забыл, что многие Rust библиотеки внутри зависят от C/C++ библиотек и делают их сборку внутри себя?

Не, я всё равно не понял. Вот я объявил функцию как импортную из системной дллки а каким-то именем. Разве компоновщику что-то нужно знать дополнительно, чтобы скомпилировать екзешник?

Здравствуйте, T4r4sB, Вы писали:

TB>Потому что обычно я этими вопросиками гружу потенциальных растаманов на собесах. Слишком много людей хорошо выучило правило про две мутабельные ссылки, но не понимают, зачем оно, и от каково количества разнообразных граблей оно защищает, причём местами геморрой на обход защиты превышает геморрой на поиск бага в аналоге на С++

Это ты потратил столько слов, чтобы поделиться "тайным знанием" про noalias?..

Здравствуйте, DarkEld3r, Вы писали:

DE>Это ты потратил столько слов, чтобы поделиться "тайным знанием" про noalias?..

Это одно из последствий двух мутабельных ссылок, но не единственное.
Знание, как видишь, действительно тайное, потому что тут не все понимают, что это может быть реальной проблемой в растокоде.

Здравствуйте, T4r4sB, Вы писали:

TB>Это одно из последствий двух мутабельных ссылок, но не единственное.

Ок, а второе? В СПб перебираться не планирую. (:

Здравствуйте, DarkEld3r, Вы писали:

DE>Здравствуйте, T4r4sB, Вы писали:

TB>>Это одно из последствий двух мутабельных ссылок, но не единственное.

DE>Ок, а второе? В СПб перебираться не планирую. (:

Ну кроме смены логики при оптимизации можно чисто в дебажном режиме, когда исполняется в точности то, что написано, из двух изначально валидных ссылок сделать одну висящую.

Здравствуйте, T4r4sB, Вы писали:

_>>Ну давай, расскажи о том какие будут проблемы. )))
TB>Сначала скажи, не хочешь ли ты в СПб переехать?

Вряд ли может возникнуть достаточно существенная причина для подобного. ) А вот просто заехать выпить в Питер я вполне могу иногда. ))) И конечно же всегда могу организовать подобное же в Москве. )))

TB>Потому что обычно я этими вопросиками гружу потенциальных растаманов на собесах. Слишком много людей хорошо выучило правило про две мутабельные ссылки, но не понимают, зачем оно, и от каково количества разнообразных граблей оно защищает, причём местами геморрой на обход защиты превышает геморрой на поиск бага в аналоге на С++

Вообще то любимый тобой refcell именно что плодит множественные мутабельные ссылки (вот прямо тем самым unsafe кодом). И ничего страшного от этого не происходит. Единственная разница в том, что при этом ещё добавлена рантайм проверка на тот факт, что ссылки не используются одновременно и всё. В случае однопоточного кода это элементарно делается просто по построению (например ссылка формируется только при создание колбека).

И да, ты так и не ответил на вопрос, какие такие страшные проблемы возникнут от факта существования двух мутабельных ссылок на одну сущность? )))

Здравствуйте, alex_public, Вы писали:

_>Что-то ты куда-то не туда смотрел. Лично мне использование этой https://github.com/stm32-rs/stm32-rs штуки нравится намного больше, чем родная библиотека (https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html),

И то и другое — это одни и те же яйца, только с разных углов )) Структурно твой код на расте почти не будет отличаться от кода сишника с использованием HAL STM32 )) Т.к. динамическое выделение памяти практически не используется, преимуществ у раста почти нету. А если сравнивать с плюсами и его constexpr, то плюсы лично для меня предпочтительнее. У меня даже делители/множители для синтезатора тактовой частоты считаются в компайл-тайм.

Лично моё мнение, что киллер-фичи раста (крутые макросы, на которых основан в том числе рефлекш, итераторы, async, алгебраические типы, паттерн-матчинг) практически бесполезны при разработке для младших МК и ничего не дают по сравнению с си или плюсами (ну кроме повышения ЧСВ, т.к. ты пишешь ембед на расте ))))

N>Пишут это в контексте C/C++, но пример с энергоэффективность почему-то касается javascript.
Node.JS написано на С++, а раст быстрее чем javascript, а значит быстрее чем С++. Шах и мат сишники.

Здравствуйте, alex_public, Вы писали:

_>Вообще то любимый тобой refcell именно что плодит множественные мутабельные ссылки (вот прямо тем самым unsafe кодом).

Да, но у него есть маааленький нюанс, для него не генерится кой-какой атрибутик в LLVM-IR коде, от которого всё потенциально поедет нафиг, если ты сделаешь подобное не для refcell а для интов.

_>И да, ты так и не ответил на вопрос, какие такие страшные проблемы возникнут от факта существования двух мутабельных ссылок на одну сущность? )))

Ну я хочу ещё тебя помучать) Я на первой странице ещё рассказал про один атрибутик, которые генерит Раст, но не имеет права генерить С++. И про него на этой странице уже вспомнили)

Здравствуйте, T4r4sB, Вы писали:

_>>Только в C++ нет пакетного менеджера для таких пакетов с библиотеками-заглушкам под ОС АПИ — подразумевается, что они уже лежат в системных путях. Ну и ты же не забыл, что многие Rust библиотеки внутри зависят от C/C++ библиотек и делают их сборку внутри себя?
TB>Не, я всё равно не понял. Вот я объявил функцию как импортную из системной дллки а каким-то именем. Разве компоновщику что-то нужно знать дополнительно, чтобы скомпилировать екзешник?

Ты предлагаешь руками их объявлять? ))) Всё же для этого используют специальные библиотеки... В Rust эти библиотеки (-sys) ставят пакетным менеджером. А в C++ они прилетают с тулчейном. )))

Здравствуйте, alex_public, Вы писали:

_>Ты предлагаешь руками их объявлять? )))

А разве не так делается?
Скачиваешь из интернета заголовок, в котором руками объявлены импорты всех функций ВинАПИ, не?

Здравствуйте, ArtDenis, Вы писали:

AD>У меня даже делители/множители для синтезатора тактовой частоты считаются в компайл-тайм.

Интересно, а можно где-то глянуть?

Здравствуйте, Reset, Вы писали:

R>Сейчас идет активная работа по включению возможности писать на Rust модуля ядра Linux. Уже прошло несколько итераций (4 или 5), внесли некоторые изменения в библиотеку Rust и, возможно, компилятор. Раньше в Rust были какие-то ограничения, кажется, в виде поддержки в runtime чего-то, что для ядра неприемлемо и Panic, когда не надо. Сейчас уже многое исправлено, причем в стабильной версии компилятора и библиотек и теперь Rust близок к тому, чтобы на нем можно было писать модули ядра Linux.

Пропал калабуховский дом

Впрочем, буханка не нужна и так

Здравствуйте, Marty, Вы писали:

M>Интересно, а можно где-то глянуть?

https://github.com/art-den/stm32_pll_calculator

Там некоторые параметры указаны по умолчанию, но их тоже можно задавать (MinVcoFreq, MaxVcoFreq и т.п.) полезно при сильном разгоне чипа, если это вдруг понадобилось.

Здравствуйте, ArtDenis, Вы писали:

M>>Интересно, а можно где-то глянуть?

AD>https://github.com/art-den/stm32_pll_calculator

AD>Там некоторые параметры указаны по умолчанию, но их тоже можно задавать (MinVcoFreq, MaxVcoFreq и т.п.) полезно при сильном разгоне чипа, если это вдруг понадобилось.

Спс

Здравствуйте, T4r4sB, Вы писали:

_>>1. У тебя был некорректный C++ код (на самом деле в нём требовались shared_ptr), а Rust заставит тебя написать его корректно (с Rc).
_>>2. У тебя был правильный C++ код (т.е. в задаче на самом деле не нужен подсчёт ссылок), но ты не смог его корректно перенести в Rust из-за не знания языка.
TB>Ну давай, есть граф, его вершины хранятся в юниках, каждая вершина хранит ссылки на другие вершины в виде сырых указателей. Корректна ли эта архитектура? Нет, ведь если мы вытащим юник вершину и грохнем граф, то в вершине будут висячие ссылки. Корректна ли архитектура, если мы запретим вытаскивать вершины и поклянёмся, что вершина будет удаляться только вместе со всеми ведущими на неё ссылками? Да. Можем ли мы это доказать компилятора Раста? Нет, не может.

Сомнительная архитектура что для Rust, что для C++. Я бы для начала попробовал бы так (код на Rust, но на C++ переписывается дословно):

struct Node {
    name: String,
    children: Vec<usize>
}

struct Graph {
    nodes: HashMap<usize, Node>
}

impl Graph {
    fn insert(&mut self, node: Node, parent: Option<usize>) -> usize {
        let id = self.nodes.len();
        self.nodes.insert(id, node);
        parent.map(|p| self.nodes.get_mut(&p)).flatten().map(|p| p.children.push(id));
        id
    }
}

Здравствуйте, ArtDenis, Вы писали:

_>>Что-то ты куда-то не туда смотрел. Лично мне использование этой https://github.com/stm32-rs/stm32-rs штуки нравится намного больше, чем родная библиотека (https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html),
AD>И то и другое — это одни и те же яйца, только с разных углов )) Структурно твой код на расте почти не будет отличаться от кода сишника с использованием HAL STM32 ))

Даже близко не похожи. Ты вообще сам в курсе стандартного кода при использование обеих этих библиотек или нет?

AD>Т.к. динамическое выделение памяти практически не используется, преимуществ у раста почти нету. А если сравнивать с плюсами и его constexpr, то плюсы лично для меня предпочтительнее. У меня даже делители/множители для синтезатора тактовой частоты считаются в компайл-тайм.
AD>Лично моё мнение, что киллер-фичи раста (крутые макросы, на которых основан в том числе рефлекш, итераторы, async, алгебраические типы, паттерн-матчинг) практически бесполезны при разработке для младших МК и ничего не дают по сравнению с си или плюсами (ну кроме повышения ЧСВ, т.к. ты пишешь ембед на расте ))))

Я с тобой полностью согласен, что у Rust тут преимуществ нет (как у языка). Нюанс в том, что для получения красивого (с типами и т.п.) кода на C++ мне надо будет его самому написать. А в случае Rust я его получаю подключением зависимости.

Т.е. преимущество у Rust всё же есть, но не техническое, а так сказать историческое (в нём от рождения начали пытаться решить по красивому, а в C++ в промышленных библиотеках до сих пор не дошли до этого).

Здравствуйте, T4r4sB, Вы писали:

_>>Вообще то любимый тобой refcell именно что плодит множественные мутабельные ссылки (вот прямо тем самым unsafe кодом).
TB>Да, но у него есть маааленький нюанс, для него не генерится кой-какой атрибутик в LLVM-IR коде, от которого всё потенциально поедет нафиг, если ты сделаешь подобное не для refcell а для интов.

С чего бы это он не генерится то? )))

_>>И да, ты так и не ответил на вопрос, какие такие страшные проблемы возникнут от факта существования двух мутабельных ссылок на одну сущность? )))
TB>Ну я хочу ещё тебя помучать) Я на первой странице ещё рассказал про один атрибутик, которые генерит Раст, но не имеет права генерить С++. И про него на этой странице уже вспомнили)

Ты лучше расскажи какие такие ужасы могут возникнуть из-за твоего атрибутика при условие отсутствия одновременной работы с несколькими мутабельными ссылками (но при одновременном существование этих ссылок).

Здравствуйте, T4r4sB, Вы писали:

_>>Ты предлагаешь руками их объявлять? )))
TB>А разве не так делается?
TB>Скачиваешь из интернета заголовок, в котором руками объявлены импорты всех функций ВинАПИ, не?

Ты это сейчас про Rust (в нём вроде нет "заголовков") или про C++ (а тут "заголовков" недостаточно и нужны ещё lib файлы)?

Здравствуйте, alex_public, Вы писали:

_>Даже близко не похожи. Ты вообще сам в курсе стандартного кода при использование обеих этих библиотек или нет?

Ну покажи свой (или чужой) код с использованием stm32-rs. Инициализацию периферии, устройств, которые к ней подключены и т.п.

Здравствуйте, alex_public, Вы писали:

_>Сомнительная архитектура что для Rust, что для C++.

Да нормальная. Ты предлагаешь вместо ссылок индексы. Это лишняя индирекция, а ещё тебе надо протаскивать мутабельную ссылку на граф во все методы вершин. Это надёжнее и легче отлаживать, но и исходный вариант оптимален.

Здравствуйте, alex_public, Вы писали:

_>С чего бы это он не генерится то? )))

С того, что RefCell содержит внутри некую Lang Item. То есть компилятор знает, что именно для определённой структуры из std не надо генерить этот атрибутик.
Если у тебя есть rust на компе, то всегда можешь сгенерить релизный код с --emit=llvm-ir и посмотреть.

_>Ты лучше расскажи какие такие ужасы могут возникнуть из-за твоего атрибутика при условие отсутствия одновременной работы с несколькими мутабельными ссылками (но при одновременном существование этих ссылок).

Как ты думаешь, что делается с кодом при наличии этого атрибутика?

Здравствуйте, alex_public, Вы писали:

_>Ты это сейчас про Rust (в нём вроде нет "заголовков") или про C++ (а тут "заголовков" недостаточно и нужны ещё lib файлы)?

Про оба.
В Расте есть крейт с заголовками, если кому хочется поупарываться с окнами. И стандартная либа наверняка внутри зовёт ВинАПИ, когда компилишь под винду. То есть я опять не понимаю, зачем нужен специальный линкер.

Здравствуйте, ArtDenis, Вы писали:

_>>Даже близко не похожи. Ты вообще сам в курсе стандартного кода при использование обеих этих библиотек или нет?
AD>Ну покажи свой (или чужой) код с использованием stm32-rs. Инициализацию периферии, устройств, которые к ней подключены и т.п.

Ну вот https://habr.com/ru/post/495948/ например.

Здравствуйте, alex_public, Вы писали:

_>Ну вот https://habr.com/ru/post/495948/ например.

Это антипример какой-то

Несколько строк оттуда:

    // за что либа меня мучает тем, что я должен знать регистр управления флэшем - acr?  
    let clocks = rcc.cfgr.freeze(&mut flash.acr); 

    // за что либа меня мучает тем, что я должен знать что регистр тактирования порта GPIOB - это apb2?
    let mut gpiob = dp.GPIOB.split(&mut rcc.apb2);

    // за что либа меня мучает тем, что я должен знать что управление настройками 
    // порта разделено на два регистра и один из них crh (для пинов с 8 по 15)?
    let mut led = gpiob.pb12.into_push_pull_output(&mut gpiob.crh);

Код с использованием HAL будет удачнее хотя бы из-за того, что программист не должен знать тонкости тактирования и устройства регистров перифирии. При всех своих больших недостатках HAL является именно hardware abstraction layer, а не поделкой в стиле "смотри, я могу программировать МК на расте!!!"

Повторюсь: даже если закрыть глаза на эти косяки, то всё равно это те же яйца, только в профиль. Если раст даёт преимущества перед С++ на "большом компе", то для МК пока таких преимуществ не видно

Здравствуйте, T4r4sB, Вы писали:

_>>Сомнительная архитектура что для Rust, что для C++.
TB>Да нормальная.

Ну не знаю как для тебя, а для меня голые (не инкапсулированные в RAII) указатели/ссылки приемлемы только если речь про глобальные объекты. А так, ситуация с потенциально дохлыми ссылками на локальные объекты — это очень не хорошо, даже если и контролируется административно.

TB>Ты предлагаешь вместо ссылок индексы. Это лишняя индирекция, а ещё тебе надо протаскивать мутабельную ссылку на граф во все методы вершин.

Главное что это безопасно. Ну и протягивать ничего не требуется, просто надо весь функциональный код делать в Graph, а не Node. В данной задаче явно лучше функциональный подход, а не ООП (т.е. Node — это просто хранилище данных, а не сложная ООП сущность с внутренними состояниями).

TB>Это надёжнее и легче отлаживать, но и исходный вариант оптимален.

Насчёт оптимальности (речь про быстродействие, как я понимаю?) на самом деле мне так с сходу не всё очевидно. Точнее в C++ коде твой вариант конечно же однозначно быстрее будет. А вот в Rust с учётом всех манипуляций в Rc и RefCell не факт что это будет быстрее механизма доступа по таблице.

Здравствуйте, alex_public, Вы писали:

_>Главное что это безопасно. Ну и протягивать ничего не требуется, просто надо весь функциональный код делать в Graph, а не Node.

Не получится, если Node это полиморфный тип (dyn trait если по-растовски).

_>Насчёт оптимальности (речь про быстродействие, как я понимаю?) на самом деле мне так с сходу не всё очевидно. Точнее в C++ коде твой вариант конечно же однозначно быстрее будет. А вот в Rust с учётом всех манипуляций в Rc и RefCell не факт что это будет быстрее механизма доступа по таблице.

Ну пока что я сделал на Rc<RefCell> потому мне ещё надо в калбаки распихивать ссылки на элементы.
Жаль что в Расте нету связки UniquePtr-WeakPtr. Вообще странно, потому что хотя бы будет сложнее наделать циклических ссылок

Здравствуйте, T4r4sB, Вы писали:

TB>С того, что RefCell содержит внутри некую Lang Item. То есть компилятор знает, что именно для определённой структуры из std не надо генерить этот атрибутик.
TB>Если у тебя есть rust на компе, то всегда можешь сгенерить релизный код с --emit=llvm-ir и посмотреть.

Так ты это всё про UnsafeCell писал? )))

_>>Ты лучше расскажи какие такие ужасы могут возникнуть из-за твоего атрибутика при условие отсутствия одновременной работы с несколькими мутабельными ссылками (но при одновременном существование этих ссылок).
TB>Как ты думаешь, что делается с кодом при наличии этого атрибутика?

Возникает определённая оптимизация. Которая никак не повлияет на ситуацию, в которой нет одновременного использования двух ссылок.

Здравствуйте, T4r4sB, Вы писали:

_>>Ты это сейчас про Rust (в нём вроде нет "заголовков") или про C++ (а тут "заголовков" недостаточно и нужны ещё lib файлы)?
TB>Про оба.
TB>В Расте есть крейт с заголовками, если кому хочется поупарываться с окнами. И стандартная либа наверняка внутри зовёт ВинАПИ, когда компилишь под винду. То есть я опять не понимаю, зачем нужен специальный линкер.

Ну а если ты захочешь использовать C/C++ библиотеку? Что весьма часто внутри Rust библиотек...

Здравствуйте, ArtDenis, Вы писали:

_>>Ну вот https://habr.com/ru/post/495948/ например.
AD>Это антипример какой-то

AD>Несколько строк оттуда:
AD>...
AD>Код с использованием HAL будет удачнее хотя бы из-за того, что программист не должен знать тонкости тактирования и устройства регистров перифирии. При всех своих больших недостатках HAL является именно hardware abstraction layer, а не поделкой в стиле "смотри, я могу программировать МК на расте!!!"

Ну это дело вкуса уже. В любом случае думаю ты не будешь спорить, что приведённый пример просто в разы компактнее и проще, чем портянка генерируемая Кубом.

AD>Повторюсь: даже если закрыть глаза на эти косяки, то всё равно это те же яйца, только в профиль. Если раст даёт преимущества перед С++ на "большом компе", то для МК пока таких преимуществ не видно

Я с этим и не спорил (более того, именно это я и заявлял изначально). Только вот можно увидеть готовые библиотеки (скажем для STM32) на C++, написанные в подобном же современном стиле?

Здравствуйте, T4r4sB, Вы писали:

_>>Главное что это безопасно. Ну и протягивать ничего не требуется, просто надо весь функциональный код делать в Graph, а не Node.
TB>Не получится, если Node это полиморфный тип (dyn trait если по-растовски).

Ну вот этим и плох тут ООП подход.

_>>Насчёт оптимальности (речь про быстродействие, как я понимаю?) на самом деле мне так с сходу не всё очевидно. Точнее в C++ коде твой вариант конечно же однозначно быстрее будет. А вот в Rust с учётом всех манипуляций в Rc и RefCell не факт что это будет быстрее механизма доступа по таблице.
TB>Ну пока что я сделал на Rc<RefCell> потому мне ещё надо в калбаки распихивать ссылки на элементы.

А если сделать по моей схеме, то в колбек можно было бы кидать просто целочисленный индекс, плюс статическую ссылку на глобальный graph.

TB>Жаль что в Расте нету связки UniquePtr-WeakPtr. Вообще странно, потому что хотя бы будет сложнее наделать циклических ссылок

Так Box в отличие от Rc/Arc может быть мутабельным. Так что наличие Weak для него как раз обеспечит нарушение того самого базового правила ссылок.

Здравствуйте, alex_public, Вы писали:

_>Возникает определённая оптимизация. Которая никак не повлияет на ситуацию, в которой нет одновременного использования двух ссылок.

Я могу накидать код на пару строк, в котором повлияет.

Здравствуйте, alex_public, Вы писали:

_>А если сделать по моей схеме, то в колбек можно было бы кидать просто целочисленный индекс, плюс статическую ссылку на глобальный graph.

На глобальный RefCell<Graph> ты хотел сказать? Я же в колбаке ещё и менять данные хочу.

Здравствуйте, alex_public, Вы писали:

_>Ну это дело вкуса уже. В любом случае думаю ты не будешь спорить, что приведённый пример просто в разы компактнее и проще, чем портянка генерируемая Кубом.

Думаю, это дело привычки. Куба нету, чтобы проверить )

_>Я с этим и не спорил (более того, именно это я и заявлял изначально). Только вот можно увидеть готовые библиотеки (скажем для STM32) на C++, написанные в подобном же современном стиле?

С этим проблема. Общей удобной либы нету. Когда-то давно была одна огромная либа монструозная либа на шаблонах, но я её сейчас даже не смог найти. Конкретно сейчас на гитхабе полно таких либ, но я не степени знаю их охвата, удобства и безглючности.

Но на то они и С++-ники, чтобы городить свой велосипед. У меня своя либа практически на всю периферию STM32 + набор шаблонов для разных устройств (экраны, память, радио, точскрины и т.п.), которые параметризуются шаблонами периферии.

Та же инициализация порта GPIOB у меня выглядит как

PB::clock_on();

В целом использование либы выглядит примерно так:

// Объявляем перифирию для подключения к дисплею
using DisplayCSPin    = PA1;
using DisplayResetPin = PA2;
using DisplayDCPin    = PA3;
using DisplayMisoPin  = PA6;
using DisplaySckPin   = PA5;
using DisplayMosiPin  = PA7;
using DispSpi         = Spi1;
using DispDma         = Dma2_Stream2;

...

// далее идут уже другие либы (тоже шаблонные)

// тип подключения к дисплею
using DispSpiConn = mgfxpp::HardSpiDma6WireConnection<
    DisplayResetPin, 
    DisplayCSPin, 
    DisplayDCPin, 
    DispSpi, 
    DispDma
>;

...

// тип дисплея
using Display = mgfxpp::ili9341_display<DispSpiConn, DelayForDisplay>;

// реализация дисплея - 16 бит, частичная отрисовка в буфер по 64 строки
MGFXPP_DISPLAY_PART_BUF_565_IMPL(Display, 64)

...


// тут инициализируем почти всю периферию, которая участвует в подключении кроме SPI. Его отдельно
DispSpiConn::init();

Здравствуйте, T4r4sB, Вы писали:

_>>Возникает определённая оптимизация. Которая никак не повлияет на ситуацию, в которой нет одновременного использования двух ссылок.
TB>Я могу накидать код на пару строк, в котором повлияет.

Был бы благодарен, т.к. очень интересно взглянуть на подобное. )

Здравствуйте, T4r4sB, Вы писали:

_>>А если сделать по моей схеме, то в колбек можно было бы кидать просто целочисленный индекс, плюс статическую ссылку на глобальный graph.
TB>На глобальный RefCell<Graph> ты хотел сказать? Я же в колбаке ещё и менять данные хочу.

Мы же вроде уже обсудили, что в &'static mut нет ничего магического.

AK>При чём здесь Clang? Это же компилятор.
AK>Более экономичным по определению он может быть, например, там, где он избавляется от vtable и, как следствие, от "лишнего" разыменования указателя при вызове метода. Это если сравнивать с плюсами.
Такто никто не заставляет тебя в плюсах делать классы с виртуальными методами.

Здравствуйте, ArtDenis, Вы писали:

AD>Писать на расте можно, но код на расте по структуре и идеологии будет похож на код на си. И особо не понятно, зачем в данном случае нужен именно раст. Лично мне в расте пока не хватает некоторых фич, чтобы на него перейти для использования при написании прошивок

Между тем, нужные фичи становятся более-менее юзабельными: https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html#const-generics-defaults-and-interleaving
Полезно для библиотек, которые работают с экранами с буфером в памяти, а так же всего другого, где нету аллокации в куче, а размер буфера задаётся через константный параметр

Здравствуйте, alex_public, Вы писали:

_>Был бы благодарен, т.к. очень интересно взглянуть на подобное. )

Пишем в одну ссылку, потом читаем из другой. Это не одновременно. Это по очереди. Оптимизатор может решить, что эти события не связаны.

Здравствуйте, alex_public, Вы писали:

_>Мы же вроде уже обсудили, что в &'static mut нет ничего магического.

Засовывать в калбак мутабельную ссылку это отстой. Ну либо в калбак просунуть параметр ссылку на граф, да.

Здравствуйте, ArtDenis, Вы писали:

AD>Между тем, нужные фичи становятся более-менее юзабельными: https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html#const-generics-defaults-and-interleaving
AD>Полезно для библиотек, которые работают с экранами с буфером в памяти, а так же всего другого, где нету аллокации в куче, а размер буфера задаётся через константный параметр

Так константные параметры были уже год как в языке. ) А в этом релизе добавили всего лишь возможность задания дефолтного значения (что конечно же тоже полезно, но не так чтобы принципиально).

А вот встроенный ассемблер (который добавили в этом же релизе) https://doc.rust-lang.org/nightly/rust-by-example/unsafe/asm.html для программирования МК как раз крайне полезен будет.

Здравствуйте, T4r4sB, Вы писали:

_>>Был бы благодарен, т.к. очень интересно взглянуть на подобное. )
TB>Пишем в одну ссылку, потом читаем из другой. Это не одновременно. Это по очереди. Оптимизатор может решить, что эти события не связаны.

Так это у тебя опять же две ссылки в одном коде (кстати я бы тебе тут легко более гарантированный вариант с ошибкой привёл бы, который кстати и в C++ работает). А я уж думал что ты реально что-то неизвестное мне покажешь...

Возвращаясь к твоему исходному вопросу (с колбеками), то две мутабельные ссылки (одна в основном коде и одна переданная в колбек) будут превосходно работать, при условие однопоточности кода.

Здравствуйте, alex_public, Вы писали:

_>Так константные параметры были уже год как в языке. ) А в этом релизе добавили всего лишь возможность задания дефолтного значения (что конечно же тоже полезно, но не так чтобы принципиально).

Ну я и не пишу, что их только сейчас добавили. Они дорабатываются и это уже хорошо. И asm был до этого, правда в виде внешнего крэйта

Хотя опытные Erlang-программисты давно заметили, что их программы для тех же задач получаются более краткими
по сравнению с другими широко используемыми в промышленности языками программирования, эмпирическое исследование
показало, что для изученных телекоммуникационных приложений код на Erlang был на 70—85% короче, чем на C++,
а производительность системы при переписывании кода с C++ на Erlang возросла почти на 100% [143][144].
Для одного из использованных в исследовании проектов разница была объяснена написанием дополнительного C++-кода
в рамках защитного программирования, управления памятью и кода для высокоуровневой коммуникации, то есть возможностями,
которые являются частью языка Erlang и библиотек OTP [144].

Здравствуйте, ononim, Вы писали:

O>Такто никто не заставляет тебя в плюсах делать классы с виртуальными методами.

Тогда из С++ выкидывается большая часть ООП.
В Rust тоже есть виртуальные методы (dyn Trait), но там где возможно, их стараются заменить статическим вызовом. Получается довольно неплохо. И полиморфизм сохраняется, и скорость не страдает. В С++, в общем-то, можно делать почти так же через шаблоны. Но шаблоны в С++ эт не самая простая в использовании фича.

Здравствуйте, alex_public, Вы писали:

_>Так это у тебя опять же две ссылки в одном коде (кстати я бы тебе тут легко более гарантированный вариант с ошибкой привёл бы, который кстати и в C++ работает). А я уж думал что ты реально что-то неизвестное мне покажешь...

Нет, на С++ такое не напороть на ссылках. На С++ нужны хаки с reinterpret_cast для такого.
Потому что С++ не осилил noalias

_>Возвращаясь к твоему исходному вопросу (с колбеками), то две мутабельные ссылки (одна в основном коде и одна переданная в колбек) будут превосходно работать, при условие однопоточности кода.

Не будут, если случайно какая-то функция не будет работать последовательно с ними двумя, не зная об этом.

O>>Такто никто не заставляет тебя в плюсах делать классы с виртуальными методами.
AK>Тогда из С++ выкидывается большая часть ООП.
AK>В Rust тоже есть виртуальные методы (dyn Trait), но там где возможно, их стараются заменить статическим вызовом. Получается довольно неплохо. И полиморфизм сохраняется, и скорость не страдает. В С++, в общем-то, можно делать почти так же через шаблоны. Но шаблоны в С++ эт не самая простая в использовании фича.
Ну да через шаблоны. Виртуальные методы — это динамический полиморфизм, шаблоны — статический.
Но имхо использование раста только ради того чтоб не использовать шаблоны С++, это сродни использовать это, ради того чтоб не стоять в очередях аэропортов

Здравствуйте, T4r4sB, Вы писали:

_>>Так это у тебя опять же две ссылки в одном коде (кстати я бы тебе тут легко более гарантированный вариант с ошибкой привёл бы, который кстати и в C++ работает). А я уж думал что ты реально что-то неизвестное мне покажешь...
TB>Нет, на С++ такое не напороть на ссылках. На С++ нужны хаки с reinterpret_cast для такого.
TB>Потому что С++ не осилил noalias

Так я же вроде ясно написал, что не такой пример, а другой (более гарантированный). Я имел в виду что-то такое:

for c in collection {
    collection.remove(...);
}

Этот код очевидно некорректен и в C++ и в Rust. Но в C++ он без проблем скомпилируется. А в Rust нет. Однако с помощью чёрной магии двух ссылок можно заставить этот код скомпилироваться и в Rust.

Только это конечно же будет явное вредительство. Как по сути и твой вариант с одновременным (не в смысле многопоточности) манипулированием двумя ссылками.

_>>Возвращаясь к твоему исходному вопросу (с колбеками), то две мутабельные ссылки (одна в основном коде и одна переданная в колбек) будут превосходно работать, при условие однопоточности кода.
TB>Не будут, если случайно какая-то функция не будет работать последовательно с ними двумя, не зная об этом.

Ещё раз: код будет работать однозначно и корректно. Просто в данном случае за это должен будет отвечать уже программист, а не компилятор (собственно в этом смысл слова unsafe и есть). Т.е. в данном случае Rust просто превращается (в маленьком участке кода) в C++ (не в смысле наличия прямо этой особенности, а в смысле необходимости ручного контроля определённых процессов в голове).

Здравствуйте, ononim, Вы писали:

O>Но имхо использование раста только ради того чтоб не использовать шаблоны С++

Ну не только ж ради этого. Я это привёл в пример как одну из причин, почему Rust на практике может оказаться чуть быстрее, чем С++. Хотя быстрее ли он на самом деле или нет, я не берусь судить. Для того чтобы это понять, тестировать нужно не на искусственных тестах, а на реальных программах. Т.е. нужно по сути написать одну и ту же программу на двух языках, используя одну и ту же внутреннюю архитектуру. И потом замерить производительность. И я очень сомневаюсь, что кто-то реально делал это на практике с программами сложнее, чем задачки на leetcode. А задачки на leetcode и прочие искусственные тесты, в свою очередь, дают лишь грубо приближённую оценку производительности на отдельных выдранных из общей картины примерах.

Ещё очков в производительности Rust'у может добавить отсутствие исключений в том виде, в котором они есть в C++. Там под капотом в Rust всё равно есть исключения, через них скорее всего и работает panic!(). Но в целом в Rust выбрасывать и ловить исключения не принято. Если там где и будет некое подобие try/catch, то скорее всего на границах потоков и на верхнем уровне всей программы. В плюсах, по-хорошему, тоже не принято злоупотреблять исключениями, а некоторые их и вообще исключают. Но в среднем по больнице их там всяко куда больше, чем в Rust.

А ещё экономия на явных и неявных runtime проверках. В Rust физически невозможно получить неинициализированный указатель, так что проверять на Null его не нужно. А в С++ частенько приходится, причём зачастую по нескольку раз для одного и того же указателя. Ну и ещё какие-то там приятные мелочи есть. В моих глазах Rust это вообще "правильно сделанный С++". Там убрали ООП в том виде, в каком он есть в плюсах, через наследование, но при этом переписали темплейты и макросы к более удобному виду. Убрали многие возможности выстрелить себе в ногу, намного более активно используются проверки на этапе компиляции, и при этом нет ни сборки мусора, ни виртуальных машин, ничего лишнего — на выходе мы получаем обычный бинарник, собранный тем же компилятором clang.

В рамках моего понимания Rust'а, я думаю, что с производительностью у него и в самом деле должно быть всё хорошо. Не сильно хуже, чем у Си и С++. Где-то идёт выигрыш за счёт более широкого применения статического полиморфизма, где-то будет больше накладных расходов из-за дополнительных проверок в рантайме. В общем результате — примерно те же цифры по производительности, но намного более красивая картина в плане стабильности и безопасности, так что в моих глазах Rust определённо в выигрыше.

O>это сродни использовать это, ради того чтоб не стоять в очередях аэропортов

Не загрузилося.

Здравствуйте, alex_public, Вы писали:

_>Ещё раз: код будет работать однозначно и корректно.

Да-да, просто его логика будет меняться в релизе.

_>Просто в данном случае за это должен будет отвечать уже программист, а не компилятор (собственно в этом смысл слова unsafe и есть).

Да-да, просто ЗА ПРЕДЕЛАМИ unsafe ты должен следить за UB. Это делает Раст бессмысленным.

Здравствуйте, T4r4sB, Вы писали:

_>>Ещё раз: код будет работать однозначно и корректно.
TB>Да-да, просто его логика будет меняться в релизе.

У корректного кода ничего меняться не будет, не надо бредить. ) А чтобы писать корректный код, достаточно соблюдать некоторые простейшие правила.

И кстати в твоём конкретном случае эти правила будут выполняться автоматически. Просто потому что колбеки по своему построению отделены от всего остального кода и имеют одну точку подключения внешних данных.

_>>Просто в данном случае за это должен будет отвечать уже программист, а не компилятор (собственно в этом смысл слова unsafe и есть).
TB>Да-да, просто ЗА ПРЕДЕЛАМИ unsafe ты должен следить за UB. Это делает Раст бессмысленным.

Не стоит делать из Rust серебряную пулю, которая решит за тебя все проблемы. Да, это следующая ступень эволюции за C++, но до идеала там всё ещё очень далеко...

Здравствуйте, alex_public, Вы писали:

_>У корректного кода ничего меняться не будет, не надо бредить. )

Если ты в ансейфе сделал манипуляцию, после которой приходится сделать за UB в safe-коде, то код некорректен по определению.

_>Не стоит делать из Rust серебряную пулю, которая решит за тебя все проблемы. Да, это следующая ступень эволюции за C++, но до идеала там всё ещё очень далеко...

Не стоит, но ты нарушил все контракты, получил кучу лишних возможностей выстрелить в ногу, сделал safe-код потенциально опасным для тех, кто случайно внесёт в него не те правки. В pet-проекте можно творить что угодно, но это не значит, что это нормально.

Здравствуйте, T4r4sB, Вы писали:

_>>Не стоит делать из Rust серебряную пулю, которая решит за тебя все проблемы. Да, это следующая ступень эволюции за C++, но до идеала там всё ещё очень далеко...
TB>Не стоит, но ты нарушил все контракты, получил кучу лишних возможностей выстрелить в ногу, сделал safe-код потенциально опасным для тех, кто случайно внесёт в него не те правки. В pet-проекте можно творить что угодно, но это не значит, что это нормально.

Если что, то вся стандартная библиотека Rust'а написана именно в таком стиле. Как раз потому, что её писали спецы по C++, которые не падают в обморок при слове указатель. )))

А плодить кучу бесполезных (при данной архитектуре приложения) рантайм проверок — это совсем не путь Rust'а. Более того, если бы это были только небольшие расходы CPU, то это ещё можно было бы допустить. Но оно же ещё и загромождает исходники, портя код, что совсем не дело. И всё это ради каких-то глупых принципов.

Здравствуйте, alex_public, Вы писали:

_>Если что, то вся стандартная библиотека Rust'а написана именно в таком стиле.

Примерчики можно? Чтоб в ансейфе был код, который несёт потенциальные грабли для безопасных участков.

_>Как раз потому, что её писали спецы по C++, которые не падают в обморок при слове указатель. )))

Ага, понятно, школьный хакер, который вчера выучил С и отказывается переходить на С++ с умными указателями потому что "это надо только ламерам, я сам контролирую память", тоже считает себя спецом.

Здравствуйте, T4r4sB, Вы писали:

_>>Если что, то вся стандартная библиотека Rust'а написана именно в таком стиле.
TB>Примерчики можно?

Там половина кода в unsafe — ты что, не заглядывал в исходники?

TB>Чтоб в ансейфе был код, который несёт потенциальные грабли для безопасных участков.

А это уже твои фантазии, на которые я тебе уже не раз указывал. Вот тебе пример (причём прямо под твою задачку) unsafe кода с организацией двух мутабельных ссылок:

    fn install_callback(&self) {
        unsafe{
            let this = &mut *(self as *const Self as *mut Self);
            set_system_callback(move || this.on_callback());
        }
    }

С удовольствием послушаю что надо написать в окружающем не unsafe коде (ну т.е. по сути в on_callback в данном случае), чтобы вылезли какие-то проблемы в однопоточном коде.

_>>Как раз потому, что её писали спецы по C++, которые не падают в обморок при слове указатель. )))
TB>Ага, понятно, школьный хакер, который вчера выучил С и отказывается переходить на С++ с умными указателями потому что "это надо только ламерам, я сам контролирую память", тоже считает себя спецом.

Ммм, что-то ты в какое-то неконструктивное русло пошёл. Похоже пора заканчивать дискуссию с тобой...

Здравствуйте, alex_public, Вы писали:

_>

_>    fn install_callback(&self) {
_>        unsafe{
_>            let this = &mut *(self as *const Self as *mut Self);
_>            set_system_callback(move || this.on_callback());
_>        }
_>    }
_>

_>С удовольствием послушаю что надо написать в окружающем не unsafe коде (ну т.е. по сути в on_callback в данном случае), чтобы вылезли какие-то проблемы в однопоточном коде.

Я не очень понимаю, какой лайфтайм у этого this получается? Если 'static, то нет гарантий, что ссылку не протухнет.

_>C Ммм, что-то ты в какое-то неконструктивное русло пошёл. Похоже пора заканчивать дискуссию с тобой...

Да не, просто аргумент в стиле "я всё контролирую" вообще тухлый. Можно всё контролировать в небольших участках unsafe кода, но когда этот принцип перетекает и на safe код, то это нездоровая ситуация

Здравствуйте, T4r4sB, Вы писали:

_>>

_>>    fn install_callback(&self) {
_>>        unsafe{
_>>            let this = &mut *(self as *const Self as *mut Self);
_>>            set_system_callback(move || this.on_callback());
_>>        }
_>>    }
_>>

_>>С удовольствием послушаю что надо написать в окружающем не unsafe коде (ну т.е. по сути в on_callback в данном случае), чтобы вылезли какие-то проблемы в однопоточном коде.
TB>Я не очень понимаю, какой лайфтайм у этого this получается? Если 'static, то нет гарантий, что ссылку не протухнет.

Время жизни у this будет очевидно таким же, как и у замыкания, и соответственно будет равно времени существования системного колбека.

Корректность этого кода в смысле висячих ссылок зависит уже от окружающей архитектуры (которая просто не показана тут).

Если self — это глобальный объект (не важно какой природы), то собственно для корректности больше ничего добавлять и не нужно.

Если же есть желания устанавливать системный колбек на сущность, которая может динамически создаваться/уничтожаться во время работы программы, то это тоже можно сделать абсолютно корректно, но тогда уже придётся сделать для Rust несколько пояснений:
— реализовать деструктор для Self и сделать в нём вызов clear_system_callback() — в этой точке будет уничтожаться та вторая ссылка (this).
— возможно (надо смотреть как оно у тебя там хранится) засунуть self в Pin и добавить поле PhantomPinned в Self — чтобы ссылка не испортилась из-за игр Rust'а в перемещения.

Здравствуйте, alex_public, Вы писали:

_>Если же есть желания устанавливать системный колбек на сущность, которая может динамически создаваться/уничтожаться во время работы программы,

Да, я про этот случай.

_> то это тоже можно сделать абсолютно корректно, но тогда уже придётся сделать для Rust несколько пояснений:

Ну то есть придётся добавить и тщательно продумать довольно много unsafe кода. Я бы это не оставлял в основном коде, а вынес бы в отдельную более-менее абстрактную библиотеку, где это всё достаточно компактно прописано

Здравствуйте, T4r4sB, Вы писали:

_>> то это тоже можно сделать абсолютно корректно, но тогда уже придётся сделать для Rust несколько пояснений:
TB>Ну то есть придётся добавить и тщательно продумать довольно много unsafe кода. Я бы это не оставлял в основном коде, а вынес бы в отдельную более-менее абстрактную библиотеку, где это всё достаточно компактно прописано

Возможно, тем более что для реально системных колбеков (в них правда надо будет не замыкание передавать, а по отдельности указатель на функцию и указатель на self) требуется ещё и перехват паники (catch_unwind). Хотя отдельная библиотека возможно всё же перебор, но вот отдельная сущность в проекте — это уж точно. )

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	22.02.22 04:00
Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	22.02.22 04:46
Оценка:	+8

	От:	vsb
	Дата:	22.02.22 05:21
	Оценка:	+7

	От:	kov_serg
	Дата:	22.02.22 05:58
	Оценка:	3 (1) +3 -1

	От:	Michael7
	Дата:	22.02.22 09:59
	Оценка:

От:	reversecode	google
Дата:	22.02.22 10:06
Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	22.02.22 12:58
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	22.02.22 13:34
Оценка:

От:	Basil2	https://starostin.msk.ru
Дата:	22.02.22 20:35
Оценка:

От:	Artem Korneev	https://www.linkedin.com/in/artemkorneev/
Дата:	23.02.22 04:29
Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	23.02.22 17:02
Оценка: