Комментарии 469
Может быть разработчикам Rust стоит написать свою ОС со своим ядром, чтобы был proof о пригодности языка к таким задачам? А то выглядит хождением в чужой монастырь.
Btw, я сам из тех кто C не осилил :) Меня хватает на простые утилиты или чтение кода, но под что-то больше сотни строк я не готов возиться с нюансами языка и беру что-то более простое в осмыслении вроде Go. Однако, потребность в низкоуровневых языках без GC остается, Rust мне в ходе изучения не понравился -- для меня выглядел существенно сложнее C, для моих проектов его правила безопасности оверхид. Я в итоге решил свою потребность в низкоуровневых языках использованием новых C-подобных языков с ручным управлением памятью, прошел по цепочке изучения Nim -> Zig -> Hare. И пока последний всем устраивает: незамысловато и непротиворечиво, при этом все возможности C в наличии. Автор языка кстати пишет свою учебную ОС на Hare, как раз подходит для доказательства, что язык пригоден для таких задач. Я не продвигаю Hare, но имхо, если в этом направлении двигаться, то можно и в огромных проектах как ядро Linux переходить на новые основанные на C языки -- не сильно меняющие подходы, но устраняющие часть проблем исходного C. Если же радикально новое предлагать, как Rust, требующий перестраивать логику кода для правил владения памятью по его правилам, то оно так и будет встречать сильное сопротивление сложившихся сообществ больших проектов.
Так пишут же
Не знал, спасибо за ссылку. Им бы на нём или другом подобном проекте и сконцентрироваться. Тем более в Redox микроядро -- если не альтернативу C, то хотя бы замену GNU/Hurd (он кстати всё еще не умер) продемонстрировать. Вокруг ядра Linux собралось много разработчиков с действительно впечатляющим знанием языка C и для меня эти реверансы в сторону Rust выглядели как распыление сил и вероятность раздробить проект. Пусть уже пишут на том, что знают и умеют. Делайте свою новую ОС на своем языке -- если она вытеснит Linux, значит она лучше его и новые концепты работают. А все эти заявления "искренне верю, что будущее ядер — за языками, безопасными для памяти" -- какая-то абстрактная футурология.
Вот здесь есть довольно любопытный тред, почему Rust в линуксе скорее нужен, чем нет, для его же блага. Ну и людей, которые пишут на си, никто не заставляет начать писать на расте.
TL;DR, Rust вскрыл кучу проблем кода на С, на которую авторы отвечают "amdgpu работает, пишите так же".
Ну и людей, которые пишут на си, никто не заставляет начать писать на расте.
Ну их испуг тоже можно понять. Они 40 лет пишут на С89, сидя в тёплом кресле где-нибудь в Red Hat или Microsoft. А тут какие-то дети засунули что-то непонятное, написали уже на нём целый драйвер, и - о ужас - ещё и ставят под сомнение твой код.
Ладно бы под сомнение только, таких можно авторитетом и выслугой лет задавить, тут хуже - оно работает...
Так по возрастному критерию претензии к кому угодно старше 40 лет можно выставить :) Консерватизм, необучаемость, маразм и т.д. по списку. Нее, тут другая принципиальная проблема в обратную сторону -- больше похоже на синдром NIH. Приходят какие-то люди в сложившийся проект и говорят "вы работаете неправильно, но у нас есть инструмент решающий все ваши проблемы". Сорри, но доводы апологетов Rust похожи на религиозный фанатизм, этот тред не исключение, скорее подтверждение. "Уверуйте в Иисуса!" "Rust is solution" -- отлично, так идите и напишите свое ядро, тем более уже инициатива на это в виде Redox есть. Если получится лучше, через время на него переползут даже фанаты Linux, чисто из прагматизма.
"Уверуйте в Иисуса!" "Rust is solution"
Там про эту претензию тоже было
Один вопрос: зачем придумывать велосипед, если можно старый исправить?
Если ты не можешь написать безопасный код, то спешу расстроить: это не в языке проблема, а в тебе. И изобретать велосипед просто потому что ты не умеешь работать с памятью(образно) - абсурд
Так получается что никто не умеет. Как уже ниже заметили, сколько в мире существует сложных и реально используемых программ на С - у всех у них в анамнезе баги и дыры из-за ошибок работы с памятью или UB. И в линуксовом ядре тоже. Причем допускают их в том числе очень опытные разработчики, прекрасно понимающие, как надо работать с памятью - не из-за незнания, а просто из-за человеческого фактора, невнимательности. А если программист считает, что он-то уж точно всегда внимательный и никогда не делает ошибок, то из великого в нём только самомнение.
Так получается что никто не умеет.
ну так дело то не в языке, а в человеческой природе: люди допускают ошибки! Никакой новый язык это не исправит, просто ошибки уйдут на другой уровень, и их скорее всего еще сложнее будет находить и исправлять.
Уже есть куча языков как бы безопасных в разных аспектах, это не мешает человекам плодить на них код с ошибками.
Никакой новый язык это не исправит
Ну вообще-то очень даже исправит, пусть не стопроцентно, но существенно. Люди по невнимательности совершают ошибки приведения типов, неправильный порядок аргументов, и т.д. - язык с хорошей системой типов поможет отловить большое количество таких ошибок ещё на этапе компиляции. Люди делают ошибки при выделении и освобождении памяти - тут, опять же, довольно сильно может помочь тот же самый контроль заимствований, во многих случаях не позволяющий сделать откровенную дичь и написать явно некорректный код. И так далее, и так далее. И в большинстве случаев все это с нулевым оверхедом по производительности.
просто ошибки уйдут на другой уровень, и их скорее всего еще сложнее будет находить и исправлять.
Как вы себе вообще это представляете? Ну вот у меня есть язык, явно запрещающий использовать указатель на блок памяти после его освобождения. Или не дающий перепутать местами аргументы функции типов "enum цвет"и "enum форма фигуры". Как эти ошибки "перейдут на другой уровень"?
Уже есть куча языков как бы безопасных в разных аспектах, это не мешает человекам плодить на них код с ошибками.
Вы путаете логические ошибки (ошибки самого алгоритма) и ошибки при кодировании этого алгоритма. Все эти статические анализаторы, системы типов, и так далее - это про существенную понижение вероятности от ошибок второго типа, которых в реальной жизни очень и очень много, поэтому это важно.
язык с хорошей системой типов поможет
тут вы наверно заговорились, хороший язык, С++ например, позволяет программисту определять типы, которые конкретно ему нужны для его конкретной задачи, язык не может задать какую-то одну универсальную систему типов для решения любых задач (примитивные типы уже давно перечислены и мало чем отличаются между языками). Возникает вопрос: а что тут можно изобрести если уже есть язык, который это позволяет? Но вот придумали же Java и C#, которые на самом деле сокращают формальности при определении типов, (как минимум хидера писать не надо) + тот же мемори менежмент автоматический как раз. Но для некоторых задач все равно С++, а иногда и чистый С остаются незаменимыми.
Можно сделать вывод что язык все таки привязан к определенному классу задач, и значит если этот класс задач не достаточно понятен будущее языка остается под сомнением.
А вот рассказывать про то что язык вас от чего-то защищает мне кажется не очень конструктивно, потому что любая палка о двух концах как известно, но это мое сугубо субъективное мнение и не только про палку.
Система типов это не только про типы. Это считай целая научная тема. Рекомендую ознакомиться, перед тем, как.
ну можете считать, что я уже жду когда вы меня начнете знакомить, а заодно и весь Хабр.
Ссылку хоть дайте что ли.
Однажды Хабр уже знакомили с этим всем, но потом Дедфуд переехал в Техас, занялся политикой и все посты превратились в тыкву. Так что ссылок не будет.
Разве что вот тут немного осталось: https://habr.com/ru/users/PsyHaSTe/publications/articles/
Но лучше гуглить type theory и читать на английском.
мне кажется это какое то отвлечение на негодный объект, то есть перевод темы в непонятном направлении.
чем не нравится сентенция о том что
С++ например, позволяет программисту определять типы,
мне интересно узнать.
Вы тоже считаете что есть какая то универсальная система типов которая позволяет решать любые задачи?
чем не нравится сентенция о том что
С++ например, позволяет программисту определять типы
Потому что в C++ довольно плохо развитая и в целом весьма примитивная система типов, даже в сравнении с Rust, не говоря о уж о других языках.
чем не нравится сентенция о том что "С++ например, позволяет программисту определять типы", мне интересно узнать.
Если кратко - то типы не про то, что с ними делать можно (в противном случае идеальным языком был бы sloppy mode javascript, где можно даже список локальных переменных вычислять в рантайме), а про то, чего с ними делать нельзя. И вот в выражении этого "нельзя" и наблюдаются проблемы - даже банальное утверждение "у пустого optional нельзя получить value" уже невыразимо на языке С++.
в противном случае идеальным языком был бы sloppy mode javascript
то есть это разговор о поиске идеального языка. А я то думал что всем понятно, что одного идеального языка не существует:
Можно сделать вывод что язык все таки привязан к определенному классу задач ...
как минимум, соответственно нет смысла его искать, по моему.
То есть это я не удачно зашел или, скорее, попал.
Но тут не могу удержаться:
sloppy mode javascript, где можно даже список локальных переменных вычислять в рантайме
во первых, не ужели вы считаете что для javascript есть рантайм? он что компилируемый? Какие локальные переменные вы собираетесь получить после оптимизации на этапе компиляции?
потом, вы сначала говорили про типы, и вдруг переключились на переменные, разве нет разницы между типами и переменными?
если что, в языке Perl который вроде как ровестник С-ей тоже можно получить список локальных и любых переменных, но он точно не компилируемый был.
во первых, не ужели вы считаете что для javascript есть рантайм?
У слова "рантайм" несколько значений. Это может быть и "момент выполнения", и "среда выполнения", и даже "библиотека времени выполнения".
он что компилируемый
Ну вообще-то вполне может быть. В разных реализациях он может быть как чисто интерпретируемый, так и AOT нативной компиляцией, так и JIT (и ниетпретауия, и нативная компиляция горячих частей).
во первых, не ужели вы считаете что для javascript есть рантайм?
Не понял вопроса. Куда он, по-вашему, делся-то?
Какие локальные переменные вы собираетесь получить после оптимизации на этапе компиляции?
Вопрос странный, оптимизация не может влиять на поведение.
Вообще говоря в С или в С++ вы тоже можете посмотреть все локальные переменные и сделать с ними что вам нужно, но только в Дебаге. Если вы не в курсе. Я достаточно часто этим пользуюсь, например.
Только я вот, хоть убейте, не понимаю что, по вашему, должна доказать это возможность относительно языка программирования, если даже мы оставим наши разногласия по определениям терминов.
занялся политикой и все посты превратились в тыкву
А за что его?
занялся политикой и все посты превратились в тыкву
Он, вроде, сам попросил администрацию удалить аккаунт.
Кстати, некоторые посты остались на его сайте
Все посты (часть нерелевантна вашему комменту) с комментариями (в пяти самых старых, чтобы посмотреть комментарии, не нужен отдельный URL, достаточно долистать)
В США по L-1: от первых собеседований до гринкарты
В США по L-1: от первых собеседований до гринкарты (комменты)
Следуй за денотацией (комменты)
Разбираемся в рекурсии (комменты)
Радости и горести побед над C: делаем конфетку из прототипа wc на хаскеле
Радости и горести побед над C: делаем конфетку из прототипа wc на хаскеле (комменты)
Побеждая C двадцатью строками Haskell: пишем свой wc
Побеждая C двадцатью строками Haskell: пишем свой wc (комменты)
Стрелочка поворачивается: поговорим об обобщениях, или зачем программисту математика
Стрелочка поворачивается: поговорим об обобщениях, или зачем программисту математика (комменты)
Быстрее, чем C++; медленнее, чем PHP
Быстрее, чем C++; медленнее, чем PHP (комменты)
Зачем избегать друзей, или как я растерял все свои плюсы
Зачем избегать друзей, или как я растерял все свои плюсы (комменты)
Can I haz? Ударим программированием на типах по дженерикам
Can I haz? Ударим программированием на типах по дженерикам (комменты)
Can I haz? Рассматриваем ФП-паттерн Has
Can I haz? Рассматриваем ФП-паттерн Has (комменты)
О новых стандартах C++ (комменты)
Как развернуть односвязный список на собеседовании
Как развернуть односвязный список на собеседовании (комменты)
Статически безопасная динамическая типизация à la Python
Статически безопасная динамическая типизация à la Python (комменты)
Этот ваш хаскель (не) только для факториалов и годен
Этот ваш хаскель (не) только для факториалов и годен (комменты)
Как сделать ещё больше некорректных состояний ещё более невыразимыми
Как сделать ещё больше некорректных состояний ещё более невыразимыми (комменты)
Передаем указатели на функции-члены в C API
Передаем указатели на функции-члены в C API (комменты)
Аналитическое вычисление производных на шаблонах C++
Аналитическое вычисление производных на шаблонах C++ (комменты)
Простой инлайн-визитор для boost::variant
СС: @rukhi7
да-тут-вот уже в следующем коменте написано:
Система типов это ... набор правил
то есть под системой типов имелась ввиду не система типов, а набор правил по контролю, преобразованию, приведению, ... типов. Мне этого вполне достаточно что бы понять о чем на самом деле речь.
И еще сразу понятно что разговаривать не о чем, так как подмена понятий происходит уже на уровне названий и это ни кого не беспокоит.
а набор правил по контролю, преобразованию, приведению, ... типов.
Так именно это и есть "система типов". Это общепринятое определение в computer science, даже словарное.
так как подмена понятий происходит уже на уровне названий
Не происходит же. Если вы для себя выдумали какие-то свои определения, которые расходятся с общепринятыми, то это ваша проблема. Sad but true.
Если вы для себя выдумали какие-то свои определения, которые расходятся с общепринятыми, то это ваша проблема.
я ничего не выдумал я интерпретирую смысл словосочетания в соответствии с правилами русского языка. Я не обязан знать ту книжку или сайт по которым вы сейчас работаете. Я не занимаюсь разработкой или тестированием компиляторов в данный момент, поэтому я не обязан идентифицировать значения ваших терминов в соответствии с какими либо правилами кроме правил русского языка.
Во-первых, вы инженер или кто? И если инженер, то какого хрена кичитесь своим незнанием вместо того, чтобы пойти и узнать?
Во-вторых, определение системы типов полностью согласовано со всеми правилами русского языка. Что такое "система"? Это форма организации чего-то. Значит, система типов - форма организации типов. Как можно организовать типы в языке программирования? Ну, для начала вообще выяснить что такое тип в данном ЯП (отсюда и набор правил назначения типов термам). Потом надо классифицировать сами типы.
если инженер, то какого хрена кичитесь своим незнанием вместо того, чтобы пойти и узнать?
ну у меня действительно до сих пор не было необходимости вникать, что понимают под системой типов. Но я не согласен что это надо определять словом "кичитесь", я бы сказал я этого не стесняюсь.
Я например одно время плотно работал с кодом написанным по COM спецификации не зная про эту спецификацию или не совсем осозновая ее положения, при этом ко мне очередь стояла проконсультироваться по выбору-применению правильных интерфейсов в коде на практике. Очень благодарен одному, тоже кстати недовольному, читателю моей статьи что подсказал мне где прочитать теорию.
Но в отличие от вас я не пропагандирую это свое не знание, как вы это делаете здесь например:
Почему вы на Си остановились? Почему бы ещё ассемблер не выучить, а потом не научиться писать в машинных кодах, и нам закуску коснуться разработки железа? А потом обнаружить, что в фронтенде это всё не помогает вообще никак.
Хотя я тоже не считаю что ассемблер надо прям учить, но знать основы машинных языков точно никому не помешает на мой взгляд, просто потому что это действительно основы всего программирования.
Мне ваши коментарии такого рода напоминают классику:
Зачем изучать географию? Есть же извозчики - довезут куда надо.
ну у меня действительно до сих пор не было необходимости вникать, что понимают под системой типов. Но я не согласен что это надо определять словом "кичитесь", я бы сказал я этого не стесняюсь.
Вы не в прошлом кичились, а кичитесь незнанием прямо сейчас, доказывая всем в комментариях что не знать про системы типов - нормально вместо того, чтобы прочитать про них самому.
Но в отличие от вас я не пропагандирую это свое не знание, как вы это делаете здесь например [...]
А где я писал про своё незнание? Я как раз пишу про те вещи, которые сам знаю. И я именно потому уверен в их бесполезности, что мне самому они не пригодились.
Я как раз пишу про те вещи, которые сам знаю. И я именно потому уверен в их бесполезности, что мне самому они не пригодились.
Так я не знал только название! А то что, как я теперь выяснил, имеется ввиду под этим названием я прекрасно знаю, и так же уверен в бесполезности (ну если вы не разработчик компиляторов конечно!) этого чего-то, что очень трудно определенно сформулировать, судя по количеству приведенных ссылок, и замечания о том что это что-то превратилось в тыкву.
Но вы похоже думаете, что только вам позволено быть увереным в бесполезности чего-то. Извините что помешал вам пребывать в этой уверенности.
и так же уверен в бесполезности
Огорчу вас своим контрпримером. Я вот не разраб компилятора (да и вообще не разраб, ассемблера ведь не знаю), но мне теория типов помогает в разработке каждый день, не даёт писать глупости и работать с данными неправильно.
Хотите сказать, что типы-суммы нужны только разработчикам компиляторов? Видимо, я на прошлой неделе писал компилятор.
Или нетривиальные типы высших порядков? Эти вообще могли бы упростить любой CRUD, если правильно применить их.
А те же зависимые типы могли бы совершить революцию в DDD, если бы существовали в императивных языках.
Вы со всем этим тоже встречались, только слов не знали? Вот не верю...
и что интересно, - таки да. Извозчик - он же драйвер - довезет ваше сообщение например до принтера, и вам совершенно не надо при этом быть специалистом в области переноса изображения на бумагу.
Система типов это не сколько набор стандартных примитивных типов и не возможность объявлять новые не-примитивные, а скорее набор правил - см. Система типов — Википедия (wikipedia.org), Типобезопасность — Википедия (wikipedia.org), Зависимые типы — будущее языков программирования / Хабр (habr.com) , Магическая система типов Rust / Хабр (habr.com)
Хидеры и в C++ писать не надо. И на C++ достаточно приятно писать и высокоуровневый код, умные указатели менеджат что надо.
у меня есть язык, явно запрещающий использовать указатель на блок памяти после его освобождения.
Что значит "запрещает" и что значит "после"?
На этапе компиляции, на этапе выполнения?
Если в рантайме, то смысла вообще ноль. Он и так "запрещает".
А если на этапе компиляции, то что? Не скомпилится программа? Допустим, даже у вас умный компилятор который может пройти по всем условиям. А если порядок вызова определен в области недоступной компилитору? Я вполне могу понять нежеление колупаться с языком в котором есть такие "дурные" ограничения.
Официант, ваш дурной компилятор не даёт мне совершать глупые ошибки! Замените его быстро! Race condition, double free, de-referencing a NULL pointer - мне всё это просто необходимо, не могу писать код без этого!
Что значит "запрещает"
Это значит что содержащая проблему программа не компилируется.
Что значит "после"
Обратитесь к толковому словарю, пожалуйста.
Если в рантайме, то смысла вообще ноль. Он и так "запрещает".
Если бы в рантайме и правда оно "запрещалось" (в виде исключения, паники или там сигнала) - было бы полбеды. Так ведь нет, вместо этого случается повреждение кучи, приводящее к вылету в совершенно другом месте. Или вовсе к дыре в безопасности.
Так я вас не про значение слова "после" спрашиваю, а прошу уточнить критерии как именно компилятор определяет последовательность.
Вполне конкретный вопрос. Я бы мог поискать ответ сам, но судя по вашему тону вы разбираетесь гораздо лучше меня и могли бы снизойти до одолжения и ответить.
Если бы в рантайме и правда оно "запрещалось"
segmentation fault это разве не оно?
segmentation fault это разве не оно?
Нет никакой гарантии что segmentation fault возникнет, как и никакой гарантии что в возникшем segmentation fault "виноват" тот код, который исполнялся в этот момент.
Так я вас не про значение слова "после" спрашиваю, а прошу уточнить критерии как именно компилятор определяет последовательность.
Проще почитать учебник по Rust чем вылавливать крупицы знаний на 10м уровне вложенности дерева комментариев. Хотя ниже вам самое основное уже написали.
Можно потратить немного времени, и разобраться, что вообще компилятор гарантирует, а что нет. Это не так уж сложно. Даже я, ненастоящий программист, который ассемблера в жизни не нюхал, немного понял.
Что значит "запрещает" и что значит "после"?
// Мне надо значение, не ссылка
fn im_comsume_data(s: String) {
println!("{}", s);
}
// Мне достаточно ссылки
fn im_just_looking(s: &String) {
println!("{}", s);
}
fn main() {
let s = String::from("Hello"); // Вот у нас значение в куче
im_comsume_data(s); // Тут мы его передаём с концами в функцию
im_just_looking(&s); // Упс, тут наше значение уже не принадледит нам, новый хозяин - im_comsume_data
// ^-- тут ошибка компиляции
}
После завершения функции im_comsume_data, значение, которое мы туда передали исчезнет автоматом. Таким образом, если мы уж передаём именно значение, а не ссылку, то не можем дальше его использовать, потому что хз что с ним могла сделать функция im_comsume_data - после передачи в неё значения она стала его хозяином.
Если же нам не надо прям значение, а мы просто хотим ссылку, то всё ок:
fn main() {
let s = String::from("Hello"); // Вот у нас значение в куче
im_just_looking(&s);
im_just_looking(&s); // Берём ещё раз ссылку, всё норм
im_just_looking(&s); // Берём ещё раз ссылку, всё норм
}Но если нам надо уметь мутировать значение по ссылке, то можно иметь только 1 мутабельную ссылку в момент времени. Тут лень расписывать, есть куча статей, видосов и комментов на хабре про это.
Вот и всё, это и есть весь основной прикол раста.
После завершения функции
im_comsume_data, значение, которое мы туда передали исчезнет автоматом
Это разве какая-то уникальная фича? О_о
Но если нам надо уметь мутировать значение по ссылке, то можно иметь только 1 мутабельную ссылку в момент времени
А вот это прикольно, потокобезопасность искаропки. Хотя лично для меня это не причина переходить на новый язык.
Это разве какая-то уникальная фича? О_о
Нет, это просто raii, много где есть. Но тут фича в том, что компилятор проверяет доступность ресурса далее по коду. Если используем то, что уже вышло из текущей области - бьёт по рукам.
Это разве какая-то уникальная фича? О_о
Да. Есть много языков, где значение исчезает в рантайме - но Rust едва ли не единственный популярный язык, в котором значение исчезает статически.
В таких примерах ошибок с выделением памяти делать не будут. В реальных программах эти строчки не стоят друг за другом. И даже в пределах одной функции в зависимости от контекста часть из них может быть не выполнена или выполнена в неправильном порядке.
Ну и для данного примера не сложно написать анализатор кода который бы делал тоже самое.
На то это и пример. В реальности всё это выглядит несколько сложнее и очень неочевидно - сложные взаимосвязи данных, что-то в замыканиях, что-то в цепочках методов. И хрен пойми с первого взгляда, где ошибка (не логическая, а именно ошибка с памятью). Но в расте ты об этом узнаешь от компилятора сразу, а не по segfault.
А статические анализаторы надо прикручивать сверху. Вот сколько процентов проектов на C их используют? А в расте могу сказать, что в 100% проектов есть встроенная проверка от race-condition или null-deref, например.
Да, можно обойти эти проверки, но надо стараться сломать программу.
И даже в пределах одной функции в зависимости от контекста часть из них может быть не выполнена или выполнена в неправильном порядке.
Borrow-checker чудес не делает, по веткам и функциям не ходит, он достаточно прост. Вообще, если бы вы время, которое тратите на спор и измышлений "как там всё работает" по вашему мнению, реально почитали бы 1 статью по расту, вам стало гораздо понятнее о чём я говорю.
Вот сколько процентов проектов на C их используют?
Ну там где надо, там используют.
Более того, их много и используют разные в соответствии с требованиями.
И это проблема не языка. И не факт, что вообще проблема.
Вообще, если бы вы время, которое тратите на спор и измышлений "как там всё работает" по вашему мнению, реально почитали бы 1 статью по расту, вам стало гораздо понятнее о чём я говорю.
Поставлю задачу в очередь. ) Думаю, всё же, это больше 5 минут займёт.
Вот интересно, как себя поведёт компилятор, если эти вызовы обернуть в IF?
А как это работает? Вопрос не риторический.
Если это опечатка уровня - не проверил исключительные ситуации или забыл освободить память, то это решается или в виде функции обёртки и/или анализатором кода.
В каких-нибудь трмозах автомобиля вообще (по крайней мере раньше) нельзя было использовать динамическую память, рекурсию и т.п. И никакой специальный язык для этого не создавали.
Ведь никакой раст не сделает память бесконечной.
Если человек перестанет об этом задумываться ошибки просто поднимутся выше на алгоритмический уровень. А писать что-то в ядро линукс не понимая устройства памяти и ядра, это сомнительное решение. Это всё же не джейсоны в базу складывать.
Все таки надо RTFM. Rust построен на определённой старой научной теории, забыл то-ли линейное то ли последовательное программирование. В общем ряд ошибок на этапе компиляции отлавливает. Но у всего есть цена.
Изучение раст ради пары комментариев я вижу избыточным. Но пару моментов хотелось бы прояснить.
Я так понимаю, цена этого, это радикальное иземенение вообще подхода к программированию и алгоритмам.
При этом смешанное программирование только усложняется. Будет ли обеспечиваться безопасность памяти если из программы на раст будут вызываться функции написанные на сях, которые делают все эти ужасные вещи с памятью?
Собственно конечный вопрос который я для себя хочу прояснить, это то, чего такого делает раст, чего нельзя сделать на "си + внешний анализатор кода". Потому, что если последовательность можно определить по исходному коду, то это же сможет сделать анализатор кода си.
Я так понимаю, цена этого, это радикальное иземенение вообще подхода к программированию и алгоритмам.
Не особо. Пишу сейчас много прикладного на расте. По сравнению с другими ЯП, типа шарпов или typescript код не сильно уж отличается. Конечно, там другой подход к ООП, но это не специфика раста, а просто один из путей. То есть, лично у меня мало чисто-растового-кода, т.е. который не встречается в других ЯП в связи с растовой моделью памяти. Но иногда всплывает. А когда решаешь в итоге свою проблему, то понимаешь, что да, это ты что-то странное хотел, а не компилятор дурной. Но это не значит, что там вообще всё так же, есть свои приколы с временем жизни, например, если хочешь использовать ссылки в типах.
чего такого делает раст, чего нельзя сделать на
Ничего. Всё в итоге в машкоды приходит. Но раст (лично для меня) просто очень хорошо спроектированный язык, на котором приятно писать без глупых ошибок. Часть ошибок вообще отсутствует как класс.
Там одна вещь дополняет другую. Например, там нет null, но развитая система типов позволяет выражать свои намерения другими инструментами (Result/Option-типы), использовать продвинутый паттерн-матчинг, расширять типы своими методами, и т.д. Там нет перегрузки функций, или рефлексии, но нормальные гигиенические макросы позволяют избавиться от бойлерплейтов, и при этом ловить ошибки в них на этапе компиляции. Простой синтаксический сахар (? и await) для наиболее частых паттернов тоже позволяет писать лаконичный код, не теряя в безопасности.
В программах на сях много привязанного именно к сишной специфике работы с указателями и памятью. Я много занимался эмбедом, там надо переписывать 99% чтобы соответствовало вышеописанному подходу. И немного лазил в сетевой стек ядра линукс, там тоже сравнимо.
Т.е. условно, можно писать на C как на JS/typescript но нельзя писать на JS/Typescript как на C.
Изучить Раст стоит хотя бы ради профессии, надо понимать в ней всё.
Ответ на 1й вопрос отрицательный.
Ответ на конечный вопрос - анализ слишком сложный и математически нерешаем в общем случае, потому в Расте ограничили юзеров линейной логикой программирования.
Будет ли обеспечиваться безопасность памяти если из программы на раст будут вызываться функции написанные на сях, которые делают все эти ужасные вещи с памятью?
Да, будет, если сишную часть писал тот самый мифический сверхчеловек, никогда не допускающий ошибок при работе с памятью - и он же составлял интеропную часть кода на Rust.
На линейной логике Rust построен. Линейное программирование - это всё-таки "немного" другое.
Верно. Но по доброй воле в эту субструктурную систему аффинных квантовых преобразований типов я добровольно больше не полезу =)
а он до сих пор впадает в панику когда память не получается выделить или с этим уже что то сделали? сор не особо слежу за развитием
Обычные функции выделения памяти, вроде Box::new, конечно же, до сих пор падают в панику. Однако, есть экспериментальные Box::try_new
Ну и в ядре linux не стали ждать у моря погоды, а сделали свои функции выделения памяти.
Не совсем. Возможности человека все же конечны, а сложность программ растёт неограниченно. Потому помощь требуется обязательно.
если бы это была именно помощь вопросов бы не было, но вместо помощи часто предлагается просто набор ограничений.
Типа мы вам помогли, теперь вы не можете делать так ... , и так, и так, ...
делайте только так ....
Сообщество Rust: Мы вам помогли, теперь вы не можете стрелять себе в ногу разрывными, и вообще стрелять себе в ногу.
Насильники: Этот гадкий нарезной карабин! Ни зарядки с дула, ни камень вместо пули использовать, нужны какие-то специальные патроны правильного калибра и мощности — ужас-ужас! Предохранитель мешается, а мушка вообще внушает ужас — ее даже не спилишь нормально!
как то не очень толерантно, можно подумать что сообщество Rust вооружает не понятно кого (или понятно?), то есть кто по вашему является целевой аудиторией пользователей Rust?
После приведенного вами комментария даже название языка в переводе и без начинает играть новыми красками.
Вы бы поосторожнее с аналогиями и аллегориями, тут ведь все записывают. Как говорится все можно использовать против вас!
Вот не надо так утрировать. Так можно:
Нельзя надевать штаны двумя руками, потому что нельзя занять штаны как мутабельные больше чем одной рукой одновременно.
Кажется, такая аналогия была бы для @rukhi7 не по силам. Он в соседнем комменте буквально признался, что историю языка даже в меметичной форме усвоить не смог…
теперь вы не можете делать так
Не так. "Теперь вы можете делать так, но только если явно объявите о своих намерениях - unsafe". Например, безопасный rust не позволит собрать указатель функции, который ни на что не указывает. В сях это делается лёгким движением, удачи в дебаге!
никто не заставляет начать писать на расте.
Далее цитата из самой статьи:
если он рефакторит код и сломает программы на Rust, он не хочет идти и исправлять их, потому что он не знает языка,
Т.е. нет, буквально конфликт в том, что чтобы Раст работал в ядре, нужно чтобы и те кто разрабатывает на Си, умели исправлять код написанный на расте.
Потому что когда они рефакторят сишный код, ломается так же и код написанный на расте, который нужно исправлять.
слегка посмотрел что народ пишет на форумах, можно понять Ted Ts'O за файловую систему отвечает, которая внутри не слишком хорошо документирована, не понятно как на rust переписывать, если частями, то просто не потянуть ему, слишком много работы, imho дело не в изучении языка, скорее требуется больше ресурсов, которых нет
ps
не знаю как сейчас you tube виден, но там интересный транскрипт есть с конференции по файловой системе Linux, 9 июля 2024 - Kent Overstreet, типа найти нетрудно
почему Rust в линуксе скорее нужен
Дык написали бы для начала мешок пользовательского ПО, а потом уже (если то ПО станет популярным) лезли в ядро. Слабо GIMP на расте переписать? Слабо вместо катящегося х.з. куда GTK выкатить архиофигительную замену, на которую все радостно перейдут?
Например потому что раст скорее системный язык, чем прикладной.
Ну да, ну да, не царское это дело...
Неправда. Его зачем-то так позиционируют некоторые люди, но на прикладном уровне очень приятно писать всякое ПО - хорошая система типов, куча всяких полезных библиотек, офигенный тулинг в виде cargo, lsp, clippy и других вещей. А безопасность и отсутствие GC скорее как бонус идёт. Единственная проблема с GUI, но всё остальное прям очень хорошо. Сам пишу всякие утилиты, веб-сервисы и боты на нём.
Ну что-то пишут, я вот терминалом на расте пользуюсь из прикладного.
Дык написали бы для начала мешок пользовательского ПО
Оно итак существует, но где-то 90% это TUI. Из популярного GUI пожалуй Alacritty, WezTerm, Zed, Warp могу вспомнить
Слабо GIMP на расте переписать?
Зачем?
Слабо вместо катящегося х.з. куда GTK
Зачем заменять GTK? Да и его сами GNOME используют только из-под JavaScript, Vala и Rust, а не на C интерфейсы пишут. Плюс к тому он вне Linux работает крайне криво (да и поддержку macOS вроде не завезли до сих пор).
Сами по себе GUI-фреймворки для Rust давно существуют, штук 10 или 15. Плюс 3 вариации бриджей между Flutter и Rust.
Плюс к тому трудно отнести GTK к конкретно C ввиду GI и GObject
почему Rust в линуксе скорее нужен, чем нет
А не лучше будет, если в ядро Linux добавить C++, хоть и, может, в урезанном виде. Есть же различные стандарты, например MISRA. К тому же в новых стандартах C++ вводятся возможности для эффективной и безопасной работы с памятью. Также за годы использования написано большое количество книг, статических анализаторов, систем анализа и сборки. Преимущество C++ еще в том, что синтаксис понятен разработчикам на C - в подавляющем большинстве нужно будет NULL заменить на nullptr и void* на static_ или любой другой cast.
А не выйдет ли так, что то принятое в работу подмножество всех возможностей плюсов будет не сильно отличаться от C в плане безопасности? Да и люди будут по привычке писать C-код на плюсах.
К тому же в новых стандартах C++ вводятся возможности для эффективной и безопасной работы с памятью
И сколько проектов использует эти возможности? Поддерживает ли используемый компилятор всё это добро? Согласятся ли люди, которым не охота ковыряться в расте, ковыряться в новых стандартах плюсов, где завезли столько концепций, правил, возможностей, что скорее всего никто на планете не знает их в полной мере?
Фишка раста как раз в том, что там безопасность начинается не с какой-то версии стандарта, а прям сразу. Её можно обойти, но это надо делать сознательно. В плюсах наоборот - надо сознательно писать безопасный код, и знать как это делать, а это когнитивно сложнее.
А не лучше будет, если в ядро Linux добавить C++
Так пытались ведь, очень давно. Сам Линус Торвальдс был не в восторге. И категорически отказался разрешать добавлять что-либо написанное на C++ в ядро linux. Тем удивительнее было узнать о том, что Торвальдс сам же одобрил Rust в ядре
Эммм… Удивительно, что работая с инструментом, регулярно стреляющим тебе в ногу, он отказался переходить на инструмент, при выстреле в ногу — отстреливающий голову рикошетом, но одобрил инструмент, не позволяющий стрелять в ногу?
Не об этом там суть, есть некоторый бзик на производительности.
Ну и строго говоря, есть проблема с футпринтом, если в С++ неправильно чихнуть....
Нет. Удивительно то, что существуя в мире программирования, не было добавлено других языков системного программирования. Тот же D, Pascal, Basic, Ada (тоже дофига безопасная). Но почему-то Rust
Вокруг существующих ОС сложились свои экосистемы с кучей прикладного и системного софта. Новым ОС занять достойное место в условии такой конкуренции очень тяжело.
Учитывая то, что Linux так и не смог занять существенное место. И его дистрибутивами пользуются в основном гики, или они используются на серверах.
Линукс, с учетом андроид, самая распространенная ось, вообще-то. Раз уж мы в топике про линуксовое ядро.
Да и десктопный линукс на сегодня вполне юзабелен и распространён.
Андроид не в счёт. Там всё ядро обмазано сверху проприетарщиной гугла, и вообще не важно, что там внутри. Хоть DOS, хоть BSD.
А по поводу юзабельности. Ну браузер сёрфить можно, фильмы смотреть, музыку слушать. В игры поиграть через протон. Для домашнего использования само то, да. А как доходит до профессиональной среды, так всё, в тыкву, очень его мало, часть через wine/proton, другая часть и через него не робит, народ себе через qemu виртуалки поднимает, ради одной программы.
Справедливости ради, обмазано проприетарщиной - это один единственный модуль ядра реализующий ashmem/binder и все. Его можно собрать и запустить в стандартном ядре убунты и на этом ядре андройд будет работать. Так работает https://github.com/waydroid/waydroid, бывший anbox.
Сколько гугловского проприетарного кода в ядре андроида в процентах? Порядок, хотябы?
Сей-час тенденция к мультиплатформенному софту. Альтиум, фьюжен, солидворкс, автокад - достаточно профессиональные?
Но ведь вы привели в пример софт, который мультиплатформенен, лишь по признаку cloud базированности и доступа из web-вьюшки. И то, из перечисленного, официально такую вьюшку на linux предоставляет только altium... При том у каждого из вендоров перечисленных программ есть софт, который умеет то, что не умеют их клаудбазированные решения и доступен он только на Windows
По такому принципу, Chrome OS тоже можно считать комфортной для профессионалов, ведь это всё так же можно открыть в Chrome
Может быть разработчикам Rust стоит написать свою ОС со своим ядром, чтобы был proof о пригодности языка к таким задачам?
Стоит погуглить вам наверно. На Расте уже столько ОС, ядер, драйверов, гипервизоров, bare-metal прошивок написано на сегодняшний день, что давно никому ничего не нужно доказывать. Уже лет 5 назад язык был готов к этому. И с каждым днём становится всё удобнее.
Консервативные деды всегда тормозили прогресс. Ничего здесь нового нет. Любые долгие проекты с этим сталкивались, Линукс здесь не уникален.
С другой стороны, менять что-то 50 лет работающее на такое же, но с перламутровыми пуговицами... Начиная с некоторого возраста это уже не очень интересно.
Причём ладно бы это новое было прикольным. Но нет же, у меня от 5 минут чтения кода на расте реально слезятся глаза, как будто по ним наждачкой проехали. Взяли синтаксис в стиле С, залили сахаром, а сверху накидали колючек типа разбросанных в случайных местах восклицательных знаков и прочей mutи. Просто авторам раста так было проще написать компилятор...
дело даже не в языке, Linux живая система, типа как небоскреб с людьми на каждом этаже, используется супер широко, одно дело там крышу сменить, или новые окна поставить, а другое фундамент менять, ладно там драйверы или модули на rust, но файловая система это сложная часть, предположим временно оставить старый интерфейс + добавить новый на rust, и вот часть inodes создана через один, а часть через другой интерфейс, как все это вместе будет представить трудно, imho проще с нуля всю систему на rust написать, типа Linux-2
Да в общем то, как треды про Linux не прочитаешь, там и на Си огромное множество систем не закончены/не начаты/5 лет депрекейтед но альтернативу ещё не написали. Так что как будто бы сильно хуже не будет, где то нужно что то новое, сделали на Rust, где то нужно что то зарефакторить, переписали на Rust и т.д. И работа быстрее со временем пойдёт.
Я вот как раз не понимаю суждения - напиши свой Linux, если язык лучше, то он убьёт оригинал. Linux же не про язык Си, а про логику работы самой системы... И не важно, на каком языке эту логику пишут.
ну тут речь про конкретные реализации. Напишите на расте ОС с той же самой логикой, но с кофетками от раст, и если этот релиз будет быстрее, менее глючный, красивый вкусный и т.п., им моментально начнет пользоваться куча народу. Но это если... А если окажется, что смена языка не принесла никаких плюшек - извините.
Ну, если столько всего написано но ничего из этого ещё не мэйнстрим, то, может быть, есть ещё что доказывать. :) Пригодность языка, в широком понимании (да и любой технологии) - это способность принести business value если его внедрить.С точки зрения конечного пользователя, если он платит N дополнительных денег на внедрение но его жизнь не становится пропорционально лучше / прибыль не растёт на сумму, большую чем потратили на внедрение, то технология не нужна.
Вот поэтому мне печально видеть апологетов Раста кривящих нос на "нетехническую ерунду". Потому что Rust сейчас в той стадии, где на эту ерунду как раз и надо обращать внимание. Все уже поняли что такое borrow checker, горшочек не вари, теперь надо наконец повзрослеть и определить как прелести языка трансформируются в добавленную прибыль после внедрения и донести это знание в массы. Если Rust не способен просто существованием ядер и гипервизоров доказать что он сделает жизнь конечных пользователей лучше (или их карман - толще), то надо отправлять внедренцев к менеджменту а не ещё больше евангелистов на форумы.
Пригодность языка, в широком понимании (да и любой технологии) - это способность принести business value
Так компании которые берут деньги с конечного пользователя за ОС, как раз внедряют раст в ядро см Windows. Проблемы как раз с опенсорс проектами, ибо там все строится не на том что приносит наибольшее "business value".
Раст внедрили в винду? Есть новости? А то вроде тоже заглох проект
Ну, у меня есть определённые сомнения. Монополии вроде MS как раз дошли до такой точки когда они могут себе позволить дорогостоящие эксперименты с неясным return on investment, это как бы не первое для них родео. Если получится хорошо, то и богу слава. Если Rust к стене не прилипнет - спишут убытки а тех кого нанимали, так и сократят заодно ещё с десятком тысяч человек. Если компании надо действительно считать деньги чтобы остаться на плаву - там другая история.
Аргументы, подобные вашим, обычно закрывают глаза на издержки, и хотят плюсов, мяса и вэлью. Но есть же очевиднейшие минусы, которые почему-то принято игнорировать в подобных доводах.
Я говорю про издержки от вечной борьбы с банальнейшими use after free, UB, dangling pointers, out of bounds access, race conditions и прочего, исправление чего занимает несоизмеримо большое время, которое можно потратить на написание нового кода, а не прикручивание протезов к отстреленным ногам. А тут даётся язык, у которого из коробки нет этих врождённых пороков, бери да пиши новый код, полное взаимодействие со старыми интерфейсами и ABI. Да, нужно заплатить небольшим количеством времени, мозгами пошевелить зачерствевшими, изучить что-то новое, и понять, насколько же проще живётся в языках этого вашего 2024-го года.
PS. Давно не работал на офисных работах и командах, где нет выбора инструментов разработки, а вот недавно решил залететь и глянуть, какая она сейчас эта офисная командная работа, где пишут на дедовских технологиях. И, чёрт возьми, как снова оказался в начале нулевых! Все те же болячки, все те же вечные баги, о существовании которых я уже забыл, самостоятельно выбирая инструмент для разработки. И самое страшное, что борьба с этими проблемами является нормой, а не чем-то лишним и непродуктивным. Люди настолько привыкли, что на Си ты пишешь 20% времени, а потом отлаживаешь 80%, что даже не осознают, что это давным давно не норма.
Небольшим количеством времени - это каким, мне любопытно? :) Вы, к примеру, готовы оценить, для конкретного проекта, в монетарном эквиваленте, затраты времени и ресурсов на внедрение, переобучение, разработку тулинга, адаптацию инфраструктуры, недополученную прибыль из-за приостановки внедрения новых фич - и так далее, список длинный, вы и так понимаете - и взвесить эту оценку против, скажем, поддержки (уже существующей) пачки тестов для C++ проекта, статического анализа в пайплайне и (что в любом случае должно быть) peer review перед интеграцией где люди не будут давать друг другу коммитить код не соответствующий (в принципе уже достаточно безопасным) практикам последних стандартов, плюс покрытие некоторых (поддающихся оценке) убытков от того что в конкретном проекта продакшн упадёт и будет чиниться в среднем полтора часа в год?
Не поймите меня неправильно, я не против Раста, и не против того чтобы действительно провести такую оценку. Я лишь говорю о том, что такая оценка должна быть проведена, не все могут позволить себе выбрасывать деньги на ветер, и если конечный счёт оказывается не в пользу Rust, то в этом конкретном проекте Rust хуже чем C++. Не "хуже для горстки старпёров", а объективно хуже, потому что из-за него пользователь получает меньше и платит больше. Sad but true. Серебряных пуль нет, не существует one size fits all, существуют конкретные проекты с конкретными условиями. Плюсы должны перевешивать минусы. "Несоизмеримо большее время" и "небольшое количество времени" - я вот не готов такое отнести к людям, котрым по должности положено беспокоиться о том что, если они сделают неверный выбор, то через год паре тысяч их сотрудников придётся искать новую работу а им самим останется оформлять банкротство и идти в управдомы.
Вы, к примеру, готовы оценить, для конкретного проекта, в монетарном эквиваленте, затраты времени и ресурсов на внедрение, переобучение, разработку тулинга, адаптацию инфраструктуры, недополученную прибыль из-за приостановки внедрения новых фич - и так далее, список длинный, вы и так понимаете - и взвесить эту оценку против, скажем, поддержки (уже существующей) пачки тестов для C++ проекта, статического анализа в пайплайне и (что в любом случае должно быть) peer review перед интеграцией где люди не будут давать друг другу коммитить код не соответствующий (в принципе уже достаточно безопасным) практикам последних стандартов, плюс покрытие некоторых (поддающихся оценке) убытков от того что в конкретном проекта продакшн упадёт и будет чиниться в среднем полтора часа в год?
Вы же прекрасно понимаете что дать подобную оценку нет никакой объективной возможности, это будет пальцем в небо ± лапоть, как и в обратную сторону нельзя посчитать сколько в среднем лежит прод из-за ошибок которые бы никогда не возникли c растом.
Однажды, достаточно давно, на одном NodeJS проекте лег прод из-за стандартной javascript ошибки, без подробностей, но скажу что в Typescript такая штука невозможна а eslint и peer-review ее пропустил. Можно ли стоимость простоя записывать в дебит колонку внедрения Typescript или это просто дело случая?
Точную оценку - нет, приблизительную, достаточную для оценки рисков - почему бы нет. Реальный вопрос в вашем случае, конечно, какая была стоимость простоя и окупилось ли бы внедрение Typescript. Это всё вполне себе оценивается, особенно если проект существует уже давно и есть статистика. Конечно же стоимости простоев надо считать, тем более что для разных проектов (как раз то о чём я и говорил) они могут быть от незначительных (ну упадёт у кого-то игра время от времени, зато выкатили вовремя и получили продажи) до настолько критичных что они стоят крупных инвестиций (mission critical / safety critical например).
Реальный вопрос в вашем случае, конечно, какая была стоимость простоя и окупилось ли бы внедрение Typescript.
Время простоя и потери в деньгах посчитать действительно проще некуда. Но ведь простоя могло и не быть а могло быть и десять похожих простоев и даже как-то сводную статистику не соберешь по единичным случаям.
Вот взять к примеру случай недавний с антивирусом прилетевшим с обновлением виндовс и поставившим раком половину крупного бизнеса в США, теперь всем сишным проектам записываем конкретно эту ошибку(я уже не помню что там было, чтение памяти по неправильному адресу?)в риски? А сколько процентов шанс этого риска?
Если стоимость простоя низкая, то вы начинаете с того что есть и улучшаете процессы пока у вас не получается удовлетворительный контроль качества. Если же стоимость простоя настолько высока что несколько таких простоев потопят вашу компанию то, простите, фокусируетесь вы уже далеко не только на выборе языка.
Да, root cause у CrowdStrike был с буферами памяти. Но это несущественно, потому что, если ваш продукт способен положить половину крупного бизнеса, то вы фокусируетесь не на паническом переписывании всего на Rust, а на процессах тестирования и внедрении phased rollouts, что вы так или иначе должны были сделать давным-давно потому что существует масса возможных проблем которые Rust просто не покрывает. Логические ошибки, ошибки конфигурации, недостаточный контроль входных данных, сетевые ошибки, аппаратные, человеческие ошибки на каждом этапе... Если у вас есть риски, то вы их оцениваете, и амортизируете их наиболее эффективными методами вместо того чтобы "а вот давайте всё перепишем на X и все проблемы исчезнут". Не исчезнут.
если ваш продукт способен положить половину крупного бизнеса, то вы фокусируетесь не на паническом переписывании всего на Rust, а на процессах тестирования и внедрении phased rollouts, что вы так или иначе должны были сделать давным-давно потому что существует масса возможных проблем которые Rust просто не покрывает.
Это верно что Rust не покрывает массу проблем но одно другому не мешает. Можно довольно легко представить точно такую же ошибку того же альтернативного crowdstrike которая с легкостью прошла все стандарты тестирования и проявила себя на проде через 32768 секунд. Не нужно думать что это высосано из пальца, например у меня был SSD диск m4 crucial смешного объема в 32 гб примерно в 2011 году. У них была фишка что после наработки около тысячи часов они вываливали установленную на них систему в бсод при загрузке, все без исключения.
И вот представьте себе менеджера который хочет скалькулировать риски "в монетарном эквиваленте". Ну вот у вас на руках инцидент пусть на скромных 100 млн $. Но он всего один, за 10 лет. Какова его вероятность? Да хз, раз он случился то понятно что не нулевая. С другой стороны раз он уже случился то понятно что шансы на повторение ниже чем были изначально, мы же вписали это в свои гайдланы peer-review и добавили доп тестирование. А на соседнем проекте такого и за 20 лет не случилось. И есть еще допустим с десяток типов потенциальных ошибок которые можно искоренить с внедрением раст. Приходит к вам менеджер помладше и говорит, фигня вопрос, давай 5 млн на переписывание на расте. Так вот я утверждаю что если кто-то скажет что он может посчитать в этом конкретном примере, хотя бы окупятся ли в этом плане 5 млн или нет, я уж не говорю с точностью до сотен тысяч долларов, не прибегая к универсальному аргументу "жопой чую" то такому человеку стоит плюнуть в лицо. Он нагло врет и где-то его цифры взяты с потолка.
Проблема Вашего подхода в том, что, будучи формально корректным, он совершенно бесполезен. Тут не нужен перфекционизм в оценках рисков, тут нужен практичный подход, который вполне может опираться на цифры взятые с потолка (из субъективного опыта), но при этом будет способствовать уменьшению рисков. Да, до нуля риски обычно уменьшить невозможно, но это не повод вообще ничего не делать для их уменьшения. И да, всегда есть вероятность, что ресурсы на борьбу с рисками уйдут, но не окупятся, потому что сработает какой-то другой риск, а не те, которые мы предусмотрительно уменьшили. Финальное решение какие риски учитывать и тратить ресурсы на их минимизацию, а какие игнорировать - за бизнесом, как и последствия неверного решения по этому вопросу тоже лягут на бизнес. А наше дело - своевременно проинформировать бизнес об имеющихся рисках, вариантах что можно по этому поводу предпринять и сколько ресурсов на это потребуется.
Конкретно в ситуации с CrowdStrike @Falstaffвыше всё абсолютно правильно написал: для таких проектов крайне не рекомендуется экономить на тестировании и на постепенном выкате обновлений - потому что иначе есть очень высокая вероятность, что случится именно то, что случилось. Возможно технари не донесли эту очевидную мысль до бизнеса. Возможно донесли, но бизнес принял решение проигнорировать эту рекомендацию. В обоих ситуациях это ответственность бизнеса и последствия тоже будут на бизнесе.
Проблема Вашего подхода в том, что, будучи формально корректным, он совершенно бесполезен
Не согласен, просто по той причине что как вы определили какой у меня подход?
Уменьшать риски это нормально, нормально приходить к ЛПР и говорить вот если мы внедрим раст то мы избавляемся от такого класса ошибок которые месяц назад повалили прод. Принимать решение исходя из того что мы можем жить с существованием такого риска или готовы заплатить $N за страховку от этого риска тоже нормально.
Мы же, принимая решения застраховать себя, не рассчитываем сколько процентов составляет у нас шанс попасть в аварию. И даже сама страховая не знает с каким шансом именно ВЫ попадете в аварию. Впрочем ей этого и не нужно.
А вот что ненормально так это говорить что вероятность этого события 0.01% в день, а значит цена риска за год 0.01 * стоимость простоя * 365. Любые попытки посчитать вот этот 0.01 для конкретного проекта это заведомое очковтирательство.
Любые попытки посчитать вот этот 0.01 для конкретного проекта это заведомое очковтирательство.
Я понимаю, почему Вы так думаете. Тем не менее, бизнесу для оценки рисков эта цифра может быть необходима, надёжного способа её рассчитать у нас нет, поэтому считаем как можем. Можно называть это очковтирательством, можно экспертной оценкой. Потому что посчитать хоть "на глаз" полезнее, чем ответить "вероятность неизвестна". Потому что ЛПР на "вероятность неизвестна" практически со 100% гарантией примет решение этот риск проигнорировать. И так будет с абсолютным большинством рисков. Что причинит проекту больше вреда, нежели пользы.
Кстати говоря, были бы деньги, проверил насколько Rust подходит для безопасного оборудования, потому что пока список используемых языков для него выглядит так
Скрытый текст
Ассемблер кстати кое-где таки сделали NR из-за сложности верификации. По поводу остальных — нельзя использовать указатели, динамическую память и рекурсию
Это в Сях-то нельзя использовать указатели?.. Кажется, ограничение должно касаться только динамической памяти, а указатели можно. Иначе вообще не понятно как, к примеру, передавать переменные по ссылке.
Передавать переменные по ссылке тоже нельзя :)
Я тут порылся и нашёл кратенький список требований, если что, это далеко не всё
Скрытый текст
В основном требования к указателям такие из-за того, что это усложняет расчёты показателей надёжности.
Ну, это объясняет откуда в коде Toyota взялось 9000 глобальных переменных...
Вообще, список выглядит так, как будто язык Си нельзя допускать к безопасному оборудованию ни при каких обстоятельствах.
Это какие-то древние скрижали =) Мисру надо читать
Я бы и рад, но спрашивать с нас будут по ГОСТ Р МЭК, он же перевёдённый IEC, а там требования для ж/д оборудования именно такие. Да и не мне судить, с моим-то небольшим опытом.
И почему не MIL тогда? Меня просто забавляет, как ни заикнись про надёжность, сразу Мисрой тыкают, как будто это панацея. Представьте себе, для разного оборудования есть разные требования. Хватит уже карго-культы лепить. Я против Мисры ничего не имею, просто забавно. Примерно как при каждом удобном случае тыкать Хоровицом и Хиллом или Кнутом.
Образованность даёт такое вот преимущество - потыкать в нужный талмуд.
У меня целый набор есть из разных отраслей.
Мисра она просто распространённая и есть в открытом доступе. Важен же не сколько текст, сколько идеи, а в каком справочнике - непринципиально, да и дублируется.
Но мисра только для с/с++, для другого поискать еще
Кстати, о каком МЭК идёт речь (там циферки есть) ?
Ну те стандарты что я привёл включают в себя часть требований Мисры, однако остальные с более жёсткими требованиями, вроде тех что я привёл, и они, если что, касаются только локомотивных систем безопасности (и других, вроде атомных станций, но там требования ещё жёстче). Для некоторых уровней безопасности, кстати, нужен даже сертифицированный компилятор.
Мне кажется, всё что касается безопасного оборудования поросло мхом, но по-другому никак. Я вот как попал в эту сферу ещё будучи студентом, так и думаю, туда ли я свернул.
Кстати, о каком МЭК идёт речь (там циферки есть) ?
Да, конечно, ГОСТ Р МЭК 62279— 2016
Что это воообще было? Яндекс алиса, чат жпт или гугл перевод?
язык программирования должен обеспечивать.... проверку времени... печать времени...
язык программирования должен включать в себя... любые...
Даю любые ответы на любые вопросы
На Расте уже столько ОС, ядер,
И? Какую долю в ОС занимают написанные на Расте? в десктопах, ембеддедах, серверах, гаджетах?
>Rust мне в ходе изучения не понравился -- для меня выглядел существенно сложнее C.
Я не вижу конкретно в этом хоть каких-либо проблем. Язык должен предоставлять абстракции и возможность писать гибкий, общий код. Для этого, та самая сложность просто необходима. Я лично очень не люблю го или си как раз из-за отсутствия подобных возможностей. А будут люди изучать язык 1 вечер, или же год, вообще разницы не играет в рамках разработки для себя.
Тед Цо, который поддерживает популярную файловую систему ext4, широко используемую в дистрибутивах Linux, включая Linux Mint. Цо, который использует C, считает, что, когда он рефакторит код, который приводит к ошибкам и сбоям, он может просто пойти и исправить код на C, который ему нужен, потому что он понимает C. По словам Цо, если он рефакторит код и сломает программы на Rust, он не хочет идти и исправлять их, потому что он не знает языка
Звучит как, "мне под 60 и я не буду учить что то новое. Нас и так не плохо кормят".
На старом проекте, у нас был проект манагер, который начинал в начале 90-х на этом проекте, написанном под unix, на С + Oracle-Embedded SQL. Он в коде каждую строчку знал, ориентировался в портянках на 10-15к строк как у себя дома. В кабинете стоял шкаф, где исходники были распечатаны, с пометками от руки, что все это значит. Контроль версий прямо в коде велся, в шапках файлов несколько страниц комментариев "Баг-12123: новая функция deleteContract". Видимо так повелось в 90-е из-за отсутствия контроля версий. Кроме Си и SQL больше знать ничего не хотел. Пока не наступил момент, что уже специалистов желающих разбираться в этом месиве днем с огнем не сыщешь. Начали переписывать на java с нуля. Так он и сидел потом, хлопал глазами на совещаниях, на которых про какие то "спринги, юнит тесты, хайбернейты", прости господи, говорили.
Для него думается это была потеря контроля над проектом. Мне даже жалко его было местами.
Вы утрируете.
Про стеклянный censored напомнить?
Цо имеет аргументы:
а) то, что он делает - работает,
б) то, что предлагается - не факт, что будет работать,
в) и кто это будет сопровождать? Некто из Microsoft поднял волну за Rust, потом психанул и "я устал я мухожук". Нафига этот цирк?
Получается, что Цо просто провёл стресс-тестирование. :-) И тестируемый его успешно провалил. Будем ждать следующего кандидата на эту роль…
Во-первых: не стресс тестирование а сразу посыл куда подальше, по причине "не хочу возиться с вашими технологиями" (на что он имеет полное право, но, я думаю, требует уточнения, чтобы было понятно за что выступал Филхо и почему его развернули)
Во-вторых: стресс-тестирование людей - это впринципе плохо, потому что задевает только тех кто действительно переживает за проект, не трогая людей которым наплевать и которые там чисто ради денег, а стресс-тестирование в опенсорес - это полнейшая ересь. С таким подходом в опенсорсе останутся только бюрократы.
В-третьих: не провалил, а сделал правильное решение. Если тебе не рады и твой труд не ценят - нечего надрываться, умные люди везде нужны, но видимо не в этой кодовой базе.
Я понял, смайлика мало, надо было ещё тэг сарказм добавить.
Но в каждой шутке есть доля правды, и в этой тоже: ядро линуха это громадный, сложный и критичный проект, в котором участвует очень много заинтересованных сторон, так что давление и стресс при его разработке неизбежны. И те, кто не тянут этот стресс, конкретно в этом проекте участвовать не смогут. Шутка была в том, что Цо стресс создал специально. А правда в том, что и без специального "тестирования на стресс" его в этом проекте неизбежно будет очень много. Даже Линуса несколько лет назад задолбали и чуть было вообще не отменили.
По поводу "я устал я мухожук": если твои патчи отклоняют просто потому что они на расте (что ты и пытаешься сделать), то я не вижу причины продолжать пытаться это делать.
Код отклоняли не потому что он плохой, не потому что были сомнения что он будет работать, а просто потому что ментейнер не хотел принимать его в кодовую базу, потому что "если я зарефакторю си, я не буду лезть править Раст - я же его не знаю".
Что, в целом, валидное замечание - в опенсорсе последнее слово всегда за мэнтейнером. Но это не делает работу "некто из Microsoft" хуже, и в таких обстоятельствах его "я устал я мухожук" - единственное верное решение, имхо.
А кто это будет сопровождать когда цо выйдет на пенсию? Много молодых людей, желающих бесплатно ковыряться в древнем си коде и разгребать дедовские баги с висячими указателями? Или вы хотите чтобы через 15 лет разработку ядра полностью подмял MS?
Звучит как, "мне под 60 и я не буду учить что то новое. Нас и так не плохо кормят".
Скорее так: "Есть библиотека на другом языке, использование которой приводит к критическим ошибкам из-за кода самой библиотеки - кто, когда и как исправит ее?"
Т.е. вам либо нужно изучать другой язык, что бы самостоятельно внести нужные изменения, либо искать человека, который уже знает этот язык и сможет внести необходимые изменения, кооперироваться, тестировать и т.д. А если что-то сломалось в другой части проекта из-за этого изменения - начинать сначала?
Если же все написано на одном языке - можно спокойно самостоятельно внести необходимые изменения, протестировать и т.д. И если что-то сломалось в другой части проекта - другой разработчик сможет самостоятельно внести изменения.
По скорости и удобству, последний вариант - выигрывает.
Изучение другого языка требует времени, при этом никто не даст гарантий того, что потраченный год (условно) позволит писать хороший код на новом языке. Но есть и дополнительные проблемы - отсутствие свободного времени (все же взрослые люди, семья, дети, банальная усталость), потеря скорости обучения с возрастом и т.д. Т.е. для перехода старых разработчиков на новый стек потребуется неизвестное кол-во времени и это без какой-либо гарантии результата.
Странно писать про проблемы с контролем версий у программистов на сях да еще в теме про ядро линукс. Вы в курсе откуда вообще гит взялся?
А в черипикинг я тоже умею.
Я за соседним столом наблюдаю как уже несколько раз комманда из ясноглазых йуношей и девушек берётся переписать крупный проект (организация с сотнями филиалов и десятками интеграций). Первый год они пытаются понять как оно работает. Второй год они начинают что-то ковырять и понимают что они ничего не поняли за первый год. Третий год они пытаются что-то наваять и к четвёртому году когда руководство повыше начинает ёрзать на тему почему еще ничего не сделано, они выпускают в прод 2% функционала, вся система с треском падает, команда увольняется, систему откатывают или подпирают костылями и начинают искать новых любителей модных фреймворков и цикл повторяется. Только теперь старой команде приходится тянуть уже 2 легаси системы по быстрому между задачами разобравшись с новыми технологиями и новым кодом. С четвертой попытки что-то завелось когда вместо того чтобы увольнять попавших под очередное сокращение сотрудников легаси системы их перевели в новый проект.
История дедов знает обратные примеры, когда модные новые прогрессивные упоров кучу времени, спринтов, юнит тестов и новых технологий, так и не смогли добраться до качества и перфоманса того, что пришли сделать лучше, прогнозируемее и удобнее.
Так же не раз, они приходили как волна приносили, прогресс, новые технологии и другие плюшки, черз какое то время волна катилась дальше, а ты оставался у разбитого корыта из новых, красивых, гламурных, но не работающих как задумано технологий.
Самым известным разработчиком Linux, который не согласен с Филхо по поводу Rust в ядре, является Линус Торвальдс, который написал в 2022 году
В недавнем интервью Торвальдс рассказал, что он разочарован тем, как медленно идет внедрение Rust в ядро Linux.
Это он за два года так резко сменил позицию или я чего-то не понял?
ты цитаты не понял, он и в 22-м был за Rust и в 24-м
Насколько я понял, он в 22 спорил с Филхо, который сторонник Rust, о необходимости Rust в ядре.
Не столько о необходимости, сколько о применимости. Там в ранних попытках внедрения были "некоторые" проблемы.
Если я правильно помню, раньше в стандартной поставке rust были паники, которые недопустимы в ядрах операционок. Только в винде синий экран - это норма)
Не знаю, за что вам влепили минусы, но именно так и было.
Раст действительно кидает панику при невозможности выделить память. Вы, типа, всё равно не сможете сделать ничего осмысленного при ООМ. Ну да, ну да:)
Просто для либ и тем более ядра такое поведение абсолютно недопустимо. Любой процесс начинает спамить сисколлы, требующие выделения памяти, да хотя бы чтение каталога, и быстро получает kernel panic. Охренеть решение. Я бы тоже такое в ядро не пускал.
Ну, авторам раста таки пришлось пошевелить булками и добавить kmalloc, который не бросает паники, но может вернуть NULL.
в общем и целом ему скорее по барабану "Сработает-хорошо, не сработает - вычтем этот вариант развития из перспективных". У любых проектов больше студенческого курсача есть такое же неприятное свойство как и у любого домика посерьезней шалаша - перестройка фундамента стоит некислых усилий, времени, денег и совершенно непредсказуемых рисков.
Можно, но очень сложно и очень дорого. А судя по содержимому статьи первая громкая жертва уже принесена.
они просто говорили на разных языках
Надо подождать пару десятков лет, когда все мастодонты С уже не смогут писать код на фоне альцгеймера. И будет идеальное состояние ядра: работает - не трогай, внести изменения нельзя - дееспособных программистов на древнем языке не осталось, переписать с нуля нельзя - слишком большое.
Ядро оКОБОЛится
это было бы прекрасно (нет), но количество просмотров обучающих Сишкам видео что-то никак не морозится, а только растет. Боты, наверное самообучаются, не иначе.
Студенты. Которых заставляют учить этот С, они его сдают, и тут же залпом пьют ведро шмурдяка чтобы понадёжнее забыть.
Синтактически в C ничего критично плохого нет: малое количество ключевых слов и концептов для изучения (при весьма высокой скорости работы), низкие требования компилятора к качеству кода. Это делает плохие программы на C весьма лаконичными и простыми для понимания, а значит, на C весьма неплохо можно обучать базовым концептам программирования на низком уровне.
Вот если вы захотите написать что-то большое и не прострелить себе ногу, придётся попотеть: инструменты контроля сложности очень ограничены, встроенные методы позволяют использовать их небезопасно, сплошь и рядом используются нестандартные расширения и неперносимые библиотеки, куда ни ткнись -- везде UB.
Говорю как программист, который на одном из проектов поддерживает огромную тучу кода на C.
Я недавно стянул себе llvm и for fun пилю свой toy-язык на основе C без оглядки на легаси: "как бы выглядел C, который мне нравится".
В С вообще ничего плохого нет. Просто на дворе 2024, и С стал сильно нишевой штукой, которая вообще не нужна большинству IT-шников. Поэтому те, кому его всучили в качестве первого языка, вынуждены как можно скорее его бросить и перейти к тому, что им действительно нужно. Знание С никак не улучшит умение писать на JavaScript, Python, C# особенно если человек нуб и в том, и в том.
Я считаю, что знания каждого последующего языка (языка программирования или естественного) всё-таки положительно сказываются на общем уровне владения языками, и то же понимание указателей в C в будущем упростит, например, понимание, почему есть передача по ссылке и по значению в JS.
Упростит, если знание С уже есть, как-то досталось бесплатно. Другое дело - изучать С, если целью является - JS. Оно того не стоит, лучше эти ресурсы потратить на качественное изучение JS.
Нет бесплатного знания, если за что-то заплатили давно - оно не стало от этого бесплатным.
Если цель - "изучение JS", то Вы правы, глупо учить что-то другое. Но вот если цель - "стать хорошим программистом, использующим JS", то ситуация резко меняется, и изучение более низкого уровня (например того же C) перед JS становится вполне здравой идеей.
Почему вы на Си остановились? Почему бы ещё ассемблер не выучить, а потом не научиться писать в машинных кодах, и нам закуску коснуться разработки железа? А потом обнаружить, что в фронтенде это всё не помогает вообще никак.
Чтобы стать хорошим программистом - надо учить алгоритмы, паттерны, хорошие практики, фреймворки, а не языки более низкого уровня.
Это примерно как учить алгебру без желания познать арифметику.
Начинать нужно именно с железа, машинных кодов, ручного управления памятью, а для этого С подходит как никакой другой язык.
Аналогии такие аналогии.
Это даже не примерно, это вообще не так. Можно писать программы на js/c#/java не зная машинных кодов и ручного управления памятью. Но ты не можешь пользоваться алгеброй, не используя арифметику.
Я знаю много людей, освоивших арифметику ничего незная про аксиоматику Пеано.
У вас весь мир вокруг фронтенда крутится словно.
Мир вокруг фронтенда, конечно же, не вертится - но фронтендеры от этого программистами быть не перестают.
Паттерны, практики и фреймворки - вещи преходящие. Сегодня актуально, завтра нет. Алгоритмы - другое дело, но, по-моему, фронты - последние люди, которые реально будут сидеть алгоритмы изучать.
А вот железо, ассемблер и С - вещи фундаментальные, и поэтому долговечные. Можно, конечно, не изучать, но как не чувствовать себя после этого обезьянкой?
Паттерны, практики и фреймворки - вещи преходящие. Сегодня актуально, завтра нет.
Зато железо, ассемблер и Си во фронте неактуальны с самого начала. Нет вообще ни одной задачи, которую их знание позволило бы решить.
Ну и с "преходящестью" паттернов и практик вы несколько погорячились.
Зато железо, ассемблер и Си во фронте неактуальны с самого начала. Нет вообще ни одной задачи, которую их знание позволило бы решить.
Они ровно настолько же актуальны для фронта/JS, как и для любого другого языка высокого уровня. Да, если под "задачами" понимать исключительно бизнес-фичи, то понимание железа обычно для них не требуется. Но вот как только "задачей" становится оптимизация (по используемым ресурсам и/или скорости работы), то понимание железа резко становится необходимым. И тормоза на фронте/JS вовсе не столь исключительно редкое явление, чтобы необходимость в оптимизации отсутствовала как класс.
А можете привести пример, как понимание железа помогает на фронте/JS? (Если что я просто мимо проходил.. )
Например, на производительность нередко сильно влияет то, как структуры данных попадают в кеш-линии проца. Причём тут важно как то, чтобы нужная структура попала целиком (для чего её может быть иметь смысл уменьшить, вынеся редко используемые данные куда-то ещё), так и то, чтобы в эту же кеш-линию не попала соседняя аналогичная структура (проблема false sharing, приводящая к выкидыванию из кеша второй структуры при изменении не связанных с ней данных в первой структуре - для чего размер структуры может иметь смысл дополнительно выровнять/увеличить до размера кеш-линии проца).
Аналогично, может быть важно выравнивать значения (те же поля структур) по границе слова проца (64 бита). Иногда такое автоматом делает компилятор, но нередко даже если и делает, то не везде и не всегда, и местами нужно подправлять ручками. Как с этим в популярных движках JS я без понятия.
Но вообще тема оптимизации под железо довольно обширная, и хотя не всё может быть актуально или применимо конкретно в JS, применимых подходов там, скорее всего, тоже хватает.
Подскажите, как в реакте написать компонент, чтобы он был выровнен по памяти в процессоре?
Как с этим в популярных движках JS я без понятия.
Но вообще тема оптимизации под железо довольно обширная, и хотя не всё может быть актуально или применимо конкретно в JS, применимых подходов там, скорее всего, тоже хватает.
Возник вопрос: а вы с JS работали?
Например, на производительность нередко сильно влияет то, как структуры данных попадают в кеш-линии проца [...]
Это такая шутка или что? Давно ли false sharing проявляется в единственном потоке?
Напомню, JS - однопоточный язык. Даже если где-то под капотом создаются дополнительные служебные потоки - из языковой ВМ они не видны, и к доступной памяти у единственного пользовательского потока всегда монопольный доступ. Тут, конечно, можно про SharedArrayBuffer вспомнить, но он нужен настолько "часто", что большинство js-программистов ни разу его не увидит за свою карьеру.
Да и вообще, у JS нет совершенно никакого управления расположением структур данных в памяти, что над попытками оптимизировать работу с кешем остаётся только посмеяться. Разве что обход матрицы по строкам и столбцам может отличаться по скорости - но лучшей оптимизацией тяжёлых вычислений на JS всегда был отказ от выполнения тяжёлых вычислений на JS.
Но вообще тема оптимизации под железо довольно обширная, и хотя не всё может быть актуально или применимо конкретно в JS, применимых подходов там, скорее всего, тоже хватает.
Нету этих подходов. Как бы вы не старались - между железом и вами всегда стоит языковая ВМ своим JIT, и оптимизировать нужно не под железо, а под этот JIT.
чтобы в эту же кеш-линию не попала соседняя аналогичная структура (проблема false sharing...)
Javascript однопоточный. Есть, конечно, worker-ы и даже SharedArrayBuffer, но они используются настолько редко, что фронтендер за всю жизнь может не столкнуться с ними, не говоря уже о проблемах типа false sharing
А можете привести пример, как понимание железа помогает на фронте/JS?
У меня был случай, когда фронтендер недоумевал, почему подобный код имеет низкую производительность:
arr.reduce((acc,cur)=> [...acc, cur+1], [])Мы же всего лишь увеличиваем на 1 каждый элемент массива из миллиона элементов.
Был и другой чел, который с фронта отправлял забросы в SQL напрямую, текстом, потому что никто не проследил, когда он себе на бэке решил создать php-скриптик. Отличные фронтедеры, ничего не скажешь. Свою область знают отменно.
Понимание железа и низкоуровневых штук тут вообще не поможет никоим боком.
Тут нужно базовое понимание сложности алгоритмов (того самого О-большого, которым сейчас модно мучать на собеседованиях), чтобы понимать что O(n^2) это плохо, и знание используемого языка программирования, чтобы знать что spread (...) создает новую копию массива.
Это все замечательно (в смысле ужасно). Но какое это имеет отношение к пониманию железа?
У меня был случай, когда фронтендер недоумевал, почему подобный код имеет низкую производительность:
arr.reduce((acc,cur)=> [...acc, cur+1], [])
Мы же всего лишь увеличиваем на 1 каждый элемент массива из миллиона элементов.
Чтобы понять, что это плохо, кроме знаний по алгоритмам достаточно открыть документацию по JS и почитать про функцию.
вещи преходящие
Тут интересен период этой "преходящести". Например, первая массовая книга по паттернам проектирования - GoF, в этом году отмечает свой 30-летний юбилей, она все еще массово переиздается, и актуальности не потеряла до сих пор, даже наоборот. Так может оказаться, что вещи действительно "преходящие", но человек на пенсию раньше уйдет :D
Ну и да, сам как в прошлом железячник-эмбеддер, могу сказать еще немаловажный факт, что "паттерны и практики" - это нередко именно то, что на самом деле очень даже нужно железячникам и прочим хардкорным сишникам чтобы не делать откровенное hovno. Замечательная статья на эту тему была (точнее, ее первая половина).
Очень просто не чувствовать. Пора бы в 2024 понять, что средний погромист — не посланец высшего вселенского разума. И также как среднему трубопроводчику не мешает жить отсутствие фундаментального понимания механики сплошных сред, так и среднему погромисту не мешает жить отсутствие понимания того, почему красно-чёрное дерево самобалансируется.
В сутках только 24 часа, любимых занятий у людей часто больше одного (подразумевая, что человеку нравится писать код), совершенствоваться в рабочее время — роскошь, доступная не всем. Поэтому нет ничего странного, неправильного или достойного порицания в том, что кто-то просто за деньги решает какие-то приземлённые проблемы бизнеса.
Почему вы на Си остановились? Почему бы ещё ассемблер не выучить, а потом не научиться писать в машинных кодах, и нам закуску коснуться разработки железа?
А кто вам сказал, что мы остановились? Лично я не останавливался, и писал на всём: от TypeScript до машинных кодов. Сейчас вот в Rust вкатываюсь.
Чтобы стать хорошим программистом - надо учить алгоритмы, паттерны, хорошие практики, фреймворки, а не языки более низкого уровня.
Эт вы, батенька, просто в эмбеде не работали. Иногда, чтобы быть хорошим программистом, необходимо знать, в какие конкретно машинные инструкции собирается код, или как устроен аллокатор памяти. Или без отладчика (очевидно, в инструкциях процессора, а не строках кода) никогда не найдёшь, где там в компиляторе под платформу накосячили, и почему оно работает не так, как в стандарте.
Эт вы, батенька, просто в эмбеде не работали. Иногда, чтобы быть хорошим программистом, необходимо знать, в какие конкретно машинные инструкции собирается код, или как устроен аллокатор памяти.
Эмбедеру - нужно (наверное), фронтендеру - не нужно. Программистами являются оба, и если они хорошо справляются со своей работой - их можно назвать хорошими программистами.
Мой тезис как раз про то, что сферы деятельности разные, и они накладывают некоторые требования и ограничения. Если вам повезло, и ничего не требуется, кроме TS и нескольких шаблонов проектирования, то не считайте, что всем так повезло.
Так я и не считаю, это вы почему-то пытаетесь доказать что Си нужно учить всем.
Я считаю, что может быть полезно его знать для общего развития. Остальные участники в этом треде куда более категоричны. Просто меня зацепила формулировка про ассемблер. Если бы не NDA, я бы рассказал много интересных баек про фронтенд на эмбеде.
Учить С. Или Паскаль.
Или Питон, в котором если нужно что-то посчитать раньше конца света, надо написать на С.
Так, стоп... =)
Вчера только плевался от таких хороших фронтендеров, у которых яндекс тв-программа пролагивает при прокрутке одной страницы, и назавтра переключается на вчерашнюю программу передач. Прогресс, че
И в стартапах, и в большом энтерпрайзе подобные лаги это чаще всего не потому что разработчики не умеют как надо, а потому что им не выделяют достаточно времени, чтобы сделать как надо. Можно написать код ручками, можно взять готовый фреймворк и/или библиотеки. Ручками будет очень долго (и дорого в поддержке) - менеджмент не разрешит, берем фреймворк и библиотеки, чтобы проще, быстрее, и кто угодно мог разобраться. Дальше выясняется, что эта реализация подтормаживает на каких-то сценариях - разработчик, конечно же, с удовольствием может заняться оптимизацией, сделать профилирование, переписать более оптимально узкие места, и т.д. - но ему не разрешат, но решением руководства будет "да и хер с ним, пусть юзеры железо помощнее купят, у нас нет времени на это, надо следующие фичи пилить".
Вот оправданий не надо.
Или работа выполняется сразу нормально, или нет.
А уровень качества как раз определяется образованием базовым и накопленным опытом.
Кстати, писали бы на Расте, такой бы проблемы не было)
Это не оправдания, это объективная реальность коммерческой разработки ПО.
Сделать качественно практически всегда будет ощутимо дольше, чем сделать тяп-ляп. Подключить готовую библиотеку и написать код тупо дергающий нужные методы можно за час, а реализовать весь тот же функционал самостоятельно, или разобраться как эта библиотека работает и оптимизировать в ней узкие места, потребует на порядки больше времени. Причем не только у самого разработчика, но и у тех, кто этот код в будущем будет поддерживать. И время на тестирование тоже не бесплатное, кстати.
А что важнее, "качество" или "скорость/TTM" - решает тот, кто платит и заказывает музыку.
Вчера только плевался от таких хороших фронтендеров, у которых яндекс тв-программа пролагивает при прокрутке одной страницы, и назавтра переключается на вчерашнюю программу передач. Прогресс, че
И чем бы им знание Си помогло? А знание железа?
Ха, тут помнится пару лет назад один мужик всерьез задвигал, что программисты (любые, даже бэкендеры, фронтендеры и 1Сники) обязаны знать физику и электротехнику, иначе они не имеют права называться программистами.
Потом его, правда, на хабре забанили, потому что он начал на людей с оскорблениями кидаться в личку...
Привычка писать компактно и аккуратно. А не тяп ляп, прибиндили 10 фреймворков и без проверки команды качества в прод.
Я же не мелких самодельщиков в пример привёл.
Привычка писать компактно и аккуратно.
А вот и нет, эта привычка тут не помогла бы (не говоря уже о том, что изучение Си ради одной привычки писать компактно и аккуратно - абсурд).
Этот самый "пролаг", наблюдаемый вами, на самом деле является фичей под названием "ленивая подгрузка" (ну или "ленивый рендер" - я не проверял загружаются ли данные заранее). В любом случае, пролага специально добивались, и добились бы независимо ни от каких привычек.
Чтобы такой хрени не допускать - надо изучать не Си и железо, а UX.
Выучить хотя бы один ассемблер (не обязательно до уровня написания на нём, но хотя бы до свободного чтения и понимания архитектуры проца) – весьма здравая идея, даже если писать будете на JavaScript/TypeScript.
"Почему бы ещё ассемблер не выучить, а потом не научиться писать в машинных кодах, и нам закуску коснуться разработки железа?"
Вы будете удивлены, но именно так нормальные учебные программы в ВУЗах и построены. Мы на первом курсе изучали архитектуру компьютеров и процессоров, изучали как процессоры кодируют информацию, как ее хранят, как работают с внешними устройствами, писали программы на ассемблере для Intel 8080 (как наиболее простого для понимания процессора) пеерводя инструкции в машинный код при помощи таблицы команд и вручную вычисляя адреса переходов. И это база, хорошая такая база... Алгоритмы, языки программирования высокого уровня, все это изучалось позднее, уже с пониманием как это в принципе работает под капотом.
И знаете что? Практики меняются. Фреймворки приходят и уходят. А базовые знания все те же. Ассемблер это не мой любимый язык, но мне за жизнь приходилось писать код на ассемблере для десятка разных процессоров от x86 до AVR и даже всякой дичи типа специализированных процессоров управления индикацией внутри сетевых чипов broadcom (просто потому, что никакого другого языка для этих процессоров нет), при этом я могу, при необходимости, писать код для фронтенда, а сможет ли делать мою работу фронтендер изучавший фреймворки и паттерны? Что то как то сомневаюсь.
Нет, удивлён я не буду - я ж в вузе тоже учился. Но знаете что? Ничего из того, что там рассказывалось, мне в программировании не пригодилось!
при этом я могу, при необходимости, писать код для фронтенда
Применяя известные вам практики программирования, которые вы вывели обобщив ту программу вуза? Верю. Но вот в применение неких "базовых знаний о машинных кодах" во фронтенде - извините, не верю.
Этому можно только порадоваться, что вам пригодились практики из ВУЗА, где начинают с ассемблера.
при необходимости, писать код для фронтенда
Стоит чётко обозначать, о каком именно фронтенде идёт речь, если вы говорите про фронт в рамках OS и embeded, то вопросов действительно никаких, +- так и есть.
Если говорить о web, то не вы не совсем правы. Вот вам придёт задача, на существующую страничку добавить в фон такое то видео, чтобы оно запускалось автоматически. Вы скажете, ну так легко, добавляем видео, в проперти указываем автоплей, готово. А в итоге оказывается, что на apple видео само не играется, в firefox у видео почему то появляются органы управления, и т.д.
И от ваших знаний ассемблера ни горячо ни холодно. Спеку браузеров нужно знать =)
А потом на эту страничку надо прикрутить интеграцию, а там какие-нибудь битовые флаги. А для него это магия. Если выставить бит он может по аналогии с уже написанным, то сбросить - всё тупик. Он даже не знает что гуглить.
За асоседним столом собеседования проходили. Из 10 кандидатов только один ответил сколько бит в байте (никакого подвоха, ответ 8 бы устроил). Оказалось он по образованию программист, ему на первом курсе сказали что "вот так, но вам это никогда не понадобится".
Ну тут уже какая то другая абсурдная крайность. Мне например высшее образование не нужно, чтобы ответить на такой вопрос, и на Си и ассемблере я не пишу =)
С другой стороны. Интеграции в современном вебе и не юзают битовые флаги, они обычно гоняют структуры с именными полями, так что не то чтобы вот прям чистому чистому фронтендеру это железобетонно надо. Там как бы голова не лопнула, от количества особенностей браузеров друг от друга.
Битывые флаги могут доходить до веб странички через все слои из каких-нибудь системных API. Но это не частый кейс, согласен.
Тут в пример приводят то квадратичный reduce вместо линейного, теперь битовые флаги. Но где тут польза от знания ассемблера? Это просто алгоритмы, которые не появляются автоматически после изучения асма. Зачем так напрягаться, чтобы хоть во всё пытаться присунуть это сакральное владение ассемблером, непонятно.
Двоичная система где-то рядом с ассемблером обычно обитает. Не надо прям так буквально воспринимать. Каждому программисту учить ассемблер не так чтобы обязательно нужно. Но знать как работает софт на низком уровне - лучше знать чем не знать.
Двоичная система счисления идёт в курсе дискретной математики, а ещё школьной информатики. А еще в курсе математики 5-6 класса, но это не точно.
Но даже пропустив всё перечисленное выше, программист всё равно выучит двоичную систему когда возьмётся изучать алгоритмы и структуры данных.
Ну и причём тут вообще ассемблер?
лучше знать чем не знать
Ну это очевидно. Только спор не об этом. А о том, что обязательно надо начинать с железа, что это фундамент и база, это вечное, и без этого никуда, аж кодить нельзя. А ваши вебы - это просто временная игрушка, знания ситуационные. Ну в самом деле, что там можно накодить?
Но на деле это просто заблуждение, причём в основном сишников. Они почему-то обычно считают, что надо прям обязательно изучать всё начиная с ассемблера. А как спросишь почему - ничего дельного не говорят.
А секрет прост - можно начинать с чего угодно, потому что язык - это инструмент а не цель.
Если у вас 1 маленькая формочка с 1 запросом в сутки на 64 ядерном сервере то в принципе можно ничего не учить и у чатгпт спросить.
Но если, например, нагрузка огромная и екстенсивный путь повышения производительности подходит к пределу, то уже надо заморачиваться правилами оптимизации. А они напрямую вытекают из железных особенностей.
Я не утверждал, что изучение ассемблера святая обязанность каждого программиста, это не мой тезис. Но знание железа повышает полноту картины мира. Для разных стэков технологий в разной степени.
Ну вот у вас, допустим, нагрузка огромная и БД не справляется с запросами. Как знание ассемблера поможет в их оптимизации? А никак!
Повышать "полноту картины мира" можно самыми разными способами, и ассемблер тут не имеет никаких преимуществ перед, скажем, квантовой физикой. Но в обычной веб-разработке что то, что другое бесполезно.
Ага. Продолжая логически - зачем нам учить SQL, у нас же готовый ОРМ -> ой тормозит
Еще раз - про ассемблер не мой тезис. Потому, что, например, нюансы работы макросов в том или ином ассемблере слабо связаны с железом.
А, например, нюансы работы процессора с памятью оказывают огромное влияние.
Полнота картины мира помогает следующим образом. Если вы все правила воспринимаете как магию, то вам легко ошибиться. Если вы знаете основания появления этого правила - вам легко себя проверить повторив цепочку выводов. Или даже не зная правила вывести его самому.
К тому же, хорошим тоном является делать удобный внешний API для взаимодействия извне)
Даже жалко таких, у кого цель жизни выучить ЖС
Это перпендикулярные вещи. "Зачем мне пахать в спортзале и качать физподготовку, если я всё равно не буду работать лопатой и сразу сяду за экскаватор"
Знание С никак не улучшит умение писать на JavaScript, Python, C# особенно если человек нуб и в том, и в том.
Оооох, как вы ошибаетесь. Я изначально PHP, JavaScript программист. Специально прочитал знаменитую книгу от Кернигана и Ритчи, чтоб понимать низкоуровневое устройство инструментов с которыми работаю. Это дало большой буст моим знаниям.
Сейчас я Golang программист, и С нежно люблю, даже несмотря на то что ни одной строчки кода на нем не написал.
Частенько приходится писать на С по долгу работы. Скажем так, у нас абьюзивные отношения.
С нежно люблю, даже несмотря на то что ни одной строчки кода на нем не написал
Ну, это типичная любовь к выдуманному образу :)
Я вот попробовал С, написал на нём несколько мелких программок, понял что "нахер-нахер" и перешёл к С++.
В принципе, уже есть betterC, вариант рабочий.
Синтактически в C ничего критично плохого нет
Так в нём впринципе ничего нет. Системы типов нет, инструментов контроля жизненного цикла объекта нет, инструментов потокобезопасной работы нет. Просто ассемблер обобщенный под разные архитектуры.
Как это потокобезопасной работы нет?! В C11 добавили поддержку тредов, атомиков и вот этого всего. Осталось только мейнтейнереов уговорить переписать свои C90 поделия на этот свежайший стандарт, и тогда заживём!
Да, сарказм. Наполовину.
Ну так да. И это круто. И это гарантия долгой жизни для С. И поэтому сравнения с Коболом(в другой ветке) совсем неуместны.
Синтактически в C ничего критично плохого нет
А как же шикарный синтаксис указателей на функции?
Тогда ИИ напрягут писать ядра. Будет своё ядро для каждой проги как в древние времена
Вообще-то, на Си написано не только ядро линупса. А ещё написаны (и пишутся) практически все значимые библиотеки, кодеки, протоколы и т.д. Си весь этот новомодный мусор десять раз переживёт. Потому что создан инженерами для инженеров, позволяет делать то что нужно так как нужно, не выкручивает руки, не навязывает всякие придурошные паттерны, представялет из себя просто чистый лист, на котором можешь просто изобразить всё что хочешь так как хочешь (особенно, в связке с Ассемблером, там где это нужно). Всевозможные вредители уже который десяток лет пытаются заместить Си всякой хренью, только их воз и поныне ровно там же где и тогда. Правда с некоторого времени вредители придумали новый хитрый план - поганить стандарт Си, чтобы языком стало невозможно пользоваться и все в итоге перешли на всякий новомодный мусор. Впрочем, правильный стандарт - ANSI C никуда не делся и не денется.
Если программист считает себя внимательнее машины, то из великого в нём только самомнение.
практически все значимые библиотеки, кодеки, протоколы
Потому что это проекты, начатые в прошлых десятилетиях?
Си умрет и не останется от него даже эха. Но не руст его убьет. Руст умрет еще раньше.
поганить стандарт Си, чтобы языком стало невозможно пользоваться и все в итоге перешли на всякий новомодный мусор
Вам так сильно нравится memset, что инициализация через {} вызывает страдания?
Если вы не используете C, это не значит что на нем пишут только условные преденсионеры. Своя ниша у языка есть и будет.
Очередной "убийца C" себе так и не нашел нишу, уже сколько лет вокруг него вой, а в народ язык как то не идет. Например какой нибудь Go, который существует примерно столько же, распространился сильно лучше.
Go намного проще и понятнее. Еще Swift начал движения в сторону других платформ, может у него получится немного подвинуть C/C++
Уверен и go и swift и даже rust умрут гораздо быстрее Си. Придет новый модный "самый безопасный" или "самый быстрый" и вытеснит их, а программу для вашей стиральной машинки опять напишут на С.
Вчера было скучно, делал программу для железки для управление кондиционером через HomeKit. Писал на Swift.
Может и производители стиральных машинок тоже начнут что-то осваивать)
Вот именно. Вам просто скучно, вы развлекаетесь, а ребятам надо сделать машинку / утюг / мультиварку на самом дешевом кстайском чипе за пять центов, и впихнуть все в 2кб памяти. Как думаете они выберут swift? Вернее даже так. Как думаете, под такой чип вообще есть компилятор swift?
Тут не в ту сторону копаете.
В промышленной автоматизации (АСУ ТП), где не утюги и мультиварки, а немного более сложные вещи типа насосов, кранов, производственных линий, электростанций, и т.д. на Си, например, пишут очень редко. Он для этого слишком небезопасный и сложный в использовании. Там индустриальным стандартом уже десятки лет являются так называемые МЭКовские языки, самых популярных из которых три, один текстовый (похож на сильно урезанный Паскаль) и два графических (один похож на схемы релейной автоматики, другой на схемы на дискретных элементах). Смысл прост - во-первых на такие языки гораздо проще переносить алгоритмы той же самой релейной и дискретной логики, а во-вторых, там от разработчика заранее убрали все колющее, режущее, и стреляющее, никаких неоднозначностей, никакой прямой работы с памятью, и т.д. - учитывая, что код под такие штуки часто пишут не программисты, а инженеры-электроники и инженеры-автоматчики, которые не умеют программировать, то так проще и безопаснее для всех.
Так вот, уже давно существуют открытые трансляторы этих самых МЭКовских языков в ANSI C и открытая среда разработки для них, что позволяет писать на этих языках практически под любой микроконтроллер. Вот в этом направлении ребятам стоит двигаться, просто, быстро, безопасно.
Как думаете, под такой чип вообще есть компилятор swift?
ESP32?
Вы знаете я как то читал "Колеса", Артура Хейли так вот там есть очень интересная мысль, "четыре лишних болта, стоимостью в один доллар, при партии автомобилей в сто тысяч штук приносят компании убыток в сто тысяч долларов".
Вы же предлагаете заменить восьмибитный контроллер стоимостью в пять центов (функционала которого тем не менее вполне достаточно чтобы управлять стиралкой или утюгом), 32битным двухядерным контроллером стоимостью в 10-15$ чтобы что? Чтобы вам было удобней писать код?
Стоп, я ничего не предлагаю. Я вообще на ассемблере под них писал.
Вы спросили:
под такой чип вообще есть компилятор swift?
Я вам ответил.
Так правильный ответ "Нет, для этого чипа такого компилятора нет." Все умные механизмы выделения и контроля памяти требуют для своей работы этой самой памяти больше, чем в принципе есть в мелких микрухах. И поэтому не слишком подходят для эмбедед. А с ESP32 можно и на питоне писать. В общем думаю мы с вами друг руга поняли.
Все умные механизмы выделения и контроля памяти требуют для своей работы этой самой памяти больше, чем в принципе есть в мелких микрухах.
Только те, что работают в рантайме. Прошивку для двухкилобайтного контроллера необязательно компилировать на двухкилобайтном контроллере.
Может стоило начать с того, что динамическое распределение в таких системах минимум моветон или вообще под явным запретом..
четыре лишних болта, стоимостью в один доллар, при партии автомобилей в сто тысяч штук приносят компании…
… $3'600'000 прибыли, потому что отпускная цена возрастет на $10.
ну и продолжать там можно долго )
Почему вы решили что цена возрастет? В данном случае речь идет о 4 лишних болтах без которых можно было бы обойтись, а не о какой то новой фиче, которая делает продукт привлекательней и дороже в глазах потребителя. США не Россия, а Форд это не автоваз, там конкурировать надо.
Если можно просто повысить цену на $10 и получить $3M+ прибыли, то почему её ещё не повысили, не внося никаких изменений?
Почему вы решили, что пространство для простого повышения цены не было выбрано ранее?
Почему вы решили, что сможете подменить некоторую фичу — ее отсутствием, и никто этого не заметит?
Почему вы решили, что можете позволять себе демагогические приемы?
Почему вы решили, что пространство для простого повышения цены не было выбрано ранее?
Я решил? Это вы решили, что можно безнаказано удорожать производство, и компенсировать потери простым подъёмом отпускных цен, цитата: "$3'600'000 прибыли, потому что отпускная цена возрастет на $10" Я же как раз утверждаю, что на высоконкурентном рынке цены уже у потолка, и выигрывает тот производитель, который снижает себестоимость (про прочих равных), там самым повышая свою маржу.
Почему вы решили, что сможете подменить некоторую фичу — ее отсутствием, и никто этого не заметит?
Форд где-то сказал, что 4 болта -- это фича? Если нет, то разумно предположить, что удаление 4 болтов -- это оптимизация конструкции без ухудшения потребительских свойств.
Команда Rust для Linux терпит поражение в сражении с разработчиками на С, её лидер ушёл из-за «нетехнической ерунды»