Профиль: Аноним (вход | регистрация) неRU opennet.me  
OpenNET

[ новости /+++ | форум | теги |    ]

NVIDIA представила CUDA Rust для разработки GPU-ядер на языке Rust

17.09.2026 11:39 (MSK)

Компания NVIDIA объявила о развитии инструментария CUDA Rust, позволяющего использовать язык Rust для разработки ядер, выполняемых на стороне GPU. Инструментарий обеспечивает безопасность работы с памятью на этапе компиляции и предотвращает возникновение состояний гонки. В следующем году CUDA Rust планируют довести до уровня, пригодного для разработки рабочих проектов, аналогичного инструментариям CUDA C++ и CUDA Python.

Инструментарий CUDA Rust поддерживает две модели разработки параллельно исполняемых ядер - SIMT (Single Instruction, Multiple Threads) и Tale. Модель SIMT позволяет на низком уровне определять логику одного потока, запускать тысячи таких потоков и управлять ими. Модель Tile предлагает более высокий уровень абстракции, в котором вместо явного управления отдельными потоками определяются алгоритмы действия с блоками данных (tile), а все манипуляции с потоками, синхронизацию доступа, управление памятью и распределение данных по тензорным ядрам берёт на себя компилятор Tile IR.

Для разработки на языке Rust с использованием модели SIMT развивается компилятор cuda-oxide, позволяющий компилировать код на языке Rust, использующий штатную систему типов и модель владения Rust, напрямую в инструкции для выполнения в виртуальной машине CUDA PTX (Parallel Thread Execution). Ядра для GPU создаются на обычном Rust, но выполняются в окружении no_std и могут использовать только функции из библиотеки libcore и специализированные Rust-абстракции, без доступа к стандартной библиотеке Rust (libstd).

В CUDA-ядрах на Rust допускается применение защиты через систему типов (safe), использование блоков unsafe и обращение к низкоуровневым аппаратным инструкциям. Для обеспечения безопасности предлагается тип DisjointSlice, гарантирующий, что каждый поток получает эксклюзивный доступ только к своим данным. Код cuda-oxide распространяется под лицензией Apache 2.0.

