AMD внедряет Rust в свои графические драйвера

звучит как nih-синдром

Нет. Хотя nih я считаю уважительной причиной самой по себе, но в данном случае есть как минимум две другие: во-первых, у меня имеется своё мнение касательно того, чего не хватает в языке, и я бы его реализовал (список не проси, до реализации незачем), а во-вторых (это уже позже выяснилось) авторы gcc последнее время начали чтить всякую графоманию выше здравого смысла, и портить код всякими дурацкими UB, т.е. есть опасность что спустя какое-то время им станет пользоваться так же неудобно, как и шлангом.

А собственно кто куда внедряет то? Судя по новости, они наняли какого-то хрена веревкина на должность VP по чему-то там и тот завел на линкедине вакансию. То есть ни одной строки кода еще на написано, а впечатлительные барышни с лора уже начали бросать лифчики в воздух

после:

вируса в 10 байт заражающего (.com) файлы.
Колибри ос занимающая несколько мегабайт в bios.
надавно debian 9 nginx + php помещался целиком в кеше процесора xeon 24mb.
мир идёт не туда.

Ну да, а драйверы амуде — сама элегантность

ROCm 7.2 — потолок для Windows 10. llama.cpp уже на 10.0 скаканула.

rust 1.97.1 для своей сборки требует более 32 ГБ оперативной памяти

ерунда, на днях собирал с 8ГБ

А, господь, свидетели десятки. Пон

Ааа, адепты сравнения жопы с пальцем. Пон

тот же C++ дальше от Unixway

«Unix-way» - давно протухший концепт, причём, он уже протух в 80х, когда сетевую подсистему в юниксы вкрячили. BSD сокеты, TLI - это уже никак не вписывается в один из столпов unix way, «всё - это файл»… А C++ в 80х пешком под стол ходил, и коллеги Страуструпа по BellLabs тихонько посмеивались над экспериментом датчанина, когда уже хрюникс-вей был де факто историей.

Разработчики Rust’а специально не включили в состав языка батарейки

Но вкючили сраную Каргу. И теперь большинство растовиков не понимают, что свет клином на Карге не сошёлся.

Все архитектуры со временем эволюционируют, а не просто уходят в прошлое.

Если Вы про скачивание библиотек по сети, то к чему эти двойные стандарты?

Такое есть у всех современных (и даже у некоторых, мягко говоря, не очень современных) языков программирования: npm (JS), pip (Python), NuGet (.NET), Composer (PHP), RubyGems (Ruby), Maven/Gradle (Java), pub (Dart), Hex (Elixir/Erlang), Cabal (Haskell), opam (OCaml), CPAN (Perl), CRAN (R), Pkg (Julia), Dub (D), Nimble (Nim), LuaRocks (Lua), Conan/vcpkg (C++),... и т.д.

Если C/C++ даёт свободу стрелять себе по ногам, то Rust даёт свободу сосредоточиться на логике на борьбе с компилятором.

Исправил. Можешь не благодарить. Причём, проблемы с памятью в C++ могут быть от «джун не знал, где и как использовать умные указатели, но это вообще никак не сказалось на потребительских качествах, потому что процесс грохался при завершении работы с ним» до астральных проблем с UB, которые останавливают производство.

Но дело тут ещё в том, что в расте вместо UB будет просто изменение реализации. Что-то поменяют в реализации unsafe части компилятора, эти изменения пройдут через фильтры всех тестирований. А на новую версию компилятора разрабы захотят перейти, потому что в safe части языка им насыпят гудисов.

Ну так надо учиться, учиться и учиться. Чем меньше ошибок будет делать программист тем меньше ему будет бить по пальцам borrow checker.

Что за наглое враньё?

То, что подобные мусорки кто-то делал «для любых языков» совершенно не означает, что они есть «у языков». В частности, composer это сторонняя прога, хоть и написанная на пхп, но никаким боком не являющаяся его частью. Всякие «для С++» - тем более, просто чьи-то поделки. npm и pip вроде как весьма аффилированы с языками, да, ну, осуждаем и не пользуемся этой чушью. Единственный нормальный способ реализации пакетного менеджера - это когда он интегрирован в ОС (и, разумеется, никакие языки «своими» не позиционирует). Всё остальное - чушь и должно быть искоренено.

Вы просто не понимаете зачем это нужно и какие задачи решает.

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

Никаких нормальных задач это не решает.

Вот те задачи, для которых это делается:

