Comments 88
Гораздо полезнее будет предоставить безопасный интерфейс для оригинальной библиотеки, повторно используя её код.
Ну ну
www.reddit.com/r/rust/comments/biq864/giving_up_on_wlrootsrs
Тут еще стоит вспомнить как Tox сервер переписывали на раст и нашли ошибку в C версии.
Как говорится, it depends. Если у библиотеки упоротый API, то ей может помочь новый API. Для этого вовсе не обязательно переписывать именно на Раст — можно просто переписать, чтобы избавиться от исторических наслоений (конечно же добавив новых багов, но не в этом суть), перебрать код по косточкам, и так далее. Это приятно с точки зрения программирования, но с точки зрения инженерии в общем случае энергию лучше было бы направить написание и тестирование приложений, использующих библиотеку, чтобы найти практические проблемы. Вот если у этих практических проблем огромная история и все просто жрут кактус, тогда есть смысл задуматься о переписывании.
Правда, open source часто держится на идеалистах, которым по барабану вся эта инженерия и экономическая целесообразность, и потому «из ниоткуда» появляются библиотеки и проекты, без которых люди потом жить не могут. Особенно в случае Раста, где количество компетентных желающих на нём писать существенно больше, чем количество желающих за это платить. Творческую энергию надо куда-то направлять. Вместе со стабилизацией async/await это желание только возрастёт.
можно просто переписать, чтобы избавиться от исторических наслоенийТак не лучше ли переписать сразу на безопасном Rust чем продолжать страдать с C?
но с точки зрения инженерии в общем случае энергию лучше было бы направить написание и тестирование приложенийПо мне так проще системно перейти на то что тебя страхует чем жрать кактус. Это я про новые проекты или полные переписывания. Понятно что огромную кодовую базу C/C++ крайне сложно/мало реально/практично переписывать на что то еще.
Правда, open source часто держится на идеалистахТут можно привести альтернативную точку зрения что бизнес думает локально, только здесь и сейчас потому что завтра он закроется. В будущее он крайне редко смотрит. А здесь и сейчас это корыто как то работает.
Особенно в случае Раста, где количество компетентных желающих на нём писать существенно больше, чем количество желающих за это платитьВ этом в том числе и апологеты C/C++ не помогают кстати.
>Понятно что огромную кодовую базу C/C++ крайне сложно/мало реально/практично переписывать на что то еще.
Понятно что в общем случае это наверное реально так — но в данном конкретном вряд ли. Ну посудите сами, что такого может быть в формате .chm, чтобы его нельзя было переписать на любой вменяемый язык за осмысленное время? Я пожалуй знаю только несколько примеров, когда такое не проходит. Один из них — когда некоторые алгоритмы (шифрование, условно) просто не открыты.
Если нет низкоуровневого мухлежа с железом, жесткой экономии памяти, подсчета тактов и т.п. — переписывание обычно проходит довольно легко. В конкретно данном случае я бы даже не задумывался (при условии что потребность реальна).
Понятно что в общем случае это наверное реально так — но в данном конкретном вряд ли. Ну посудите сами, что такого может быть в формате .chm, чтобы его нельзя было переписать на любой вменяемый язык за осмысленное время? Я пожалуй знаю только несколько примеров, когда такое не проходит. Один из них — когда некоторые алгоритмы (шифрование, условно) просто не открыты.
Если нет низкоуровневого мухлежа с железом, жесткой экономии памяти, подсчета тактов и т.п. — переписывание обычно проходит довольно легко. В конкретно данном случае я бы даже не задумывался (при условии что потребность реальна).
Тут дело в другом, если переписывать библиотеку какого то ПО на Rust, значит что придется следить за всеми изменениями и вносить правки в свою версию. В случае биндингов — только за актуальностью биндингов. Кроме того в большом софте реально много кода, это просто непрактично переписывать.
Не читал статью. Просто положил в закладки, а трекер упорно показывает активность в комментах. В принципе пока мне близка Ваша позиция.
От себя могу добавить только одно — довольно молодой язык. С ещё не устоявшимся API. Боюсь, что до тех пор пока выход каждой новой версии может сможет сильно изменять двоичный результат не о каком широком практическом применении речи быть не может. Это, кстати, отчасти и является причиной того, что даже C++ не приживается во встраиваемых системах. Уж больно часто его дергают. А вот чистый C, как «кросплатформенный ассемблер» давно устоялся. И если и идут работы вокруг него, так только в части исправления откровенных косяков компиляции и оптимизации runtime библиотеки (опять же, которую во встраиваемых системах стараются использовать самым минимальным образом).
Впрочем, надо посмотреть. Только время все расставит по своим местам. Пока Rust любопытен. Пожалуй, я готов его изучать, но точно не готов писать не нем то, что уйдет в массовое производство. Пока есть сомнения. И в том, что это кто-то кроме меня сможет сопровождать, и в надежности результата в том числе. Да, последнее скорее всего напрасно, но пока оно есть — не о каком программировании для изделия речи не будет. Только «на побаловаться». Ну и скорость… Куда ж без нее. Такты наше все. Чем меньше их съем я, тем больше их останется тем кто выше.
От себя могу добавить только одно — довольно молодой язык. С ещё не устоявшимся API. Боюсь, что до тех пор пока выход каждой новой версии может сможет сильно изменять двоичный результат не о каком широком практическом применении речи быть не может. Это, кстати, отчасти и является причиной того, что даже C++ не приживается во встраиваемых системах. Уж больно часто его дергают. А вот чистый C, как «кросплатформенный ассемблер» давно устоялся. И если и идут работы вокруг него, так только в части исправления откровенных косяков компиляции и оптимизации runtime библиотеки (опять же, которую во встраиваемых системах стараются использовать самым минимальным образом).
Впрочем, надо посмотреть. Только время все расставит по своим местам. Пока Rust любопытен. Пожалуй, я готов его изучать, но точно не готов писать не нем то, что уйдет в массовое производство. Пока есть сомнения. И в том, что это кто-то кроме меня сможет сопровождать, и в надежности результата в том числе. Да, последнее скорее всего напрасно, но пока оно есть — не о каком программировании для изделия речи не будет. Только «на побаловаться». Ну и скорость… Куда ж без нее. Такты наше все. Чем меньше их съем я, тем больше их останется тем кто выше.
Не очень понятно зачем стабильное ABI для железок. Зерокостная сериализация/десериализация и без ABI делается, .so/.dll там вроде как не юзаются, а для чего еще — непонятно. Хотя вы видимо говорите про перфоманс получающегося кода, если он часто меняется то может незаметно просесть, верно?
Апишка в std устоялась, а вот в сам язык просто добавляют полезные фичи. Можно и без них обойтись. Еще по части асинхронных библиотек все очень бурно идет на данный момент (из-за только что стабилизировавшегося async/await), но пользоваться уже можно (люди еще в 2016-2017 на нестабильном в проде сидели вполне успешно). В принципе работа по части embeded вполне себе ведется сообществом, и есть no_std крейты под некоторые микроконтроллеры. Сам не занимаюсь поэтому точно сказать не могу.
В отличие от C/C++ тут можно локализировать unsafe и работать на безопасных обертках, что снижает количество потенциальных ошибок. Для меня например C и особенно C++ страшны именно количеством UB на каждом шагу.
По поводу тактов и прочего — тут также как и с C надо просто бенчмаркать, профилировать и следить за тем какой код получается, особых отличий наверное нету?
Апишка в std устоялась, а вот в сам язык просто добавляют полезные фичи. Можно и без них обойтись. Еще по части асинхронных библиотек все очень бурно идет на данный момент (из-за только что стабилизировавшегося async/await), но пользоваться уже можно (люди еще в 2016-2017 на нестабильном в проде сидели вполне успешно). В принципе работа по части embeded вполне себе ведется сообществом, и есть no_std крейты под некоторые микроконтроллеры. Сам не занимаюсь поэтому точно сказать не могу.
В отличие от C/C++ тут можно локализировать unsafe и работать на безопасных обертках, что снижает количество потенциальных ошибок. Для меня например C и особенно C++ страшны именно количеством UB на каждом шагу.
По поводу тактов и прочего — тут также как и с C надо просто бенчмаркать, профилировать и следить за тем какой код получается, особых отличий наверное нету?
Хотя вы видимо говорите про перфоманс получающегося кода, если он часто меняется то может незаметно просесть, верно?
Так точно. Завтра найдется хитрая и крайне редко возможная (и не возможная принципиально у меня) возможность переполнения, которую исправят ценой производительности и поломают все мои критичные ко времени выполнения участки. Я именно про это.
… по части асинхронных библиотек все очень бурно идет на данный момент (из-за только что стабилизировавшегося async/await)…
Я тут только в процессе. Учусь и присматриваюсь. Если честно, то я пока не понял насколько это востребовано в моем варианте. Асинхронный код, запускаемый по обработчикам прерываний на bare metall (которые по природе асинхронны) — это вкусно. Я умею такое на С, но что с этим делать на Rust я пока не представляю. Посмотрим…
… тут можно локализировать unsafe…
Но знаю… Давайте я осторожно скажу, что не уверен. Тема математического доказательства безопасности — не мой конек, но множество архитектур железа наводит на некоторые мысли о том, что не все safe действительно всегда и везде будут безопасны. Впрочем, еще раз — не мой конек. Готов принять на веру что в этой части все сильно лучше, чем кажется.
… C и особенно C++ страшны именно количеством UB на каждом шагу.
Черт его знает. Может быть это просто уже привычный кактус. И он не так колется. Или просто привык выкусывать мякоть и не попадаться на колючки.
А может и наоборот — многолетняя практика ошибок выявила все возможные места, которые могут трактоваться программистами по разному. И узаконила их. Если так, то где гарантия что с ростом популярности и количеством сторонних компиляторов любой язык не обрастет чем-то похожим?
… надо просто бенчмаркать, профилировать и следить за тем какой код получается, особых отличий наверное нету?
Ну, бенчи и профилировщики в bare metall это редкие гости. Просто в силу проблемности реализации. Это все же не прикладной код под D-Trace'ом.
А вот следить за тем какой код получается — это точно. Но тут-то как раз и ловушка. Оставлять unsafe — значить писать как на C. А зачем, если есть С? Ставить safe — разменивать скорость на безопасность, но это же можно и на C. Только там я контролирую процесс, а тут? В лучшем случае баланс сильно смещается в безопасность. Но устроит ли меня такой вариант? Больше того, для кода с safe никто не обещает гарантированного времени выполнения. Т.е. то густо, то пусто… Неприятно. Впрочем, это мои задачи. И это специфика bare metall. Для прикладного ПО, пожалуй, это все не столь критично.
Но в целом чем дальше, тем больше спор напоминает спор автомобилистов. Одни кричат, что у нас безопасность и удобство: коробка автомат, ABS, ESP, EBD, BA, на крайний случай ремни и подушки по кругу, вторые кричат что безопасность — это мастерство водителя и возможность тотального контроля поведения машины, который ни одна электронная система никогда не перехватит. По мне спор этот будет длиться еще очень и очень долго. Но рано или поздно победа так или иначе будет за автоматами. Тотальный контроль если и останется, то будет нишевым решением. Так и с языками. Останется С где-нит на самом нижнем уровне. А все, что выше планировщика — все будет на чем-то «безопасном».
Оставлять unsafe — значить писать как на C. А зачем, если есть С?Чтобы в остальных местах использовать zero-cost safe, где компилятор на стадии компиляции ловит за тебя ошибки (или сразу показывает что твоя архитектура не работает). C таких гарантий не дает просто из-за своей структуры.
Ставить safe — разменивать скорость на безопасностьНу вообще далеко не всегда. Те же массивы если обращаться к конкретному элементу — да, будет по умолчанию проверять границы, но если через итератор то этих проверок не будет. Далеко не весь safe дорогой, я бы сказал даже наоборот. Обычно если идет какой то оверхед то для этого уже конкретный тип применяется (условный Rc/Arc) и это явно видно.
Впрочем я сам наверное junior в расте, как и в системном программировании в общем.
Больше того, для кода с safe никто не обещает гарантированного времени выполненияНичем не отличается от unsafe кода. У вас либо на уровне логики все хорошо, либо вы вводите дополнительные примитивы для той же многопоточной синхронизации, что в safe что в unsafe. Просто в safe вам никто не даст забыть такой примитив.
вторые кричат что безопасность — это мастерство водителяогромное количество CVE состоящие из банальных buffer overflow довольно красноречиво говорит о том что лучше бы эти дела ловил компилятор. Особенно во всяких сложных случаях где структуры завязаны друг на друга. Условно говоря в Rust вам не страшно взять лишний раз ссылку и не бояться что вы забудете что то синхронизировать или освободить, а в C вы бы для страховки сделали лишнюю копию, или того хуже — не сделали бы и получили use after free. Просто потому что в большой программе сложнее следить за целостностью между разными частями.
В принципе Rust позволяет делать тоже что и C, поэтому C может понадобиться только в таких частных случаях как у вас например, где хочется чтобы компилятор как можно стабильнее генерировал одни и те же инструкции. Или платформа где кроме обрезанного C компилятора ничего и нету.
В прочем это обычное перечисление плюсов и минусов, каждый сам для себя выбирает. Мне например, (как начинающему «системщику») полезно когда компилятор за ручку держит, да и в целом ощущение почти как в скриптовых языках (удобно и приятно), только без пенальти по производительности (zero-cost).
Ну а по поводу железок, да, пока что в Rust экосистема не так развита под embeded (хотя есть working group под это дело), да и для конкретной платформы микроконтроллера поддержка может быть Tier3 поддержка (если вообще присутствовать). Это не значит что не получится скомпилировать под нужную архитектуру, но однозначно придется плясать на каждом шагу.
огромное количество CVE состоящие из банальных buffer overflow довольно красноречиво говорит о том что лучше бы эти дела ловил компилятор.
А такая постановка вопроса заставляет нас задуматься в другом ключе: программирование это ремесло или искусство?
Я начинал, когда оно было искусством. Как и схемотехника, и многие другие сферы. Потому умом соглашаюсь с Вашими доводами, но сердцем ругаю «серых троечников» от программирования.
Посмотрим. Технически практически во всех сферах есть область «ширпотреба» и область «hand maid'а». От пиво- и самогоноварения, через кулинарию и Hi-Fi до авиастроения. Наверное, в этом что-то есть. И, вполне возможно, что рано или поздно дойдет очередь и до программирования.
Я вижу в элитарности программирования вред. Машины на автопилоте как и умные компиляторы потенциально лучше человека справляются (и работают быстрее).
Я думаю в области программирования и так много задач/проблем чтобы фокусироваться на таких мелочах которые компилятор вполне способен сам отловить.
Тут еще интересный эффект что компилятор Rust меня по сути учит как безопасно и правильно программировать. В свое время лет в 14 я просто не осилил C++ на нормальном уровне ибо там было слишком много мудреных проблем и криптованных ошибок.
Ну и когда продакшен стоит уязвимый из-за hearthbleed который допустили вроде как опытные разработчики (да и всем миром проглядели в исходниках) становится совсем печально.
Я думаю в области программирования и так много задач/проблем чтобы фокусироваться на таких мелочах которые компилятор вполне способен сам отловить.
Тут еще интересный эффект что компилятор Rust меня по сути учит как безопасно и правильно программировать. В свое время лет в 14 я просто не осилил C++ на нормальном уровне ибо там было слишком много мудреных проблем и криптованных ошибок.
Ну и когда продакшен стоит уязвимый из-за hearthbleed который допустили вроде как опытные разработчики (да и всем миром проглядели в исходниках) становится совсем печально.
Стоит ли это понимать, как роспись в собственном бессилии? Ведь компилятор тоже не с небес спустился. Его тоже кто-то написал. И кто-то проверил. Стоит ли так безоговорочно верить ему?
А единственный компилятор, который реально безопасно программировать учит — это компилятор с ассемблера. При чем учит так, как кошмарят по поводу плавания: бросили за борт — выплывешь, значит научишься, а нет… не судьба. Безопасно писать можно только своими руками пощупав все костыли, которые только возможны. Даже С такой свободы не дает (и ответственности не налагает).
Так что по сути ситуация как сейчас. Кто-то пишет драйвера, а кто-то Web-приложения. И между ними всякие браузеры гуляют. Вот и разделение. Для низа C и Assembler. Дай бог Rust'у туда влезть, но… Без боя не прокатит — это вам не прикладников теснить, тех которые на голом C по голому железу да без malloc() не могут. Для серединки — ну тот же Rust и какой-нить Go. Тут С++ тоже повоюет, но… Я бы сказал, есть шансы его подавить… Ну а в вебе скриптовые языки. Тут без вариантов.
Тут уж Вам решать какой слой элитарным обзывать. Я, кстати, про элитарность ничего не говорил. И даже мысли не было. Мне все равно кого элитой назовут. Просто чем ниже, тем большая подготовка нужна. Там возможностей больше, но и требования выше, и ответственность серьезнее. Я это искусством называл, а не элитой. Разные понятия. Особенно в современном мире.
Мне (не?) повезло — я всегда в самом низу. В лучшем случае (контроллер) весь проект мой, в худшем (BSP, драйвера, подсистемы) сверху гора прикладников, которых не волнует медленная периферия, необходимость синхронизации данных или что-то еще. Им нужны данные в любое время или как минимум четкий сигнал об их отсутствии. Ну и не занимать процессор. А то до тактов их скриптовые языки жадные.
А безопасность Rust… Не получилось бы с ней как с небезизвестной Spectre. Сначала все прикрыли, а потом ужаснулись провалу в производительности и призадумались — а справедлива ли цена? И это тот еще вопрос. Нет по нему консенсуса.
А единственный компилятор, который реально безопасно программировать учит — это компилятор с ассемблера. При чем учит так, как кошмарят по поводу плавания: бросили за борт — выплывешь, значит научишься, а нет… не судьба. Безопасно писать можно только своими руками пощупав все костыли, которые только возможны. Даже С такой свободы не дает (и ответственности не налагает).
Так что по сути ситуация как сейчас. Кто-то пишет драйвера, а кто-то Web-приложения. И между ними всякие браузеры гуляют. Вот и разделение. Для низа C и Assembler. Дай бог Rust'у туда влезть, но… Без боя не прокатит — это вам не прикладников теснить, тех которые на голом C по голому железу да без malloc() не могут. Для серединки — ну тот же Rust и какой-нить Go. Тут С++ тоже повоюет, но… Я бы сказал, есть шансы его подавить… Ну а в вебе скриптовые языки. Тут без вариантов.
Тут уж Вам решать какой слой элитарным обзывать. Я, кстати, про элитарность ничего не говорил. И даже мысли не было. Мне все равно кого элитой назовут. Просто чем ниже, тем большая подготовка нужна. Там возможностей больше, но и требования выше, и ответственность серьезнее. Я это искусством называл, а не элитой. Разные понятия. Особенно в современном мире.
Мне (не?) повезло — я всегда в самом низу. В лучшем случае (контроллер) весь проект мой, в худшем (BSP, драйвера, подсистемы) сверху гора прикладников, которых не волнует медленная периферия, необходимость синхронизации данных или что-то еще. Им нужны данные в любое время или как минимум четкий сигнал об их отсутствии. Ну и не занимать процессор. А то до тактов их скриптовые языки жадные.
А безопасность Rust… Не получилось бы с ней как с небезизвестной Spectre. Сначала все прикрыли, а потом ужаснулись провалу в производительности и призадумались — а справедлива ли цена? И это тот еще вопрос. Нет по нему консенсуса.
UFO just landed and posted this here
Ну вот… Конечно. Только давайте все же не сравнивать эти два компилятора. Особенно по части обращения с данными. Ибо C творит с ними ровно то, что может процессор. Потому и не возражает против переполнений или чего-то похожего, и система кодогенерации у него крайне простая. А вот Rust напротив вносит некоторое количество проверок усложняя код. Да еще как мне тут рассказывают для разных случаев разные проверки. Мало того что в каждой из них потенциально проблемы, так еще возможность выбора «не той системы».
И еще момент — в силу простоты реализации компилятор С легко проверяется изучением дизассемблированоого текста. Можно ли так же на Rust'е? Понятен ли будет его ассемблерный код (особенно тому, кто ратует за него, ибо даже C сложно)? Сработает ли этот факт на повышение надежности? Мое мнение — однозначно нет.
И еще момент — в силу простоты реализации компилятор С легко проверяется изучением дизассемблированоого текста. Можно ли так же на Rust'е? Понятен ли будет его ассемблерный код (особенно тому, кто ратует за него, ибо даже C сложно)? Сработает ли этот факт на повышение надежности? Мое мнение — однозначно нет.
UFO just landed and posted this here
Мы не первый раз встречаемся с Вами в комментарих. Может стоит попытаться расставить реперные точки? Давайте сначала.
Так вот — пока Rust воевал с С++ и Go, я молчал: это не моя поляна.
Это поляна прикладников, они пусть с ней и разбираются. Меня вопрос заинтересовал исключительно после комментария Грега о том, что Rust вполне возможно появится как инструмент кодогенерации в ядре. Вот тут мне пришлось пошевелиться и посмотреть что это за «зверь неведомый», «с чем его едят» и «стоит ли его бояться»? Решать не мне, конечно, но… Пока я вижу только проблемы. Везде. От кросскомпиляции до форматов данных. Нет, это работает. Но диапазон сильно уже, чем минимально необходимый. Потому ждем. Слишком рано.
Теперь отдельно про кодегерацию и дизассемблерный листинг. Начнем с простого. Конечно, не -O0. Ну что Вы в самом деле. Базовая настройка всегда -Os. Но весь прикол в том, что включать, допустим, -O3 в подавляющем большинстве случаев приведет к замедлению, а не к ускорению. И как раз дамп это прекрасно показывает. Причины этого я напишу чуть ниже. Просто чтобы не мешать в одну кучу мух и котлет. Каждая строка моего C кода транслируется в одну-две (редко больше) ассемблерные инструкции. При чем в подавляющем большинстве случаев я знаю какие именно инструкции будут, и как повлияют настройки оптимизации на поведение компилятора. Больше того, я точно знаю что в подавляющем большинстве случаев никак не повлияют. Что бы я не поставил после -O. А в меньшинстве, как раз приходится бороться с «излишне умным» компилятором. Чаще всего путем #pragma GCC optimize («O0»)
Теперь про переполнения. Знаковые, беззнаковые — уже детали. Да, у процессора есть флаг, позволяющий данную ситуацию отловить. Т.е. если спуститься глубже, то можно это дело накрыть. И да, язык С не транслирует это выше. Переполнение и переполнение. Ну что теперь…
Казалось бы криминал-криминал. Но ведь нет. И знаете почему нет? А ровно потому, что мастер знает свой инструмент. Даже люди старой закалки, писавшие на ассемблере, практически никогда не проверяли флаг переполнения. Тому есть несколько причин. Первая — мастер, в отличие от ремесленника, не решает задачу, а проектирует систему. А в этом случае размерность типов данных выбирается такой, чтобы переполнений не возникало. Или они были строго контролируемы. Причина, вызывающая переполнение, в подавляющем большинстве случаев это недостаточная фильтрация входных данных. Так вот всегда бороться надо с причиной, а не со следствием. Вторая причина в том, что информация о случившимся переполнении на уровне процессора практически бесполезна. Хорошо, случилось переполнение. И как прикажете на него реагировать? Направлять программу по другому пути, где предусмотрены большие размеры? Падать с ошибкой? Или что? Вот потому-то и важно не садиться кодить сломя голову, а садиться и думать. О системе. О том как она будет работать и как будет себя вести в случае неадекватных входных данных. Опять же — скриптовым языкам это может быть и полезно, но всему что транслируется в машинный код информация о переполнении… Не думаю.
А вот теперь, сказав о необходимости проектирования системы и контроля входных параметров можно вернуться к дополнительным проверкам в Rust. Впрочем, я уже все сказал. Потому особо задерживаться здесь не будем. Контроль входных данных (как минимум на самом низком уровне) — однозначно ответственность автора. Только так, и никак иначе.
Теперь про дизассемблер оптимизированных плюсов. Тут я сразу отмажусь тем, что актуального состояния не знаю. Может быть. Но плюсы и более высокие языки в дизассемблере… Впрочем, Вы ж не ломаете собственный код. У Вас же есть отладочная информация. Что там может остаться непонятным? Для меня загадка. На рубеже 2000-2010 годов (эпоха shareware софта) я развлекался сломом и написанием кейгенов. Так со временем даже Delphi (не к ночи будь помянут) в дизасемблере становился понятным. А уж плюсы просто с листа читались. Но еще раз — актуальным состоянием дел я не владею. Потому верю на слово, и, если хотите, сочувствую. Мне бы без понимания того как именно работает написанный мной код было бы очень тяжело.
И напоследок. Скажите, а Вы осознанно ставите знак равенства между C и C++? Если это и родственники, то дальние. В лучшем случае двоюродные братья. По мне не очень разумно их сливать в один чан. Конечно, офисный пакет класса LibreOffice или САПР класса AutoCAD писать на С не будешь. Для этого есть плюсы. Но и у C есть своя ниша. Конечно, одну и ту же задачу можно решить разными инструментами. Но несколько негоже оперировать мечем, колоть дрова скальпелем или забивать гвозди микроскопом. Еще хуже жаловаться при этом на инструмент. Разве нет?
А теперь вернемся к началу статьи. В битве прикладных языков я занимаю позицию наблюдателя. А системная составляющая Rust вызывает у меня (и не только у меня) вполне обоснованные вопросы. И только.
И еще. Я старался максимально убрать любой сарказм и любые подколки. Если что осталось, прошу простить. Я не со злаю
Когда нацисты хватали коммунистов, я молчал: я не был коммунистом.
Когда они сажали социал-демократов, я молчал: я не был социал-демократом.
Когда они хватали членов профсоюза, я молчал: я не был членом профсоюза.
...
Так вот — пока Rust воевал с С++ и Go, я молчал: это не моя поляна.
Это поляна прикладников, они пусть с ней и разбираются. Меня вопрос заинтересовал исключительно после комментария Грега о том, что Rust вполне возможно появится как инструмент кодогенерации в ядре. Вот тут мне пришлось пошевелиться и посмотреть что это за «зверь неведомый», «с чем его едят» и «стоит ли его бояться»? Решать не мне, конечно, но… Пока я вижу только проблемы. Везде. От кросскомпиляции до форматов данных. Нет, это работает. Но диапазон сильно уже, чем минимально необходимый. Потому ждем. Слишком рано.
Теперь отдельно про кодегерацию и дизассемблерный листинг. Начнем с простого. Конечно, не -O0. Ну что Вы в самом деле. Базовая настройка всегда -Os. Но весь прикол в том, что включать, допустим, -O3 в подавляющем большинстве случаев приведет к замедлению, а не к ускорению. И как раз дамп это прекрасно показывает. Причины этого я напишу чуть ниже. Просто чтобы не мешать в одну кучу мух и котлет. Каждая строка моего C кода транслируется в одну-две (редко больше) ассемблерные инструкции. При чем в подавляющем большинстве случаев я знаю какие именно инструкции будут, и как повлияют настройки оптимизации на поведение компилятора. Больше того, я точно знаю что в подавляющем большинстве случаев никак не повлияют. Что бы я не поставил после -O. А в меньшинстве, как раз приходится бороться с «излишне умным» компилятором. Чаще всего путем #pragma GCC optimize («O0»)
Теперь про переполнения. Знаковые, беззнаковые — уже детали. Да, у процессора есть флаг, позволяющий данную ситуацию отловить. Т.е. если спуститься глубже, то можно это дело накрыть. И да, язык С не транслирует это выше. Переполнение и переполнение. Ну что теперь…
Казалось бы криминал-криминал. Но ведь нет. И знаете почему нет? А ровно потому, что мастер знает свой инструмент. Даже люди старой закалки, писавшие на ассемблере, практически никогда не проверяли флаг переполнения. Тому есть несколько причин. Первая — мастер, в отличие от ремесленника, не решает задачу, а проектирует систему. А в этом случае размерность типов данных выбирается такой, чтобы переполнений не возникало. Или они были строго контролируемы. Причина, вызывающая переполнение, в подавляющем большинстве случаев это недостаточная фильтрация входных данных. Так вот всегда бороться надо с причиной, а не со следствием. Вторая причина в том, что информация о случившимся переполнении на уровне процессора практически бесполезна. Хорошо, случилось переполнение. И как прикажете на него реагировать? Направлять программу по другому пути, где предусмотрены большие размеры? Падать с ошибкой? Или что? Вот потому-то и важно не садиться кодить сломя голову, а садиться и думать. О системе. О том как она будет работать и как будет себя вести в случае неадекватных входных данных. Опять же — скриптовым языкам это может быть и полезно, но всему что транслируется в машинный код информация о переполнении… Не думаю.
А вот теперь, сказав о необходимости проектирования системы и контроля входных параметров можно вернуться к дополнительным проверкам в Rust. Впрочем, я уже все сказал. Потому особо задерживаться здесь не будем. Контроль входных данных (как минимум на самом низком уровне) — однозначно ответственность автора. Только так, и никак иначе.
Теперь про дизассемблер оптимизированных плюсов. Тут я сразу отмажусь тем, что актуального состояния не знаю. Может быть. Но плюсы и более высокие языки в дизассемблере… Впрочем, Вы ж не ломаете собственный код. У Вас же есть отладочная информация. Что там может остаться непонятным? Для меня загадка. На рубеже 2000-2010 годов (эпоха shareware софта) я развлекался сломом и написанием кейгенов. Так со временем даже Delphi (не к ночи будь помянут) в дизасемблере становился понятным. А уж плюсы просто с листа читались. Но еще раз — актуальным состоянием дел я не владею. Потому верю на слово, и, если хотите, сочувствую. Мне бы без понимания того как именно работает написанный мной код было бы очень тяжело.
И напоследок. Скажите, а Вы осознанно ставите знак равенства между C и C++? Если это и родственники, то дальние. В лучшем случае двоюродные братья. По мне не очень разумно их сливать в один чан. Конечно, офисный пакет класса LibreOffice или САПР класса AutoCAD писать на С не будешь. Для этого есть плюсы. Но и у C есть своя ниша. Конечно, одну и ту же задачу можно решить разными инструментами. Но несколько негоже оперировать мечем, колоть дрова скальпелем или забивать гвозди микроскопом. Еще хуже жаловаться при этом на инструмент. Разве нет?
А теперь вернемся к началу статьи. В битве прикладных языков я занимаю позицию наблюдателя. А системная составляющая Rust вызывает у меня (и не только у меня) вполне обоснованные вопросы. И только.
И еще. Я старался максимально убрать любой сарказм и любые подколки. Если что осталось, прошу простить. Я не со злаю
UFO just landed and posted this here
Ядро системы формальных доказательств описывается на одной странице A5 предельно строгим и формализованным набором правила сколько занимает описание нотаций этого А5?
Как, кстати, вы к [флагу переполнения] на С обратитесь?
__builtin_add_overflow() и компания.
И функции у вас не инлайнятся...
Вот она моральная проблема. С одной стороны надо свой код показать, с другой именно то, что показать можно не очень показательно. Да и хвастовством отдает… Ладно, посмотрите драйвер и подсистема. Ну, и чуть более сложный пример и прочие драйвера рядом.
А потом скажите — много ли свободы остается для оптимизатора? И уж поверьте на слово — в контроллерах примерно так же. Рад бы показать, но все проекты коммерческие — и в открытую не лежат. Когда одна из базовых идей как раз минимизация кода (и тактов) оптимизатору остается разве что платформо-специфичные трюки проделывать. Он, собственно, именно этим и занят. На уровнях выше никакого. Не та область, где ему развернуться можно.
Как, кстати, вы к нему на С обратитесь?
Вдруг сейчас выяснится, что С тоже не подходит для системного программирования.
А вы читали то, что я выше писал? Я же четко и однозначно написал:
И да, язык С не транслирует это выше. Переполнение и переполнение. Ну что теперь…
И даже пояснил, почему это не важно от слова совсем. Разве нет?
Но раз пошли наезды на мои любимые инструменты, то могу за них постоять. Для начала «кто сам без греха пусть первым бросит камень». Что-то я навскидку не припомню языков, которые бы так умели. Опять же — причина выше обозначена. Во вторых, я не знаю реализовано ли это в Rust (не дошел), но беглый поиск приводит к этой статье. И если так, то при необходимости я легко сделаю это «как в Rust» банальной ассемблерной вставкой или даже статически линкумемой библиотечкой. В обоих случаях, кстати, может находиться и банальная заглушка ежели вдруг найдется архитектура такую функциональность не поддерживающая. А вот как будет выкручиваться на таких архитектурах Rust? Неужели переписывать ассемблерные команды математики?
Нужна ли эта функциональность в стандарте языка? Мое мнение — абсолютно не нужна. Во всяком случае в стандарте языка С точно нет.
Потому что себе я не доверяю, не доверяю тому, что буду поддерживать 100% внимательность всё время, что не напишу хрени с недосыпа, и тому подобные вещи...
Странно, мы исходим из одних и тех же предпосылок, но приходим к разным выводам. Мне кажется, что «семь раз отмерь, один отрежь» более правильный подход. Не надо писать «хрени с недосыпу». От слова совсем. Есть множество работ, даже у программиста, которые не требуют головного мозга. Достаточно спинного (читай инстинктов). Вот их с недосыпу и надо делать. Они всегда откладываются, ибо тупые и неинтересные, но когда мозг не работает — для них самое время.
Впрочем, поправьте если я ошибаюсь. Вы же больше прикладник? Или пришли в системщики из прикладников? Математические обоснования, необходимость писать во что бы то ни стало чтоб успеть к очередному дедлайну — это скорее оттуда. Я пришел из схемотехников. А там суетность всегда приводит к выпуску из устройства главной составляющей — волшебного дыма. Потому наш лозунг «Сейчас медленно спустимся с горы и, хм..., разберемся со всем стадом».
Наверное поэтому Вам важен "… мощный язык может позволить выразить требование этого контроля ...", а мне грамотно проектировать систему в целом, меньше писать и больше думать. Вообще лучший код это тот, которого нет.
Только не сочтите это за наезды или что-то такое. Мир большой. В нем место найдется любому подходу.
Потому что сравнивать раст разумнее с плюсами, ИМХО.
Вот именно поэтому меня и не покидает ощущение, что мы говорим об одном и том же, но приходим чуть ли не к диаметрально противоположным выводам.
Вы меня «валите» теми плюсовыми заморочками, которые меня или совсем не касаются, или касаются очень опосредовано. И по большому счету мне и возразить нечего — я просто с этим никогда не сталкивался.
Но я согласен с Вами. Если Rust и конкурент (с оговоркой, конечно, — в современном мире), то конкурент плюсам. Потому с ним можно поиграться, как с забавной игрушкой, но до применения в железе ему еще далеко. Впрочем, вполне себе предвидя Ваши возражения, все же напишу что и плюсов это тоже касается. С одно маленькой поправкой. Им уже далеко.
Конечно, все написанное исключительно мое субъективное мнение. Ни коим образом не претендующее на звание «единственно верного и идеологически выдержанного».
Мало того что в каждой из них потенциально проблемы, так еще возможность выбора «не той системы».Выбор системы в Rust обычно либо явный либо оптимальный. А базовые проверки в no_std можно и ручками разглядеть разок чтобы знать в дальнейшем как они под капотом выглядят. Я уже не говорю о том что есть и unsafe варианты которые дают вам тоже что и в C. Надо perfomance critical — делайте в конкретном месте unsafe. В остальных местах компилятор поможет отловить банальные но очень больные ошибки.
Потому и не возражает против переполнений или чего-то похожегоRust тоже не возражает в release режиме, а вот в дебаге он вам покажет что вы не правы.
и система кодогенерации у него крайне простаяА я то читал как там все невероятно запутано в компиляторах и его оптимизациях, наверное я не прав.
Да еще как мне тут рассказывают для разных случаев разные проверки. Мало того что в каждой из них потенциально проблемы, так еще возможность выбора «не той системы».Строго говоря с ними разобраться и «выучить» их быстрее чем разбираться со всеми UB в разных компиляторах на разных платформах C.
Понятен ли будет его ассемблерный кодА почему он должен так сильно отличаться от C?
godbolt.org/z/am8Bwf
godbolt.org/z/wp6wpu
Сработает ли этот факт на повышение надежности? Мое мнение — однозначно нет.Но компилятор ловит больше ошибок чем компиляторы C, разве это не повышает надежность?
А почему он должен так сильно отличаться от C?
godbolt.org/z/am8Bwf
godbolt.org/z/wp6wpu
А если примеры посложнее, да с safe массивами? А еще замечательный пример — реализация кольцевых буферов, где переполнение чуть ли не основная фишка. Впрочем, я уже ответил выше.
Строго говоря с ними разобраться и «выучить» их быстрее чем разбираться со всеми UB в разных компиляторах на разных платформах C.«undefined behavior» — категория стандарта языка, он не зависит от платформ и компиляторов.
Я вижу в элитарности программирования вред. Машины на автопилоте как и умные компиляторы потенциально лучше человека справляются (и работают быстрее).
Это мне напоминает известную дискуссию с Пирксом в «Ананке» Лема:
— Командор… — Хойстер говорил тихо и со странной медлительностью, будто осторожно подбирал слова. — Вы ведь ориентируетесь в ситуации, правда? Два следующих корабля того же типа, с той же системой управления сейчас находятся на линии Земля — Марс; «Арес» будет здесь через шесть недель, но «Анабис» — всего через девять дней. Не говоря уж о том, к чему нас обязывает память о погибших, мы имеем еще большие обязательства перед живыми. За эти пять часов вы, несомненно, уже обдумали все, что произошло. Я не могу заставить вас говорить, но очень прошу сообщить нам, к каким выводам вы пришли.
Пиркс почувствовал, что бледнеет. С первых же слов он понял, что хочет сказать Хойстер, и вдруг его охватило странное ощущение ночного кошмара: ожесточенное, отчаянное безмолвие, в котором он сражался с безликим противником и, убивая его, словно погибал с ним вместе. Это длилось мгновение. Он овладел собой и взглянул прямо в глаза Хойстеру.
— Понимаю, — сказал он. — Клайн и я — это два разных поколения. Когда я начинал летать, автоматика подводила гораздо чаще… Это накладывает отпечаток на все поведение человека. Думаю, что Клайн… доверял автоматам до конца.
— Клайн думал, что компьютер лучше разбирается в деле? Считал, что он сможет овладеть ситуацией?
— Может, он на это и не рассчитывал… а только думал, что если компьютер не справится, то человек тем более.
Пиркс перевел дыхание. Он все же сказал, что думал, не опорочив при этом младшего собрата, уже погибшего.
— Как по-вашему, была возможность спасти корабль?
— Не знаю. Времени было очень мало. «Ариэль» почти потерял скорость.
— Вы когда-нибудь садились в подобных условиях?
— Да. Но в маленькой ракете — и на Луне. Чем длиннее и тяжелее корабль, тем труднее восстановить равновесие при потере скорости, особенно если начинается крен.
— Клайн вас слышал?
— Не знаю. Должен был слышать.
— Он взял на себя управление?
Пиркс хотел было сказать, что все это можно узнать по лентам, но вместо этого ответил:
— Нет.
— Откуда вы знаете? — это спросил Романи.
— По контрольной табличке. Надпись «Автоматическая посадка» светилась все время. Она погасла, лишь когда корабль разбился.
— А вы не думаете, что у Клайна уже не оставалось времени? — спросил Сейн. Его обращение выглядело подчеркнутым — ведь они были на «ты». Словно бы между ними обозначилась некая дистанция… может, враждебность?
— Ситуацию можно математически промоделировать, тогда выяснится, были ли шансы, — Пиркс старался говорить конкретно и по-деловому. — Я этого знать не могу.
— Но когда крен превышает 45 градусов, равновесие уже невозможно восстановить, — настаивал Сейн. — Ведь верно?
— На моем «Кювье» это не совсем так. Можно увеличить тягу сверх установленных пределов.
— Перегрузки больше двадцатикратной могут убить.
— Могут. Но падение с высоты пяти километров не может не убить.
На том и окончилась эта краткая дискуссия. Под лампами, включенными, несмотря на дневную пору, плоско стлался табачный дым. Все курили.
Собственно, сейчас тенденция уже видна по некоторым пилотам гражданской авиации, которые не способны на ручном управлении, без помощи электроники посадить лайнер. Хотя они и должны в общем-то это уметь, для этого они там и сидят.
— Перегрузки больше двадцатикратной могут убить.
— Могут. Но падение с высоты пяти километров не может не убить.
Я бы плюсанул, если бы мог. Хороший пример, и главное в месту. Вопрос только в том смогут ли это понять. А то «все это уже было в симпсонах» воспринимается, а вот «все это уже было у Лема, Хайнлайна и многих других» как-то не очень. Да и не только среди фантастической литературы, к слову.
Вот только программист — не пилот, а компилятору нет необходимости работать в реальном времени.
В данном случае это не столь важно. Речь про позицию, так сказать, принципиального неосиляторства "ничего не хочу знать, ничего не хочу уметь, не осилил и горжусь этим, ведь компилятор все сделает лучше меня, а если нет, то это плохой компилятор" и её последствия.
Так последствия-то как раз разные.
Это зависит. Проблему с MCAS у Боинга помните? Не осилили одни (причём вовсе не в плане работы со страшными указателями), не осилили другие (не сумели отключить художества первых), в результате катастрофа и гибель людей.
Помню я проблему с MCAS. Я даже помню что проблема там не в коде была.
Но даже если представить аналогичную ситуацию, но исправимую кодом — я считаю, что с хорошим компилятором у меня останется больше свободных когнитивных ресурсов для её своевременного выявления.
Насколько я помню, в каком-то смысле как раз в коде — чрезмерное доверие к показаниям определённого датчика, когда он начинал "чудить", начинались проблемы. Всё по канонам "машина не может ошибаться".
Если рассмотреть ситуацию с точки зрения программиста MCAS — то у него не было никакой альтернативы этому самому доверию, поскольку датчик-то ему дали всего один. Ошибся тот, кто "завёл" на модуль автопилота всего 1 датчик. И это решение за него точно не компьютер принял.
Если бы я был тем программистом MCAS, я бы отказался реализовывать заведомо ненадежный алгоритм, более того — уведомил бы о происходящем компетентные органы. Одно из двух — либо программист считал, что все ОК, и одного датчика достаточно, либо он не осознавал своей ответственности за потенциальные сотни трупов и ему было пофиг. Что из этого хуже — трудно сказать.
UFO just landed and posted this here
Да, я знаю о такой точке зрения, и считаю её обоснованной, тем более что как минимум один из экипажей осилил данную проблему ещё до первого падения (правда, на его сообщение о данном происшествии особого внимания не обратили). Тем не менее, считаю, это не снимает доли ответственности с разработчиков.
не потому, что датчик или MCAS чего-то там, а потому, что плохо обученные пилоты не смогли парировать совершенно восстановимый и некритичный отказ
А можно ссылку на Ваши источники? Я плохо знаю тему и вынужден верить тому, что пишут. Но пишут-то как раз обратное. Что MCAS работает только при ручном управлении, и именно она вместо неотключаемого помощника превратилась неотключаемого врага. Бороться с автоматикой в таком случае тяжело. Все равно что пытаться широким плечом несущийся камаз остановить…
Но вернувшись к теме. Это как раз ошибка проектирования. Не спас бы ситуацию тот же ошибочно спроектированный код, но написанный на Rust. Вот и думайте где безопасность, а где ее иллюзия.
А вот для того, чтобы понять что алгоритм заведомо ненадежен, как раз и нужно отвлечься от увлекательного распихивания переменных по регистрам, и хоть немного довериться компилятору.
а если автор кода начинает чрезмерно полагаться на компилятор и пропускает логические ошибки, которые тот отловить не в состоянии?
То на менее выразительном языке он тем более ничего написать не сможет.
UFO just landed and posted this here
Можно окольными путями к очередному UML-генератору вернуться.
Значит, надо брать более выразительный язык, могущий отлавливать и логические ошибки.
Хм. Программы, пишущие программы. Роботы, проектирующие и изготавливающие других роботов.
Я прозевал новый виток эволюции, на котором люди не нужны?
UFO just landed and posted this here
Вопрос только в том откуда компилятор должен знать о том, что требуется проверять? И что будет критерием отказа датчика? И как действовать в такой ситуации? Не получится так, что описание критериев тестирования встанет более сложной задачей чем их реализация? Отменит ли прохождение теста натурные испытания (и если нет, то зачем тест)?
Мне кажется, если ответы на эти вопросы будут, то язык уже не будет таким уж принципиальным фактором. Обидно, что те области, которые казалось бы должны быть ужасно консервативны в плане контроля безопасности, вдруг демонстрируют такие откровенные даже не ошибки, а убийственные недоработки. Вот и думай, так ли хороша система в которой все ради денег.
Вот и получается, что есть целый список вопросов, на которые сознательно или нет, но забили при проектировании. Как результат неверные действия тех же пилотов. Им никто не сказал о неисправном датчике или некорректно работающей подсистеме. Как результат ее никто и не отключал, а фактически боролся с ней. И даже помолчим о том, что процедура отключения данной подсистемы совсем не тривиальна.
Мне кажется, если ответы на эти вопросы будут, то язык уже не будет таким уж принципиальным фактором. Обидно, что те области, которые казалось бы должны быть ужасно консервативны в плане контроля безопасности, вдруг демонстрируют такие откровенные даже не ошибки, а убийственные недоработки. Вот и думай, так ли хороша система в которой все ради денег.
Вот и получается, что есть целый список вопросов, на которые сознательно или нет, но забили при проектировании. Как результат неверные действия тех же пилотов. Им никто не сказал о неисправном датчике или некорректно работающей подсистеме. Как результат ее никто и не отключал, а фактически боролся с ней. И даже помолчим о том, что процедура отключения данной подсистемы совсем не тривиальна.
UFO just landed and posted this here
Вы ему скажете.
:))) То есть по факту человек должен объяснять компилятору, что именно компилятор потом должен у человека проверить. Классическая проблема «Quis custodiet ipsos custodes?» Сейчас неосилятор забывает проверить, потом будет забывать объяснить компилятору, что тому надо будет у него проверить, потом надстроят еще следующий уровень, и он будет забывать уже объяснить какому-нибудь верификатору правил для компилятора, что именно надо проверить… Замкнутый круг.
UFO just landed and posted this here
Ну, не знаю. Злые языки, например, писали, что Боинг заказывает софт индийским аутсорсерам, но та же проблема с MCAS (я сейчас говорю в техническом смысле) возникла же не из-за аутсорсеров, а из-за того, что какой-то боинговский сеньор помидор счел нормальным заказывать и принимать код, который заведомо имеет single point of failure в виде этого злополучного датчика. Ну и чем бы тут помогли спеки, если он их сам и составил в таком вот ключе?
У вас же где-то, пусть даже на бумаге, эта спека есть?
Так, а вот с этого момента стоп. Если это было в спецификации, но не реализовалось в железе — вопрос как его принимали? И пофиг кто и что там проверял — компилятор, отк, натурные тесты… Но проблема в том, что судя по публикациям в спецификации такого и не было. И вообще фактически новый самолет был выпущен под видом модификации существующей модели. С крайне сокращенной программой испытаний.
Да, это та самая ошибка проектирования системы. Когда критически важные моменты проходят мимо ТЗ, спецификаций, приемки. И никакой компилятор это исправить не может. А если это есть — по по совести пофиг на компилятор. Хоть на бейсике пишите — лишь бы требованиям спецификации соответствовало.
Разве не так?
UFO just landed and posted this here
— Кто сам без греха пусть первым бросит камень.
Если ошибка на уровне спецификации, то какой смысл в том что ее гарантированно реализовали? Да и где гарантия того, что верифицирующий компилятор не пропустит ошибки? Вы можете это гарантировать и взять на себя ответственость за последствия? Я готов отвечать за свои код. Но не за код компилятора. Будь он трижды сертифицированным.
Если ошибка на уровне спецификации, то какой смысл в том что ее гарантированно реализовали? Да и где гарантия того, что верифицирующий компилятор не пропустит ошибки? Вы можете это гарантировать и взять на себя ответственость за последствия? Я готов отвечать за свои код. Но не за код компилятора. Будь он трижды сертифицированным.
UFO just landed and posted this here
Я же писал. Я топлю исключительно за грамотное проектирование. Начиная с ТЗ, продолжая реализацией и заканчивая контролем. И топлю против перекосов во всем остальном. А компилятор в грамотно спроектированной системе вещь не главная.
Но так как я все же программист, а не менеджер, согласующий ТЗ, и не начальник отдела контроля качества, то отвечать готов за тот этап, который между ТЗ и контролем. Т.е. за реализацию. А тут как раз компилятор. И поскольку за изделие отвечать мне, а не разработчикам компилятора, то я просто обязан знать как именно работает код. А тут градация простая — если код на assembler'e знаю абсолютно. Но это уж очень специфический язык. Как острый перец. Приправой необходим, а вот как основное блюдо… Дальше C. Опять же — знаю. Любой код на С автоматом переводится на ассемблер прямо в голове. Единственное от чего я избавляюсь — так это от чисто ассемблерных заморочек (контроль стека, сохранение регистров). Дальше идут C++ и Rust. По плюсам — до определенного уровня я знаю что и как делает компилятор. И мне это не очень нравится. Уж очень не гуманно в плане памяти (расплата за универсальность). Потому я редко (читай никогда) пишу на плюсах. А навык, который не развивается со временем утрачивается. Ну и Rust… По моим ощущениям он пытается усидеть на двух стульях (как минимум — тут вон еще статья была и про веб-разработку на Rust). C unsafe он ведет себя как C, а с safe еще хуже чем плюсы.
А по итогу получается так: при наличии нормально написанного ТЗ и понятных критериев контроля качества кода мне важнее понятность C, нежели безопасность Rust. Но еще раз — у меня речь идет в основном о контроллерах и системном ПО уровня ядра. Вполне допускаю, что в мире прикладного ПО все обстоит и по другому.
Но так как я все же программист, а не менеджер, согласующий ТЗ, и не начальник отдела контроля качества, то отвечать готов за тот этап, который между ТЗ и контролем. Т.е. за реализацию. А тут как раз компилятор. И поскольку за изделие отвечать мне, а не разработчикам компилятора, то я просто обязан знать как именно работает код. А тут градация простая — если код на assembler'e знаю абсолютно. Но это уж очень специфический язык. Как острый перец. Приправой необходим, а вот как основное блюдо… Дальше C. Опять же — знаю. Любой код на С автоматом переводится на ассемблер прямо в голове. Единственное от чего я избавляюсь — так это от чисто ассемблерных заморочек (контроль стека, сохранение регистров). Дальше идут C++ и Rust. По плюсам — до определенного уровня я знаю что и как делает компилятор. И мне это не очень нравится. Уж очень не гуманно в плане памяти (расплата за универсальность). Потому я редко (читай никогда) пишу на плюсах. А навык, который не развивается со временем утрачивается. Ну и Rust… По моим ощущениям он пытается усидеть на двух стульях (как минимум — тут вон еще статья была и про веб-разработку на Rust). C unsafe он ведет себя как C, а с safe еще хуже чем плюсы.
А по итогу получается так: при наличии нормально написанного ТЗ и понятных критериев контроля качества кода мне важнее понятность C, нежели безопасность Rust. Но еще раз — у меня речь идет в основном о контроллерах и системном ПО уровня ядра. Вполне допускаю, что в мире прикладного ПО все обстоит и по другому.
UFO just landed and posted this here
А почему вы останавливаетесь на этом уровне?
А хороший вопрос. А не останавливаюсь. В разработке схемы я принимаю участие. Я ее не рисую, но без моего одобрения схема не пойдет в трассировку. Если надо то и трассировщику могу рекомендации выдать. Но это, как правило, лишнее. И даже косяки монтажа я просматриваю. Еще раз — я пришел из схемотехников. Тут мой дом родной. И разработчики очень часто со мной консультируются. А временами даже просвещать приходится. Но все же авторы схемы и платы они, а не я. Я проверящий. Микрокода в контроллерах я не видел. Вроде он там и не нужен. А вот как реально внутри устроен контроллер (какие схемотехнические решения скрываются за сокращениям ALU, VIC/NVIC и иже с ними) я себе вполне представляю. В большом ПК уже нет, но в контроллере вполне. Как следствие есть довольно внятное представление о том, как электроны в изделии бегут от плюса к минусу (а на самом деле наоборот), и как на этот бег влияет моя программа. Может быть именно поэтому и не хочется уходить на языки выше С и терять это понимание.
А что в плюсах ест память?
А просто у нас очень разные представления о «есть память». На вскидку мне тяжело даже от VMT (она же vtable). И прочих капелек, из которых собираются литры. А у меня всего ведро. Хорошо когда литров на 18, а не на 3.
О себе я не такого хорошего мнения...
Интересный способ поинтересоваться не жмет ли мне корона. На самом деле даже не знаю что и сказать по этому поводу. Короны у меня точно нет. И себе я не верю в первую очередь. Потом идут монтажники. Потом трассировщики и схемотехники. Дальше разработчики компиляторов и только затем разработчики микросхем. В принципе это пирамида сложности. Проще всего со своими ошибками, хуже всего с ошибками железа микросхем.
Это мой персональный лист вероятности ошибки (выше по тексту — вероятнее), но и сложности исправления тоже (выше по тексту — проще). Не ошибается только том, кто ничего не делает. Но свои ошибки исправляются проще.
Ошибки в компиляторах редкость. Но они редкость именно потому, что компиляторы относительно простые. Есть четкая убежденность в том, что с ростом кодовой базы будет расти и вероятность возникновения ошибки. Потому я предпочту жевать привычный кактус в виде C. Я не могу себе позволить сознательно усложнять себе жизнь увеличивая количество предпоследних по уровню сложности устранения ошибок. Да, тут вопрос опята применения, привычек, тараканов в голове — но я смотрю за тем что меня окружает и понимаю — нет, я не один такой. И на мой век такого подхода хватит.
И хорошо, если я хоть кого-нить смогу воспитать в такой же парадигме тотального контроля и понимания. В принципе у меня это получается. Неоднократно в середине «курсов повышения квалификации начинающих разработчиков» меня спрашивали — чего я на ютубчик не выложу. Я всегда отвечаю — каждый следующий оказывается более хорошим. Я вижу что именно становится непонятным и пытаюсь объяснить эти моменты проще. Не лишайте меня возможности развиваться. И приятно когда люди к тебе возвращаются и говорят — вот ты рассказывал вроде и азы, а когда коснулось именно твой рассказ физику процессов понять помог. Или ушедшие в прикладники заходят в гости и рассказываю как же я был прав, когда говорил что нельзя просто так взять и использовать сторонние библиотеки. А время на подробное их изучение, как правило, не меньше чем время на их реализацию собственными силами. Но в последнем случае ты четко знаешь себе как именно оно работает. Так что пусть не везде и не всегда, но такой подход все равно востребован.
UFO just landed and posted this here
Представляете или знаете всю принципиальную схему?
Ну что вы, в самом деле. Конечно вся схема это большой коммерческий секрет. Поэтому представляю. Довольно подробно, но естественно не абсолютно точно.
По плюсам — так меня никто не заставляет вообще их использовать. Я и не использую. Но помните Чеховскую присказку «если в начале пьесы на стене висит ружье, то оно должно выстрелить». Где гарантия того, что мой не попадет к тому, кто выстрелит? Зачем мне такие заморочки? Да, это автоматом поднимает планку сопровождения в плане наращивания фич (ибо устранение багов в обоих случаях будет требовать примерно одинаковых трудозатрат), но практически сразу гарантирует что новая фича не поломает существующий функционал. Если кто из коллег сейчас или в будущем решит переписать любой мой код на любом языке — я возражать не буду. Но вся ответственность будет на нем. Больше того я загружен работой так, что даже начальство пытается найти способы меня разгрузить. Но что-то не наблюдаю толпы желающих. И я не уверен, что здесь исключительно финансово-организационные проблемы. Ибо пытались (и пытаются) многие. Но получается у единиц. Увы, но эти единицы как правило у нас не задерживаются. Впрочем, для них это скорее хорошо. Во всяком случае у меня к ним претензий нет.
… на больших ПК всем сплошь плевать на время выполнения и лишние байты.
Да боже упаси. Я, как раз наоборот. Говорю что на больших ПК этому слишком мало внимания уделяется. Но интервью Линуса, в котором он говорит о проектировании git и отсутствии в userspace привычных ядерных граблей очень показательно. Он, если я правильно помню, сказал что отдыхал.
И да, кеши у нас тоже редкие гости. Да и их размеры на ПК как правило больше размером чем вся наша память. Честь Вам и хвала если вы этими вопросами озадачиватесь.
Я до сих пор не понимаю, как вы гарантируете, что в ваших программах нет ошибок?
Во-первых программ без ошибок не бывает. И я не идеален. Наверняка они есть. На моей памяти было два случая когда программа несколько лет верой и правдой работавшая вдруг обнаружила крайне досадный баг. Спасибо прикладникам — быстро устранил.
Но буквально пара случаев — это исключительно по причине серьезного выходного контроля изделий. Они проверяются по всем статьям — и механника, и климатика, и воздействия ЕМС, и мусор или отвал по входам и все вместе взятое. В отдельных случаях мне позволено перезапускаться с восстановлением работоспособности. Критерии последней четко прописаны. По большому счету именно четкое тестирование изделий и гарантирует в достаточной степени надежность моих программ. И это не авиация, не автомобилестроение, и даже не станкостроение… Что должно твориться там я не знаю. Думаю то же, что у нас но более жестко. Во всяком случае я на это надеюсь.
Вы ему скажете. У вас же где-то, пусть даже на бумаге, эта спека есть?Предположим, у вас есть эта спека, безошибочно составленная системным архитекторам на основе ТЗ, правильно написанного менеджером, общавшимся с клиентом, который знал что ему нужно. Допустим, спеку эту вы досконально прочли, правильно поняли и безупречно реализовали. А спека вообще ссылается на отраслевой стандарт восемьдесят-лохматого года. Казалось бы, что может пойти не так? А потом оказывается, что датчик вообще не тот (тру стори), или что он не соответствует стандарту (тру стори №2) и производитель, разумеется, не собирается это исправлять. Итого система
Хоть заверифицируйся, натур испытания никто не отменял.
Уже хотел начать возмущаться, но дочитал до конца и полностью поддерживаю. Разве что уточню что объем натурных испытаний тоже тот еще вопрос. В зависимости от критичности изделия это может быть и выборочное тестирование из партии, и приемо-сдаточные, и периодические. При чем у изделия критика может проверяться приемо-сдаточными и периодикой, а менее критичные моменты выборочным тестированием.
Впрочем, на технических ресурсах, эти чисто менеджерские (в крайне хорошем смысле этого слова) заморочки не в чести. А зря.
UFO just landed and posted this here
Что-то я сомневаюсь, что в данном случае погромисты были настолько заняты распихиванием переменных по регистрам, что не приметили слона :)
UFO just landed and posted this here
Ох, как философией запахло…
Нет, общий вывод неоспорим. Конечно все именно так.
Однако любая струна рано или поздно лопнет. Работа под постоянной нагрузкой даром не проходит. А токсичные свинцовые белила одно время были весьма популярны в качестве косметического средства. Да и в состав красок они входили.
К чему я? Да к тому, что каждый технологический или научный виток отправляет на свалку истории то, что было сделано раньше. Беда в том, что супер безопасность Rust'а не защитит от уязвимостей класса той же spectre. Вот так раз — и главный козырь оказался побит.
Однако я не буду делать выводов. Еще раз — в целом я полностью согласен. Искусство — это писать грамотно и безопасно в современном понимании этих понятий. И, конечно, не от одних только UB это зависит.
Нет, общий вывод неоспорим. Конечно все именно так.
Однако любая струна рано или поздно лопнет. Работа под постоянной нагрузкой даром не проходит. А токсичные свинцовые белила одно время были весьма популярны в качестве косметического средства. Да и в состав красок они входили.
К чему я? Да к тому, что каждый технологический или научный виток отправляет на свалку истории то, что было сделано раньше. Беда в том, что супер безопасность Rust'а не защитит от уязвимостей класса той же spectre. Вот так раз — и главный козырь оказался побит.
Однако я не буду делать выводов. Еще раз — в целом я полностью согласен. Искусство — это писать грамотно и безопасно в современном понимании этих понятий. И, конечно, не от одних только UB это зависит.
UFO just landed and posted this here
Там немного спорная история ИМХО. Автор пытался обернуть АПИ, завязанное на хендлах с временем жизни, определяемым в рантайме. Т.е. любой хендл мог сдохнуть в любой момент. Такое почти нереально натянуть на глобус лайфтаймов.
Ну а как си код справляется с этим? Приходит событие что указатель сдох? Вообщем может автору было важнее делать композитор а не выдумывать новые типы данных в раст.
Да, приходит событие, после которого надо перестать пользоваться указателем. Ничего супер-сложного.
Если не пытаться слепо следовать мантре «время жизни объекта в Rust» = «время жизни Wayland-объекта», то по идее отлично можно всё разрулить, переводя Rust-объект в неактивное состояние и транслируя событие в Rust-код, чтобы он перестал пользоваться этим объектом.
Как не переписать проект на Rust
Все просто, не нужно начинать его изучать. И желаний не появится.
Мне надо было вытащить информацию из существующих CHM-файлов, а времени разбираться в формате не было. Лень — двигатель прогресса.
Если было лень почему не распаковали штатными методами
hh.exe -decompile output_dir source.chm
И потом любым перлом парсите и преобразуете обычные html файлы в то что вам надо.
библиотеку такого объема не логичнее ли сразу на раст переписать? ~3к строк сишного кода должны транслироваться в <1k строк раста. А точек отказа в итоге будет меньше.
500 строк обёртки < 1000 строк родной реализации < 3000 оригинальной реализации.
В общем случае, как мне кажется, лучше будет сначала написать обёртку, обкатать на ней интерфейс, а потом его постепенно заменять на родную реализацию, постоянно сравнивая поведение.
500 строк обёртки < 1000 строк родной реализации < 3000 оригинальной реализации.но эти 500 строк обертки сложнее чем 1000 строк родной реализации )
В общем случае, как мне кажется, лучше будет сначала написать обёртку, обкатать на ней интерфейс, ...интерфейс новой либы может быть удобнее интерфейса обертки т.к. он не зависит от интерфейса исходной либы
… а потом его постепенно заменять на родную реализацию, постоянно сравнивая поведение.или написать несколько юнит-тестов и лабать пока не сойдется. Тем более что юнит-тесты всё равно нужны
500 строк обертки (еще не включая домашнее задание) выглядят неоправданно дорого. По сравнению с околонулевой аналогичной нагрузкой в C++/D/Crystal
Но вот, что есть генератор биндингов, это очень большой плюс — уж очень FFI бывает нетривиально.
Но вот, что есть генератор биндингов, это очень большой плюс — уж очень FFI бывает нетривиально.
Может быть я чего-то не понимаю, но действие в самом начале
не должно сработать, команда `cargo new --lib` ведь сама не пропишет members в главный Cargo.toml. Наверное имелось в виду
чтобы самому руками создать требуемую структуру в Cargo.toml.
Хотя в оригинале написано так же, как и в переводе. Нет, наверное я всё же что-то не понимаю.
$ cat Cargo.toml
[workspace]
members = ["chmlib", "chmlib-sys"]не должно сработать, команда `cargo new --lib` ведь сама не пропишет members в главный Cargo.toml. Наверное имелось в виду
$ cat > Cargo.toml
[workspace]
members = ["chmlib", "chmlib-sys"]чтобы самому руками создать требуемую структуру в Cargo.toml.
Хотя в оригинале написано так же, как и в переводе. Нет, наверное я всё же что-то не понимаю.
Действительно, Cargo сам workspace не пропишет.
Это не то, чтобы исчерпывающий список действий. Просто иллюстрация. Подразумевается, что корневой Cargo.toml будет создан вручную, а вызов cat только демонстрирует его содержимое.
Смутило как раз то, что нигде не указано что содержимое Cargo.toml надо указывать самому, только `touch Cargo.toml` для его создания, после куча других действий и после в конце `cat Cargo.toml` с выводом содержимого как будто бы оно само появилось в результате предыдущих действий. Но это само собой камень в огород Майкла Брайана, ни в коем случае не вас как переводчика.
Sign up to leave a comment.
Как не переписать проект на Rust