|
| 1.6, Аноним (6), 00:30, 23/01/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Чё там какие-нибудь подвижки по асинхронным генераторам? Сабж даже питон неспособен заменить из-за этого. Релизы ради релизов тоже странная практика, в прошлый раз пришлось 10 раз подряд скомпилировать тулчейн раста и буквально ничего полезного не добавили.
| | |
| |
| 2.24, Карлос Сношайтилис (ok), 03:02, 23/01/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Чё там какие-нибудь подвижки по асинхронным генераторам?
Нет, хватает того что есть
> в прошлый раз пришлось 10 раз подряд скомпилировать тулчейн раста
"Я три дня гналась за вами, чтобы сказать как вы мне безразличны!"
> и буквально ничего полезного не добавили
Для этого достаточно прочитать анонс. Буквально пара минут
| | |
| 2.27, Аноним (27), 03:38, 23/01/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>Чё там какие-нибудь подвижки по асинхронным генераторам?
А что это такое?
| | |
| 2.30, morphe (?), 04:08, 23/01/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Чё там какие-нибудь подвижки по асинхронным генераторам? Сабж даже питон неспособен заменить из-за этого.
У тебя X-Y проблема, сначала скажи зачем они тебе нужны, и какие проблемы нельзя решить уже сейчас
У асинхронных генераторов есть сложности с правильным дизайном, в Rust подобные вещи не делают хуяк-хуяк, если бы делалось так - то Future так и требовали бы аллокации. Если есть желание решить вопросы с ними - то вперёд в RFC/issues, а пока есть https://docs.rs/async-gen/latest/async_gen/index.html который ничуть не костыль, а библиотечная реализация того же самого функционала, которая немногим хуже того что будет в самом Rust.
| | |
|
| |
| 2.17, пох. (?), 02:11, 23/01/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Слава Рептилоидам, господам нашим!
Будущее, правда, ну очень отдаленное. Сколько там этот как его дырку от бублика переписькивают-переписькивают - а "паритет" все еще где-то за горизонтом планирования.
Ну ничего, зато щас программ для ebpf понапишут просто гору!
| | |
|
| 1.13, Аноним (13), 01:07, 23/01/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>asm!(
если это асм то о какой безопасной работе с памятью речь? а если там работа с памятью безопасная тогда какой это к чёрту асм...
| | |
| 1.14, Аноним (14), 01:14, 23/01/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Что почитать по теме управления памятью? Типа как устроена память в java, регионы и так далее, не про статические проверик, при этом не на уровне hello world
| | |
| 1.20, Аноним (20), 02:33, 23/01/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Методы работы с памятью в Rust избавляют разработчика от ошибок при манипулировании указателями и защищают от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей,
Это разве соответствует реальности? С указателями нету проблем, поскольку нету безопасных указателей. Есть ссылки и подсчет ссылок, но и обычный сборщик мусора тоже защищает от этих проблем.
> выход за границы буфера и т.п.
А как выход за границы защищен? Всегда таскают размер в ссылке, всегда делают проверку индекса, и если что не так, то паника?
| | |
| |
| 2.22, Карлос Сношайтилис (ok), 02:58, 23/01/2026 [^] [^^] [^^^] [ответить]
| +/– |
> обычный сборщик мусора тоже защищает от этих проблем
А ещё он мусор собирает.
И пусть весь мир подождёт
> Всегда таскают размер в ссылке...?
Периодически.
Или в объекте.
И плюс кучка мелких оптимизаций
> и если что не так, то паника?
Сначала хотели сделать как в сях - при выходе за границы, делать вид, что ничего не происходит и работать дальше. Но потом передумали.
Согласен, скучно.
| | |
| 2.28, Аноним (27), 03:44, 23/01/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>Есть ссылки и подсчет ссылок, но и обычный сборщик мусора тоже защищает от этих проблем
Есть системные языки для которых сборщик мусора не нужен, принципиально.
| | |
|
| 1.23, Аноним (23), 03:02, 23/01/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>В Rex-программах допускается использование подмножества языка Rust, предоставляющего гарантии безопасности.
unwrap допускается?
>легковесный Runtime
Прямо даже легче С?
| | |
| |
| 2.29, morphe (?), 04:04, 23/01/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Прямо даже легче С?
Учитывая что у C есть только BPF со стрёмным верификатором и JIT - да
| | |
|
|