Как-то смешались в кучу кони люди. Статья должна быть о параллелизме тогда, а не о многопоточности. Ну и про Arc всего лишь крошечный абзац, а про Send/Sync так и вовсе ничего не рассказали. Про каналы, как способ общения между тредами тоже ноль.
потому что там двойное заимствование окажется. Одно от итератора, второе от потока, судя по всему. Чтобы внутри лямбды работать со значениями, а не со ссылками явным образом обозначаем сигнатуру, а дальше сахаратор языка самостоятельно сделает разыменование до значения. Либо можно сделать это ручками
|x| **x % 2 == 0
Но если функция окажется сложнее и значение x понадобиться несколько раз, то придётся каждый раз разыменовывать.
это SSH2, который работает по протоколу HTTP/3 <..>
Значительно более быстрое установление сеанса
Я не понимаю как оно может быть быстрее если оно в HTTP (который plain text) заворачивает бинарный трафик SSH2? Я б понял если бы речь шла за обычный QUIC+TLS, но у вас оно "И", да ещё и с Http Auth. Также непонятно какой профит от более быстрого установления сессии, если всё остальное не меняется.
За секурити решения тоже вопросы. В репе есть кучка дисклеймеров по теме, но нет в статье.
Речь за AFLPlusPlus или вы прям тот самый старый AFL используете?
Мне интересно, а как вообще происходит прогон фаззинга. Ну, то есть написали тест, а дальше с ним что? Как вы его запускаете, когда останавливаете? По критериям ФСТЭК?
А есть что-нибудь про формальную верифицированные программы, которые были сформированы из пруфов на каком-нибудь Coq/Lean/Idris?
Преимущества перед растом - собственно тесная интеграция с плюсовой же кодовой базой. То есть постепенно переписать проект на это заметно проще ибо оно в итоге все равно в плюсы превратится.
У ржавых про это хотя бы запариваются. Поди найди кулибинов, которые так жаба или шарповые пакеты так проверяли да ещё и собирали их бд и автоматом проверяли их присутствие в проекте.
Тут есть другая крайность - можно попасть под прицел Rust Evangelism Strikeforce и распевать с ними гимны про blazing fast, empowering и fearless concurrency.
"Идиоматичнее", наверное хотели сказать. В общем на производительность такое никак не повлияет и можно жить и с циклами, но чтобы уменьшить цикломатическую сложность - то что доктор прописал. В некоторых ситуациях можно даже параллелизм прикрутить, но вам оно пока вроде не сильно нужно, т.к. bevy под капотом вроде что-то похожее проворачивает.
Подставьте в формулу рассчёта замедления времени массу нейтрона и посчитайте с какой скоростью ему надо двигаться. Ну и про парсеки вы загнули, конечно.
И как именно ускоряется нейтрон до околосветовой скорости
Синтез элементов на условной поверхности чего-то сверхмассивного + импульс от вращения в джете насколько я понимаю. Вопрос конечно, какие там предельные скорости могут быть, но сдаётся мне, что пару десятков процентов скорости света набрать хватит.
for (mut commands) in commands_query.iter_mut() {
if check_in_progress(&commands) {
continue;
}
set_current_command(&mut commands_query);
}
Такие штуки просто замечательно писать через всякие filter / map / for_each, чтобы количество вложенности уменьшать. Код выше превращается во что-то такое.
Тут просто возникает вопрос "а к какому из них кастить?". iter/ iter_mut / into_iter - соотвественно иммутабельная ссылка, мутабельная ссылка, поглощающий итератор - значения контейнера будут перемещены. А если тут какой-нибудь кастомный итератор по странной структуре, то как его кастить если ты забыл какой-нибудь IterMut ему прописать?
А какой профит менять шило на мыло если меняется только человек при той же цене. Взрастить кого-то дофига лояльного врядли выйдет в такой ситуации, если на горизонте ещё плюшек за это не обещают.
Не знаю что там можно разглядеть на первых скриншотах, когда у вас там всё тёмно-красным фильтром залито. Где там передний, где там задний план, какая башня там лазерная. а какая не очень. К игровому полю вопросов нет, разве что попоросить шрифты пожирнее сделать, а то половина пикселей в сабпикселях при сглаживании теряется.
Система приоритетов для башен
С точки зрения игрока задание приоритетов ручками в большинстве случае духота, а не весёлый геймплей. Ещё и окошко под это дело рисовать. Обычно в TD делают специализацию на тип юнитов (какой-нибудь наземный, воздушный, водоплавающий) и приоритет отдаётся всегда ближайшему к башне/ядру юниту.
Как-то смешались в кучу кони люди. Статья должна быть о параллелизме тогда, а не о многопоточности. Ну и про Arc всего лишь крошечный абзац, а про Send/Sync так и вовсе ничего не рассказали. Про каналы, как способ общения между тредами тоже ноль.
потому что там двойное заимствование окажется. Одно от итератора, второе от потока, судя по всему. Чтобы внутри лямбды работать со значениями, а не со ссылками явным образом обозначаем сигнатуру, а дальше сахаратор языка самостоятельно сделает разыменование до значения. Либо можно сделать это ручками
Но если функция окажется сложнее и значение x понадобиться несколько раз, то придётся каждый раз разыменовывать.
Так расту уже 10+ лет, а Саттеровскому cpp2 всего ничего. Если не работать в каком-нибудь Thinkcell, то фронтистов и не сыскать.
Я не понимаю как оно может быть быстрее если оно в HTTP (который plain text) заворачивает бинарный трафик SSH2? Я б понял если бы речь шла за обычный QUIC+TLS, но у вас оно "И", да ещё и с Http Auth. Также непонятно какой профит от более быстрого установления сессии, если всё остальное не меняется.
За секурити решения тоже вопросы. В репе есть кучка дисклеймеров по теме, но нет в статье.
Речь за AFLPlusPlus или вы прям тот самый старый AFL используете?
Мне интересно, а как вообще происходит прогон фаззинга. Ну, то есть написали тест, а дальше с ним что? Как вы его запускаете, когда останавливаете? По критериям ФСТЭК?
А есть что-нибудь про формальную верифицированные программы, которые были сформированы из пруфов на каком-нибудь Coq/Lean/Idris?
Преимущества перед растом - собственно тесная интеграция с плюсовой же кодовой базой. То есть постепенно переписать проект на это заметно проще ибо оно в итоге все равно в плюсы превратится.
Ну и зря.
DoS тоже вполне себе атака.
У ржавых про это хотя бы запариваются. Поди найди кулибинов, которые так жаба или шарповые пакеты так проверяли да ещё и собирали их бд и автоматом проверяли их присутствие в проекте.
Это как-то связано с Пенроузовскими эонами?
Тут есть другая крайность - можно попасть под прицел Rust Evangelism Strikeforce и распевать с ними гимны про blazing fast, empowering и fearless concurrency.
"Идиоматичнее", наверное хотели сказать. В общем на производительность такое никак не повлияет и можно жить и с циклами, но чтобы уменьшить цикломатическую сложность - то что доктор прописал. В некоторых ситуациях можно даже параллелизм прикрутить, но вам оно пока вроде не сильно нужно, т.к. bevy под капотом вроде что-то похожее проворачивает.
Подставьте в формулу рассчёта замедления времени массу нейтрона и посчитайте с какой скоростью ему надо двигаться. Ну и про парсеки вы загнули, конечно.
Синтез элементов на условной поверхности чего-то сверхмассивного + импульс от вращения в джете насколько я понимаю. Вопрос конечно, какие там предельные скорости могут быть, но сдаётся мне, что пару десятков процентов скорости света набрать хватит.
А что это?
Я в курсе. Речь про автоматическую дедукцию, сигнатуры, как комментатор выше спрашивал.
Такие штуки просто замечательно писать через всякие
filter/map/for_each, чтобы количество вложенности уменьшать. Код выше превращается во что-то такое.Тут просто возникает вопрос "а к какому из них кастить?".
iter/iter_mut/into_iter- соотвественно иммутабельная ссылка, мутабельная ссылка, поглощающий итератор - значения контейнера будут перемещены. А если тут какой-нибудь кастомный итератор по странной структуре, то как его кастить если ты забыл какой-нибудьIterMutему прописать?Когда-то Рим захватил половину Ойкумены, где та латынь ныне?
А какой профит менять шило на мыло если меняется только человек при той же цене. Взрастить кого-то дофига лояльного врядли выйдет в такой ситуации, если на горизонте ещё плюшек за это не обещают.
Ну хоть не про ITSCSS уже неплохо.
Не знаю что там можно разглядеть на первых скриншотах, когда у вас там всё тёмно-красным фильтром залито. Где там передний, где там задний план, какая башня там лазерная. а какая не очень. К игровому полю вопросов нет, разве что попоросить шрифты пожирнее сделать, а то половина пикселей в сабпикселях при сглаживании теряется.
С точки зрения игрока задание приоритетов ручками в большинстве случае духота, а не весёлый геймплей. Ещё и окошко под это дело рисовать. Обычно в TD делают специализацию на тип юнитов (какой-нибудь наземный, воздушный, водоплавающий) и приоритет отдаётся всегда ближайшему к башне/ядру юниту.