Комментарии 472
Может быть разработчикам 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"
Там про эту претензию тоже было
Один вопрос: зачем придумывать велосипед, если можно старый исправить?
Если ты не можешь написать безопасный код, то спешу расстроить: это не в языке проблема, а в тебе. И изобретать велосипед просто потому что ты не умеешь работать с памятью(образно) - абсурд
Так получается что никто не умеет.
ну так дело то не в языке, а в человеческой природе: люди допускают ошибки! Никакой новый язык это не исправит, просто ошибки уйдут на другой уровень, и их скорее всего еще сложнее будет находить и исправлять.
Уже есть куча языков как бы безопасных в разных аспектах, это не мешает человекам плодить на них код с ошибками.
язык с хорошей системой типов поможет
тут вы наверно заговорились, хороший язык, С++ например, позволяет программисту определять типы, которые конкретно ему нужны для его конкретной задачи, язык не может задать какую-то одну универсальную систему типов для решения любых задач (примитивные типы уже давно перечислены и мало чем отличаются между языками). Возникает вопрос: а что тут можно изобрести если уже есть язык, который это позволяет? Но вот придумали же Java и C#, которые на самом деле сокращают формальности при определении типов, (как минимум хидера писать не надо) + тот же мемори менежмент автоматический как раз. Но для некоторых задач все равно С++, а иногда и чистый С остаются незаменимыми.
Можно сделать вывод что язык все таки привязан к определенному классу задач, и значит если этот класс задач не достаточно понятен будущее языка остается под сомнением.
А вот рассказывать про то что язык вас от чего-то защищает мне кажется не очень конструктивно, потому что любая палка о двух концах как известно, но это мое сугубо субъективное мнение и не только про палку.
Система типов это не только про типы. Это считай целая научная тема. Рекомендую ознакомиться, перед тем, как.
ну можете считать, что я уже жду когда вы меня начнете знакомить, а заодно и весь Хабр.
Ссылку хоть дайте что ли.
Однажды Хабр уже знакомили с этим всем, но потом Дедфуд переехал в Техас, занялся политикой и все посты превратились в тыкву. Так что ссылок не будет.
Разве что вот тут немного осталось: https://habr.com/ru/users/PsyHaSTe/publications/articles/
Но лучше гуглить type theory и читать на английском.
мне кажется это какое то отвлечение на негодный объект, то есть перевод темы в непонятном направлении.
чем не нравится сентенция о том что
С++ например, позволяет программисту определять типы,
мне интересно узнать.
Вы тоже считаете что есть какая то универсальная система типов которая позволяет решать любые задачи?
чем не нравится сентенция о том что "С++ например, позволяет программисту определять типы", мне интересно узнать.
Если кратко - то типы не про то, что с ними делать можно (в противном случае идеальным языком был бы sloppy mode javascript, где можно даже список локальных переменных вычислять в рантайме), а про то, чего с ними делать нельзя. И вот в выражении этого "нельзя" и наблюдаются проблемы - даже банальное утверждение "у пустого optional нельзя получить value" уже невыразимо на языке С++.
в противном случае идеальным языком был бы sloppy mode javascript
то есть это разговор о поиске идеального языка. А я то думал что всем понятно, что одного идеального языка не существует:
Можно сделать вывод что язык все таки привязан к определенному классу задач ...
как минимум, соответственно нет смысла его искать, по моему.
То есть это я не удачно зашел или, скорее, попал.
Но тут не могу удержаться:
sloppy mode javascript, где можно даже список локальных переменных вычислять в рантайме
во первых, не ужели вы считаете что для javascript есть рантайм? он что компилируемый? Какие локальные переменные вы собираетесь получить после оптимизации на этапе компиляции?
потом, вы сначала говорили про типы, и вдруг переключились на переменные, разве нет разницы между типами и переменными?
если что, в языке Perl который вроде как ровестник С-ей тоже можно получить список локальных и любых переменных, но он точно не компилируемый был.
во первых, не ужели вы считаете что для 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
да-тут-вот уже в следующем коменте написано:
Система типов это ... набор правил
то есть под системой типов имелась ввиду не система типов, а набор правил по контролю, преобразованию, приведению, ... типов. Мне этого вполне достаточно что бы понять о чем на самом деле речь.
И еще сразу понятно что разговаривать не о чем, так как подмена понятий происходит уже на уровне названий и это ни кого не беспокоит.
Если вы для себя выдумали какие-то свои определения, которые расходятся с общепринятыми, то это ваша проблема.
я ничего не выдумал я интерпретирую смысл словосочетания в соответствии с правилами русского языка. Я не обязан знать ту книжку или сайт по которым вы сейчас работаете. Я не занимаюсь разработкой или тестированием компиляторов в данный момент, поэтому я не обязан идентифицировать значения ваших терминов в соответствии с какими либо правилами кроме правил русского языка.
Во-первых, вы инженер или кто? И если инженер, то какого хрена кичитесь своим незнанием вместо того, чтобы пойти и узнать?
Во-вторых, определение системы типов полностью согласовано со всеми правилами русского языка. Что такое "система"? Это форма организации чего-то. Значит, система типов - форма организации типов. Как можно организовать типы в языке программирования? Ну, для начала вообще выяснить что такое тип в данном ЯП (отсюда и набор правил назначения типов термам). Потом надо классифицировать сами типы.
если инженер, то какого хрена кичитесь своим незнанием вместо того, чтобы пойти и узнать?
ну у меня действительно до сих пор не было необходимости вникать, что понимают под системой типов. Но я не согласен что это надо определять словом "кичитесь", я бы сказал я этого не стесняюсь.
Я например одно время плотно работал с кодом написанным по COM спецификации не зная про эту спецификацию или не совсем осозновая ее положения, при этом ко мне очередь стояла проконсультироваться по выбору-применению правильных интерфейсов в коде на практике. Очень благодарен одному, тоже кстати недовольному, читателю моей статьи что подсказал мне где прочитать теорию.
Но в отличие от вас я не пропагандирую это свое не знание, как вы это делаете здесь например:
Почему вы на Си остановились? Почему бы ещё ассемблер не выучить, а потом не научиться писать в машинных кодах, и нам закуску коснуться разработки железа? А потом обнаружить, что в фронтенде это всё не помогает вообще никак.
Хотя я тоже не считаю что ассемблер надо прям учить, но знать основы машинных языков точно никому не помешает на мой взгляд, просто потому что это действительно основы всего программирования.
Мне ваши коментарии такого рода напоминают классику:
Зачем изучать географию? Есть же извозчики - довезут куда надо.
ну у меня действительно до сих пор не было необходимости вникать, что понимают под системой типов. Но я не согласен что это надо определять словом "кичитесь", я бы сказал я этого не стесняюсь.
Вы не в прошлом кичились, а кичитесь незнанием прямо сейчас, доказывая всем в комментариях что не знать про системы типов - нормально вместо того, чтобы прочитать про них самому.
Но в отличие от вас я не пропагандирую это свое не знание, как вы это делаете здесь например [...]
А где я писал про своё незнание? Я как раз пишу про те вещи, которые сам знаю. И я именно потому уверен в их бесполезности, что мне самому они не пригодились.
Я как раз пишу про те вещи, которые сам знаю. И я именно потому уверен в их бесполезности, что мне самому они не пригодились.
Так я не знал только название! А то что, как я теперь выяснил, имеется ввиду под этим названием я прекрасно знаю, и так же уверен в бесполезности (ну если вы не разработчик компиляторов конечно!) этого чего-то, что очень трудно определенно сформулировать, судя по количеству приведенных ссылок, и замечания о том что это что-то превратилось в тыкву.
Но вы похоже думаете, что только вам позволено быть увереным в бесполезности чего-то. Извините что помешал вам пребывать в этой уверенности.
и так же уверен в бесполезности
Огорчу вас своим контрпримером. Я вот не разраб компилятора (да и вообще не разраб, ассемблера ведь не знаю), но мне теория типов помогает в разработке каждый день, не даёт писать глупости и работать с данными неправильно.
Хотите сказать, что типы-суммы нужны только разработчикам компиляторов? Видимо, я на прошлой неделе писал компилятор.
Или нетривиальные типы высших порядков? Эти вообще могли бы упростить любой CRUD, если правильно применить их.
А те же зависимые типы могли бы совершить революцию в DDD, если бы существовали в императивных языках.
Вы со всем этим тоже встречались, только слов не знали? Вот не верю...
и что интересно, - таки да. Извозчик - он же драйвер - довезет ваше сообщение например до принтера, и вам совершенно не надо при этом быть специалистом в области переноса изображения на бумагу.
Хидеры и в 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-скриптик. Отличные фронтедеры, ничего не скажешь. Свою область знают отменно.
Это все замечательно (в смысле ужасно). Но какое это имеет отношение к пониманию железа?
У меня был случай, когда фронтендер недоумевал, почему подобный код имеет низкую производительность:
arr.reduce((acc,cur)=> [...acc, cur+1], [])
Мы же всего лишь увеличиваем на 1 каждый элемент массива из миллиона элементов.
Чтобы понять, что это плохо, кроме знаний по алгоритмам достаточно открыть документацию по JS и почитать про функцию.
Очень просто не чувствовать. Пора бы в 2024 понять, что средний погромист — не посланец высшего вселенского разума. И также как среднему трубопроводчику не мешает жить отсутствие фундаментального понимания механики сплошных сред, так и среднему погромисту не мешает жить отсутствие понимания того, почему красно-чёрное дерево самобалансируется.
В сутках только 24 часа, любимых занятий у людей часто больше одного (подразумевая, что человеку нравится писать код), совершенствоваться в рабочее время — роскошь, доступная не всем. Поэтому нет ничего странного, неправильного или достойного порицания в том, что кто-то просто за деньги решает какие-то приземлённые проблемы бизнеса.
Почему вы на Си остановились? Почему бы ещё ассемблер не выучить, а потом не научиться писать в машинных кодах, и нам закуску коснуться разработки железа?
А кто вам сказал, что мы остановились? Лично я не останавливался, и писал на всём: от TypeScript до машинных кодов. Сейчас вот в Rust вкатываюсь.
Чтобы стать хорошим программистом - надо учить алгоритмы, паттерны, хорошие практики, фреймворки, а не языки более низкого уровня.
Эт вы, батенька, просто в эмбеде не работали. Иногда, чтобы быть хорошим программистом, необходимо знать, в какие конкретно машинные инструкции собирается код, или как устроен аллокатор памяти. Или без отладчика (очевидно, в инструкциях процессора, а не строках кода) никогда не найдёшь, где там в компиляторе под платформу накосячили, и почему оно работает не так, как в стандарте.
Эт вы, батенька, просто в эмбеде не работали. Иногда, чтобы быть хорошим программистом, необходимо знать, в какие конкретно машинные инструкции собирается код, или как устроен аллокатор памяти.
Эмбедеру - нужно (наверное), фронтендеру - не нужно. Программистами являются оба, и если они хорошо справляются со своей работой - их можно назвать хорошими программистами.
Мой тезис как раз про то, что сферы деятельности разные, и они накладывают некоторые требования и ограничения. Если вам повезло, и ничего не требуется, кроме TS и нескольких шаблонов проектирования, то не считайте, что всем так повезло.
Так я и не считаю, это вы почему-то пытаетесь доказать что Си нужно учить всем.
Я считаю, что может быть полезно его знать для общего развития. Остальные участники в этом треде куда более категоричны. Просто меня зацепила формулировка про ассемблер. Если бы не NDA, я бы рассказал много интересных баек про фронтенд на эмбеде.
Учить С. Или Паскаль.
Или Питон, в котором если нужно что-то посчитать раньше конца света, надо написать на С.
Так, стоп... =)
Вчера только плевался от таких хороших фронтендеров, у которых яндекс тв-программа пролагивает при прокрутке одной страницы, и назавтра переключается на вчерашнюю программу передач. Прогресс, че
Вчера только плевался от таких хороших фронтендеров, у которых яндекс тв-программа пролагивает при прокрутке одной страницы, и назавтра переключается на вчерашнюю программу передач. Прогресс, че
И чем бы им знание Си помогло? А знание железа?
Привычка писать компактно и аккуратно. А не тяп ляп, прибиндили 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?
Как думаете, под такой чип вообще есть компилятор swift?
ESP32?
Вы знаете я как то читал "Колеса", Артура Хейли так вот там есть очень интересная мысль, "четыре лишних болта, стоимостью в один доллар, при партии автомобилей в сто тысяч штук приносят компании убыток в сто тысяч долларов".
Вы же предлагаете заменить восьмибитный контроллер стоимостью в пять центов (функционала которого тем не менее вполне достаточно чтобы управлять стиралкой или утюгом), 32битным двухядерным контроллером стоимостью в 10-15$ чтобы что? Чтобы вам было удобней писать код?
Стоп, я ничего не предлагаю. Я вообще на ассемблере под них писал.
Вы спросили:
под такой чип вообще есть компилятор swift?
Я вам ответил.
Так правильный ответ "Нет, для этого чипа такого компилятора нет." Все умные механизмы выделения и контроля памяти требуют для своей работы этой самой памяти больше, чем в принципе есть в мелких микрухах. И поэтому не слишком подходят для эмбедед. А с ESP32 можно и на питоне писать. В общем думаю мы с вами друг руга поняли.
Все умные механизмы выделения и контроля памяти требуют для своей работы этой самой памяти больше, чем в принципе есть в мелких микрухах.
Только те, что работают в рантайме. Прошивку для двухкилобайтного контроллера необязательно компилировать на двухкилобайтном контроллере.
Может стоило начать с того, что динамическое распределение в таких системах минимум моветон или вообще под явным запретом..
четыре лишних болта, стоимостью в один доллар, при партии автомобилей в сто тысяч штук приносят компании…
… $3'600'000 прибыли, потому что отпускная цена возрастет на $10.
ну и продолжать там можно долго )
Почему вы решили что цена возрастет? В данном случае речь идет о 4 лишних болтах без которых можно было бы обойтись, а не о какой то новой фиче, которая делает продукт привлекательней и дороже в глазах потребителя. США не Россия, а Форд это не автоваз, там конкурировать надо.
Если можно просто повысить цену на $10 и получить $3M+ прибыли, то почему её ещё не повысили, не внося никаких изменений?
Почему вы решили, что пространство для простого повышения цены не было выбрано ранее?
Почему вы решили, что сможете подменить некоторую фичу — ее отсутствием, и никто этого не заметит?
Почему вы решили, что можете позволять себе демагогические приемы?
Почему вы решили, что пространство для простого повышения цены не было выбрано ранее?
Я решил? Это вы решили, что можно безнаказано удорожать производство, и компенсировать потери простым подъёмом отпускных цен, цитата: "$3'600'000 прибыли, потому что отпускная цена возрастет на $10" Я же как раз утверждаю, что на высоконкурентном рынке цены уже у потолка, и выигрывает тот производитель, который снижает себестоимость (про прочих равных), там самым повышая свою маржу.
Почему вы решили, что сможете подменить некоторую фичу — ее отсутствием, и никто этого не заметит?
Форд где-то сказал, что 4 болта -- это фича? Если нет, то разумно предположить, что удаление 4 болтов -- это оптимизация конструкции без ухудшения потребительских свойств.
Попробуйте перечитать внимательно то, на что отвечали, и то, что пишете.
себестоимость (про прочих равных)
Наличие фичи аннулирует это условие.
Форд где-то сказал, что 4 болта -- это фича? Если нет, то разумно предположить, что удаление 4 болтов -- это оптимизация конструкции без ухудшения потребительских свойств.
Прекрасное высказывание.
У вас есть автомобиль? Оптимизируйте в нем с колес ненужные четыре болта.
До понимания или признания в непингуемости осталось: 3… 2… 1…
Оптимизируйте в нем с колес ненужные четыре болта.
Типа заменить одной центральной колёсной гайкой, как в Ф1? Вряд ли даст выигрыш. А вот, скажем, заменить горсть болтов и шурупов на пластиковые защёлки для закрепления деталей обивки, всяких панелей, кондуитов и проч -- задача вполне оптимизируемая.
Какой-нибудь 8-битный PIC18 легко может стоить в 10 раз дороже 32-битного двухядерного ESP32. Но в ряде применений первый не получится заменить вторым совсем или это будет переусложнение.
Очень зря. Я думаю вас rust/go/swift переживет. И у C будет положение аля Delphi/COBOL/FORTRAN.
Любопытно, что к тому моменту придёт на смену Расту?
"дееспособных программистов на древнем языке не осталось" - этот древний язык входит в программу обучения каждого профильного ВУЗа в стране, и не все студенты достаточно глупы чтобы разом его забыть. Количества кода который даже сейчас пишется на Си огромно. Рейтинг Tiobe оценивающий популярность языков программирования на основе анализа поисковых запросов отдает С третье место с 9.17% (второе место у С++ с 10,04% и эти парни тоже в Си умеют). Так, что полагаю, ваши представления о его смерти, как минимум, сильно преувеличены.
Какой средний возраст мейнтенера Linux? Какой средний возраст разработчика комитящего в ядро Linux? (Просто интересно)
Кобол тоже вроде живёт, но можно ли назвать это жизнью?
Смотрел я на этот Rust и решил, что сила Rust велика и она в Cargo, потом в Сети нашлось много высказываний в том же духе. Всё остальное - маркетинг высшего уровня подлости, вот и в этой истории уши Микрософт (Билл Гейтс - утвердитель Нового Мирового Порядка, численность населения - 500_000_000 человек, слышал я) повылезли. Тут компилятор недопонимает, там надо защищаться от бед которые не наступят никогда, здесь предоставлены средства зачёркивания всех обещаний, за углом - проблемы с памятью решены так, что она официально может течь.
Применительно к ядру, единство Cargo значения не имеет. В сухом остатке...
Сторонникам Rust надо просто форкнуть ядро и переписать его на Rust полностью. Так им никто мешать не будет. И если получится версия ничуть не хуже, но безопаснее, все естественным образом начнут переезжать на неё, голосуя этим за превосходство Rust.
Не работает это так.
На практике будет, что ядро в ядерной части ничуть не хуже и даже лучше, потому что от легаси избавились. Но при этом 95% железа и файловых систем не поддерживается, потому что сорокалетних залежей дров нет.
А дрова никто не пишет, потому что ядро не используется потому, что дров нет.
Можно написать основу ядра, с поддержкой сишных периферийных модулей, только падать они будут в сто раз чаще оригинального ядра, потому что новое ядро высветит все ранее проигнорированные косяки в модулях.
Не работает это так.
Потому что растишки вырастут и возьмутся за новые интересные игрушки, и скорее всего не успеют сделать ничего.
Собственно, на практике пока развитие раста так и выглядит. Уже прошло 5 лет., ой уже 15...
Справедливости ради, хотя CLI считается одной из основных областей использования Go, на Rust уже есть немало отличных CLI, которые явно лучше Go-шных аналогов как минимум по производительности и уже получили намного бóльшую популярность. Ну и в целом общие ожидания от любой CLI на Rust: надёжное, быстрое, легко ставится одним бинарником = годное! Так что что-то они уже совершенно точно успели сделать.
Не понял, при чем тут command line interface и go?
Это был ответ на:
и скорее всего не успеют сделать ничего.
Кое-что они определённо уже успели сделать, потеснив Go в нише CLI.
Ой, ровно 4 года назад я тут переводил про кли. И очень сомневаюсь, что раст может тут что то потеснить, кроме синдрома них
Собственно раст и кли это очень близко про гвозди и микроскоп
Ну, из того, что я сам использую (если брать только CLI и то, что сходу вспомнил):
https://github.com/vi/websocat
https://github.com/ast-grep/ast-grep
https://github.com/BurntSushi/ripgrep
https://github.com/sharkdp/fd
https://github.com/sharkdp/bat
https://github.com/dprint/dprint
Плюс ещё присматриваюсь к нескольким современным терминалам (тоже написанным на расте, что характерно). Переходить с urxvt неохота, но всё выглядит так, что предел расширения его функционала сторонними патчами уже достигнут, и скоро выбора уже не будет.
Пока все спрашивают, что же пишут на rust, я уже несколько лет пользуюсь десктопным экранным переводчиком, эмулятором терминала, терминальным файловым менеджером, руссификатором для Dwarf Fortress, Shadowsocks клиентом и шеллом написанными на Rust...
Pot - Экранный переводчик
Wezterm - Эмулятор терминала
Yazi - Консольный Файловый менеджер
dfrus - Патчер Руссификатор для Dwarf Fortress
shadowsocks-rust - Shadowsocks client+server+utilies
nushell - Экзотичный шелл
zoxide - Более умная команда cd, вдохновленная z и autojump.
И ещё, сам не пользуюсь, но народ (и сам создатель) очень хвалит Alacritty как быстрейший эмулятор терминала.
Предвкушая ваш вопрос, нет. Я пользуюсь ими не потому что они на Rust (около половины я сначала установил, попользовался, они мне понравились, и только потом я увидел что они на Rust), а потому что некоторым программам альтернатив нет, а некоторые по юзабилити лучше конкурентов. Возможно у разработчиков на Rust остаётся больше времени подумать над тем, как написать собственно хорошую программу, нежели думать над тем, как складывать байты в памяти =)
Ну вероятно список авесомераст будет достаточно. А по последнему утверждению - не думаю что это сильно зависит от языка
Списки осом обычно содержат инструменты для разработчиков, и содержание в них прикладного софта как правило минимально, к тому же, не всё из этих списков действительно awesome и это будет выбрано среди альтернатив. Я же привёл прикладнуху, которой я пользуюсь в реальной жизни. Единственным исключением тут может быть nushell, ибо несмотря на свои преимущества, он довольно извращенский, и подойдёт совсем не каждому.
Как минимум потому, что если расширить C до Rust, то вы получите Rust, но хуже.
Не факт.
А чем вас, собственно, синтаксис раста не устраивает?
Сила Rust - вовсе не в кейвордах и синтаксисе, а в модели памяти. То есть ровно в том, от чего плюются ортодоксальные сишники.
Реализовать модель памяти раста и на ассемблере можно. А чтобы добавить ее поддержку на уровне компилятора, вам как минимум придется завести в язык raii, borrow checker, новые типы данных чтобы с ними управляться... Собственно, вот у вас и получается раст, но без остальных фишек раста. Стоило ли оно того, учитывая, что теперь ваш язык и на родную сишечку-то не особо похож?
Пусть коммьюнити решает, я бы проголосовал за.
Вы как будто бы не понимаете, что итогом этих трудов будет не новый крутой си, а странный клон раста со скрепным синтаксисом.
Это какие-то новые эксклюзивные технологии, которые нельзя реализовать в других компиляторах?
Прежде всего это "новые" технологии, которые не очень хорошо дружат со вседозволенностью Си.
Это какие-то новые эксклюзивные технологии, которые нельзя реализовать в других компиляторах?
Можно. Только это будет другой язык программирования.
Да не похож, но он будет совместим по кодовой базе.
Наличие дополнительных ключевых слов, ограничивающих операции с указателями и размещение в аналогичной расту модели памяти никак не повлияет. Просто кому то очень захотелось свой язык написать с нуля, а не развивать существующий.
Так надо не добавлять, а убавлять. Чтобы получить Раст, нужно из С сначала выкинуть половину возможностей, потом на остаток добавлять другие. То есть, оно всё равно будет никак не совместимо с С, и точно так же всех возмущать, даже больше.
Я бы сказал, не только в модели памяти, но и в его высокоуровневых/функциональных фичах и тулинге.
А при чём тут кейворды вообще? Речь в первую очередь про абсолютный контроль владением объекта, что противоречит всем основам С. Вы себе как представляете С без указателей и без операций с адресами? А динамические типы как делать без трейтов?
А тип Result<T,E> можно хоть в Бейсик зафигачить, Растом он от этого не станет.
Да нет. Сишники бы ещё больше взвыли, только не от необходимости учить новый язык, а от того, что их хотят пересадить на обрубок Си, запретив пользоваться почти всем, что есть в языке, который они знают десятки лет.
С точки зрения Rust, хоть есть оправдание, что это другой язык, и что в нём не только забрали, но и подарили крутые фичи.)
Кейворды и синтаксис – малосущественная часть.
Как минимум потому, что если расширить C до Rust, то вы получите Rust, но хуже
Не надо С подтягивать до Раста, он (Раст) использует другие, непривычные и необязательные для надежной работы концепции. Просто betterC было бы абсолютно достаточно.
Точно так уже получились C++, C--,C# и Objective C.
C++ небезопасный, C# с останавливающим работу программы сборщиком мусора, C-- недостаточно высокоуровневый, у Objective C странная работа с памятью (полуручная) и он уже устарел.
Именно.
И все они были betterC
я думал, ты так пошутил, но нет, видимо не в курсе
То-то этому казалось, что что-то осталось забытым… D, конечно же.
Впрочем, от замены Rust на D, даже в ограниченном режиме совместимости с C придется осваивать новые инструменты, отвалятся грязные хаки при попытке их втупую перенести на D, и много чего придется все равно переписывать, равно как и менять методологию работы с кодом.
Против всех этих пунктов приципиальные возражения, поэтому замена Rust⇒D поменяет только форму риторики, но не суть
Вообще то нет. Код с С на Д почти даже исправлять не надо (порядок скобок в массиве), не то что переписывать. Грязные хаки конечно отвалятся, ибо безопасность, но не так они часто а С используются, реже чем ансейф
Они хотели быть betterC, но не были ими (и D туда же). Большая разница.
Не нужно. С нормально со всем справляется. Skill issue и евангелизм со стороны растовщиков - не более.
С - это устаревший весьма плохой язык, в котором даже две строки безопасно сложить черт ногу сломит.
Он хороший, просто кому-то дано а кому-то не дано.
С это переносимый ассемблер.
И требовать от него возможностей Java как-то некомильфо.
Кто-то понимает в каких случаях какие инструменты надо использовать, а кто-то кичится малополезными знаниями в современном мире
Он хороший, просто кому-то дано а кому-то не дано.
Можно примеры, кому дано? :) Сколько я ни видел реально используемых программ на С - у всех у них в анамнезе баги и дыры из-за ошибок работы с памятью. Как-то получается, что никому не дано.
ОС на которой вы работаете, 99.99% написана на Си.
Си имеет промышленный стандарт, в отличии от всех остальных.
И ещё 1005001000 библиотек, которыми пользуется весь IT мир от мэйнфреймов до чипа в банковской карте.
То что вы не видели, не говорит о том, что этого нет. Вам это просто не показывали.
Ну да, никому не дано, только операционная система того на чем вы это пишете написана на C, и браузер в которм вы все это пишете написан на С/С++ и драйвер клавиатуры на которой вы это печатаете на Си. И софт вашего роутера который передает ваше сообщение написан на Си, и код всех магистральных маршрутизаторов и мультиплексоров через который проходит ваше сообщение по пути ко мне тоже на Си. А так да, никому не дано.
И вы можете уверенно заявить, что все что никогда не глючило и никогда не было багов из-за ошибок работы с памятью? Вы же спорите именно с этим
Сколько я ни видел реально используемых программ на С - у всех у них в анамнезе баги и дыры из-за ошибок работы с памятью.
А вы можете уверенно заявить, что все написанное на Раст никогда не глючило? Смешно. Проблемы есть в любой программе если она чуть сложнее hello world. Я не спорю с тем что С опасный, я спорю с тем что нужно все бросать и срочно переписывать на раст работающий код. Нафига? Лезть туда грязными руками чтобы что? Старики правы - оно работает и работает стабильно, у меня у роутеров и серверов по пять-семь лет аптайма бывает пока питание не отрубят. Я не согласен с тем, что надо все срочно бросать, и переходить на "новый самый защищенный" или "новый самый быстрый", сколько их таких было...
Есть логические ошибки из-за неверно выстроенной логики кода, а есть чисто технические ошибки из-за того, что язык слишком примитивен и слишком многое возлагает на ручную работу программиста.
Например, когда вы работаете с массивом в С, вы просто обязаны вручную обрабатывать его размер. Забыли об этом или допустили ошибку в обработке - получили ошибку работы с памятью, что чревато глюком/падением программы или уязвимостью. Тогда как в С++ вы просто берёте std::vector и не паритесь насчёт размеров - язык сам всё это сделает как надо.
Таким образом, отваливается большой пласт потенциальных ошибок вместе с большим количеством ручной работы. Как можно это отвергать - лично мне решительно непонятно.
И нет, я не топлю за Rust, мне этот язык и самому не нравится по нескольким причинам. На мой взгляд, лучше бы ядро переводили на С++ (точнее, на его подмножество, т.к. в С++ есть вещи, которые неуместны в ядре ОС), тем более что в ядре и так наверчен свой велосипедный ООП.
Еще раз, я не спорю с тем, что С опасный, и там вручную надо все контролировать. Я не спорю с тем, что любой современный язык лучше в этом плане. Вы видимо меня не понимаете, мой пойнт в том, что переписывать огромный пласт кода, стабильно работающего, не имеющего явных проблем кода, только потому, что появился "новый более безопасный" как минимум неразумно. Ибо это не только трудозатратно, но и ведет к проблемам в совместимости с другими частями системы. Делать это надо при наличии явных проблем или в ходе обновления функционала, то самое "работает не трогай". В ядре есть много других вещей куда можно приложить усилия.
А что, кто-то предлагает переписывать работающее?
Оглянитесь, даже здесь есть комментарии в стиле, "надо все переписать на Rust". И да растаманы всерьез считают, что это надо срочно делать, просто с ядром их сразу осадили дав понять, что стрые стабильные части пока трогать не дадут.
Тут - да, есть такие комментарии. Но в ядре, насколько я знаю, никто не пытался переписать уже работающие системы на Rust, там всего-то пытались сделать к ним биндинги, чтобы можно было с ними из Rust работать.
насколько я знаю, никто не пытался переписать уже работающие системы на Rust
Сам пост о том, что пытались переписать работающую систему на Rust. Один из программистов проекта Rust for Linux полез в ext4. Вопрос «для чего?» оставим за скобками. Суть конфликта в том, что программиста на C, контрибутора ext4, пытались заставить учить Rust, а он не захотел.
Вывод из этого простой. Нужно кому-то из Rust тусовки выучить C. Стать контрибутором чего-нибудь в ядре Linux. Взять на себя ответственность за патчи в ядро. И тогда дело (переписывание ядра на Rust) пойдёт быстрее.
А то, что кто-то хочет себе лычку, что он переписал что-то в ядре linux, не отвечая при этом за написанный код, ну это не серьёзно. И то, что его контрибуторы на хер шлют - правильно делают. И то, что дядя «выгорел» - косвенный показатель его истинных намерений, ему не нужно было ядро linux. Он свой личный бред развивал. Это моё личное мнение
По содержанию поста и правда кажется, что они зачем-то полезли в ext4, но по коммитам видно, что на самом деле они делали биндинги к vfs. И ментейнера ext4 возмутило само наличие биндингов к vfs.
Вывод из этого простой. Нужно кому-то из Rust тусовки выучить C.
Конечно же они там все знают Си, как бы иначе они писали биндинги?
...что на самом деле они делали биндинги к vfs.
Не только, они делали изменения, которые вмешивались в код других файловых систем. Сам Филхо говорит о том, что он взял обвязку из ext4. Они делали дополнительную абстракцию над кодом. Отсюда и пошёл конфликт. Ряд программистов Rust for Linux полезли в рабочую систему. Им на это указали. Филхо приложил видео выступления как раз на этот счёт с тайм кодом, где указывал насколько агресивно наехали комментаторы выступления. Но если посмотреть всё выступление, то оно не даёт ответа зачем добавлять абстракцию (там есть стандартные для Rust лозунги, но не более). Это по сути было, переписать на Rust, ради того, чтобы написать на Rust. И вывод, который выходит из этого выступления именно тот, который был высказан комментатором. Что контрибуторам, которые не знают Rust, придётся учить Rust. Сказано было резко, но это правда. Этого требуют те изменения, которые пытались добавить в рамках идеи с абстракцией для файловых систем. Это закостенелость опыта, да. Это понятно. Но можно понять людей, который выступают против. Потому что поддерживать то код им. Для этого собственно и проводятся выступления, чтобы получить обратную связь. Чтобы подискутировать. Это же не рекламное выступление, типа презентации Apple. Где выступающий просто декларирует, что там новое появится в ядре.
При этом никто не мешает программистам проекта Rust for Linux писать отдельный код, не вмешивающийся в работу. И те кто пишет такой код, им не мешают вливаться в ядро. По крайней мере, я не видел обсуждений на этот счёт. Все конфликты выплывающие на свет касаются только тех моментов, когда программисты на Rust пытаются переписать рабочий код. То есть текущие контрибуторы мешают тем, кто лезет в чужую работу. И почему-то, как раз, в чужой код программисты на Rust лезут чаще. Получая закономерные гневные комментарии.
Конечно же они там все знают Си, как бы иначе они писали биндинги?
Автогенерацией например? Как некоторые Rust разработчики делают, не задумываясь о последствиях. Суть не просто написать биндинги, а конкретно взять на себя ответственность по поддержке кода. Чтобы не только Rust код курировать, а и код на C в том числе. Я об этом. Я думаю, что лишние руки в контрибуторах ядра никогда не помешают. И насколько я понял, как раз Филхо, не был заинтересован в поддержке C кода, он именно поэтому пытался влезть в некоторые системы под лозунгами безопасности кода.
Чтобы не было недопонимания. Я не выступаю против Rust. Rust имеет место быть, так как он помогает писать безопасный код. Но идиоматичный Rust слишком сильно отличается от идиоматичного C, и тем более от идиоматичного кода для ядра linux. И конфликты на этой почве будут. Потому что разработчики на C и на Rust говорят по сути на разных языках. Нужно искать подходы. Это сложно. Странно, что Филхо этого не понимал. И выводы напрашиваются сами собой
Автогенерацией из Си можно получить только наиболее слабый из видов биндинга - небезопасный биндинг на сырых указателях. Однако, цель проекта "Rust for Linux" - сделать возможным написание безопасных модулей ядра, для этой цели автосгенерированных небезопасных биндингов совершенно недостаточно.
А чтобы получить безопасный биндинг - нужно вводить абстракции и кодировать ими на уровне типов все те детали контрактов, которые в коде на Си подразумеваются и в лучшем случае описаны в документации для разработчиков.
Да, это требуется сделать для каждого элемента внутреннего API ядра, и эта задача не имеет ничего общего с переписыванием.
Да, это требуется сделать для каждого элемента внутреннего API ядра, и эта задача не имеет ничего общего с переписыванием.
Так в самом видео об этом говориться. Что это именно проблема. Так как Rust не основной язык ядра. А все эти доп.слои и абстракции создают по сути необходимость сделать Rust основным. Потому что без этого некоторые программисты проекта Rust for Linux не могут внедрить свои наработки. Суть проблемы в этом. И это не приемлемо для текущего набора контрибуторов ядра linux. Потому что они просто не смогут исправить проблему, если она возникнет на уровне Rust кода. И пока процент контрибуторов знающих Rust не будет больше чем знающих C, конфликт никуда не исчезнет
А все эти доп.слои и абстракции создают по сути необходимость сделать Rust основным.
С чего бы? Несмотря на свою сложность, биндинг остаётся всего лишь биндингом.
И это не приемлемо для текущего набора контрибуторов ядра linux. Потому что они просто не смогут исправить проблему, если она возникнет на уровне Rust кода.
Проблема, возникшая на уровне Rust кода - это проблема тех, кто поддерживает Rust код.
Единственное действие, которое и правда затрудняется для ментейнеров Си-части из-за наличия Rust-кода - это изменение внутреннего API ядра. Но действительно ли его нужно делать столь часто?
С чего бы? Несмотря на свою сложность, биндинг остаётся всего лишь биндингом.
Как я понял из конфликта, то, что хотели сделать для файловых систем было не просто биндингом. Там был довольно серьёзный рефакторинг со сломом API. Отсюда весь конфликт и начал расти. Выступление на конференции, как я понимаю, была попыткой объяснить изменения для других контрибуторов. Но что-то пошло не так.
Проблема, возникшая на уровне Rust кода - это проблема тех, кто поддерживает Rust код.
Так и есть. Но помимо поддержки Rust кода остаётся и код на C. Который всё ещё основной для ядра Linux. Отсюда получается, что контрибутор должен быть подкован в обоих языках, чтобы понимать, что проблема на определённом уровне языка C или Rust. Разделять ответственность - ошибка. А судя по выступлению и последующей хлопанью дверью. Именно так и хотели сделать. Разделить ответственность. Программисты на Rust отвечают за свою часть. Программисты на C отвечают за свою часть. Отсюда все эти странные новые API, которые пытались объяснить
А у вас есть информация о том, что конкретно там планировалось? Потому что на гитхабе ничего крамольного нет, в списке рассылки я тоже не нашёл ничего особенного...
Переписать API для файловых систем. То, что показывали на докладе, это как раз и было частью нововведений. Kent Overstreet разработчик Bcachefs, который недавно удалили из Debian, а Торвальдс прокомментировал как «зря вмержил в ядро». И это человек предлагает изменения в файловой системе. То есть наезд на нововведения был не без основательный
мой пойнт в том, что переписывать огромный пласт кода, стабильно работающего, не имеющего явных проблем кода, только потому, что появился "новый более безопасный" как минимум неразумно
Я согласен с этим, но ведь дело в том, что Rust пытаются затащить не только потому, что он появился такой прогрессивный. Есть как минимум пара веских причин:
ядро нуждается в свежей крови разработчиков, а новые поколения не горят желанием прогать на сишке с её обилием ручной работы (я не уверен, что это прям так и есть, но по крайней мере выглядит правдоподобно);
да, с разработкой ядра много проблем - обилие ошибок и уязвимостей из-за неправильной работы с памятью, серьёзные ошибки проявляются даже в подсистемах, которые должны быть стабильными как скала, вроде основных файловых систем.
Вообще то есть тенденция в эмбеде таки переходить на плюсы. Кроме уж совсем крайних случаев. Именно на плюсы, а не куда либо ещё.
fyi, если ciena metro уровня, то C++, участвовал слегка
И софт вашего роутера который передает ваше сообщение написан на Си, и код всех магистральных маршрутизаторов и мультиплексоров через который проходит ваше сообщение по пути ко мне тоже на Си
Во-первых там полно аппаратных решений, во-вторых Erlang, в третьих у того же Cloudflare весь DDoS detection и DNS stack написаны на Rust.
браузер в которм вы все это пишете написан на С/С++
Тот С++, который используется в Chromium минимально похож на C with classes. Про Firefox и говорить нечего.
операционная система того на чем вы это пишете написана на C
Да, при этом разработчик самых популярных десктопных операционных систем - главный евангелист Rust. И вполне пишет на нём код в Windows 11. Ещё один - крупный разработчик браузеров. Не замечаете закономерность?
Не умеешь - не берись.
В С есть строки?!
Тут Бьярне мимо проходил, вам ручкой помахал.
По той же причине, по которой любая попытка написать отказоустойчивое приложение приводит к переизобретению кривой косой и глючной реализации BeamVM
Затем, что в Си вы можете стрелять в ноги постоянно, и никто вам не мешает. Статистика говорит, что 75% CVE и RCE - это ошибки работы с памятью и стэком. Раст заставляет не делать эти ошибки.
зависшие указатели
если речь о dangling pointers, то они скорее висящие, нежели зависшие )
Микки маус жпг.
Вроде когда Раст собирались включать в ядро, речь шла о безопасных драйверах. Какого полезли в работающую ФС, непонятно.
Лично мне абсолютно все равно на чем написано ядро Linux, да и другим вменяемым программистам наверное тоже. Критично то что билд система для драйверов может только С. В идеале нужно уметь С, С++, Rust итп для создания драйверов. Но походу этого не дождаться в обозримом будущем. Я помню патчи финских студентов которые давали поддержку С++ в ядро и это было больше 20 лет назад, но это так - была типа дипломной работы...
Ядро это и есть на 90% драйверы.
Собственно, сейчас конфликт и заключался в том, что проект Rust for Linux пытался запихать обвязку для написания файловой системы на Rust
Судя по треду в Mastodon, кажется что там была обвязка, для взаимодействия с файловой системой из под Rust, и у человека там был поинт как раз в том, что одной из причин написания таковой, была недостаточная документация кода, на Си, при том, что сам код на Си далеко не всегда является самодокументированным, и приходится лезть и читать хедеры целиком, и разбираться, что именно делается с переданной переменной, чтобы понять заранее, что можно передать в функцию, чтобы не случился краш системы.
Я не специалист в компиляторах, но мне интересно, а комитет по стандартизации Си что-то делает в направлении безопасности этого языка? Есть ли вообще теоретическая возможность сделать синтаксис более безопасным с обратной совместимостью? Особенно, тех вещей, что касаются управления памятью.
Для этого С++, но вообще оффтоп
Чтобы сделать более безопасным, нужно не только добавить безопасные инструменты, но и убрать (подальше, или насовсем) опасные. А это уже идёт полностью вразрез с обратной совместимостью
Но, можно ведь добавить опции в компиляторах, чтобы, например, включить только новый стандарт, а остальное переделать. Проще, навенное, чем смешивать языки в ядре. По идее Торвальдс должен в первых рядах давить на комитет в этом направлении, ведь постоянно баги в ядре из-за памяти
Тогда все равно будет два языка, просто засунутые в один компилятор и запутывающие вообще всех своей схожестью
Ну, в PHP, например, есть mysql и mysqli - чтобы плавно убрать небезопасный mysql из проектов, не сломав имеющийся багаж. Думаю, можно объявить опасный синтаксис deprecated и плавно рефакторить код на новый синтаксис, сохранив обратную совместимость. Как по мне, это менее болезненно, чем радикально переписывать на другой ЯП.
Но не судите меня строго - я совсем не разработчик, и уж совсем не про C (в юности немножко изучал, в рамках УПК, наравне с QB и TP, но там давали только азы)
Делают. Всякие функции с проверкой размера буфера, например, добавляются в стандарт( upd хотя всё это было добавлено в с11, котрому уже 13 лет. В с23 в основном языковые фичи, которые не про безопасность ). Другое дело, что надо как-то заставить всех их использовать. И вот с этим есть большие проблемы - где-то компилятор протухший, где-то программист, а в результате adoption как-то страдает.
Но базовые "особенности" C просто так не обойдёшь, а без них безопасным его не сделать. Например то же автопреобразование массивов к указателям ( да и вообще отсутствие существенной разницы между ними с т.з. языка ). Такая фича как borrow checking на С непереносима если не ломать совместимость, а это чуть ли не основной момент безопасности раста.
s/Филхо/Фильо/g
Я думаю тут проблема как с раскладкой клавиатуры. QWERTY самая неудобная раскладка она появилась только потому что механические пишущие машинки заклинивали если человек нажимал клавиши расположенные рядом, поэтому самые часто используемые буквы разнесли в разные стороны.
После этого были изобретены раскладки намного более удобные чем QWERTY, но люди которые уже научились печатать на QWERTY не хотят использовать эти более удобные раскладки.
Тоже и с языками программирования, если человек гуру в C зачем ему Rust?
С знают или учат почти все программисты. Потом спокойно пишут на других языках, удобных в своих нишах.
У раста же есть свои недостатки, кому то критичные, а кому то достоинства перевешивают.
не хотят использовать эти более удобные раскладки
А зачем? Что это даст? Я программист, а не секретарша, мне скорость набора текста не важна от слова "совсем". Владение десятипальцевым слепым методом набора на QWERTY даёт скорость, которой более чем достаточно для всех моих задач (а печать одним пальцем будет медленной на любой раскладке). И возникает вопрос: а чего ради мне переучиваться? Более того, не просто переучиваться, а ещё и купить клавиатуру, на которой можно будет на кнопках вывести буквы реально используемой раскладки или переставить кнопки (ну потому что "слепой" набор как минимум на период переучивания перестанет работать и нужно будет видеть, куда надо нажимать). А потом ещё иметь дополнительные сложности при попытке поработать на абсолютно любом компе кроме собственного, потому что везде только QWERTY. Как по мне - не смотря на объективные преимущества альтернативных раскладок этот поезд уже ушёл, потому что исторически сложилась ситуация, когда смена раскладки несёт намного больше недостатков, чем преимуществ. И это далеко не первый пример, когда технически более совершенное решение проигрывает более популярному (вспомним OS/2 vs Windows, mercurial vs git, софт от DJB, …).
Неужели кто-то всерьёз собирается переписывать проект такого масштаба как ядро Linux со всеми его драйверами и файловыми системами на другом языке? Это просто нереально. Проще действительно написать всё заново, учитывая накопленный с Linux опыт. И обязательно вставить туда прослойку для поддержки драйверов Windows или хотя бы MacOs.
В итоге получится сборная солянка, и чтобы поддерживать это добро требования к разарботчикам удваиваются (а то и утраиваются, учитывая специфику раста).
В итоге через 2-3 итерации добавления новых языков ядро превратится просто в лютый неподдерживаемый треш.
Так что тут опять ситуация сводится к "старые седые деды не хотят разбираться ни в чем новом". Что, кстати, довольно забавно звучит на фоне высказываний других таких же дедов, мол, "язык программирования не важен, это всего лишь инструмент, настоящий программист может писать на любом языке".
"Седым дидам" пришлось учить растошколотронов очевидным вещам, например, что облом с выделением памяти в драйвере - это не повод ронять все ядро. Забавно, что школотронам, предлагавшим эти патчи, вообще пришлось это специально объяснять - значит, сами они никаких проблем с этим не видели, что говорит об уровне их умственного развития в целом. И вообще, вон в редоксе этом самом нужны рабочие руки, его пилит полтора инвалида. Пусть растошколотроны вложатся и покажут, как надо.
Автор этого письма - Линус Торвальдс.
Которому сейчас 55 лет. А на момент написания письма было соответственно 53 года.
Тот самый, который потом после ряда улучшений в языке и рабочих PoC, сам сказал, что "there are real technical reasons why Rust is a good idea in the kernel".
Время все расставит по своим местам, как это всегда бывает.
Которому сейчас 55 лет. А на момент написания письма было соответственно 53 года.
Не совсем понял, что вы хотели сказать этой фразой?
Не совсем понял, что вы хотели сказать этой фразой?
"старые седые деды не хотят разбираться ни в чем новом". Кстати, сам Торвальдс на растике не пишет. Только готовый код читает.
Напомню, что "в молодости" ядро Limux точно так же паниковало в ответ на любую ошибку, и "деды" (в том числе и сам Линус) точно так же медленно писали эту обработку, обучаясь её необходимости по ходу дела.
Что допустимо в исследовательском "полустуденческом" проекте, то недопустимо в софте, которое установлено на миллиардах устройств. "Седые диды" это понимают, а школотроны? Вопрос риторический, если что.
В то время когда обсуждаемое письмо писалось - статус у Rust в ядре как раз такой и был.
Но у самого ядра был уже немного другой статус, и добавлять в него откровенно самопадающие вещи Линус уже как-то не хотел. А вот растошколотроны не видели в этом "ничего такого", что возвращает нас к вопросу.
Сами-то вы с этим знанием вот прям родились?
С этим знанием никто не рождается. Но у кого-то хватает ума сначала обкатать свои решения на исследовательском проекте и набить побольше шишек перед тем, как предлагать свои патчи в мейнлайн, а кто-то считает, что это все лишнее и от лукавого, как шутил один мой знакомый в свое время: "компилируется - значит, работает".
На каком ещё проекте можно обкатать патчи в ядро Linux?
На своем форке, например. Периодически синхронизируемом с мастером. Ведь очевидно, что патчи на тот момент не были в достаточной степени протестированы, а их авторы даже не задавались вопросами типа "а что, если...". Вообще растокомпилятор печально известен своей любовью к "quiet farting" в плане выделения динамической памяти, поэтому где-то даже забавно, что Линус, который на расте не пишет, приложил усилия к изучению этого аспекта его работы, а "продвинутый молодняк", который пишет на расте ежедневно - нет. И после этого местные растаманы что-то там говорят про "дидов, которые не хотят разбираться ни в чем новом", бгг.
Ну вот они и обкатывали свои патчи несколько месяцев на форке. В чём проблема-то?
Вообще растокомпилятор печально известен своей любовью к "quiet farting" в плане выделения динамической памяти
Кому известен и в чём выражается эта любовь?
Ну вот они и обкатывали свои патчи несколько месяцев на форке. В чём проблема-то?
Действительно, никаких проблем, Линус сразу их принял же не глядя, ну.
Кому известен и в чём выражается эта любовь?
Ясно, всего хорошего.
Существует ли хоть один крупный патч, принятый Линусом сразу и не глядя?
И зачем вообще жти списки рассылки придуманы, если патчи либо принимаются сразу и не глядя, либо настолько ужасны что их авторов надо гнать из профессии?
Вы это к чему вообще ?
Претензия заявлена вполне конкретная:
Running out of memory simply MUST NOT cause an abort. It needs tojust result in an error return.
Не ронять все ядро при ошибках выделения памяти, и @KanuTaHимел ввиду именно данный пункт.
Причём тут "молодое" ядро и то как быстро принимаются патчи - к чему эта демагогия ?
С этой конкретной претензией всё в порядке. Она справедливая (была, на момент обсуждаемого письма), её приняли и код исправили.
А вот с тем, что авторов того кода можно называть "растошколотронами" только на том основании, что они посмели предложить патч, который не был принят с первого раза - я решительно не согласен.
Ну справедливости ради когда посылают патчи с плашкой [RFC] никогда и не претендуют на принятие с первого раза.
Так что это даже не "первый раз", а просто "гляньте чё я тут понаделал".
Я называю их "растошколотронами" в пику тем, кто называет старых мейнтейнеров "дидами 45+, не желающими ни в чем разбираться". Ирония в том, что в данном случае "дед"-то как раз разобрался, а вот "растошколотроны" - нет, "деду" пришлось им тыкать пальцем, что в таких-то местах (на самом деле в растовском std это происходит много где) генерируется код, который неявно аллоцирует память, и при этом не способен корректно обработать ошибку аллокации.
А никто не говорит что надо все подряд языки тащить в ядро
Ну сегодня решили начать тащить раст, а завтра выйдет новый язык который после анализа аргументов будет лучше чем раст и с, и вот уже надо новый язык в ядро тащить?
С большой долей вероятности такое "поэтапное переписывание", а точнее не переписывание а разрешение "пишите на чем хотите как договоритесь" никогда не закончится полноценным переходом на новый язык, как это часто бывает с крупными рефакторингами в крупных проектах.
Так что тут опять ситуация сводится к "старые седые деды не хотят разбираться ни в чем новом
А, собственно, почему они должны хотеть? У разных разработчиков разные предпочтения. Одним нравится С, другим Питон, третьим Раст, четвертым что-то ещё. Почему вдруг имеющиеся разработчики должны взять и захотеть писать вместо того языка на которым им нравится, на другом языке?
Принимая решения о смене языка надо быть готовым что многим из имеющихся разработчиков это не понравится, вплоть до того что они уйдут из проекта если им придется иметь дело с этим новым языком. Возможно на их место придут другие, а возможно и нет. В любом случае новым разработчикам придется не только хорошо знать раст, но и хорошо знать с и ядро чтобы работать с кодовой базой.
C Rust же он после анализа аргументов и взвешивания "за" и "против" вполне согласился.
Тут вопрос что не только Торвальдс должен быть согласен, а большинство ключевых мейнтенеров тоже должны поддержать этот путь развития. И выработать какие-то гайдлайны для разрешения ситуаций описанных в посте. Иначе выглядит странно - принимается решение о переходе на другой язык, но де факто PRы на этом другом языке блокируются некоторыми мейнтейнерами.
Эта интероперабельность только в теории good enough. На практике, да ещё и в таком большом и сложном проекте как линукс, это полное адище. Слишком разные парадигмы у языков.
Рекомендую читнуть эссе Worse is better, написанное Richard P. Gabriel. Оно мало того что интересное, так ещё и поучительное.
Он написал их несколько:
The Rise of Worse is Better
Worse is Better is Worse
Is Worse Really Better?
Back to the Future: Is Worse (Still) Better?
Back to the Future: Is Worse (Still) Better!
Worse Is Better (обзор их всех по ссылке выше)
Причём каждое последующее (кроме обзора) опровергает предыдущее :)
Как по мне, лучше бы взяли C++, а не раст, раст в целом не стоит того.
Мне интересно, а почему этот мистер Филхо не перепишет ядро и драйвера Windows на Rust? Насколько мне известно, они тоже в основном на C и C++. Там в их виндовсах проблем с безопасностью намного больше.
Вообще, бесят фанаты новых языков, которые думают, что все что написано на других языках должно быть переписано на их любимый, современный и самый лучший язык программирования. Этих "самых лучших" языком программирования штампуют каждых 5-10 лет, каждая большая IT компания пытается создать свой язык в целях вендор лока.
Короче говоря, разработчики правильно сделали, что послали их куда подальше.
…каждая большая IT компания пытается создать свой язык в целях вендор лока.
А можно подробнее, с примерами?
Да почти все. Оракл, ибм, сан, мс, гугл, эппл, даже джетбрейнс =)
Кто навскидку помнит, может продолжить
А можно пару компания - язык? (Я даже уже не буду заикаться про обоснования, что именно в целях вендор лока.)
Потому что на других платформах или сильно урезанная функциональность или вообще через ж работает.
Т.е зачастую чисто демоверсия
На какой именно платформе урезана функциональность Go? Где "ж" работает котлин?
Поскольку гугл не поставляет в явном виде железную или программную платформу, с ним получается не так в лоб.
Го создан как замена Яве для северных приложений, например гуглу не платить же сану/ораклу за лицензии, ну и перспективу тоже не отдавать. А Ява, хм, несколько подорожала для энтерпрайза.
Разработка на Котлин без Идеи (=АС) затруднительна.
Череж Ж работает например свифт на винде)
Го создан как замена Яве для северных приложений
Го создавался в первую очередь как попытка получить сравнимую с С++ производительность и простоту уровня Python, а не как замена джавы на сервере, посмотрите презентацию "Another Go at Language Design" Роберта Пайка в стэнфорде
не платить же сану/ораклу за лицензии
для этого есть OpenJDK
Разработка на Котлин без Идеи (=АС) затруднительна.
LSP котлина есть и под VSCode и под NeoVim, что конкретно заструднительно?
Череж Ж работает например свифт на винде)
Это как раз исключение, связаное с тем, что эппл целинаправлено делает так, чтобы люди не выходит из ее экосистемы. По этой же причине приложения для iOS приходится писать на маках и с пакетом xcode.
что эппл целинаправлено делает так, чтобы люди не выходит из ее экосистемы
Видимо именно по этому есть под VSCode и NeoVim. С 2015 open source и поддерживает Linux (Ubuntu на то время, сейчас расширились немного).
Вот я не понял, надо поверить в бескорыстие гугла, или в то что го проще или быстрее явы, или в то, что надо контрибутить конкуренту?
Впрочем это оффтоп.
Ладно, про котлин непонятно, но там же изначально был вендорлок на андроид.
Kotlin
Вот я не понял, надо поверить в бескорыстие гугла, или в то что го проще или быстрее явы, или в то, что надо контрибутить конкуренту?
Причем тут вера? Гугл разработал язык под свои задачи для которых существующие решения плохо подходили.
го проще или быстрее явы
Го значительно проще java как на уровне синтаксиса, так и на уровне концепций исполнения. Одно только отсуствие проблемы цветных функций делает язык значительно проще.
Оценка скорости зависит от выбраного бенчмарка, но для большинства случаев Go показывает более высокую скорость работы, меньшее время старта и меньшее потребление памяти.
что надо контрибутить конкуренту
Оракл и Гугл не являются конкурентами, они почти не пересекают по своему рынку.
вендорлок на андроид.
https://kotlinlang.org/docs/multiplatform.html
Какой нафиг изначальный вендорлок на андроид, если изначально он вообще под стандартную виртуальную машину Java делался, а на андроид был отдельно портирован?
LSP котлина есть и под VSCode и под NeoVim
Это кривой LSP от сообщества, а не официальный, от которого только проблемы. Официального/полноценного LSP просто не существует и это намеренное решение команды Jetbrains для того чтобы люди использовали IDEA. Если вы его сами не использовали, то посмотрите хотя бы отзывы о нём на Реддите Котлина
Это как раз исключение, связаное с тем, что эппл целинаправлено делает так, чтобы люди не выходит из ее экосистемы. По этой же причине приложения для iOS приходится писать на маках и с пакетом xcode.
Во-первых, для Swift существует официальный LSP в полностью открытом доступе, разрабатываемый самой Apple. Так что твои слова противоречат тому что ты написал в прошлом абзаце.
Во-вторых, для Android точно также придётся писать в Android Studio (или IDEA с плагином для поддержки Android и Compose)
Вот и МС послала его куда подальше =)
Не все такое черно - белое, полагаю. Во-первых, эти деды создали индустрию (да, тогда они были молодыми и сами продвигали новые фичи). Во-вторых, во времена ассемблера и машинных кодов, многим ресерчерам было за 40, но они легко уловили приемущество высокоуровневых языков перед ассемблером и довольно быстро перешли на фортран или Си, это была революция. Возможно, многие не видят резкой границы между растом и си и его приемущества считают не настолько ключевыми чтобы тратить время на изучение нового языка, теряя свою экспертизу
может я тоже закостенелый :), уже не работаю, но в программировании примерно с конца 60х, мне было (почти) все равно на чем писать, после знакомства с algol 68 и Эль76, что требовалось то и делал, в основном embedded systems, т.е. C, С++, хотя rust вполне нравится, но с трудом верю, что ядро Linux будет на него переписано в обозримом будущем, слишком много работы, простого интереса вероятно недостаточно, а экономический не очевиден
Команда Rust для Linux терпит поражение в сражении с разработчиками на С, её лидер ушёл из-за «нетехнической ерунды»