1. Воспроизводимые сборки
   
   В разных дистрибутивах опакечивают разные версии библиотек. И никто не может гарантировать, что при использовании библиотек из репозиториев дистрибутивов и на Ubuntu 22.04, и на Arch'е соберётся одно и то же.
2. Зависимости не только от системных библиотек
   
   В Rust, Python, Go, JavaScript,... и т.д. огромная экосистема библиотек, которых нет в репозиториях дистрибутивов. Их тысячи. Ждать пока майнтейнеры Debian упакуют очередную версию serde или tokio - нереалистично.
3. Разрешение версионных конфликтов
   
   Разным библиотекам могут требоваться разные версии других библиотек. И тут мы плавно подходим к следующему пункту.
4. Изоляция проектов
   
   Cargo/pip/npm и т.д. позволяют писать десятки разных проектов, которым нужны разные версии библиотек, одновременно.

В разных дистрибутивах опакечивают разные версии библиотек

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

экосистема

Не используй это слово в контексте ИТ, это маркер то ли маркетолухов, то ли идиотов.

библиотек, которых нет в репозиториях дистрибутивов. Их тысячи.

Всякие лефтпады тащить незачем. Реально полезных библиотек весьма мало.

Выбор владельца компа надо уважать.

Ну так вот он благодаря Cargo/pip/npm и т.д. и выбирает какие версии библиотек использовать для проектов не ограничиваясь конкретными версиями из репозитория дистрибутива.

Не используй это слово.

Так короче называть «совокупность взаимосвязанных библиотек и инструментов».

Всякие лефтпады тащить незачем. Реально полезных библиотек весьма мало.

Это субъективное мнение. Многие разработчики считают иначе.

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

глубоко в стек графических процессоров

количество направлений куда можно послать пополнилось еще одним вариантом

записал в книжечку

P.S.: все-таки какая-то польза от rust есть, что ни говори

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

Многолетняя практика тысяч макак меня не интересует.

Если Вы про скачивание библиотек по сети

Я не про скачивание библиотек.

И в остальном Cargo полезный инструмент. Что-то, конечно, можно делать и руками, однако...

Чем, например, каждый раз делать

mkdir -p progname/src ; touch progname/src/main.rs progname/Cargo.toml

cargo new progname

Как бы, времена ассемблера и первых Pentium'ов уже давно позади

Я точно читаю Саахрикту?

И в остальном Cargo полезный инструмент.

Кагбэ да, но нет.

Что-то, конечно, можно делать и руками

Теоретически да, на практике кагбэ есть нюансы.

Лучшее враг хорошего. У сишки сборочник не является частью компилятора, мы получили обширный зоопарк разных собираторов: make, cmake, meson и ещё десятки других. Мы получили возможность сравнить разные подходы, выбрать лучшее решение. Собиратор не является частью Python’а, а pip завоевал популярность в непростой борьбе с egg, setup.py и прочими, а сейчас вытесняется uv. Gradle выдавливает Maven. Я не против того чтобы одна собиралка была популярнее других, но я за конкуренцию.

Есть принципиальные различия между скриптами (тот же Python), байткодом в JVM (Java) и системным программированием.

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

Cargo жёстко привязывает версии и хеши.

На дворе 26 год, все болей-лимений современные сборочники привязывают.

В C/C++ это не обязательно. Более того, при динамической линковке юзер потом может заменить библиотеку на свой другой вариант - и программа с ней запустится.

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

Воспринимайте Cargo как своего рода аналог Secure Boot. Как Secure Boot обеспечивает защиту от подмены ядра, так и Cargo предназначен для защиты от подмены библиотек. В мире C/C++ аналогами можно рассматривать разве что Nix/Guix, Bazel и Conan 2.0, а не «все более-менее современные сборочницы». При этом, разумеется, любые надстройки не являются обязательными. В то время как то, что Cargo является стандартом из коробки, обеспечивает соответствующую защиту по умолчанию.

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

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

Так может ну его, плюрализм этот для устоявшегося инструмента?

для устоявшегося инструмента

Устоявшийся инструмент таковым стал, потому что победил конкурентов, удовлетворяет потребности и решает задачи…пока. Когда-то make был устоявшимся инструментом. И Subversion был устоявшимся инструментом. И gcc для многих был устоявшимся инструментом.

Сишка и python пережили уже много переходов с одного «инструмента по умолчанию» на другой, не развалились.

я ни разу не слышал, чтобы язык ругали

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

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

В гошке тоже самое. У них и форматтер в язык встроен. Всё довольно жёстко в этом плане.