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

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

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

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

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

Хотя опытные 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). Хотя отдельная библиотека возможно всё же перебор, но вот отдельная сущность в проекте — это уж точно. )