Для применения модели Tail предлагается библиотека cutile-rs, позволяющая использовать идеоматический язык Rust для создания кода, компилируемого напрямую в CUDA-ядра. Cutile-rs применяет предлагаемые в Rust строгие правила владения и заимствования к коду, выполняемому на GPU. Ядро оформляется как однопоточная программа, работающая с блоком данных, а компилятор сам разбивает вычисления на потоки и обеспечивает их синхронизацию. Потокам предоставляется совместный доступ к неизменяемым тензорам, а для безопасного доступа к изменяемым тензорам применяется их разделение на непересекающиеся блоки. Код cutile-rs распространяется под лицензией Apache 2.0.

  1. Главная ссылка к новости (https://developer.nvidia.com/b...)
  2. OpenNews: Выпуск ZLUDA 6, универсальной открытой реализации технологии CUDA
  3. OpenNews: NVIDIA опубликовала CUDA-oxide, компилятор из Rust в CUDA
  4. OpenNews: Проект LibreCUDA для запуска кода CUDA на GPU NVIDIA без проприетарного Runtime
  5. OpenNews: NVIDIA препятствует разработке транслирующих прослоек для запуска CUDA на других платформах
  6. OpenNews: AMD развивает основанный на LLVM универсальный компилятор C++ и CUDA для CPU/GPU
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/66295-nvidia
Ключевые слова: nvidia, cuda, rust
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (81) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:52, 17/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    И ты, Брут.
     
     
  • 2.14, Аноним (14), 12:26, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Корпы пропихивают, им это выгоДНО...
     
     
  • 3.23, лул (?), 12:43, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Удивительно, почему эти негодяи хотят меньше проблем, вместо постоянных CVE...
     
     
  • 4.29, Аноним (29), 12:52, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Странно, но в раст-утилзах всё наоборот получилось.
     
     
  • 5.36, Аноним (36), 13:12, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Потому что язык принесли.
    А уметь программировать не принесли.

    Одни pronounce engineers и прочие сотнегендерные

     
  • 5.61, Бжежко (ok), 17:02, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В раст программах больше CVE чем в сишках? Это какое-то отрицание реальности, на уровне религиозности.
     
  • 4.31, aname (ok), 12:58, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Чтоб зашить возможность делать те же руты на телефонах, например.

    Очень полезная корпоратам вещь

     
  • 3.49, Аноним10084 и 1008465039 (?), 15:52, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    скорее смешно, как на Опеннете раньше отторгали блистательный Rust с криком "да никто на этом не пишет, ни одна крупная компания в это не ввяжется". Сейчас же, когда это очевидно не так, сменили пластинку, теперь наоборот "да его только корпорации и пропихивают, надо писать на народном, не крупном".
     

  • 1.2, Аноним (2), 11:52, 17/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну вот, теперь и у видеокарт память будет исчезать в неизвестном направлении. Да и блокировки непонятные им на пользу пойдут.
     
     
  • 2.4, Аноним (4), 11:58, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Только если полной утечкой видеопамяти в никуда, механизм сброса видеопамяти в оперативную они уже очень много лет в своём блобе реализовать не могут (и вряд-ли соберутся).
     
  • 2.5, Алексей (??), 11:59, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Добрый, а можете, пожалуйста, прислать пояснительную бригаду? В чем конкретно Вы видите проблемы в Rust, как так память теряется?
     

  • 1.9, Аноним (9), 12:13, 17/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Зловреды на расте пишутся только в путь - из-за того, что в "ассемблере каша", это я цитирую. Дизассемблирование неосуществимо.
     
     
  • 2.12, Аноним10084 и 1008465039 (?), 12:18, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Дизассемблирование всегда осуществимо, это просто показ ассемблерных команд для бинарного кода. А что касается "каши" - она и в любых других языках каша, особенно с оптимизациями. Просто сияющий Rust ещё относительно молод, и реверсеры ещё к нему не помучились. По старым языкам просто уже компиляторы популярные все знают как облупленные, как они код генерируют

    Да и не дизассемблированием единым код исследуют

     
     
  • 3.15, Аноним (15), 12:29, 17/09/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 3.27, Аноним (27), 12:51, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > относительно молод

    А молод - это до скольких лет, до 40 или до 50?

     
     
  • 4.35, Аноним10084 и 1008465039 (?), 13:08, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут молодость/зрелость скорее не в конкретных годах будет исчисляться, а в объеме кода, который пишется и реверсится. Если язык малопопулярный, то будь ему хоть 30 лет, под него не будет заточки. Хотя у старых непопулярных языков редко сильно продвинутые оптимизирующие компиляторы.

    В общем, отвечая на вопрос - когда напишут и отреверсят достаточно много кода, чтобы наработать инструменты реверсинга для великолепного Rust

     
  • 3.46, опеншлёпивпродакшн (?), 15:28, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Rust - результат всех наших прошлых страданий. В этом смысле он зрелый и своевременный.
     
     
  • 4.48, Аноним (48), 15:50, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "наших" это про тех, кто неосилил си?
     
     
  • 5.62, Бжежко (ok), 17:06, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Никто не осилил Си, программисты топового уровня не могут писать на нем без ошибок. Собственно такими программистами и создавался раст.
     
     
  • 6.76, Аноним (76), 18:09, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ошибки были, есть и всегда будут. Нельзя писать абсолютно без ошибок и это не проблема языка.
     
     
  • 7.84, Бжежко (ok), 18:36, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Нет смысла спорить, проблема это языка или проблема программистов, если на выходе все равно нерабочий код с UB. Раст всего лишь инструмент, позволяющий как минимум снизить количество ошибок с памятью, а если не выходить из safe подмножеста то вообще исключить их. Откуда столько хейта и истерики, как-будто кто-то заставляет писать программы на расте. Продолжайте писать на Си, если вам нравится, никто же не запрещает.
     
  • 3.73, Смузихеб забывший пароль (?), 17:50, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Он ведь вроде через LLVM идёт
    Т.е это м.б отреверсить лишь до многоэтапно-оптимизированного IR( или как он там называется )
    Ну а далее - до чего угодно, что преобразуется в IR( хоть сишка хоть раст ). Но это скорее будет не реверс, а просто генерация исходного кода на выбранном ЯП на основе промежуточного представления.

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

     
     
  • 4.75, Аноним10084 и 1008465039 (?), 18:03, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Генерация исходника по байткоду или машинному коду редко бывает идеальной для сколько-нибудь сложной программы. Она худо бедно может быть близка к идеалу в Java, особенно если поленились включать обфускатор. Но такова уж JVM,. много инфы сохраняет. Из нативного же кода, особенно при подрубленных оптимизациях, очень навряд ли. Максимум верхнеуровневая структура

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

     

  • 1.10, Аноним10084 и 1008465039 (?), 12:13, 17/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Даже великолепная nVIDIA добавляет поддержку блистательного Rust. Тем не менее, ещё находятся на Опеннете критики, что мол никто серьезный не использует сияющий Rust, и что мол надо просто умело писать на Си. А меж тем идея безопасной памяти живёт, и за нее реально голосуют долларом корпорации
     
     
  • 2.18, Аноним (18), 12:36, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    голосуют за содержимое блоков unsafe
     
     
  • 3.34, Аноним10084 и 1008465039 (?), 13:03, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Раньше был один сплошной unsafe, и это никого не волновало. Теперь же дали возможность писать safe, так все кричат "а как же unsafe блоки?!!11". При том, что unsafe даже не все гарантии отключает, а лишь ограниченный их список
     
     
  • 4.77, SanityEclipse (ok), 18:10, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Unsafe ничего не отключает, а дает доступ к четко прописанному списку:

    The only things that are different in Unsafe Rust are that you can:
        Dereference raw pointers
        Call unsafe functions (including C functions, compiler intrinsics, and the raw allocator)
        Implement unsafe traits
        Access or modify mutable statics
        Access fields of unions

     
  • 2.19, Аноним (-), 12:37, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Корпорации тоже гонятся за хайпом. В них тожу живые люди работают. Или ты наивно полагаешь, что с Растом у них увеличистя капитализация и продажи? В соседней ветке обсуждают Жабу. Ты видимо опоздал родится и не застал времена хайпы Жабы. И где сейчас эта Жаба?
     
     
  • 3.32, Аноним10084 и 1008465039 (?), 12:59, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Остаточный хайп Джавы я помню - и что же, Джава оставила огромное наследие, инфраструктуру JVM, на ней написано тонна кода, она заработала много денег самым разным людям. Чем не успех? Разве я говорю, что сияющий Rust будет вечен? Когда-то и его чем-то заменят
     
  • 3.42, eugener (ok), 14:41, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И где сейчас эта Жаба?

    да везде практически.

     
  • 3.80, Аноним324 (ok), 18:25, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > И где сейчас эта Жаба?

    Буквально везде.

     
  • 2.24, Sm0ke85 (ok), 12:43, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >идея безопасной памяти живёт,

    она "живет" только в голове у леммингов

    >и за нее реально голосуют долларом корпорации

    не за нее голосуют, совсем не за нее...


    ЗЫ ищи где прибыль может быть и буратиной не помрешь может быть, ахахахах

     
  • 2.25, Ivan_S (?), 12:44, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Производитель железа от этого имеет финансовую выгоду в виде продажи своей продукции. Сей "чудесный" язык память и дисковое пространство кушает лопатами. Им такой Си со своими миниатюрными бинарниками, простой системой сборки не даёт заработать столько, сколько хочется. Вот и всё. Никакой магии, никакой безопасности в работе с памятью итд. Бизнес. Лишь бизнес. Мани
     
     
  • 3.33, Аноним10084 и 1008465039 (?), 13:02, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я думаю, что жор памяти многославным Rust сильно преувеличен. На Си или голом ассемблере вообще можно сделать бинарь, конечно, сильно мельче. Но стоит ли оно того, если так легко накосячить с памятью?
     
     
  • 4.39, Аноним (36), 13:19, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну посмотри сколько растовых лефтпадов приезжаетна диск с этой новой кудой, которая даже не в паритете по фичам

    и сколько на сях/питонах

     
     
  • 5.56, Аноним10084 и 1008465039 (?), 16:15, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А причем тут лефтпад? Грех лефтпада был не в том, что он тяжёлый, а в том что тривиальную функцию все бесконтрольно вынесли в библиотеку и вообще все бездумно используют абы чьи библиотеки, что открывает огромные возможности атак на цепочки поставки. Это дурное поветрие, к сожалению, не обошло стороной коммьюнити пышноблещущего Rust, но по крайней мере ты сам можешь принять решение, какие либы и сколько тащить?
     
  • 4.47, Аноним (47), 15:30, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У меня программа на 20мб для компиляции тянет зависимости на 5гб.
     
     
  • 5.54, Аноним10084 и 1008465039 (?), 16:13, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Так не тяни столько зависимостей, причем здесь сверкающий Rust? Это и на C++ можно притащить библиотек, что он будет весить гигабайты, качать полИнтернета для сборки и тормозить из-за Тьюринг-полных шаблонов
     
  • 5.63, Бжежко (ok), 17:18, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Не используй зависимости, пиши всё сам, компактно будет.
     
  • 5.79, Смузихеб забывший пароль (?), 18:21, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    это ты образ линя не собирал той же йоктой
    образ 40-60Мб - собирается сутки, тянет зависимостей и генерит промежуточных файлов на 40-60 Гб
     
  • 4.105, Ivan_S (?), 01:22, 18/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Тут можно не думать. Это факт. Он просто ест память.
     
  • 2.44, Сладкая булочка (?), 14:59, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Даже великолепная nVIDIA добавляет поддержку блистательного Rust.

    Почему нвидия "великолепная"?
    Почему раст "блистательный"?
    Ну и самое главное, вы под куду что-то пишите/писали? Какая разница от добавления вам?

     
     
  • 3.51, Аноним10084 и 1008465039 (?), 16:01, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Какая разница от добавления вам?

    Мне греет душу, что небезопасные языки заменяются более безопасными. Ещё в 2000-х в своих книгах Брюс Шнайер писал, что обилие переполнений буффера и прочих подобных проблем - позор индустрии, и во многом он вызван использованием ручного контроля памяти. Но в 2000-х из этого не было элегантного выхода - из крупных языков с автоматическим управлением памяти была только Java со своим специфическим набором проблем (медленнее натива, слабо управляемый GC). Java, конечно, эволюционировала и продолжает жить. Но в целом было разделение: или пишешь на относительно низкоуровневых Си/C++ ради скорости или низкоуровневых фишек и уповаешь не накосячить с UB, либо пишешь на тяжеловесной Java.

    Но появление лучезарного Rust совершило прорыв - появился язык, который может одновременно и быть низкоуровневым, и при этом дать zero-cost гарантии памяти. И потому я не могу не радоваться, наблюдая его развитие

    P.S. да, я знаю, что ошибки идут не только из-за памяти и что в Java тоже умели делать RCE, однако так или иначе - чем меньше программисту нужно заниматься мелким bookkeeping'ом, тем более концентрации на логической корректности

     
     
  • 4.60, Malinovsky (?), 16:55, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, библиотеки на расте можно и в джавовский байт код запихать, но вот этот щенячий восторг выглядит странно. Библиотеки годятся - меньше парить мозг. А вайб кодинг скоро и так убьет программирование. Так что высокоуровневые языки это как раз норма, а подобные неудобные языки применительны только в форме библиотек. Тратить излишне много усилий на освоение "безопасных" методов бессмысленно когда нужны все методы. Проще сразу переходить на джавовский байт код. Он уже давно работает.
     
     
  • 5.64, Бжежко (ok), 17:20, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Проще сразу переходить на джавовский байт код. Он уже давно работает.

    Переходи, тебе кто-то мешает это сделать?

     
  • 5.71, Аноним10084 и 1008465039 (?), 17:46, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Так а смысл компилировать блистательный Rust в Java-байткод? Для интеропа с JVM-системами что ли? А так сам по себе сияющий Rust в нативный код компилируется, при этом со своими гарантиями
     
     
  • 6.81, Malinovsky (?), 18:26, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что? Я думал я понятно написал. Библиотеки Scala могут бить написаны на C, C++ и Rust запросто. Язык настраиваемый. Scala Native тоже как проект есть для ускорения. Тут все зависит от способности освоить высокий язык программирования. Многие думают высокоуровневый язык это просто, а на деле страниц так 700 например нужно прочитать, чтобы просто начать, помимо практических примеров конечно же. Маленькие кирпичики тоже неплохо иметь, но на мой взгляд лютая жесть со сложными инструментами слишком часто уделывает низкоуровневые языки программирования. Из-за кривой организации мультипоточности они такой ужас выдают на деле, из-за чего и приходится заморачиваться с разными аппаратными конфигурациями для игр. Слишком много неосиляторов моделей конкурентного подхода. Просто ради интереса сравните. А в Java можно хоть ассемблерные вставки пихать. Многие Java программисты, которые не догоняют как работает процессор часто по граблям прыгают. Было как-то видео про ассемблер на конференции несколько лет назад на английском. Можете поискать. Просто ненужно так выслуживаться. Это убивает критический взгляд и не может считаться здоровым подходом. Не знаешь в итоге как это немного снизить по градусу, ведь мозги в восхвалении не то чтобы участвуют.
     
     
  • 7.89, Аноним10084 и 1008465039 (?), 18:48, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Я думал я понятно написал.

    Честно говоря, нет, мне довольно сложно вас понимать, вы пишете довольно сумбурно

    Я даже не могу понять, что вас конкретно смущает в блистательном Rust, потому что вы как-то всё к не то Java, не то Scala свели. И каким-то рассуждениям про 700 страниц.

    >  А в Java можно хоть ассемблерные вставки пихать

    Это что за новость такая? Писал на Java давно, во времена седьмой, но отродясь такого не помню. Java ж write once run everywhere. Или вы ассемблер JVM имеете в виду? Ну это очень специфическая опция какая-то

    > Просто ненужно так выслуживаться.

    Не знаю где вы это в моих сообщениях прочитали

     
  • 4.87, Сладкая булочка (?), 18:43, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >> Какая разница от добавления вам?
    > Мне греет душу, что небезопасные языки заменяются более безопасными. Ещё в 2000-х
    > в своих книгах Брюс Шнайер писал, что обилие переполнений буффера и
    > прочих подобных проблем - позор индустрии, и во многом он вызван
    > использованием ручного контроля памяти.

    С того времени кучу всего поменялось, как в самих яп (тот же современный с++), так и в инструментарии.

     
  • 4.88, Сладкая булочка (?), 18:45, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >> Какая разница от добавления вам?
    > Но появление лучезарного Rust совершило прорыв - появился язык, который может одновременно и быть низкоуровневым, и при этом дать zero-cost гарантии памяти.

    Они есть и в с++. Плюс в расте они не такие уж и zero-cost, например, та же проверка на границы ни разу не такая.

     
     
  • 5.91, Аноним10084 и 1008465039 (?), 18:53, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    В теории - да. На практике в C++ эти инструменты во-первых лишь опция, можно писать по-старому в Сишном стиле и ловить переполнения и прочее. Во-вторых, насколько мне известно, даже в описании этих абстракций в C++ имеются различные UB, да и в целом там есть UB. А моя позиция по UB максимально жесткая - его должно быть минимально. Если компилятор не может гарантировать defined behavior - он должен запретить этот код и выдать ошибку компиляции. В крайнем случае - заставлять программиста явно указывать, что проверку нужно отключить, чтобы в коде явно было видно, где тонкое место

    Ну и плюс в блистательном Rust есть и некоторые другие концепции, не только лишь RAII

     
     
  • 6.100, Сладкая булочка (?), 22:00, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > В теории - да. На практике в C++ эти инструменты во-первых лишь
    > опция, можно писать по-старому в Сишном стиле и ловить переполнения и
    > прочее.

    Кто мешает писать на расте в unsafe и

    > ловить переполнения и прочее.

    ?

     
     
  • 7.103, Аноним10084 и 1008465039 (?), 22:15, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, unsafe не отключает все гарантии, а во-вторых - явное требование обрамлять такие места unsafe-блоком явно помечает, какой код нужно пристально проверять. Это гораздо более верный подход, чем опциональная безопасность, хотя конечно и понятно, что C++ пошел на это из-за обратной совместимости в числе прочего
     

  • 1.11, Смузихеб забывший пароль (?), 12:15, 17/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > и предотвращает возникновение состояний гонки

    Это тот самый ЯП, по которому в одной из предыдущих новостей аккурат состояние гонки и было одной из осн. возникших проблем ?)

     
     
  • 2.22, VVVVVV (?), 12:43, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это в какой новости?
     
     
  • 3.38, аморим (?), 13:18, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    про uutils видимо
     
  • 3.40, Смузихеб забывший пароль (?), 13:39, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Да, анон ниже был прав
    > Ubuntu 26.10 полностью переведён на Rust Coreutils

    https://www.opennet.me/opennews/art.shtml?num=66274

    > в LTS-ветке Ubuntu 26.04 был совершён откат
    > на поставку утилит cp, mv и rm из набора GNU Coreutils
    > Варианты[из uutils] cp, mv и rm были возвращены из-за проблем с
    > безопасностью, выявленных в ходе аудита кодовой базы
    > Rust Coreutils. Большая часть уязвимостей
    > в Rust Coreutils вызвано наличием состояния гонки

     
     
  • 4.58, Аноним (58), 16:44, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > в Rust Coreutils вызвано наличием состояния гонки

    И ты правда не соображаешь, что состояния гонки там были на уровне файловой системы? В тексте новости же об этом черным по белому написано, с примерами. 🤦

     
     
  • 5.90, Смузихеб забывший пароль (?), 18:49, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я просто привёл цитату из статьи )

    > выявленных в ходе аудита кодовой базы Rust Coreutils

    Очень интересно. Дыры в ФС, но выявили их почему-то в ходе аудита кодовой базы растовой корутилс и у сишной подобных проблем не было

    Очевидно, если всё дело в ФС, то и исправления связаны непосредственно с ФС и никак не касались кода растовых корутилс, не так ли ?

     
     
  • 6.95, Аноним (58), 19:56, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, ты буквально утверждал, что в аккурат состояние гонки А теперь, когда ок... большой текст свёрнут, показать
     
  • 2.53, Человек из СССР (?), 16:04, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > состояние гонки и было одной из осн. возникших проблем

    Если не быть программистом, а лишь вайбкодером, и не такое становится возможным даже на раст.

     

  • 1.17, Аноним (17), 12:35, 17/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Для разработки на языке Rust с использованием модели SIMT развивается компилятор cuda-oxide, позволяющий компилировать код на языке Rust, использующий штатную систему типов и модель владения Rust, напрямую в инструкции для выполнения в виртуальной машине CUDA PTX (Parallel Thread Execution).

    В макросню для компиляции внутри раста в куду нишмагли

     
  • 1.30, Аноним (29), 12:55, 17/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > обеспечивает безопасность работы ... предотвращает возникновение состояний гонки

    Недавняя новость: "...из-за проблем с безопасностью, выявленных в ходе аудита кодовой базы Rust Coreutils. Большая часть уязвимостей в Rust Coreutils вызвано наличием состояния гонки".

     
     
  • 2.41, Аноним (17), 14:36, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >Большая часть уязвимостей в Rust Coreutils вызвано наличием состояния гонки".

    зачем там многопоток и почему не переписать уутилс на хаскель, в котором есть исключатор гонки как основной примитив itc?

     
  • 2.57, Аноним (58), 16:37, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Большая часть уязвимостей в Rust Coreutils вызвано наличием состояния гонки".

    Состояния гонки в Rust Coreutils были на уровне файловой системы, а не внутри программы.

     
     
  • 3.70, Аноним (15), 17:45, 17/09/2026 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
     
  • 4.92, Аноним (58), 19:03, 17/09/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 5.97, Аноним (15), 20:51, 17/09/2026 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
     
  • 6.101, Аноним (58), 22:04, 17/09/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 3.86, Аноним (29), 18:37, 17/09/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     

  • 1.52, Человек из СССР (?), 16:03, 17/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кто-то объяснит мне причину хейта в сторону раст?
     
     
  • 2.67, Бжежко (ok), 17:27, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Непрофессионализм и религиозная приверженность к уже освоенным инструментам.
     
  • 2.68, анон (?), 17:33, 17/09/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.74, Аноним (15), 17:55, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А кто объяснит причину хайпа?
     
     
  • 3.102, чатжпт (?), 22:12, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    бесконечные cve в сишном коде
     
     
  • 4.106, Ivan_S (?), 01:26, 18/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Найденные ИИ. А тот глупостей сколько хочешь повыдает.
     
  • 2.78, Аноним (76), 18:13, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Он очень сложен, некрасив и долго компилируется.
     
  • 2.85, Аноним (85), 18:36, 17/09/2026 [^] [^^] [^^^] [ответить]  
  • +4 +/
    1. язык хороший, мощный, но сложный: те кто не осилили - хейтят, потому что они не смогли
    2. раст претендует на ту же поляну что и C/C++: диды не любят конкуренции - хейтят как новое и угрожающее их уютному мирку
    3. у языка много "фан-боев" которые топят за "святой раст" похлеще проповедников (часто не понимая даже самого языка): тут хейтят самих "боев", ну и расту достаётся заодно
    4. прямой перевод "safe" раста почти всегда трактуется неверно: от языка ожидают чуда и решения всех проблем сразу - хейтят за обломанные завышенные ожидания
     
     
  • 3.99, Аноним (99), 21:44, 17/09/2026 Скрыто ботом-модератором     [к модератору]
  • +2 +/
     
  • 2.104, Аноним (-), 00:38, 18/09/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Единственное за что можно поругать, некрасивый многословный синтаксис. Но с другой стороны плюсы с прибамбасами выглядят даже хуже. А так его хейтят люди, верящие в то, что программисты это элитная каста с 200IQ, которая не совершает ошибок.
     

  • 1.107, Ivan_S (?), 01:32, 18/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отличный ЯП. Память ест правда. Дисковое пространство сжирает. Надо память и диски докупать. Синтаксис такой, что сложно разобраться. Следовательно не понять, что программа делает кроме заявленного. Багов в программах на нем много как в любом ЯП. А так отличный ЯП. Блистательный. Только дорого очень софт на нем иметь.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    XSQUARE
    Inferno Solutions
    Hosting by Hoster.ru
    Хоcтинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить новость, Поддержать