Comments 227
Вот читаю подобные новости про то, как Rust начинают использовать в крупных компаниях -- начинаю ловить себя на мысли, что жалею, что всё ещё пишу свои поделки на C/C++, а не на Rust. :(
Что тебе мешает перейти на ржаву?
Мне лично мешает перейти на раст следующие пункты
на работе раст пока не случился, придётся практиковаться на пет-проектах
на рынке пока мало вакансий на раст, надо подождать ещё, взлетит/не взлетит
новые стандарты C++ продлевают ему жизнь и не позволяют совсем выкинуть из индустрии высоконагруженных серверов, встроенных систем, игр, т.д.
сложно в голове удерживать синтаксис, а главное дизайн-паттерны сразу нескольких языков, например, C++, Golang, Python, и если на каком-нибудь не пишешь, скажем, 3 месяца, то теряется навык
Первый код на C был еще где-то в школе, это середина 90-тых. Сейчас 2023, и уже даже слабо помнится сколько языков за это время вызвало мысли "надо бы перейти на него, вот у крупняка он восстребован", а на C/C++ еще пишут.
Единственное что в окружении более или менее аналогично устояло (хотя и чертовски видоизменилось) это Java, которая по большому счету (ох сейчас будут пинать) тоже C/C++ with benefits.
Имхо, если Вам нравится c/c++, а хотите сменить стэк только потому что "его где-то начинают использовать", то надо просто немного подождать и все пройдет:)
"То самое чувство когда пишешь на PHP"
Очень замечу, что все те кто активно использует ржаву пишут только критические к безопасности куски кода на нём, а остальное работает на православных Си&Кресты. Ибо писать обычные приложения на ржаве - боль
Как я заметил, кто-то спокойно пишет на расте, но это больше зависит от скилла и от привычек пишущего кода, а так, самое неприятное это написание gui, но в этом направлении крейты очень неплохо развиваются.
Ну уж куда меньшая, чем на чистом Си и даже крестах. Но переписывать на Расте конечно лучше самые важные части, а не все попало.
Си&Кресты это стандарт на, мать его, 2000 страниц. Количество ошибок напрямую влияет на то, как хорошо ты запомнил книжку.
Но суть что на Си&Кресты можно писать "быстро и красиво". Пока ты пишешь свои интерфейсы на ржаве и занимаешься пердолингом, я уже занимаюсь отладкой написанной программы, ибо где-то есть какая-то ошибка, о причине возникновения которой нужно знать 2000 страничный документ - добро пожаловать, так сказать.
я даже ради интереса скачал C99, сам язык - 70 страниц, +70 страниц библиотека. Но да, не 2000. "кресты" сам язык около 400 страниц.
Ну в этом и суть)
Грубо говоря, ржава не требует много внимания, но требует много писать, а Си&Кресты наоборот.
Что-то подобное было в бородатые времена, когда срались Pascal vs C, а ведь даже микрософт топили за паскаль. Мол букав больше, ошибок меньше. Но как-то это просто осело в неких нишах и всё.
Грубо говоря, ржава не требует много внимания
Не требует внимания к частностям, но требует намного больше к высокоуровневому проектированию. Если на расте зашёл в тупик, то давай всё по новой, и кучу кода надо перепахать, если не хакать через unsafe. А на плюсах можно заплатками закостылить и дальше двигаться.
Ну да, куда лучше жить вовсе без стандартов.
Я не знаю ни C++ ни Rust, но решил изучить С++ первым. Понятно что Rust безопаснее все дела, но это лучше работает когда ты можешь писать безопасный код на C++ а потом упрощаешь себе жизнь с помощью Rust полностью осознавая что конкретно он делает за тебя.
А потом читаю последнии новости по вин 11 и понимаю не тем ребята в МС заняты, не тем...
от этого не меняется факт что десктопная система работает все более и более странно
dotnet что-же еще.
Не, не похоже. Запустил на Win 11 tasklist /m "mscor*" для выдачи списка процессов использующих .net. Таких оказалось очень мало - в основном приложения вендора (Lenovo), один сервис от Intel, из майкрософтовских вроде только нечто PhoneExperienceHost.exe.
WinUI можно и из плюсов использовать (и возможно из раста т.к. к нему тоже прикрутили WinRT через который работает интероп). Но учитывая что они сами недавно переписали магазин приложений с плюсов на C# я не думаю что этим весело заниматься.
WebUI xD
WinUI (XAML и C++/C#)
тестируют-как-курица-лапой другие.
"Это не хвост лапа, Красная Шапочка..."
В целом, то что они сделали под названием Windows 11 — это очень хорошо: наконец-то займусь переходом на Linux после завершения жизненного цикла Windows 10 в 2026.
А как же тиктак цикл релизов?
а я зашел почитать сначала вроде "чо там нового появицца?", а потом дочитал до "вин 11", и вспомнил, что меня на 10-й это не касается.
Ну, не знаю. Я сижу на Федоре, и багов мне хватает с головой! В том числе и в Гноме.
Я живу на Win 10 LTSC, она без обновлений и рекламы.
Также вынужден сказать, что молодёжи Windows 11 "нраица". Ох уж это поколение Z.
Я уже давно не молодежь, помню еще времена DOS и переход на win3.1, но меня тоже устраивает. Винда как винда, сразу как появилась возможность и обновился с 10-ки. Рекламу я даже не знаю где искать - ни разу не видел, обновления не сильно то и напрягают, а так IDE запускается, проекты компилятся, игры играются, консолька даже удобная с WSL есть. Пуском не пользуюсь практически, только тыцнуть клавишу WIN быстро набрать в поиске название програмки и тыцнуть ентер.
А меня семёрка вполне устраивает, до сих пор на ней сижу. Потому что до чёртиков задрали перетасовки иконок и перезды кнопок.
Что будете делать, когда на нём перестанет работать Steam?
А мне без разницы, я себе spyware добровольно и с песней не устанавливаю.
А что насчет Python и Chrome? У них последние версии с Windows 7 несовместимы. У Питона 100%, про Хром недавно писали.
Chrome
Кажется, я уже сказал — я себе spyware добровольно и с песней не устанавливаю.
Python
Питонам место там, где они родились — под пингвином!
Кажется, я уже сказал — я себе spyware добровольно и с песней не устанавливаю.
Сказал человек который сидит на винде, а какой не spyware православный браузер вы используете?
Там не то, чтобы такая уж несовместимость. Для Win7 энтузиасты делают отдельные установочные дистрибутивы: https://github.com/adang1345/PythonWin7
Да, а вот PyCharm официально нет: https://www.jetbrains.com/help/pycharm/installation-guide.html. Видимо и Idea/CLion и пр. тоже. Игрушки многие.... А, еще драйвера nVidia, кажется, больше не совместимы. Нет поддержки новых процессоров с разнотипными ядрами. Увы и ах.
Поколение ЕГЭ, досточтимый сэр. Они никогда не слышали, что бывают какие-то там "инсталляторы", а тем более "голые экзешники".
Именно. Более того, если играть в игру годика через два после релиза, из неё уже давно как будут выпилены все баги.
Более того, не прилетит обновление, вносящее цензуру в угоду текущей повесточке, выпиливающее всю музыку, потому что лицензии закончились, или без выбора ставящие поверх старой любимой игры совсем другой "ремастер", который на твоём железе не идёт, или там игровые механики подправленные. Если что, я не выдумываю, это всё было с играми в Стиме.
автообновление в стиме всегда можно выключить
Насколько я знаю, выключенное автообновление просто превращается в ленивое, но запустить старую версию игры Стим просто так не даст
автообновление в стиме всегда можно выключить
Можно, но откуда ты узнаешь, что завтра из этой игры вырежут музыку, а в этой игре пофиксят баг, мешающий прохождению сюжетного квеста. А на торренте — все версии в твоём распоряжении, откатывайся-накатывайся, как хочешь.
расскажите, как ? steam.exe -no-update ?
Помоему оно и не подразумевается для поиска иконки прокруткой в этом списке всех программ
Либо поиск либо закрепить в меню пуск. На 11 ещё с бета версии, около 2х лет, за это время я не разу не открывал список всех приложений )
Ну, винда11 объективно лучше работает, из-за перепила работы менеджера окон больше... Куча всяких мелких нововведений, чтоб тебе легче жилось. Буквально превратили свою ОС в один большой менеджер плагинов, но есть нюанс...
Вот ты установил какой-то архиватор который добавляет в контекстное меню новую строчку, и всё, у тебя теперь эта менюшка по секунде открывается. Удаляешь приложение - всё опять летает. Пробуешь другие, та же лажа.
И так много где. Фичи есть, но часто глючат, спс
Вроде направление правильное выбираю зачастую, но из-за непонятных флуктуаций их недоделывают до конца или постоянно меняют. Как это было с сенсорной клавиатурой, режим для двух пальцев был хорош, там была прозрачная область чтоб было видно что ты набираешь, а потом... Почему-то... Прозрачность убрали... А потом вернули... А потом убрали... А потом вообще переделали что с двух пальцев теперь писать нельзя... Я-я-я не знаю.
Да, именно на 11. Все эти новые свистелки работают только если у тебя какой-нибудь разогнанный инцелкор9999К с ссд на 10ТБс. Люди по беднее жалуются что подлагивает. Бывает даже что новый интерфейс не успевал подгружаться кадра 2-5, лол.
Но это было пол года назад, примерно. Может уже починили, я не знаю
UI и на китайских "ноутбуках" на селероне быстрее работает… До тех пор пока не надо поработать в любом графическом приложении (даже банальном paint.net) или с графическим планшетом. Тогда каждое движение планшетом или тачпадом вызывает каскадные микро-фризы "не отвечает" на рабочее окно на 0.3с с мерцанием и переключением на другие окна. Неизлечимо.
А вин10 тем временем пашет как часы.
А что в Windows 10 не работает, в таком случае? У меня в Windows 10 проблем не возникает, я просто спокойно пользуюсь ОС. Можно в Windows 10 придраться к разношерстности иконок, разноликости мест, где управляют ОС (Control Panel против более новых мест управления), да ограничению в 16 элементов на статус-иконки — это когда у вас стоит одновременно Dropbox, Google drive, Onedrive, и допустим TortoiseGit, и все переопределяют свои статус-иконки в проводнике из-за этого глупого ограничения. Если в Windows 11 это ограничение по-прежнему на месте — то и говорить не о чем.
На наш взгляд, шинда10 просто хорошая. В ней всё сделано строго и со вкусом, а новые (для 7ки) свистоперделки не лезут в лицо.
Тупо хорошая ОС
За исключением желания микрософта впихнуть все свои сервисы тебе в лицо... Но это можно списать на то, что они перестали именно "продавать ОС", даже на пиратке ты будешь получать обновления безопасности... как бы???
Поставьте LTSC. Я как бы не по теориям заговора, но она действительно ест меньше батареи ноутбука и шустрее. Там убраны рекламы, лишние сервисы, и вот это всё. Ms Store при желании можно вернуть и выборочно все Metro-приложения тоже, если хочется.
Ты не поверишь, но мы уже собрали "особенный" образ, который сам себя настраивает и даже регистрируется как лицензия (без взломов и прочего, чисто 2-3 команды в консоли), обновления даже приходят... :)
ЗЫ - На моём ноуте на целероне именно LTSC и стоит.
Для незнающих, LTSC сборка настолько кастрирована, что там пикчи в paint открываются, то есть буквально ОС и стандартные, ещё для win xp, приложения.
Молодёжб в чате! (36 лет). 11 прям сильно лучше 10 по ощущениям. Возможно, сказывается то, что у меня для дома и сёрфинга Мак и я привык к тамошнему UX, которое потихоньку переползает в 11.
Я пытался четыре года жить на OSX, имел три Мака. Не пошло. Очень дурной UX, много мелких недоделок в этом UX, считающихся "круто" и сливающихся для меня в одно большое "нет". Это конечно всё субъективно очень, но на мой взгяд UX Windows даже просто быстрее, чем OSX (хотя маки мощные). Вся эта пластилиновость OSX просто приводила в уныние и отваживала от всяческой работы.
А для этого туториал нужен? Также легко установить как винду.
Они ж кстати трезубец вроде выложили?
Раз пошла такая пьянка: а что сейчас есть вместо скайпа, чтобы с пробросом в обычную телефонную сеть?
Дано: престарелая мама, которая ничего не понимает в этих ваших компухтерах, но умеет пользоваться телефоном с вертушкой, и сын, который может себе позволить платить за SkypeOut. Нужно всё то же самое, но без участия Microsoft.
Купите маме интернет пакет и вайбер поставьте. Я так сделал.
Viber out — тоже работает.
вайбер поставьте.
Вы когда-то пробовали ставить вайбер на дисковый телефон?
(Тут так исторически сложилось, что тот телефон был прописан как адрес для кода авторизации. Если б Вы только знали, каких усилий мне стоило объяснить, что нужно снять трубку и услышать четыре цифры. При том, что, с одной стороны, слушала сиделка лет на много моложе мамы, а с другой — что цифры произносились на непонятном английском языке.)
Нет ничего невозможного.
https://tehmo.com/diskovyiy-4g-telefon-postupaet-v-prodaju-6582p.html
Но вайбер аут же работает тоже.
Преземлении сип — тоже не проблема, в общемто.
Можно воткнуть между дисковым телефоном и городской линией "народный" Linksys SPA 3000. И маршрутизировать звонки как заблагорассудится: звонить на дисковый телефон напрямую по sip; принимать звонки с городской линии на sip; совершать исходящие из sip в город.
.... и потом летать на другую сторону шарика чинить каждый раз, когда в роутере что-то глюкнёт?
Мозгов у сиделки хватает на то, чтобы купить новый стандартный телефонный аппарат и включить его в розетку. Но не хватает на более сложные конфигурационные действия. SkypeOut меня устраивает по функциям, я хочу всё точно такое же, но с расправленными крыльями без микрософта.
Получится ли у майков похоронить ChatGPT? Делайте ваши ставки, господа!
Вот ты ж блин. Interop и так был интересной задачей, а станет ещё веселее! Раньше условному питонисту нужно было немного знать синтаксис c++, теперь еще и rust, для обращения к unmanaged коду.
Почему же? Не знаю, как в python, но в c# для того, чтобы обратиться к unmanaged библиотеке, нужно всего лишь описать импортируемый метод. Тут даже не нужен небезопасный контекст, если нужно перекидывать указатели между вызовами неуправляемого кода, потому что существует System.IntPtr.
using System.Runtime.InteropServices;
DllImport("kernel32.dll")]
public static extern bool WriteProcessMemory(
nint hProcess,
nint lpBaseAddress,
byte[] lpBuffer,
int nSize,
out nint lpNumberOfBytesWritten);
А как себе представляете использование новых библиотек без питона? К примеру, программистами на с++? Думаете, им тоже придётся синтаксис rust учить просто чтобы понять системное api?
Это чушь, всё системное api будет доступно из с++. А значит, и вам достаточно знать плюсы для интеропа.
Господа, манглинг в C++ - нестабилен и несовместим между компиляторами. Единственный популярный abi совместимый язык, известные мне - чистый С. И в плюсах и в расте в ffi используется C abi. С плюсами еще может быть случай, когда проект собирается одним компилятором вместе с его библиотеками-модулями как Qt и UE.
У виндузятников, конечно, совй мир, в котором может быть только один благословенный компилятор, но у interop внутри, скорее всего, будет чистый C. Для написания биндингов без документации, конечно, надо знать язык оригинала.
Вот этот благословенный компилятор меня как то, чуть в с ума не свел, в проекте была библиотека и ее потребитель, все отдельно в тестах работало отлично, а вот вместе никак при запуске креш. Проблему заметил добравшись до дизасемблированого кода, оказалось потребитель аргументы в стек укладывает в прямом порядке, а либа читает в обратном. Ударил себя по лбу, мол идиот не проверил, что совпадают abi, но не туту то было они совпадали! Долго не мог понять, что же идет не так, пока не обратил внимание, что компилятор в либе и приложении при сборке используется разной версии.
Единственный популярный abi совместимый язык, известные мне - чистый С
C ABI конечно самое стабильное из того что есть, но у него тоже своих проблем хватает :D
C Isn't A Programming Language Anymore
TL;DR:
Когда вам нужно соединить любые два языка, вы идёте через C. Используя его не как язык, а как протокол
Но при этом C вообще не задумывался стать протоколом, и поэтому:
распарсить сишный хедер не такая простая задача как кажется. Все кто это делают, используют компилятор С как библиотеку
C ABI очень, очень слабо определено. На самом деле существует огромная куча разных C ABI, определяемая по архитектуре железа, ОС и поставщику стандартной либы, aka target triple (x86-84-unknown-linux-gnu). Только в rustc таких триплов 176 штук (не все поддерживаются нормально, но rustc о них знает)
И это мы ещё не рассматривали calling conventions
И случайно сломанную обратную совместимость в пределах одного тулчейна
Даже среди двух основных компиляторов — gcc и clang есть несовместимые различия в генерируемом коде. Не факт, что собранное одним компилятором прилинкуется к собранному другим как надо
И исправить это уже невозможно. Каждое изменение, будь оно хоть трижды стандартным (в конце концов, стандарт ABI так и не определяет :D ) сломает кучу кода, который просто привык полагаться, что int это 32 бита (а задумывался быть 64 на современных процессорах)
Где-то был проект, создающий именно ABI, с нуля, с учетом фич современных языков (чтобы например соединяя Rust и C++ не приходилось обоих кастрировать до уровня C), но ссылка на него потерялась :(
У виндузятников кстати очень....прикольное ABI внутри. В той статье рассматриваются способы сделать ABI, совместимое как назад так и вперед, и один из примеров как раз от майкрософта. Выглядит...устрашающе :D
Это вы ещё такое не видели:
use pyo3::prelude::*;
use pyo3::types::IntoPyDict;
fn main() -> PyResult<()> {
Python::with_gil(|py| {
let sys = py.import("sys")?;
let version: String = sys.getattr("version")?.extract()?;
let locals = [("os", py.import("os")?)].into_py_dict(py);
let code = "os.getenv('USER') or os.getenv('USERNAME') or 'Unknown'";
let user: String = py.eval(code, None, Some(&locals))?.extract()?;
println!("Hello {}, I'm Python {}", user, version);
Ok(())
})
}Похоже на хелловолд либы-обертки интерпретатора. Это не интероп в понимании вызова бинарного кода из интерпретатора (да, там дам давно JIT и AOT, но, конвенциональненько), о котором написал топик-стартер. Здесь запускается интерпретатор и происходит копошение в его памяти по его правилам. Я видел похожее, когда внедрял javascript скрипты с V8 в плюсовый проект. Сам код, очевидно, бесполезен в проде и приведен как пример. На мой взгляд rust-идеоматичненько, вроде нравится.
На раст есть и генераторы биндингов под питон :D
Я уже не помню точно названия, но я их тыкала, они есть. Пишете Rust-функцию, возвращающую PyResult, суете в макросек и макросек все описание модуля для питоновского C API сгенерирует
Потом кладете .so/.dll туда же где питоновские либы, и делаете import. Всё, оно работает
Microsoft для интеропа продвигает WinRT (ребрендинг COM). Там биндинги генерируются автоматически из winmd файлов с описанием классов и функций (https://learn.microsoft.com/en-gb/uwp/winrt-cref/winmd-files). Можно написать библиотеку на C++ и использовать ее из C# или наоборот. Для Rust это вроде как тоже поддерживается.
Большая часть новых высокоуровневых api Windows (например класс для доступа к цвету который пользователь выбрал в настройках Windows) доступны именно через WinRT и не входят в Win32 API.
Ответ прост — по данным самой корпорации, примерно 70% уязвимостей, которые выявлены в программных продуктах корпорации за последние пару десятков лет, базируются на ошибках управления оперативной памятью.
Даже интересно устранив возможность возникновение ошибок при работе с памятью, получится более безопасная система. Или как с каким нибудь PHP где проблем с памятью не было, что не помешало наделать дырявых CMS.
Но зачем?
Я так думаю - во втором конверте была рекомендация всё переписать.
«Производственные эксперименты» с Rust в Microsoft стали реализовать не сейчас, а еще летом 2019 года.
Вот это - самое интересное. С тех пор Rust стал как минимум поприличнее выглядеть. Catalyst перепугал до полусмерти? Надежда что с .NET MAUI сумеют/успеют одних вдохновляла а других отнюдь? Поди знай, но любопытно.
Безопасная работа с памятью обеспечивается в Rust во время компиляции посредством проверки ссылок, отслеживания владения объектами и учета времени жизни объектов (области видимости).
Безопасная работа с памятью в Rust не обеспечивается. Право утекать за памятью закреплено официально. Остальная «безопасность» легко отключается если компилятор реально достал.
Использование Rust дает возможность снизить риск появления уязвимостей, которые вызваны ошибками при работе с памятью, включая обращение к области памяти после ее освобождения и выход за границы буфера.
Даёт возможность, да. Но и без Rust такие возможности существуют. И список практически исчерпывающий. Как эта цитата вяжется с предыдущей, автору виднее.
Помимо прочего, США интересны тем, что подушки безопасности были внедрены там массово и за короткое время, а не неторопливо и только на новых машинах, что позволило увидеть их эффект через статистику. Смертность снизилась, а потом вернулась на прежний уровень - все узнали что подушки гарантируют безопасность. Почему с Rust должно быть иначе, особенно когда основной заботой программиста будет как заткнуть рот компилятору?
Сила - в правде.
Как по мне, в Rust разумно переосмыслены старые парадигмы, начиная с наследования, и любовно усовершенствована система шаблонов. Типа развитие С в другую сторону от С++. И Cargo удалась. И глупостей типа сборщика мусора нет. А «безопасность» и связанные с ней указания времени жизни, обычно выполняемые одним способом из одного возможного, скорее провал чем успех.
Но кому-то очень нужно применить маркетинговые методы для… А, собственно, для чего?
разумно переосмыслены старые парадигмы, начиная с наследования
Наследование там "переосмыслено" по принципу "мы лучше знаем, что вам нужно, и вам это не нужно". Ну, такое.
любовно усовершенствована система шаблонов
Шаблонов там нет, там генерики - со своими плюсами и минусами соответственно. Нельзя сказать что это какое-то "усовершенствование шаблонов", просто выбран другой подход к обобщенному программированию, в стиле других языков типа C#.
Но и без Rust такие возможности существуют.
Только не используются разработчиками :-/
На машине можно гонять быстрее и садиться за неё пьяным. Что можно делать с программированием, что не делают уже сейчас?
Гонять быстрее и пьяным можно было и на машине, не имеющей подушек. Что можно делать на машине с подушками такого, чего нельзя было без подушек? Да ничего. Просто наличие подушек подсознательно (а бывает что и сознательно, знаю людей, которые на полном серьезе считают, что при наличии в машине подушек пристегиваться необязательно) расслабляет, и это провоцирует людей к пофигизму и к облегчению нагрузки на свой мозг под лозунгом "подушки меня защитят". А вот хрен.
Гонять быстрее и пьяным можно было и на машине, не имеющей подушек
...но на машине без подушек это можно было делать только один раз в жизни!
"подушки меня защитят"
Чего не скажешь о кошельке! Не очень понимаю, откуда взяться пофигизму, ведь аварии – это очень дорого.
Остальная «безопасность» легко отключается если компилятор реально достал.
"borrow checker" никак не выключается. "unsafe" здесь не поможет.
С одной стороны да, но с другой можно легко вывести ссылки из под контроля бч через сырые указатели. Но это надо намеренно стремиться проломить борроучекер. Через такое реализованы некоторые вещи в стандартной библиотеке, например.
А стремиться проломить борроучекер обычно очень плохая идея. В конце концов, он старается вам помочь, и в подавляющем большинстве случаев прав, даже если вы этого не осознаёте)
Ваша история про статистику смертности в автокатастрофах в США до и после внедрения подушек безопасности меня заинтересовала! Я поискал подтверждения, но пока не нашёл.
Нашёл вот такой график. Внедрение подушек безопасности происходило между примерно второй половиной 80-х (всё более широкое внедрение технологии, продолжавшей совершенствоваться; закон был принят в 1991-м, с отложенным вступлением в силу) и 1998-м годом (закон полностью вступил в силу). Красная кривая (смерти на милю) шла вниз, но не драматично (заметен небольшой зубец более резкого падения около 1992-го года - более заметный на оранжевой кривой, смерти на миллион населения). Главное - я не вижу отскока.
Аттрибуция графика: By Dennis Bratland - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=66179446
Вы пишете о том, что не знаете, нахватавшишь от людей, что также знают о языке по слухам.
Потому, что я не могу представить как вы увидев в работе программы падение с ошибкой «чтение за пределами» вместо того чтобы исправить свой код, пишете нетривиальный код с unsafe и многословными сырыми указателями «чтобы заткнуть рот компилятору».
Надо быть одновременно слишком тупым, чтобы решиться ТАК маскировать ошибки, и слишком умным, чтобы знать как это сделать.
Остальная «безопасность» легко отключается если компилятор реально достал.
Проверку правил владения и Send+Sync отключить невозможно, даже в unsafe. Можно только сильно запутать компилятор, если начать использовать сырые указатели, вместо ссылок.
Даёт возможность, да. Но и без Rust такие возможности существуют. И список практически исчерпывающий. Как эта цитата вяжется с предыдущей, автору виднее.
Не вспомню где, но где-то видел картинку со статистикой, что в проектах, которые написаны на раст по сути нет вообще ошибок связанных с неправильной работой с памятью - только баги в логике. Так что на больших числах это "даёт возможность снизить риск" = "снижает риск".
Таких картинок можно нарисовать сколько угодно, а по факту как-то так. И на RustSec ошибки при работе с памятью светятся практически через раз. Комментатор выше написал чушь: нетривиальный код с unsafe будут писать не тогда, когда программа падает, а тогда, когда она еще не падает, но борроу чекер в силу своих сильно примитивных правил уже не может понять, что хочет сделать разработчик. Падать программа начнет уже потом (если разработчик при написании этого нетривиального кода ошибся).
Вся линейка x86 процессоров, начиная с i8086, предлагали концепцию разделения данных и кода в разных сегментах. С введением защищённого режима (сначала в 80286 а затем в 80386) эта концепция только развилась. Однако M$ до сих пор продолжали складывать всё в одну кучу, а саму кучу в стэк, поближе к адресам возврата. И что же могло пойти не так?
Причем тут стэк и адреса возврата? Вообщето одним из основных нововведений защищенного режима была страничная адресация, позволяющая создать плоское защищенное виртуальное адресное пространство процесса. А сегменты это анахронизм, который давно закопали, и не в одной современной ОС, прежде всего *nix они не используются.
PS: если вы про аллокацию локальных переменных на стеке, то это стандартная реализация семантики большинства нативных языков программирования, в частности Си, и его потомков. Теоретически можно делать два стека один под адреса возврата, другой под данные, но такого в процессоре физически нет, и видимо концепция ни очень прижилась.
Причем тут стэк и адреса возврата?
Очевидно: затирание адреса возврата своими данными/мусором приводит к переходу не на адрес возврата, откуда была вызвана процедура. Базовая уязвимость. Казалось бы, раздели стеки для данных и для кода (хранение адресов возврата) и все эти переполняторы буферов разом превратились бы в тыкву.
При этом не надо было бы даже менять язык. Просто перестроить компилятор на то, что данные строго отдельны от кода. И пересобрать весь код. Ведь существуют же MCS51 микроконтроллеры и даже компиляторы ЯВУ для них. А ведь у них память данных строго изолирована от памяти кода.
К сожалению в x86/x64 один железнячный стек, а реализация в софте второго скорее всего ведет к различным неприятным последствиям, в плане производительности и совместимости. Данная концепция насколько я знаю нигде не была реализованна ни только M$.
ведет к различным неприятным последствиям
Имя, сестра, имя! Практические примеры — в студию!
в плане производительности
То есть недетское падение производительности от защиты от row hammering (каковая уязвимость in the wild вроде как не встречалась) типа никого не волнует, а мизенрое падение производительности от защиты от stack owerflow (каковая уязвимость используется чуть менее, чем каждым) ВНЕЗАПНО волнует?
Это ломает кучу ABI. По поводу последствий подобного подхода надо смотреть на реальный прототип, хотябы исследовательский, которого нет, и думаю ни просто так. А не рассуждать о преимуществах сферического коня в ваккуме. Тем более что последствия от подобных уязвимостей в определенноц степени закрываются NX битом, но конечно не до конца.
Это ломает кучу ABI
ВНЕЗАПНО, "двойной стек" работает только для нового, свежескомпилированного кода. Старый он никак починить не может. А проблема сопряжения старого и нового кода решается элементарными обёртками вокруг вызовов старого кода, которые могут происходить прозрачно для вызывающего и вызываемого.
Так осталось дело за малым, реализовать работоспособный прототип, в процессе чего возникнут еще подводные камни. Замерить падение производительности. И убедить людей это использовать. Но в среднем люди не очень любят, когда им предлагают лечить перхоть гильотиной.
PS: начать можно с анализа, можно ли в принципе сделать защищенный стек содержащий только адреса возврата, на x64.
Именно так сделаны форт-системы, и никакой особой потери в производительности там нет. Железячный стек - это всего лишь две команды push и pop.
51ые, говорите? В очке 256 байт лежат вперемешку РОНы, битовые переменные, стек и ОЗУ. Код изолирован, ну так он и в типичной ОС с защитой памяти нонче тоже -- ридонли всегда. А то, что через movx адресуется -- крайне неудобно примерно для всего. Положить туда стек данных -- это 10х к времени исполнения и 5х к размеру кода будет.
Теоретически можно делать два стека один под адреса возврата, другой под данные, но такого в процессоре физически нет
Ну для arm64 есть реализация "shadow call stack", это именно отдельный стек для адресов возврата. Так же там есть "Pointer Authentication". В Эльбрусе отдельный стек возврата реализован в процессоре.
Так речь шла про x86/x64 я не уверен, что защищенный стек там можно в принципе реализовать(защитой страниц, сегментов или чего угодно), даже если принять накладные расходы на второй стек для данных. А так да есть железки с защитой от подмены адресов возврата.
У интела тоже есть эта фича, и AMD в Zen 3 её к себе скопировала
https://habr.com/en/companies/eset/articles/303086/
Другое дело, что вот так взять и включить её на уровне всей ОС чревато некоторой потерей совместимости, т.к. в больших програмных продуктах будут встречаться всякие хаки, а то и просто защиты типа Denuvo, которые только и делают, что ломают правила "нормального" кода.
Два стека можно сделать практически в любом процессоре, даже в amd64. Ну всего-то займётся ещё один регистр под программный стек для данных, а их там не то чтобы дофига, но достаточно, 15 штук. Весь вопрос лишь в том, кто под это будет писать, на каких языках и т.д. На форте что ли, где как раз 2 стека всегда было? :)
В x86-64 как раз сегментацию памяти убрали (засунули под ковер), ибо рудимент.
Концепция разделения памяти на сегменты выигрывает с точки зрения безопасности, но проигрывает в скорости. Преобразование виртуального адреса в физический там сложнее, и сегментированная память нуждается в периодической дефрагментации. Поэтому в Windows (как и в Linux) была принята плоская модель памяти, где всё в одну кучу.
Преобразование адреса из логического в физический сложнее, но он происходит аппаратно и прозрачно на лету и на скорость никак не влияет. Что касается дефрагментации, то это при программном управлении в плоской она действительно и часто нуждается в ней. А когда у тебя сегменты тебе не особо важно что там в физической памяти, главное чтобы страниц хватало. Другое дело, что делать свободную карту страниц это дорого, ведь нужен как минимум 1 регистр на каждую физическую страницу. Поэтому стараются получить непрерывный кусок, чтобы описать его одним дескриптором. И это реализовано через пэйджинг.
Концепция разделения памяти на сегменты выигрывает с точки зрения безопасности, но проигрывает в скорости
x86 уже берёт данные из сегмента ds, код из cs, стек из ss.
Пользуются этим ОС и программы, или все сегменты настроены на одинаковое пространство, процессору безразлично.
Наверное, совсем избавившись от сегментых регистров, можно выиграть в транзисторах, упростив схемы. Но это уже будет не x86 архитектура.
Преобразование виртуального адреса в физический там сложнее, и сегментированная память нуждается в периодической дефрагментации
Да ну, не больше, чем потребность в дефрагментации кучи в линейном адресном пространстве. Все эти сегменты появились в 286 как костыль, чтобы остаться на 16-битных регистрах, но получить доступ к большей памяти.
Интересно, насколько там плотно тестами обложено. Недавно, например, в 11-й сломали и чинили функцию копирования экрана в д3д в портретном режиме. Если всё перепишут, багов совместимости будет намеренно.
Rust. Они переписывают что-то на Rust. Зачем?! А! Они хотят избавиться от ошибок управления памятью! Прибавить ходу! Раз-два, раз-два!
Вот так из одного изречения капитана Смоллетта путём замены некоторых слов можно родить целую статью на Хабр.
Рискну попасть пальцем в небо, но я не верю, что работа с памятью — это единственная причина. Следует ожидать что-то более масштабное.
Кроме того, Уэстон осветил еще один интересный момент — сейчас код одной из основных подсистем Windows, Win32k GDI, переводится на новый язык.
Было бы здорово, если бы они предложили новую классификацию элементов пользовательского интерфейса. Так сказать, учли бы опыт нескольких десятилетий.
Как я понимаю, сказался еще и небольшой буст производительности, что здорово.
повысилась не только защищенность компонентов, но и увеличилась их производительность при выполнении некоторых операций
Конечно, не ясно реально ли только это повлияло на решение переписывать. Но на мой взгляд, получить относительно стабильный и безопасный код так ещё и с увеличением производительности и потенциалом еще большего роста со временем (за счет более точной системы типов) — выглядит крайне заманчиво.
Остаётся надеяться, что они реально переписывают свои компоненты, а не как в случае с WinAPI. Тот просто прогнали через какой-нибудь cbindgen и просто добавили возможность вызывать сишный код. В итоге приложения с WinAPI на расте выглядят так
fn main() -> Result {
unsafe {
// весь код тут
}
}
И ни слова о том что в декабре 2022 Rust официально стал вторым языком разработки ядра Linux после более нескольких лет тестирования...
© "Куда крестьяне, туда и обезьяне"
новость из разряда "офигеть",
и одновременно мотивирующая новость
продолжать изучать Rust с ещё большим интересом.
за один только dbg! я бы сказал авторам большое спасибо.
а "Использование перечислений для
хранения множества разных типов"
разрывает некоторые шаблоны.
На голой ветке
Ворон сидит одиноко.
Осенний вечер.
Простите, не удержался )
Так точнее
На бюсте Паллады
Ворон сидит одиноко.
"NEVERMORE!" — каркает.
Rust - потому что "модно, стильно, молодёжно". Бугага ))))
https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
Тоже бугага? :)
В этой статистике забавно то, что 79% нового нативного кода в Android 13 по-прежнему написаны на C/C++, при этом количество уязвимостей, связанных с memory safety, упало более чем в 2.5 раза, т.е. сильно непропорционально количеству нового растокода. Все это выглядит так, что дело не столько в расте, сколько в пересмотре/усовершенствовании практик написания C/C++ кода.
Или они просто начали внедрение с того кода, который больше подвержен уязвимостям, потому что, например, обрабатывает untrusted input. Причин много :)
Там также отмеченно, что новых уязвимостей в раст-коде не найдено. В отличие от старого и нового кода на C/C++.
А так да, они идут широким фронтом в борьбе с уязвимостями.
Пока не найдено. Учитывая, что этого нового кода сравнительно мало (особенно если брать два предыдущих года, где его ещё меньше), то очевидно, что основной бонус к уменьшению количества уязвимостей (в разы) даёт отнюдь не он.
Тем не менее с момента имплементации прошло более двух лет. Так-что когда найдут тогда и говорите. А пока факты в пользу Rust.
Факт тут такой: в новом коде, доля C/C++ в котором составляет в зависимости от года от 80% до 95%, количество проблем, связанных с памятью, уменьшилось в 2.5 раза. А вы с упорством фанатика пытаетесь каким-то непонятным образом примотать к этому раст. Ну-ну. По факту рулят практики, а не языки, как всегда было и всегда будет. Тот же log4shell появился в коде на вполне себе "безопасном" по терминологии всяких трепачей языке.
А ещё там написано
To date, there have been zero memory safety vulnerabilities discovered in Android's Rust code.
Неплохо так для 1.5 млн строк кода?
MS, как всегда, однажды сделав нечто годное и перспективное, затем бросает это и начинает пилить новое - лишь бы регулярно менять парадигмы.
Они еще в 90-х добавили в свой VC++ немало Microsoft Extensions, многие из которых удобны именно для кода ядра. Казалось бы, сам бог велел развивать собственный компилятор в первую очередь для своих же нужд - как в плане возможностей языка, так и в плане генерируемого кода. Они могли бы добавить в язык атрибуты, упрощающие контроль и за выделением/освобождением памяти, и за использованием объектов на разных уровнях приоритета, чтобы не ловить это исключительно через Driver Verifier в процессе выполнения. Могли бы, вдобавок к примитивным средствам RTC, добавить и другие проверки, которые автоматически действовали бы на весь код.
Нет, вместо этого они предпочли писать и отлаживать весь системный код на C/C++ примитивными дедовскими методами, а теперь убедили себя, что нет ничего лучше, как переписать его на Rust.
Если бы они продолжили развивать свой VC++, то в конечном итоге он отошёл бы от общепринятого настолько, что пришлось бы под него учить программистов задорого. А программистам это тоже не выгодно, так как вне Microsoft это нафиг никому не сдалось
Одно из главных преимуществ у популярных и стандартных штук — именно их популярность и стандартность. Хотя майкрософт конечно очень любит сначала делать нестандартно, а потом делать всем этим мозги...но тут видимо стратерия EEE слишком сильно ударила бы в обратку
Ну свои собственные диалекты C++/CLI и C++/CX с нестандартным синтаксисом они тем не менее родили. К счастью сейчас акцент делается больше на C++/WinRT, который совместим со стандартным C++.
Когда речь идет о программировании только под определенную ОС, тем более системном - кого вообще интересует совместимость со стандартным языком?
Вы действительно полагаете, что стоимость обучения программистов каким-то второстепенным особенностям применяемых средств будет хоть сколько-нибудь заметна на фоне стоимости их обучения программированию под ядро и голое железо? :)
Если б они сделали "под себя" толковые расширения, вроде тех же проверок при выполнении, и они показали бы себя хорошо - велика вероятность, что это переняли бы и другие компиляторы, а там и до стандартизации дошло бы.
Я полагаю, что под ядро и голое железо код пишут (к счастью) не только в майкрософт. И чем меньше новый программист будет разбираться с нестандартными расширениями, тем меньше его времени оплачивается "вхолостую" :)
Да, при этом теряется выигрыш от этих нестандартных расширений, но перевесил ли бы он — вопрос открытый. В майкрософте вот посчитали, и решили что нет
Если текучка программистов под ядро находится на таком же уровне, что и под GUI, то уже совершенно не важно, сколько они там будут "разбираться с расширениями" - ядро довольно скоро превратится в полное дерьмо, и близость языка к стандарту на это нисколько не повлияет.
Почему Вы думаете, что в MS "посчитали и решили"? Я вот почти уверен, что такую идею они либо вообще не рассматривали всерьез, либо ее рассматривали не те, кто мог бы пользоваться результатами, а "идеологи", оценивающие все через призму "корпоративных ценностей".
в конечном итоге он отошёл бы от общепринятого настолько, что пришлось бы под него учить программистов задорого
Интересно, почему Apple это никогда не останавливало.
Хотел бы прокоментировать
1. "Они могли бы добавить в язык атрибуты, упрощающие контроль и за выделением/освобождением памяти, и за использованием объектов на разных уровнях приоритета, чтобы не ловить это исключительно через Driver Verifier в процессе выполнения"
и
2. "Нет, вместо этого они предпочли писать и отлаживать весь системный код на C/C++ примитивными дедовскими методами, а теперь убедили себя, что нет ничего лучше, как переписать его на Rust".
По 1: приведу один пример того, что не только могли, но и делали. Вы, наверно, никогда не сталкивались с майкрософтовским SAL (Standard Annotation Language). Этот "язык аннотаций" для C, C++ был впервые внедрён, насколько я помню, в нулевые годы - и выпускался тогда в составе DDK (Dirver Development Kit) как хороший инструмент для повышения качества third party драйверов. https://learn.microsoft.com/en-us/cpp/code-quality/understanding-sal - хотя ныне, оставаясь полезным для кода в стиле C, этот инструмент кажется мне недостаточно современным для C++ кода. Современный msvc инструментарий включает майкрософтовский статический анализатор C++ кода, синхронизованный с рекомендацими C++ Core Guidelines (и, скорее всего, некоторыми стандартными атрибутами в двойных квадратных скобках - проверю этот аспект, когда мне это будет более кстати), и, в дополнение к этому, интеграцию с анализатором clang-tidy. Visual Studio предоставляет относительно удобный UI для использования этих возможностей. VS Code поддерживает эти возможности в какой-то мере тоже (читаю сейчас блог-пост про использование clang-tidy с VS Code).
По 2: это не так, в Microsoft активно используются статические анализаторы кода и другие методы формальной верификации (выше я коснулся только отдельных примеров, как такое использование возможно при применинии msvc toolchain), вот обзорная лекция по этому вопросу (я остановил на слайде, где перечисляются такие проекты / инструменты с 2001-го по 2022-й - для верификации в основном критического кода системного уровня): https://youtu.be/GEsvGGp0jyQ?t=935. Про переписывание на Rust - это ещё один инструмент; исходная заметка, которую мы комментируем, указывает только несколько таких проектов, пока имеющих относительно маленький размах, насколько я могу судить.
Вы, наверно, никогда не сталкивались с майкрософтовским SAL
Сталкивался, конечно - он ужасен. Во-первых, такое нужно делать на уровне компилятора, а не толстой пачки макросов, в которой, подозреваю, сами разработчики очень скоро перестали ориентироваться. Во-вторых, он функционально беден - позволяет описывать только свойства параметров, но никак не помогает отслеживать взаимодействия между функциями и объектами. В ядре было бы очень полезно маркировать функции и объекты по приоритетам процессора (PASSIVE/DISPATCH/HIGH и т.п.), это помогло бы статически обнаружить немало ошибок.
в Microsoft активно используются статические анализаторы кода и другие методы формальной верификации
А почему только статические/формальные? У них в руках собственный кодогенератор, в который можно набить 100500 проверок времени выполнения, которые будут сами по себе выполняться хоть при каждой модификации объекта, хоть при любом обращении к нему, вплоть до "значение всегда должно быть кратным 4". Это же почти ничего не стоит - всего-то добавить несколько таблиц, ключей компилятора, да соответствующих прагм. Зато эффект был бы колоссальным по экономии времени на отладке.
Нет, вместо этого они предпочли писать и отлаживать весь системный код на C/C++ примитивными дедовскими методами, а теперь убедили себя, что нет ничего лучше, как переписать его на Rust.
Откуда вообще следует, что они весь системный код решили переписать на расте? Не надо тут схоластики =)
Пока что тут не особо масштабные и официально афишируемые эксперименты (в линухе кстати, та же стадия)
Почему Microsoft не применила свой C#, вместо чужого Rust?
Так помогли бы продвинуть своё родное.
Язык с GC в ядре? Вы издеваетесь?
У них был экспериментальный проект по выделению подмножества языка C# и сочинению на нем ядра новой ОС.
Что-то сомнительный какой-то проект.
Если из языка C# выделить подмножество, не требующее GC, останется язык с удобством ниже чем Си (в Си-то хотя бы макросы есть).
Тише, тише, про D не забывай. Он и в @ nogc даст фору почти всем.
Так что все возможно и для языков с GC в базе
Причём тут вообще D, если выше был комментарий про ОС на C#, и я отвечал про C#?
Если из языка C# выделить подмножество, не требующее GC, останется язык с удобством ниже чем Си (в Си-то хотя бы макросы есть).
Я про то, что это утверждение в общем случае ложно (D как контрпример), и в С#15 вполне может быть stackalloc для объектов.
Да фиг с ним, со stackalloc, структуры данных с минимумом аллокаций на C# писать — боль. Слишком много мест где чистота кода требует на 1 аллокацию больше… и это при наличии GC. Без него ещё сложнее все будет.
malloc и сырые указатели никто не отменял, где не хватает статики и стека.
Сложнее, чем реализовывать нетривиальные структуры данных на расте? Не думаю.
И зачем нам такой C#, в котором нет лямбд (требующих аллокаций) и даже параметров/полей типа IEnumerable<T> (которые хоть и могут быть реализованы структурой, но при передаче куда-либо или сохранении в переменную эта структура упакуется в кучу).
А это никуда не денется.
Чтобы не городить вавилонское столпотворение языков в одной программе/системе. в критичных участках можно и подужаться.
Зачем, например, в ядре лямбды?
Чтобы не городить вавилонское столпотворение языков
Придётся изобретать свой диалект языка. Без Object, без String, без LINQ, без BCL, но с ручным malloc/free. И зачем? Чтобы программист, привыкший писать c# код в юзерспейсе, "с лёгкостью" перешёл на ядерный диалект и натворил кучу ошибок?
Вот именно, в критичных участках можно и подужаться.
Но чем писать в таком виде весь код — лучше уж найти другой язык.
Так сейчас ещё немного низкоуровневых фич по работе с памятью к тем, что уже существуют, добавят, можно будет без GC использовать /s
вместо чужого Rust?
Extend, Embrace, Extinguish?
Поди всё банальнее. Переложим асфальт на пли... ой, перепишем с одного языка на другой, освоим бюджеты!
один из системных вызовов полностью переписан на Rust и уже есть в ядре
Windows 11. К сожалению, он не рассказал о том, какой именно из
системных вызовов имеет в виду,
почему он не рассказал ? у кого какие идеи ?
у меня идея только одна - конкретно этот сисколл злые хакеры фаззингом затрахают.
Вот был бы способ писать библиотеки по тестовым данным\текстовому описанию, как в ChatGPT/DreamCoder ...
Microsoft переписывает код ядра и некоторых библиотек Windows на языке Rust. Но зачем?