Комментарии 194
Во первых, вы забыли указать ссылку на первоисточник новости: https://www.opennet.ru/opennews/art.shtml?num=62685
Во вторых, вы либо по не знанию, либо намеренно исказили смысл и техническую суть проблемы:
Суть проблем с сопровождением в том, что Rust-обвязки ставят сопровождающих в зависимость от кода на языке Rust. На первый взгляд кажется, что обвязки лишь надстройки над Си-структурами и функциями, которые никак не влияют на разработку и сопровождение кода на Си. Но это не так. При наличии подобных обвязок разработчики подсистем, написанных на Си, должны учитывать влияние их изменений на продолжение работоспособности обвязок. Любое изменение структур данных или внутренних функций на Си может привести к необходимости изменения кода обвязок, поэтому влияющие на обвязки изменения в Си коде нужно отслеживать и синхронизировать с кодом на Rust. Многие сопровождающие не готовы брать на себя дополнительную ответственность за исправление проблем, возникающих в коде на Rust, и не намерены тратить своё время на отслеживание состояния Rust-обвязок.
В третьих, сам кризис:
Как вариант, Гектор упомянул привлечение Кристофа к ответственности за нарушение кодекса поведения из-за комментария, в котором Кристоф сравнил Rust с раковой опухолью. Кроме того, Гектор написал, что устал от всех бюрократических проволочек, не готов просто довериться сложившимся процессам и намекнул на привлечение социальных сетей.
После чего:
К обсуждению подключился Линус Торвальдс, который указал, что проблема возможно в самом Гекторе и его самоуверенности в том, что он знает что-то лучше других, а не в текущем процессе разработки ядра, который работает. У процесса разработки ядра есть проблемы, но это жизненная реальность - в жизни нет ничего идеального. Попытки травли через социальные сети - это то, что отбивает желание у Линуса иметь что-либо общее с подходом Гектора. Значение для Линуса имеют технические обсуждения и патчи, а не оказание давления через социальные сети.
Кристоф сравнил Rust с раковой опухолью.
Внесу небольшую корректировку. Хелльвиг не сравнивал Rust с раковой опухолью. Оригинал его сообщения доступен по ссылке.
If you want to make Linux
impossible to maintain due to a cross-language codebase do that in
your driver so that you have to do it instead of spreading this cancer
to core subsystems. (where this cancer explicitly is a cross-language
codebase and not rust itself, just to escape the flameware brigade).
Т.е. он явно объяснил, что сравнивает с раковой опухолью процесс поддержки двух-язычной кодовой базы, а не Rust.
Приведу его другое сообщение относительно Rust:
This is NOT because I hate Rust.While not my favourite language it's definitively one of the best newones and I encourage people to use it for new projects where it fits.I do not want it anywhere near a huge C code base that I need tomaintain.
Я не перевожу эти сообщения на русский язык, чтобы каждый сформировал свое личное мнение.
К позиции Хелльвига есть вопросы, но переводить её на эмоциональный уровень нет необходимости.
Суть проблем с сопровождением в том, что Rust-обвязки ставят сопровождающих в зависимость от кода на языке Rust.
Давайте почитаем вашу же ссылку ещё:
Разработчики патчей указали, что они возьмут на себя всю работу по сопровождению кода на Rust, готовы сопровождать эти патчи самостоятельно и вынесли обвязки в отдельный подкаталог (rust/kernel/dma.rs). В ответ Кристоф наложил вето ("Nacked-by") на приём связанных с Rust патчей и указал, что ему не нужен ещё один сопровождающий.
То есть, возникает абсолютно шизофреническая ситуация, когда Кристоф не хочет мейнтейнить код на расте сам, но при этом отказывается от предложения, чтобы растовские обвязки мейнтейнились их авторами, говоря, что дополнительные мейнтейнеры не нужны.
Ну, вернее, шизофреническая она, только если считать, что вся мотивация всех участников базара высказана ими же полно и без вранья. Шизофрения исчезает при вполне естественном и подтверждаемым опытом предположении, что мейнтейнер — это человек с непочиненным синдромом вахтёра, и ему хочется продолжать иметь полный и безраздельный контроль над МОЁ!!!
Значение для Линуса имеют технические обсуждения и патчи
Теперь особенно смешно это читать. Это теперь какой-то другой Линус, не тот, который же финн?
Значение для Линуса имеют технические обсуждения и патчи
Ну, да, патчи. Например, удалить разработчиков из ядра методом применения патча.
TL;DR.: Некий Christoph Hellwig устраивает срачи в сообществе, будучи противником второго языка в проекте. Конкретики и технических деталей относящихся к языкам в статье нет.
Тут история как раз наоборот. Срач устроили адепты Rust. В привычной им манере выйти в Twitter, и там написать гневное письмо. Я даже видел срачи во всяких Rust пабликах. А по факту, если разбирать конкретную ситуацию, можно заметить, что Кристоф не отказывает авторам патчей на Rust воспользоваться другим путём, добавив не обобщённую обвязку на весь DMA API, а на каждый драйвер в отдельности. И в этом есть рациональное зерно. Потому что если проблема будет только в драйвере, то его можно одного будет откатить или заблокировать без серьёзных проблем. А если проблема будет во всём DMA, то восстановление работоспособности может быть проблемой, так как нужно будет искать проблему не в коде одного языка программирования. И это сложно. Я это знаю, так как работал с многоязыковой кодовой базой. Тот ещё геморрой
Я не в курсе ситуации, претензия была к качеству пустопорожней статьи, которая местами одну мысль гоняет трижды) "TL;DR.:" предваряет основные тезисы для экономии времени читателя.
И в этом есть рациональное зерно. Потому что если проблема будет только в драйвере, то его можно одного будет откатить или заблокировать без серьёзных проблем.
Не правда. Крис предлагает копипастить одни и те же обвязки в каждый драйвер и если в С коде что-то поменяется, то все эти обвязки нужно будет такой же копипастой менять. Главное, чтобы в его папке никакого раст кода не было, а то проект будет тяжело "грепать"
What does "your code" mean? Duplicated in every driver?
Yes, interfaces to the DMA API should stay in readable C code and not
in weird bindings so that it reminds greppable and maintainable.
Не правда. Крис предлагает копипастить одни и те же обвязки в каждый драйвер и если в С коде что-то поменяется, то все эти обвязки нужно будет такой же копипастой менять. Главное, чтобы в его папке никакого раст кода не было, а то проект будет тяжело "грепать"
А я по вашему не это же написал? Его предложение связано с поддержкой. И я его предложение понимаю. Потому что я знаю, что из себя представляет кодовая база из разных языков.
Его предложение связано с поддержкой.
Нет, раст код будет поддерживаться только раст командой и будет работать только если в конфиге раст включить. Если же выключить, то это никак не повлияет на С код.
Потому что я знаю, что из себя представляет кодовая база из разных языков.
Ну прям достижение. Я всю свою карьеру работал с разными языками в одном проекте и ничего, разобрался как-то. Для веба это вообще-то характерно, совмещать бек и фронт в монорепе.
Нет...
А вы читали то, что сам Кристоф писал? Он именно о поддержке кодовой базы писал. И я имел в виду именно это. Почему вы отрицаете это? У вас проблемы с тем, что Rust притесняют? Не хотите молчать об этом?
Я всю свою карьеру работал с разными языками в одном проекте и ничего, разобрался как-то
А в вашем проекте писали ли код на двух языках для одной библиотеки? Когда одна часть библиотеки написана на Pascal, а другая на C. И это одна библиотека. А на трёх? Или писали ли вы C#/C++/CLI код? И вы один, кто весь этот код поддерживает. Не группа программистов, каждый из которых знает только свой язык и отвечает только за свою область компетенции. А всего один человек. Я вижу, что вы не понимаете всю особенность той проблемы о которой пытался рассказать Кристоф. Потому что у вас странное отношение к ситуации. Особенно с учётом того, что Кристоф сам не программист на Rust.
У программистов на C (или других структурных языков) другой склад ума, так как код для них должен быть линеен. Rust, из-за наличия trait'ов и макросов может скрывать реализации алгоритмов, что для программистов на C не приемлемо. В свой время по схожей причине отказались от C++ в ядре. В итоге даже кода на Pascal нет в ядре, так как у Pascal есть особенности с размещением данных в памяти. А ведь Pascal в каком-то смысле менее подвержен ошибкам, чем C.
Чтобы было понимание, я сам не против Rust. И только за развитие его в ядре. Но проблема из-за которой появился этот пост - сугубо инфантильная. Сообщество программистов ядра робеет за стабильность. Именно поэтому они отказываются от серьёзных изменений в ядре
А вы читали то, что сам Кристоф писал? Он именно о поддержке кодовой базы писал
А вы читали, что "раст фанатики" писали или сами придумали?
Again, no one asks you to deal with or maintain this piece of Rust code.
Чуваку явно 2-3 раза повторили, что от него не требуется никакая поддержка. Как можно такое пропускать?
Почему вы отрицаете это?
У программистов на C (или других структурных языков) другой склад ума
Мне все ясно. Можете дальше не продолжать, с другим складом ума вам наверное пора в спецучереждение для людей "с другим складом ума"
А вы читали, что "раст фанатики" писали или сами придумали?
Я прочитал всё ветку. И знаю, что предлагали Rust программисты. Но вы не просто так указали про фанатиков, верно? Вы мне так противопоставляете какие-то мои слова. Но ведь я про фанатиков нигде не писал. Я указал адептов ранее, в контексте, что неразобравшись в проблеме они понесли новость, будто их святыню - Rust - обидели в ядре linux.
Чуваку явно 2-3 раза повторили, что от него не требуется никакая поддержка. Как можно такое пропускать?
Почему не требуется поддержка, если это его прямая обязанность? Как раз у людей, кто раздул из этого срач, проблема с восприятием, особенно непонимающих, как это - работать с кодом, которому уже больше 30-и лет. Что просто так людей не меняют в проекте только из-за того, что кто-то другой в код влил патч. Rust'у в ядре быть, но не так как хотят авторы rust-кода.
Мне все ясно. Можете дальше не продолжать, с другим складом ума вам наверное пора в спецучереждение для людей "с другим складом ума"
Если вы здесь, значит там день открытых дверей
Если вы здесь, значит там день открытых дверей
Для меня программисты такие же люди, как и любой другой профессии. Нету ни у кого никакого "другого" склада ума, особенно у "С" программистов. Всего лишь дело привычки и навыка, который может развить любой человек. Зато сразу понятен ваш уровень ЧСВ. Попроще надо быть.
То есть вы бросаться оскорблениями можете, а другим нельзя? А не у вас ли ЧСВ? Я здесь вам только оппонирую. Если бы хотели остановиться, то остановились бы. Но я вас задел, ведь. И вы не можете молчать
То есть вы бросаться оскорблениями можете
Примеры будут?
Но я вас задел, ведь
Не перепутали? Это я вас так задел, что аж про "другой" склад ума полезло. А то лезут всякие "тупые" в священную башню со слоновой кости. Меня это очень позабавило. Я вообще к расту отношения не имею, мне все равно на каких языках ядро написано, лишь бы работало хорошо.
Примеры будут?
Вы «на двачах» учились беседы вести?
Можете дальше не продолжать, с другим складом ума вам наверное пора в спецучереждение для людей "с другим складом ума"
А то лезут всякие "тупые" в священную башню со слоновой кости.
Вот примеры.
Это я вас так задел
Ну задели, и задели. Если вас это порадует, то можете себе записать ранение. Мало ли вас таких в интернете. Я на себя не проецирую. Лишь указываю на ваши ошибки.
...что аж про "другой" склад ума полезло.
Потому что я работал с чисто C программистами. И у них совершенно другой подход в архитектуре кода из-за простоты языка. Отсюда как раз выходят особенности, как построения кодовой базы, так и её поддержки. Архитектура кода Go или Java, да даже Rust сильно отличается от того с чем работают программисты на C. И именно из-за не соответствия подходов к работе над кодом возникают конфликты.
Я вообще к расту отношения не имею, мне все равно на каких языках ядро написано, лишь бы работало хорошо.
Странно тогда видеть вас в комментариях
Прочитал внимательно о чём они там в оригинале переписываются.
Кристоф этот -- динозавр и rust-hater, там всё более, чем очевидно.
your shiny language of the day
Дальше он говорит
deal with the impedence mismatch yourself
На что ему отвечают
This is exactly what we're doing and proposing here, isn't it?
Но его интересует не "как будет лучше для ядра, сообщества, и Линукса", а как будет удобнее ему, потому что неохота делиться своей маленькой властью -- именно что синдром вахтёра, в самом чистейшем и очевидном виде -- и неохота учить новое, потому что "мы тут 40 лет на Си, ишь тут ходют всякие, напридумывали своих shiny language of the day, щенки"
А зачем растерам этот токсичный Линух?
Пусть идут в Redox там их ждут не дождутся чтобы сделать истинно безопасную ОС. А они в отсталый Линукс рвутся причинять добро.
Вы вопрос неверно ставите. Растерам вообще этот Линух не нужен. Это части разработчиков ядра Линукс нужен Раст. Спросите их, зачем.
Так даже намного лучше будет – опытные разработчики ОС, перейдут в новый, стильный, модный, молодежный проект, чтобы сделать его как надо. Что может быть лучше? И пусть Линус и другие старперы и дальше мучаются с этим жутким и опасным C.
мучаются с этим жутким и опасным C.
Подавляющее большинство уязвимостей в ядре — memory corruption:
Поэтому да, C действительно жуткий и опасный, потому что в расте доброй части этих ошибок не было бы. И, как следствие, части других тоже не было бы, потому что ограниченный диапазон внимания программиста не распылялся бы на то, как бы сконкатенировать две строки без добавления remote shell'а, и у программиста было бы время и силы подумать о чём-то ещё.
Увы, Linux — это же монолит. И stable api is nonsense. Поэтому переписать Linux на Хруст или что-то подобное невозможно.
Надо писать нормальное микроядро усим миром. И вот его-то можно на Хрусте, а горбатого — могила исправит.
Поэтому переписать Linux на Хруст или что-то подобное невозможно.
Но можно делать как в Android, например — писать новый код на хрусте. Для них это работает (хоть по версии некоторых местных это и недостаточно большой проект для демонстрации успехов).
Надо писать нормальное микроядро усим миром.
По соотношению затраченных усилий и пользы вводить раст в линух кернел мне представляется более эффективным приложением этих самых усилий.
В идеальном мире мы всё описывали бы на коке и экстрагировали бы неважно куда, и видал я этот раст в гробу, если честно, но мир не идеальный, увы.
например — писать новый код на хрусте.
Как показывает практический опыт работы в корпорации, такое работает только если эти группы (новорегов и старпёров), отделены стандартизированным API. В противном случае получается свара.
Поскольку stable API is nonsence, внутре ядра Linux места для Хруста нет. Как бы это кому ни хотелось. Законы бытия таковы — если этого не сделать, группы разосрутся и вместо вывоза говна на поля начнут лить его друг на друга.
Правки эти байндингов чисто механические, и их неактуальность выявляется в компилтайме. Практический опыт показывает, что это составляет не больше проблем, чем обычные слои изоляций в виде разных API между системами.
Административные проблемы техническими средствами решаются не всегда.
Административные проблемы отлично решаются экономическими стимулами. Будет достаточно нужно редхату/интелу/гуглу/микрософту раст в ядре (а им уже нужно, как показывают новости) — пойдёт этот Кристоф на мороз вслед за Гектором, а Линус будет вместо истории изучать rust handbook.
А если тут ещё государство что-нибудь окончательно потребует… вот это ржака будет, я ради таких лулзов даже свой анархо-капитализм поумерить готов.
Странная статистика. Кстати, с чего бы такой взрыв в 2024ом? Качество программистов уменьшилось, или они забыли внезапно C? Вот, input validation уменьшается от года в год, а memory corruption почему-то растет.
Скорее искать начали лучше. Там же свёртка из двух распределений вероятности — вероятность поставить ошибку здесь и сейчас, и вероятность найти ошибку, поставленную ранее.
UPD. Блин, забыл про третью функцию — классифицировать кусок кода, как ошибку или предупреждение. И можно переклассифицировать. Так что две свёртки.
Он именно о поддержке кодовой базы писал.
Он писал взаимоисключающие параграфы «мне не нужны помощники, мне норм самому» и «я не хочу мейнтейнить растобайндинги, потому что это слишком сложно».
Это имеет смысл только в том случае, если он относится к коду как к своей территории, и не хочет пускать на эту территорию чужаков. А это — профнепригодность для мейнтейнера.
А в вашем проекте писали ли код на двух языках для одной библиотеки?
В моих — да. У меня даже были проекты (например, с кусками на C++ и на питоне), и я не знал один из этих языков и не хотел его знать, и при этом всё нормально работало, потому что поддержка соответствующих частей была на энтузиастах этого языка.
Были и проекты на двух языках в одной либе, которые я поддерживал один, и тоже норм было.
И вы один, кто весь этот код поддерживает.
С чего бы? Ему предлагают помощь, он отказывается.
Я вижу, что вы не понимаете всю особенность той проблемы о которой пытался рассказать Кристоф.
Я как раз прекрасно понимаю эту проблему. Кристоф хочет продолжать быть королём в своём уютном загончике, а тут опасно близко подходят люди, могущие показать, что король-то голый.
У программистов на C (или других структурных языков) другой склад ума, так как код для них должен быть линеен.
Что программисты на C (те, которые не осилили другие языки) не могут рассуждать о коде, давно известно, ведь the first letter in "CVE" stands for the C Programming Language. Даже две строки сконкатенировать без того, чтобы remote shell дать, получается не всегда. Совсем не всегда.
Особый склад ума. Единственный ваш тезис, с которым я согласен.
Rust, из-за наличия trait'ов и макросов может скрывать реализации алгоритмов, что для программистов на C не приемлемо.
Знаете, как в ядре разные штуки сделаны в окрестности тех же ФС или драйверов? Там структурки с указателями на функции лежат, и эти структурки ровно этим занимаются: скрывают реализации алгоритмов. Или я что-то пропустил, и разные кристофы и анимерабы их уже выпилили?
Более того, даже простой вызов sort или там, не знаю, list_add_rcu ровно это и делает: скрывает реализации соответствующих алгоритмов. Это основа и вообще raison d'etre процедурного программирования, и она появилась даже до С (и поэтому в С эта революционная технология присутствует).
Дальше, по предыдущему вашему офигительному тейку:
И в этом есть рациональное зерно. Потому что если проблема будет только в драйвере, то его можно одного будет откатить или заблокировать без серьёзных проблем.
Это настолько вызывающе неверно, что, во-первых, смешно, а, во-вторых, вы точно занимаетесь программированием дальше хобби-проектов-однодневок?
Если проблема в обвязках, то их точно так же можно откатить или «заблокировать» (что бы это ни значило) без серьёзных проблем для сишного кода. Централизованные обвязки здесь не делают хуже.
Если проблема в обвязках, то драйвера на расте будут страдать независимо от того, что представлены эти обвязки одной копией рядом с исходной сишной реализацией, или методично скопированы в каждый раст-драйвер. Ну просто потому, что код один и тот же, блин. Копирование здесь не делает лучше.
Исправление проблем в обвязках потребует исправлять их в каждой из копий, которые неизбежно (эмпирический закон эволюции копипасты) разойдутся в мелочах (и не очень), что потребует куда больше усилий. Копирование здесь делает строго и существенно хуже.
Предлагать копипастить, особенно с таким обоснованием, как у Кристофа — это чисто политический манёвр «ну я же предложил что-то, чё эти несогласные бухтят, вечно недовольны». Абсолютно так же вёл себя один мой коллега на одной работе, например, выступавший против автоформаттеров кода (и консистентного форматирования кодовой базы вообще), мол, они ограничивают его свободу. Только он предложил мне мне самому написать по-быстрому форматтер кода для плюсов (у которых неразрешимая по Тьюрингу грамматика для начала, напомню), так как ни clang-format, ни один из кучи других форматтеров его не устраивали, и «у нас была очень специфичная база со специальными потребностями». Менеджмент схавал, а больше и не надо.
Абсолютно так же вёл себя один мой коллега на одной работе, например, выступавший против автоформаттеров кода (и консистентного форматирования кодовой базы вообще), мол, они ограничивают его свободу.
Ну откровенно же бесят эти автоформаттеры. Правда не настолько, чтобы упираться рогом, в конце-концов, за исключением паталогий вроде ocamlformat, вопрос выеденного яйца не стоит.
Единственный автоформаттер, который меня действительно бесит — ormolou. clang-format же достаточно неплохо настраивается.
В любом случае
std::string foo(int * ptr, int*otherptr) {
if (doStuff)
{
if(otherStuff) {
doSomething();
doThings(); }
} else
{
doMoreThings();
return
"success";
}
}бесит больше, особенно когда строк не 10, а 100.
И нет, я не утрирую, весь код за авторством товарища был таким.
И нет, я не утрирую, весь код за авторством товарища был таким.
У нас в той группе, где я работал, долгое время подход был простой: противно смотреть, ну отформатируй. Но в целом, всем было насрать - все профессионалы, значит без особого напряжения могут прочесть любой стиль форматирования (и приведённый выше тоже читается, хоть и противно). Основное время же всё равно тратилось на выяснение того, что откуда вызывается, и как это изменить, чтобы не поломать. Но там, как правило, код был более-менее отформатирован, просто несколько разных стилей применялось в разных библиотеках/файлах.
Единственный автоформаттер, который меня действительно бесит — ormolou.
Ocamlformat'овцы несколько кладут на обратную совместимость по форматированию. Что уж проще проверки регрессий для автоформатировщика?
Он писал взаимоисключающие параграфы «мне не нужны помощники, мне норм самому» и «я не хочу мейнтейнить растобайндинги, потому что это слишком сложно».
А где здесь взаимоисключающие параграфы? Вы то же из тех кто не понимает, но «со вселенской несправедливостью нужно бороться»?
Даже больше, оба ваших перевода неверны. И вы просто набрасываете. Как собственно все неравнодушные адепты Rust'а в пабликах, как только переписка всплыла в новостях.
Единственная верная суть в этом, что поддержка большой кодовой базы - это не биндинги написать. Не даром сам Торвальдс дал комментарий. Суть которого сводится к тому, что это не Rust плохой, а программисты на Rust плохие. Плохие для ядра linux. Им нужно меняться. Это был для них по сути совет. Как мальчик, которого бросают в воду, чтобы он научился плавать, не может изменить физику воды. Так и программисты на Rust не могу сломать принятые стандарты разработки внутри ядра linux. Когда-нибудь это произойдёт, но не в ближайшее время.
А пока что, всё то, что происходит вокруг таких новостей и постов - это просто вбросы ради просмотров.
...потому что поддержка соответствующих частей была на энтузиастах этого языка.
Это как раз показывает ваше непонимание. В ядре linux никто не будет ждать, что за дело возьмётся энтузиаст своего языка. Сломалось? Нужно чинить сразу. А лучше вообще не ломать. Отсюда эта неприязнь нововведений. Которая оправдана. Это в махровом энтерпрайзе на поддержке на аутсорсе исправление ошибок могут ждать неделями. Ядро linux - критическое ПО.
Я как раз прекрасно понимаю эту проблему. Кристоф хочет продолжать быть королём в своём уютном загончике, а тут опасно близко подходят люди, могущие показать, что король-то голый.
Вы думаете только один Кристоф работает над DMA? Он там далеко не один. И его решение поддерживают. Бугуртят в основном именно обиженки из Rust загона. В то время как никто им не запрещает работать над ядром, им рекомендуют делать это в контролируемых рамках.
Знаете, как в ядре разные штуки сделаны в окрестности тех же ФС или драйверов? Там структурки с указателями на функции лежат, и эти структурки ровно этим занимаются: скрывают реализации алгоритмов. Или я что-то пропустил, и разные кристофы и анимерабы их уже выпилили?
А что они скрывают? Реализация остаётся реализацией внутри своего же отдельного блока кода, и даже единицы трансляции. Структура определена. Это не макрос или трейт, которые могут быть в других крейтах. Если трейт это ещё более менее определённая штука, то макрос может быть вообще чем угодно. Или я опять что-то упустил?
Если проблема в обвязках, то их точно так же можно откатить или «заблокировать» (что бы это ни значило) без серьёзных проблем для сишного кода. Централизованные обвязки здесь не делают хуже.
Это как раз вы не понимаете. Если было изменение в обвязке, то просто так откатить ей не просто, так как все драйвера будут задеты изменениями, в отличии от изменений отдельного драйвера.
Копирование здесь не делает лучше.
Копирование делает поддержку проще.
Предлагать копипастить, особенно с таким обоснованием, как у Кристофа — это чисто политический манёвр...
Нет там никакого политического манёвра. Это фантазия. Заменят Кристофа - будет кто-то другой. Адепты Rust пусть попытают удачу в этом направлении. Это же не сложно - на собрании выдвинуть свою кандидатуру в мейнтейнеры DMA. Примут ли их кандидатуру? Вот в чём вопрос
А где здесь взаимоисключающие параграфы? Вы то же из тех кто не понимает, но «со вселенской несправедливостью нужно бороться»?
Рассказываю на пальцах, ELI5:
Есть функция на С, которая будет использоваться в 5 драйверах на расте. Можно сделать одну обвязку и использовать эту обвязку 5 раз. А можно в каждом драйвере одну и ту же обвязку копипастить. А потом С функция поменяется и что надо будет делать? Правильно, либо изменить одну обвязку, либо 5 одинаковых обвязок копипастой. Надеюсь теперь более понятна суть претензии?
Надеюсь теперь более понятна суть претензии?
Она изначально была понятна. Как это меняет суть отказа? В этой части кода ядра важна стабильность. Мейнтейнеры хотят продолжать поддерживать эту стабильность. И для меня лично понятно почему. Если вы этого не понимаете? Штош. Результат отказа всё равно это не изменит
А где здесь взаимоисключающие параграфы?
Потому что если бы было норм самому, то не было бы «слишком сложно». А если слишком сложно, то помощники не помешают.
Я прямо чувствую себя неудобно, объясняя базовые логические выводы.
Даже больше, оба ваших перевода неверны.
Я взял переводы по ссылке товарища выше. Конечно, понятное дело, переводы верны, когда надо опровергнуть исходную статью, и переводы неверны, когда из них следуют неприятные для вас вещи.
Как собственно все неравнодушные адепты Rust'а в пабликах, как только переписка всплыла в новостях.
Я не знаю раст, не хочу его знать, и в мои планы не входит его изучение. Попробуйте адхом ещё раз.
Единственная верная суть в этом, что поддержка большой кодовой базы - это не биндинги написать.
Ага. А ещё поддержка большой кодовой базы — это не драйвер написать. И не бинарный блоб для amd влить. И что это говорит о всех тех людях, которые этим занимаются?
Не даром сам Торвальдс дал комментарий.
Ух! Сам Яжефинн Торвальдс!
Суть которого сводится к тому, что это не Rust плохой, а программисты на Rust плохие. Плохие для ядра linux. Им нужно меняться. Это был для них по сути совет. Как мальчик, которого бросают в воду, чтобы он научился плавать, не может изменить физику воды.
Дискурс уровня базара (не в смысле того, что противопоставляется Собору Рэймондом, о котором я говорил выше, а в смыле базарных бабок).
Это как раз показывает ваше непонимание. В ядре linux никто не будет ждать, что за дело возьмётся энтузиаст своего языка. Сломалось? Нужно чинить сразу.
Вы снова врёте: ждать не нужно, потому что люди вполне себе готовы взять на себя обязательства по мейнтейнерству.
А лучше вообще не ломать. Отсюда эта неприязнь нововведений. Которая оправдана.
Да, в ядре линукса же ничего никогда не вводят (даже когда уже что-то работает, см. фолианты, скажем), не ломают, и так далее.
Ядро linux - критическое ПО.
Для этого есть LTS-релизы.
Вы думаете только один Кристоф работает над DMA? Он там далеко не один.
Конечно. Царёк в загончике тоже не один. Но царёк опирается на безапелляционный авторитет у прочих членов загончика, который в linux kernel пока ещё хотя бы на словах следует меритократическим принципам.
А что они скрывают? Реализация остаётся реализацией внутри своего же отдельного блока кода, и даже единицы трансляции.
Нет, конечно. Если бы это было так, то у вас все функции были бы в одной единице трансляции, в одном большом таком .c-файле, а это, очевидно, не так.
Вы точно понимаете, о чём пишете, или просто какие-то умно звучащие слова накидываете?
Если трейт это ещё более менее определённая штука, то макрос может быть вообще чем угодно.
Что, в ядре линукса и сишные макросы уже запретили?
Если было изменение в обвязке, то просто так откатить ей не просто, так как все драйвера будут задеты изменениями, в отличии от изменений отдельного драйвера.
Казалось бы, сишник с его #include должен понимать, что нет никакой разницы вообще с точки зрения влияния изменений между #include "foo.h" и копированием содержимого foo.h на место инклюда. У меня таки начинают закрадываться некоторые подозрения.
Копирование делает поддержку проще.
Лол.
Потому что если бы было норм самому, то не было бы «слишком сложно». А если слишком сложно, то помощники не помешают.
А исключение здесь где? То, что помощники могут помочь ещё не означает, что они нужны. И то, что кто-то не хочет делать дополнительную работу, не значит что ему нужны помощники. Взаимоисключения здесь нет. В ту же логику можно принести - зачем усложнять там, где усложнения не требуется. Или зачем исправлять то, что и так работает хорошо.
Я взял переводы по ссылке товарища выше. Конечно, понятное дело, переводы верны, когда надо опровергнуть исходную статью, и переводы неверны, когда из них следуют неприятные для вас вещи
Так вы оригиналы посмотрите, чтобы не терять смысл заявлений. И для более детальной картины всех заявлений Кристофа. Потому что переводы не верны, а дёргать отдельные выражения без контекста - портить суть его слов и своего лично понимания.
Ага. А ещё поддержка большой кодовой базы — это не драйвер написать. И не бинарный блоб для amd влить. И что это говорит о всех тех людях, которые этим занимаются?
Так и Кристов не драйверы пишет. Он сопровождает одну из критических подсистем ядра.
Вы снова врёте: ждать не нужно, потому что люди вполне себе готовы взять на себя обязательства по мейнтейнерству.
А где я вру? Мои слова описывают ситуацию, когда есть кодовая база двух языков, где один язык поддерживается одним, а другой - другим мейнтейнером. И для исправления ошибки кто-то в любом случае будет ждать выполнения работы другого. Вы же не знаете как будет, как будет и сколько это времени займёт. И я не знаю. И Кристоф не знает. Но с точки зрения простой логики зачем создавать сложности на ровном месте и вносить дополнительный процент риска там где он не нужен.
Для этого есть LTS-релизы.
А для тестов и экспериментов отдельный ветки и форки.
Конечно. Царёк в загончике тоже не один. Но царёк опирается на безапелляционный авторитет у прочих членов загончика, который в linux kernel пока ещё хотя бы на словах следует меритократическим принципам.
Все кто находится в загончике чувствуют себя хорошо. И им не нужна помощь. О чём собственно написал Кристоф. Всё остальное, в том числе и эта статья - это всё из-за «вселенской несправедливости».
Что, в ядре линукса и сишные макросы уже запретили?
А C-макросы могут генерировать код? Я вроде думал, что они просто подменяют текст.
Лол.
Это понимание приходит со временем.
А исключение здесь где? То, что помощники могут помочь ещё не означает, что они нужны.
Если человек не может выполнять работу сам, значит, нужны.
В ту же логику можно принести - зачем усложнять там, где усложнения не требуется.
Если не требуется. А переход на rust — это вполне себе полезное изменение.
Так вы оригиналы посмотрите, чтобы не терять смысл заявлений. И для более детальной картины всех заявлений Кристофа. Потому что переводы не верны, а дёргать отдельные выражения без контекста - портить суть его слов и своего лично понимания.
Окей, покажите, где что выкинуто из контекста, и где переводы неверны. С отсылкой к оригиналу, конечно.
Так и Кристов не драйверы пишет. Он сопровождает одну из критических подсистем ядра.
А будет сопровождать вместе с кем-то ещё на пару, как ему и предлагают. Не вижу ничего страшного.
А где я вру? Мои слова описывают ситуацию, когда есть кодовая база двух языков, где один язык поддерживается одним, а другой - другим мейнтейнером. И для исправления ошибки кто-то в любом случае будет ждать выполнения работы другого. Вы же не знаете как будет, как будет и сколько это времени займёт. И я не знаю. И Кристоф не знает.
После принятия этих байндингов и покажут себя. Пока драйверов на расте немного, так что ничего страшного в этом нет.
А гарантий времени реакции нет ни у кого, даже у Кристофа. Или какое у него там SLA и что будет, если он его нарушит? Поэтому избирательно напирать на отсутствие гарантий от этих мейнтейнеров, когда их нет ни у кого — это признак либо глупости, либо интеллектуальной нечестности. Выбирайте сами.
Все кто находится в загончике чувствуют себя хорошо.
Конечно, ведь неславящих царька оттуда выкидывают.
Но это не подходит для критического, общественно важного ПО.
А C-макросы могут генерировать код? Я вроде думал, что они просто подменяют текст.
А с этим текстом потом что происходит, знаете?
И, кстати, макросы достаточно близки к тьюринг-полноте в теории (не отличаясь по выразительной силе от шаблонов, которые считаются тьюринг-полными несмотря на наличие зафиксированных в стандарте возможных ограничений на количество инстанциирований) и на практике (см. boost.preprocessor — там и циклы, и условия, и контейнеры, и много чего интересного можно сделать).
Это понимание приходит со временем.
Если вы хотите свести дискуссию к сверканию регалиями, то результат будет сильно не в вашу пользу. Я бы не рекомендовал.
Говорить, что копипаста помогает поддержке — это показывать, как говорится, что иногда старость приходит одна.
Если человек не может выполнять работу сам, значит, нужны.
Так он может выполнять работу. Свою. Ему чужая не нужна. А ему почему-то пытаются навязать другую работу.
А переход на rust — это вполне себе полезное изменение.
Может быть. Время покажет.
Окей, покажите, где что выкинуто из контекста, и где переводы неверны. С отсылкой к оригиналу, конечно.
К примеру
мне не нужны помощники, мне норм самому
Он написал просто
And I also do not want another maintainer.
И не потому что они ему не нужны. У него уже есть помощники. Другие мейнтейнеры.
я не хочу мейнтейнить растобайндинги, потому что это слишком сложно
Он этого не писал.
Maintaining multi-language projects is a pain I have no interest in dealing with.
Вот его слова. Он писал не конкретно про байдинги rust кода.
А будет сопровождать вместе с кем-то ещё на пару, как ему и предлагают. Не вижу ничего страшного.
У него уже есть помощники.
После принятия этих байндингов и покажут себя. Пока драйверов на расте немного, так что ничего страшного в этом нет.
Вот когда примут, тогда и приходите. Пока что ваши же слова ниже
Поэтому избирательно напирать на отсутствие гарантий от этих мейнтейнеров, когда их нет ни у кого — это признак либо глупости, либо интеллектуальной нечестности. Выбирайте сами.
относятся и к вам в равно степени. Я же лишь вижу текущую ситуацию просто раздутой из-за нелепицы. Не приняли код на Rust в одном месте. Пусть попытает счастье в другом.Тем более, что не во всех подсистемах ядра такие отказы есть.
Говорить, что копипаста помогает поддержке — это показывать, как говорится, что иногда старость приходит одна.
А ещё спутником старости для некоторых является деменция.
Так он может выполнять работу. Свою. Ему чужая не нужна. А ему почему-то пытаются навязать другую работу.
В каком месте пытаются? Ему говорят, что обвязки готовы мейнтейнить другие люди.
Может быть. Время покажет.
Уже показало в опыте других компаний, от гугла с андроидом до cloudflare.
И не потому что они ему не нужны. У него уже есть помощники. Другие мейнтейнеры.
Где в процитированной вами фразе написано, что у него уже есть помощники?
Кстати, какие есть гарантии, что эти другие мейнтейнеры будут реагировать на проблемы в данный срок, как вы требовали ранее?
Вот его слова. Он писал не конкретно про байдинги rust кода.
Контекст дискуссии — растобайндинги. Вы говорите, что я не учитываю контекст высказываний, а потом сами берёте и выкидываете этот контекст.
А кодовая база, кстати, уже многоязычная. Проприетарные прошивки-блобы на каком языке написаны, по-вашему? Скрипты для системы сборки на чём написаны?
У него уже есть помощники.
В процитированной вами фразе этого нет.
Вот когда примут, тогда и приходите.
Говорить на серьёзных щщах «Я не буду принимать эти изменения в мой проект, пока эти изменения не покажут себя в моём проекте» не может даже сишник.
Не приняли код на Rust в одном месте. Пусть попытает счастье в другом.
Мне нравится, как легко вы распоряжаетесь чужим временем и усилиями при полном отсутствии технических причин для отказа.
А ещё спутником старости для некоторых является деменция.
Мои соболезнования, конечно, но это многое из ваших офигительных высказываний объясняет.
В каком месте пытаются? Ему говорят, что обвязки готовы мейнтейнить другие люди.
В том же где ему присылают патч с Rust кодом. Как и вы пишите выше.
Если человек не может выполнять работу сам, значит, нужны.
Он как мейнтейнер всей подсистемы отказал в патче считая, что это навредит сопровождению. Он имеет право на это. Он готов принять отдельный код на каждый драйвер, о чём написал, но не на всю систему в целом. Из-за этого начался конфликт в переписке. Из которой начали писать статьи. Будут ли помогать, не будут. Это уже не важно. Ситуация уже произошла. Решение уже принято.
Уже показало в опыте других компаний, от гугла с андроидом до cloudflare.
Красивые лозунги в новостях многие умеют писать. Это ещё ничего не говорит. Google до сих пор с заменой Java на Kotlin не разобралась у себя. Rust при этом заметно больше лет, чем Kotlin.
Где в процитированной вами фразе написано, что у него уже есть помощники?
Они прописаны в списке мейнтейнеров. Зачем их упоминать, когда они уже есть?
Контекст дискуссии — растобайндинги. Вы говорите, что я не учитываю контекст высказываний, а потом сами берёте и выкидываете этот контекст.
Потому что проблема не в самих растобайдингах. А том, где они располагаются. Кристофу инкриминируют по сути неприязнь языка Rust. В то время как сам Кристов писал, что у него нет негатива против языка. Он против тех изменений, что пришли с патчем и дал вариант решения. Это вариант решения не понравился rust-сообществу. И они разнесли это по интернету, как очередную ситуацию с притеснением языка. Из-за чего Самому Яжефинн Торвальдсу (это ваша цитата) пришлось писать комментарий на это конфликт. Весь конфликт раздут искусственно. Я комментирую, чисто из-за скуки. А вас, как мне кажется, что-то задевает. Ведь Rust'у отказали, какая же несправедливость.
В том же где ему присылают патч с Rust кодом.
Нет, конечно. Достаточно дать им мейнтейнить соответствующую субдиректорию, и нет никаких проблем.
Он как мейнтейнер всей подсистемы отказал в патче считая, что это навредит сопровождению. Он имеет право на это.
Он имеет право даже отказать в патче, у которого первый символ каждой строки, начиная с 17-й, не складывается в фразу "c{hristoph is the greatest man on earth}". Вопрос в адекватности этих отказов, и мы обсуждаем именно его.
Он готов принять отдельный код на каждый драйвер, о чём написал, но не на всю систему в целом.
Исключительно потому, что отдельный код на каждый драйвер никто не будет делать, и он это понимает.
Это уже не важно. Ситуация уже произошла. Решение уже принято.
Высечено в граните прям?
Красивые лозунги в новостях многие умеют писать. Это ещё ничего не говорит.
Там кроме лозунгов ещё есть отчёты по дырявости кодовой базы на сях и плюсах и кодовой базы на расте в андроиде, например. И есть конкретные работающие продукты, которые выбрано делать на расте. Но это всё, конечно, мелочи и лозунги.
Они прописаны в списке мейнтейнеров.
Покажите, где в списке мейнтейнеров указано, что они конкретно помощники Кристофа.
Кристофу инкриминируют по сути неприязнь языка Rust.
Ну либо это, либо он царёк с ЧСВ, тут выбора нет.
В то время как сам Кристов писал, что у него нет негатива против языка.
Человек в одном комментарии пишет по смыслу «красивые лозунги мноиге умеют писать, поэтому неважно, что говорят» и «ну раз человек что-то написал, то это должно быть правдой, буду исходить из этого».
Спасибо вам за дискуссию, вы даёте повод орать в голосину просто в каждом комментарии.
А вас, как мне кажется, что-то задевает. Ведь Rust'у отказали, какая же несправедливость.
Про своё отношение к расту я уже писал. В данном же случае меня задевает только непроходимая, фанатичная глупость некоторых персонажей, защищающих такие решения и всерьёз предлагающих копипастить код для улучшения его поддерживаемости, или очень избирательно применяющих аргументы уровня «технология может быть опасной, она не всегда приводит к тому, что хочется». Но это скорее даже не задевание, а персональный челлендж такой — получится ли что-то донести человеку, который даже осилил открыть браузер и набрать там эйч эй би ар дот ком <enter>, поэтому обладает, наверное, какими-то когнитивными способностями, или не.
Вопрос в адекватности этих отказов, и мы обсуждаем именно его.
А в чем неадекватность отказа со стороны Кристофа? Он поставил стабильность выше нововведений. Неадекватными пока что только выглядят адепты Rust. Особенно Гектор Мартин. Который ушёл из мейнтейнеров из-за обиды на слова Торвальдса. Опять же чисто эмоциональный поступок. Не прагматика движет, а эмоции. Возможно даже инфантилизм. Но это уже отдельная история.
И есть конкретные работающие продукты, которые выбрано делать на расте. Но это всё, конечно, мелочи и лозунги.
Так и на Zig сейчас проекты пишут. На Nim, Odin. (любой другой новый красивый язык) И что с того? Это нормально, что язык развивается.
Исключительно потому, что отдельный код на каждый драйвер никто не будет делать, и он это понимает.
А зачем делать на каждый драйвер? Достаточно на несколько. Показать стабильность работы кода. Объяснить, доказать верность замены. Можно попробовать так пойти. Но пошли другим путём - сраться в пабликах.
Вы проигнорировали некоторые мои вопросы, среди которых:
Где написано, что у Кристофа есть помощники-мейнтейнеры?
Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?
Является ли принятое решение в ядре высеченным в граните на века?
На каком языке написаны блобы прошивок, и как это мешает разработке?
так что я теперь буду в начале комментария их повторять и пополнять этот список.
А в чем неадекватность отказа со стороны Кристофа?
Например, в отсутствии технических причин? В предложении копипасты? В «мне сложно, но мне не нужны помощники»?
Неадекватными пока что только выглядят адепты Rust. Особенно Гектор Мартин.
Ух мерзавец какой неадекватный. Ему сказали, что результатам его труда тут не рады, и ему нужно сделать тройной тулуп с переворотом и сплясать, а он, инфантильный эмоционал, отказался тулупиться и плясать, а просто пошёл по своим делам. Ужас!
Который ушёл из мейнтейнеров из-за обиды на слова Торвальдса. Опять же чисто эмоциональный поступок. Не прагматика движет, а эмоции. Возможно даже инфантилизм.
Опять базарнобабковый дискурс пошёл.
Он это где-то написал, про обиду, про это всё? Или вы сами придумали?
Так и на Zig сейчас проекты пишут. На Nim, Odin. (любой другой новый красивый язык)
Сколько кода на Zig, Nim и Odin в AOSP? Сколько кода на Zig, Nim и Odin в клаудфларовских проксях?
Вы серьёзно не понимаете разницы, или просто упражняетесь в демагогии?
А зачем делать на каждый драйвер? Достаточно на несколько.
На каждый растовский драйвер, очевидно. Потому что без этих обвязок его невозможно написать.
Объяснить, доказать верность замены. Можно попробовать так пойти.
У этой лишней работы снова нет никаких технических причин.
Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?
Например, в отсутствии технических причин? ... В «мне сложно, но мне не нужны помощники»?
Ни один из тезисов не является правдой. Технические причины были указаны - удобство сопровождения. Про сложность Кристов не писал. Надуманное вами.
Ему сказали, что результатам его труда тут не рады, и ему нужно сделать тройной тулуп с переворотом и сплясать, а он, инфантильный эмоционал, отказался тулупиться и плясать, а просто пошёл по своим делам.
Никто не критиковал вклад Гектора в код ядра. Критика со стороны Торвальдса была в действиях Гектора в ситуации с rust кодом в DMA. Но после сообщения Торвальдса поступок Гектора выглядит как выход хлопнув дверью. Взрослые люди так не поступают. Хотя бы пытаются договориться. Дискутировать.
Он это где-то написал, про обиду, про это всё? Или вы сами придумали?
Нет. Я это додумал. И разница с Кристофом в том, что Кристоф дал альтернативное предложение. Он объяснил свою позицию. Гектор же не объяснил. Он лишь написал, что «вера у него кончилась» (это цитата).
Сколько кода на Zig, Nim и Odin в AOSP? Сколько кода на Zig, Nim и Odin в клаудфларовских проксях?
А они там должны быть? У них свои проекты. Может быть когда-нибудь они появляться в AOSP. Rust тоже не сразу там оказался.
На каждый растовский драйвер, очевидно. Потому что без этих обвязок его невозможно написать.
Ясно, понятно.
У этой лишней работы снова нет никаких технических причин.
То же самое можно перенести на ситуацию Кристофом, у него то же нет причин делать лишную работу с поддержкой кода на rust.
Вы проигнорировали некоторые мои вопросы, среди которых:
Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?
Где написано, что у Кристофа есть помощники-мейнтейнеры?
Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?
Является ли принятое решение в ядре высеченным в граните на века?
На каком языке написаны блобы прошивок, и как это мешает разработке?
так что я теперь буду в начале комментария их повторять и пополнять этот список.
Технические причины были указаны - удобство сопровождения.
Это станет техническими причинами тогда, когда будут указаны конкретные сценарии, при которых что-то будет неудобно. Потому что программистский фольклор и общий опыт показывает, что так, как предлагают растаманы, таки удобнее.
Про сложность Кристов не писал.
Писал, мол, что двуязычные кодовые базы сложно поддерживать.
Никто не критиковал вклад Гектора в код ядра.
Я не писал про критику. Вы отвечаете на какие-то собственные голоса в голове.
Кристоф дал альтернативное предложение
Которое осмысленно настолько же, насколько осмысленно предложение написать собственный форматтер кода для C++ вместо использования существующих, а иначе решить (и высечь на камне), что стиля кода нет никакого.
Он лишь написал, что «вера у него кончилась» (это цитата).
Это норм. Мы все во что-то верим — в благонамеренность тех, с кем взаимодействуем, как пример.
А они там должны быть?
Для того, чтобы это было ответом на моё «раст показывает свою пользу в крупных проектах» — да.
Ясно, понятно.
Не уверен, что вам что-либо ясно, потому что вы до сих пор воспринимаете предложение копипастить как адекватное контрпредложение.
И вы не указали, опять же, конкретные сценарии, показывающие профиты копипасты (что заставило меня добавить этот вопрос в список проигнорированных вами).
Что ж.
Это станет техническими причинами тогда, когда будут указаны конкретные сценарии, при которых что-то будет неудобно. Потому что программистский фольклор и общий опыт показывает, что так, как предлагают растаманы, таки удобнее.
Это неудобно в конкретной кодовой базе. Этого было достаточно для отказа. Не можете с этим смириться - это ваши личные проблемы.
Писал, мол, что двуязычные кодовые базы сложно поддерживать.
Сложно ему или сложно в принципе? Вот где правильный вопрос. Он указывал не лично себя.
Которое осмысленно настолько же, насколько осмысленно предложение написать собственный форматтер кода для C++ вместо использования существующих, а иначе решить (и высечь на камне), что стиля кода нет никакого.
В отличии от других участников дискусии в переписке ядра, Кристоф дал разъяснения и альтернативы. Опять же, не можете с этим смириться - это ваши личные проблемы.
Для того, чтобы это было ответом на моё «раст показывает свою пользу в крупных проектах» — да.
Пользы в крупных проектах от Rust пока не видно, чтобы так громко заявлять. То, что Rust делает кое какие вещи иначе и удобнее, я лично не отрицаю. Точно так же могут и другие языки. Часть из которых появились недавно. Время покажет что и как будет. В том числе и в ядре linux
Вы проигнорировали некоторые мои вопросы, среди которых:
Вы можете указать конкретный сценарий возникновения проблем, когда копипаста байндингов в драйвера даёт преимущество по сравнению с их централизацией в одной папочке (не обязательной для сборки ядра настолько же, насколько необязательны драйвера)?
Где написано, что у Кристофа есть помощники-мейнтейнеры?
Какие гарантии по времени отзыва даёт Кристоф и другие мейнтейнеры?
Является ли принятое решение в ядре высеченным в граните на века?
На каком языке написаны блобы прошивок, и как это мешает разработке?
так что я теперь буду в начале комментария их повторять и пополнять этот список.
Это неудобно в конкретной кодовой базе.
Я на всякий случай отмечу, что причина не становится технической от количества повторений, а конкретные сценарии вы так и не указали.
Этого было достаточно для отказа. Не можете с этим смириться - это ваши личные проблемы.
Достаточность этого для отказа в конкретном проекте просто показывает, что он окончательно скатился в клоунаду. Зачем по этому поводу испытывать вообще хоть какие-то эмоции, с которыми нужно было бы смиряться?
Сложно ему или сложно в принципе?
Сложно ему, очевидно. Или он у нас теперь демократически избранный лидер всех программистов, говорящий от их лица?
Он указывал не лично себя.
Ваша же цитата:
Maintaining multi-language projects is a pain I have no interest in dealing with.
(курсив мой)
Если я сейчас напишу «maintaining C projects is a pain I have no interest in dealing with», то это станет непреложной истиной по одному факту того, что я так написал?
Кристоф дал разъяснения
«Мне сложна но помощь не нужна»
и альтернативы
«Копипастите везде»
Вы не можете быть настолько непроходимо глупым, чтобы считать это альтернативой. Вы троллите.
Пользы в крупных проектах от Rust пока не видно, чтобы так громко заявлять.
— Польза от раста не показана.
— Результаты гугла по использованию раста в AOSP говорят об обратном.
— Nim и Zig тоже где-то используют, и что?
— Не в крупных проектах уровня AOSP или не в крупно-ответственных проектах уровня проксей клаудфлары.
— Польза раста в крупных проектах не показана.
Вы не уважаете собеседников, тролля их глупостью, поэтому я не буду уважать вас и спрошу прямо: вы идиот? Вы не можете поддерживать контекст больше, чем на 10 минут или две реплики? Или какая вообще может быть причина человеку высказывать нечётные реплики в диалоге выше?
Ну очевидно, что конкретно Кристофу добавление интерфейсов для Rust'а ничего, кроме головняка не добавляет: либо надо самому поддерживать обвязки с соответсвующим головняком при миграции, либо заниматься выпасом котов, которые будут работать над этими обвязками.
У С есть одно неоспоримое приемущество перед Rust - этот язык, в целом, мёртв. Шансов, что кто-то там что-то сделает deprecated, почти нет. Да, инструмент устарел на целую жизнь при этом, но зато никто не будет капать на мозг, что в этом сезоне мы код оформляем так, а кто не так, тот лох.
Ура, наконец-то человек, с которым достоверно можно поговорить по существу!
либо заниматься выпасом котов, которые будут работать над этими обвязками.
Зачем этим выпасом заниматься? Они уже сами предложили свою помощь и кандидатуру.
У С есть одно неоспоримое приемущество перед Rust - этот язык, в целом, мёртв.
Что имеет некоторые последствия, к слову, по части привлечения новых разработчиков (Кристоф, к сожалению или к счастью, не вечен).
Шансов, что кто-то там что-то сделает deprecated, почти нет.
Ну как тебе сказать…
Кстати, отдельный лайк за то, чтобы defined-поведение делать undefined. Такого настолько явного в настолько тривиальном коде я даже в плюсах не припомню сходу.
Да, инструмент устарел на целую жизнь при этом, но зато никто не будет капать на мозг, что в этом сезоне мы код оформляем так, а кто не так, тот лох.
Я в очередной раз напомню, что девиз ядра для ядерных вещей — stable API is nonsense.
Зачем этим выпасом заниматься?
Чтобы не остаться с чем-то недоделанным перед релизом. Впрочем, это, наверное, риторический вопрос был.
Кристоф, к сожалению или к счастью, не вечен
Достаточно очевидно, что после его смерти, это будут не его проблемы. QED.
Ну как тебе сказать…
Нормально, практически ничего.
Я в очередной раз напомню, что девиз ядра для ядерных вещей — stable API is nonsense.
Это как в разрушении песчаных замков на пляжу - разрушать нравится каждому, но только чужой замок. Кристофу, как и Линусу, нравится не иметь ответственности перед драйверопейсателями, но чтобы их инструменты были стабильны. Достаточно очевидно, не правда ли?
И чувакам из Well Typed нравится менять систему сборки GHC, но не нравится, когда меняется набор предупреждений GCC. Вот такая вот скотина девушка моей мечты.
Чтобы не остаться с чем-то недоделанным перед релизом.
А чем это отличается от любой другой вещи, которую человек не может проверить или допилить сам, вроде драйверов под железки, которых у мейнтейнера нет?
Кроме того, не вижу проблем в том, чтобы необязательные для сборки вещи были недоделанными, учитывая, что поддержка раста всё ещё находится в экспериментальном режиме.
Достаточно очевидно, что после его смерти, это будут не его проблемы.
Но я-то не Кристоф, мне интересно и важно, что будет после его смерти!
Нормально, практически ничего.
Это уже другой вопрос по сравнению с «шансов, что множество непустое, практически нет». Теперь мы уже обсуждаем меру этого множества :]
Кристофу, как и Линусу, нравится не иметь ответственности перед драйверопейсателями, но чтобы их инструменты были стабильны.
Обвязки для раста не являются их инструментами. Они ими не пользуются, и они им не нужны.
А чем это отличается от любой другой вещи, которую человек не может проверить или допилить сам, вроде драйверов под железки, которых у мейнтейнера нет?
Ничем. Именно поэтому он и не хочет нести даже малейшую ответственность за это.
Кристоф там внутри своей межушной нейросети прикинул плюсы и минусы несения ответственности за обвязки для Раста, и понял, что тут для него визгу много, шерсти мало. То есть, затраты на поддержание обвязок большие, а плюсов никаких - он ведь Растом не пользуется.
Но я-то не Кристоф, мне интересно и важно, что будет после его смерти!
Кстати, не факт. :-) Нас тут, увы, не спрашивают.
Это уже другой вопрос
Только для тех, у кого соответствующая профессиональная деформация. Вот моя профессиональная деформация про то, что абсолютно точного ничего нигде нет.
Они ими не пользуются, и они им не нужны.
Совершенно верно. Это, собственно, Кристоф и пишет в своих посланиях. :-)
Именно поэтому он и не хочет нести даже малейшую ответственность за это.
Я правильно понимаю, что в той подсистеме, которую он мейнтейнит, есть драйвера только для того, что есть лично у него?
плюсы и минусы несения ответственности за обвязки для Раста
Зачем вообще нести за неё ответственность, если ему прямо предлагалось, чтобы обвязки мейнтейнили сами растовики?
Совершенно верно.
Тогда какая им разница на стабильность этих инструментов?
Ответственность на них никто не вешает, опять же.
Ответственность на них никто не вешает, опять же.
Ну это очевидный самообман.
Зачем вообще нести за неё ответственность, если ему прямо предлагалось, чтобы обвязки мейнтейнили сами растовики?
Не зачем, а почему. Потому, что они ответственны за всю систему, а значит, ответственны за действия котов, которых пасут. А по-поводу зачем - так то, что ему, Кристофу, это лично вообще незачем, ненужно, невыгодно, я тебе и пишу который коммент.
Ты как будто никогда не участвовал в исправлении ошибок после того, как утвердил ошибочный PR. Я несколько раз участовал. Тоже очень косвенная ответственность, но она есть. И старпёры-мейнтейнеры её очень хорошо чувствуют, на уровне гениальности.
На невысказанный вопрос с устройствами:
он на это давно согласился, за них он получил плюшки мейнтейнера
он с ними уже давно научился эффективно работать, соответственно плюсы большие, а минусы стали много меньше. Rust - новое, минусы будут большими поначалу
уже выпущенные устройства не эволюционируют со временем, только уходят с рынка. В отличие от Rust и растаманов.
Ну это очевидный самообман.
А кто вешает-то? Прямо говорится, что человеку за байндинги отвечать не нужно, их будут мейнтейнить другие люди.
В чём ответственность?
Потому, что они ответственны за всю систему, а значит, ответственны за действия котов, которых пасут.
И если в биндингах для раста будут проблемы, то какие проблемы возникнут у конкретно Кристофа?
Ты как будто никогда не участвовал в исправлении ошибок после того, как утвердил ошибочный PR.
Ошибок в тех системах, за которые я не отвечал — нет. Даже если я высказывал своё ценное мнение в PR'е (чего от меня, кстати, тоже не требовали, и чего не требуют от Кристофа).
И да, даже в опенсорсе. Даже когда меня тегали на гитхабе, чтобы я отревьювил что-нибудь, отдалённо связанное с чем-то ещё, что я делал — ну посмотрел и посмотрел.
Тоже очень косвенная ответственность, но она есть. И старпёры-мейнтейнеры её очень хорошо чувствуют, на уровне гениальности.
Эта «косвенная ответственность» называется желанием быть царьком в своём загончике, опять же.
Я от этого избавился примерно на второй год корпоративной работы, а на третий — понял, что это глупое эго, не более. Нет моего кода, нет моего проекта, нет моей ответственности кроме той, которую я прямо и явно на себя взял. Не надо пытаться быть богом, не надо пытаться отвечать за всё. Более того, даже не надо пытаться понимать всё — разделение труда примерно для этого и существует.
Это понимание освобождает, рекомендую.
он на это давно согласился, за них он получил плюшки мейнтейнера
А в чём принципиальная разница? Пасти котов одинаково (не) надо и там, и там. Починить и проверить код он одинаково (не) может и там, и там. В чём разница?
он с ними уже давно научился эффективно работать, соответственно плюсы большие, а минусы стали много меньше
С кем — с ними? С драйверами устройств, которых у него нет? А в чём там вообще работа может заключаться?
уже выпущенные устройства не эволюционируют со временем, только уходят с рынка
APIшки ядра эволюционируют (stable API is nonsense же), и в работе устройств выявляются баги.
А кто вешает-то? Прямо говорится, что человеку за байндинги отвечать не нужно, их будут мейнтейнить другие люди.
Это не так, поскольку в случае любой проблемы с подсистемой, пойдут сначала к нему.
APIшки ядра эволюционируют (stable API is nonsense же), и в работе устройств выявляются баги.
За возню с этим он получает свой ярлык мейнтейнера. За возню с Rust'ом он не получит дополнительно ничего, кроме головной боли. Конкретно он, Кристоф. Всё очевидно же.
Я от этого избавился примерно на второй год корпоративной работы, а на третий — понял, что это глупое эго, не более.
Есть разные стили руководства с разными достоинствами и недостатками.
Насколько я понимаю, в разработке Linux используется стиль красных директоров — «ты царь и бог в своём загончике, но если будут проблемы, то твоя голова летит, а не головы подчинённых». С учётом того, что мы тут, а Кристоф там уже 10 лет, там так заведено. И не нам им указывать.
Это не так, поскольку в случае любой проблемы с подсистемой, пойдут сначала к нему.
Нет, конечно. Пойдут к нему с проблемой в сишной части. С проблемой в растовской части пойдут к растовикам.
За возню с этим он получает свой ярлык мейнтейнера.
А как он может с этим возиться, если у него этих устройств нет?
За возню с Rust'ом он не получит дополнительно ничего, кроме головной боли.
Ergo после того, как человек стал мейнтейнером, у него нулевой стимул добавлять в том числе новые драйверы на сишке. Я правильно понимаю, что после того, как Кристоф стал мейнтейнером, в его подсистеме не было добавлено ничего нового? Лычку-то он уже получил, зачем стараться ещё?
Насколько я понимаю, в разработке Linux используется стиль красных директоров — «ты царь и бог в своём загончике, но если будут проблемы, то твоя голова летит, а не головы подчинённых».
И какие головы там куда летят? Где можно посмотреть на примеры этой ответственности?
Так что нет, ты понимаешь неправильно.
Гектор Мартин пару дней назад заявил об уходе из разработки ядра Линукс как раз в связи с описанной Вами ситуацией.
Своим поляризирующим и излишне эмоциональным стилем изложения собственной позиции на грани флуда, он больше вредил R4L. На что ранее в мягкой форме ему было указано Торвальдсом.
Ну, если растеры хотят в ОС, то кто мешает им написать свое ядро и пусть лучший победит. Да, хоть пусть клонируют Линукс и начнут переписывать на Rust. Никто им слово не скажет. А так выходит, они хотят примазаться к уже налаженные процессы и сделать их намного сложнее, зачем? Чтобы разрекламировать язык который им нравится.
Уже есть проект - redox os.
Тут такой парадокс. Ядро на Rust миру нужно, а вот второе ядро для Linux миру не нужно. Написать микроядро для ОС людям в теме вполне под силу, а вот обеспечить совместимость с 40 лет истории и драйверов без 40 лет финансирования не сможет никто.
А так выходит, они хотят примазаться к уже налаженные процессы и сделать их намного сложнее, зачем?
Любое развитие как ни крути требует изменений. А мы, люди, внутренне часто сопротивляемся изменению наших привычек. Я думаю тут проблема не в решении (использовать раст или нет), а в его отсутствии. Часть людей хочет, часть не хочет - в итоге это разваливает выстроенное годами комьюнити. Видел хороший комментарий на hn об этом.
Чтобы разрекламировать язык который им нравится.
Почему вы так считаете? Понятное дело что у Раст комьюнити есть мода на переписывание всего подряд. Но трудно отрицать, что при сравнении С и Раст в лоб, у второго есть гора преимуществ. Вам не кажется что такой важный для всей сферы IT проект как Линукс может стать лучше вместе c Раст?
Но трудно отрицать, что при сравнении С и Раст в лоб, у второго есть гора преимуществ.
Мне легко. Я все пишу на ассемблере. С хорошим таким успехом, очень небольшим количеством багов и прекрасной производительностью. Мне даже переход на C кажется неоправданным.
Видимо на ассемблере нет программного UB, только лишь спецификация архитектуры процессора. И отвечаешь сам за выделение памяти и прочее.
Ошибку программиста (а почти все дыры ими и являются) никто не отменял. В том числе на языке ассемблера.
Это да, но очень многие ошибки на Си возникают из-за неопределённого поведения, разрешённого стандартом, но нелепого с точки зрения здравого смысла. И если на старые версии стандартов повлиять, понятное дело, нельзя, то в новых можно было бы радикально сократить количество UB -- но это не делается.
По опыту написания драйверов для Windows/Linux я не могу согласиться что много ошибок/багов было именно из языка Си, 99.9% ,багов были связаны с логикой/ алгоритмами (шифрование, репликация, файловые фильтры, сеть), дополнительно где то особенности железа кастомера привносила свое.
Для C/С++ постоянно выходят новые стандарты, которые добавляют новые возможности. Почему нельзя сделать такой стандарт, который исключит все эти неопределённые поведения?
И необходимости перехода на другие языки уже не будет.
Если есть конструкция и она работает так как разработчик и задумал на разных машинах с разными разных архитектурами и с разными флагами компиляции, то это правильно.
Сейчас C уже не так популярен. C++ пока ещё используется спросом. Но больше выбирают/учат "модным" языкам.
Почему нельзя сделать такой стандарт, который исключит все эти неопределённые поведения
Оптимизации на них держатся. А чтобы не держались нужно дизайнить совсем другой язык.
Ну, в C есть неопределённые поведения, а в Rust есть unsafe. Т.е. разработчики языка сделали его максимально безопасным, но при этом добавили возможность писать небезопасный код. Это потенциально опасная возможность, вкупе с человеческим фактором (куда же без этого), может стать источником ошибок.
Я не совсем объективен, т.к. пока ещё не осилил Rust - уж очень специфичный синтаксис. С Go, было проще, хотя и его синтаксис не сказать что привычный.
Ну и с малым размером. Ибо писать что-то большое и серъезное на асме - это наказание. Особенно, если потом надо в это через пару лет разбираться и немного переделывать. Ну и все равно используется API ядра для выделения памяти под оверлеи. Или вы не под Линукс пишете а в эмбединг?
Ну, большое – не большое, а под 500kloc писал и пишу. Вообще-то у меня большинство проектов можно скомпилировать и под Linux и под Windows – типа переносимые. И почему-то все думают, что методы написания больших проектов под асм не работают. Но это не так. Переиспользование кода, модульные архитектуры, структурное и ООП программирование – это все абстрактные сущности, которые в ассемблере работают ничуть не хуже чем в других языках программирования. И я этим пользуюсь на все 100%. И после пару (а то и больше) лет разбираюсь и переделываю легко и непринужденно. :)
И после пару (а то и больше) лет разбираюсь и переделываю легко и непринужденно. :)
Вы гений... Я в своих на асме после 5 лет уже не очень, требуется довольно много времени чтобы въехать в структуру и реализацию.
500kloc - ну, не большой проект, но уже и не маленький. У меня на асм таких немного (но есть)... Сейчас на асме только драйвера или весьма требовательные куски кода пишу, остальное - C. Недавно в проекте на Python (ARM) применил асм - вполне пошло, для ускорения.
ООП на асме - ну.... Такое себе...
Ну, были ж проекты и на несколько миллионов строк на ассемблере -- правда, не в одно рыло, но тем не менее. А в одиночку вполне реально написать проект на 50-100 тысяч строк. (Ядро RSX-11 имеет меньше, если что, -- а это, как ни крути, полноценная многозадачная ОС, пускай и с очень скромным API, если сравнивать с современными монстрами).
А насчёт переделок -- с кодом на Си ничуть не лучше, если его не комментировать. Ведь без комментариев непонятно, почему автор сделал так, а не иначе -- а, вполне может быть, для иногда очень странного кода есть разумная причина (скажем, нужно обходить ошибку в железе, совершая странные телодвижения с регистрами устройства).
Ну, на Сях все-ж проще. Причем заметно проще.
А работа с регистрами - это в основном к драйверам, там объем небольшой.
От задачи зависит. Если там, главным образом, вычисления или нечто подобное, то язык высокого уровня будет сильно читаемее, конечно. А вот если сплошные "проверить бит -- установить бит", то на асме, как по мне, даже лучше оказаться в плане читаемости может. Поэтому, скажем, драйвер некоей железяки на асме если и сложней в плане читаемости будет, чем на сях, то несильно, а вот какой-нить мозговыносительный научный расчёт... (вспомнил советскую программу расчёта зарплаты для детсадов, школ и т.п. учреждений, написанную горячими литовскими парнями на ассемблере М-5000 и затем крутившуюся на спецпроцессоре СМ-1600 -- и как весело было, когда Союз распался и потребовалось увеличивать разрядности полей данных :) ).
А вот если сплошные "проверить бит -- установить бит", то на асме, как по мне, даже лучше оказаться в плане читаемости может.
Стопудово.. Я иногда скучаю о асмовских командах установки/тестирования битов. Особенно на портах ввода/вывода (они то как раз атомарные!!!).
А вот если сплошные "проверить бит -- установить бит", то на асме, как по мне, даже лучше оказаться в плане читаемости может
Стопудово.. Я иногда скучаю о асмовских командах установки/тестирования битов. Особенно на портах ввода/вывода
Вы серьёзно? Они при желании доступны через inline-ассемблер, его (или версию на C) можно завернуть в макрос, можно в функцию, можно заменить функцией или макросом из HAL-библиотеки к железке или самостоятельно написать такую (некого Аскольда Волкова интернет не помнит, а его макросы помнит).
1) Встроенный ассемблер -- расширение конкретного компилятора, а не стандарт языка, что не всегда приемлемо.
2) Написать две команды на встроенном ассемблере -- нормально, сам пишу временами. Написать целый драйвер в несколько сотен строк -- уже нет. Во всяком случае, если есть более-менее нормальный транслятор ассемблера, а не один ублюдский ГНУсный as, который заточен не на ручную работу, а исключительно на трансляцию выхлопа GCC.
3) Макросы на С/С++? Не смешите, они исключительно убоги по сравнению с макросредствами, которые бывают у развитых макроассемблеров. Не говоря о том, что макросы в языке высокого уровня способствуют запутыванию кода и возникновению проблем, и применять их нужно с осторожностью (а по возможности -- не применять вообще).
4) А ещё компиляторы любят заниматься агрессивной оптимизацией, которая временами ломает логику. Ну а набивать текст барьерами -- это и ухудшать читаемость, и ухудшать оптимизацию, ведь барьеры достаточно неизбирательные. Ну а в случае с ассемблером транслятор подобной самодеятельностью не занимается.
В общем, наличие возможности впихнуть несколько ассемблерных команд прямо в текст на С/С++ не отменяет пользы от настоящих ассемблеров.
то что у вас это получется, по моему мнению, говорит не в пользу ассемблера перед высокоуровневыми языками, а лишь о вашей неординарности.
Спасибо, но не думаю. Я довольно средний программист. Это вопрос преодоления предрассудков и прежде всего желания написать что-то реальное на ассемблере, вопреки все традиции и обычаи которые вопят: «Нельзя такое делать!»
Это вопрос преодоления предрассудков и прежде всего желания написать что-то реальное на ассемблере
конечно и это тоже, но для меня не это самая главная проблема. Главная - человеческий фактор. Это в особенности усугубляется когда людей становится больше одного.
На простом примере. Я думаю все согласятся что стандартизировать правила именования в коде это хорошо. Но как это лучше сделать? Один вариант просто документ, а второй инструмент который будет вам говорить что имя которое вы дали не выполняет требования. Для меня второй вариант просто легче. С ним мне не нужно держать в голове: "я написал функцию, нужно проверить соответствует ли это правилам именования". Конечно, можно возразить что они быстро запоминаются и тогда вносят минимальную нагрузку, но не стоит забывать про обычную невнимательность, которая присуща всем, и про новых разработчиков.
Для меня это просто вопрос перекладывая ответственности и снижения нагрузки.
Я не отрицаю что можно все это делать самостоятельно, но считаю что это значительно менее продуктивно.
Каждый отказ думать и каждое перекладывание ответственности, конечно делает работу легче, но и одновременно с этим отнимает свободу и ведет к деградации. А самое страшное, что по итогу ничего не меняется – программы как были с багами, так и остались с ними, только работают медленнее и требуют больше памяти. А мы, из-за нашего выбора даже не осознаем что они такие и считаем все нормальным. А когда поймем, что программы плохие, то мы осознаем, что не знаем как они работают. Что там под капотом происходит. Для нас программирование превращается в магию – сбор заклинаний, которые сочинил какой-то архимаг или даже бог. Никто не знает что они означают, но ведь работают и ладно.
Каждый отказ думать и каждое перекладывание ответственности, конечно делает работу легче, но и одновременно с этим отнимает свободу и ведет к деградации.
Как говаривал мой тимлид - линтер подобен страховке на кране. Сковывает, мешает, болтается - но без нее нельзя, она спасает жизни. Потому что это у Вас свобода превращается в быстрый и красивый проект, а у Васи с соседнего отдела свобода превращается в односимвольные переменные и магические константы, а править за Васей нужно будет Вам.
А самое страшное, что по итогу ничего не меняется – программы как были с багами, так и остались с ними, только работают медленнее и требуют больше памяти.
Кмк, это ошибка после - не значит в следствии. Поменялся системный подход и майндсет пользователей. Пользователь (генеральная совокупность, а не суровые хабровские гики) хочет красивости, анимации, а бизнес хочет три тысячи фичей уже вчера. И линтер спасает. Люди даже изобрели статическую типизацию для языков с динамической типизацией (хотя это не баг, а фича языка) - чтобы ошибок не было. Да и то далеко не все - посмотреть на тот же V8 - за шутками про оперативную память мы не замечаем, насколько он быстр. Чертовски быстр.
Для нас программирование превращается в магию – сбор заклинаний, которые сочинил какой-то архимаг или даже бог. Никто не знает что они означают, но ведь работают и ладно.
Так это вроде нормально. Базу какую-то знать нужно, но можно же и дальше пойти - вот Вы на асме пишите, понимаете ли вы какие вентили в какое время переключаются в процессоре? Можно ли сказать, что mov eax, ebx - это магия?
В этом же и есть вектор развития и разделения - кто-то литографы проектирует, кто-то чипы, кто-то компиляторы, кто-то уже на верхнем уровне пишет.
Вы на асме пишите, понимаете ли вы какие вентили в какое время переключаются в процессоре? Можно ли сказать, что mov eax, ebx - это магия?
Ну да, конечно понимаю. Если не на количественном уровне (информация закрытая и современны процессоры слишком сложные) то на качественном уж точно. Это абсолютно необходимо для программирования (не только на ассемблере) и оно обязательно входит в курс обучения в университете. Все кто заканчивал какое-то программирование этого проходили.
абсолютно необходимо
Зачем? Можно даже на два вопроса разбить: зачем необходимо, и почему аж абсолютно.
Потому что такие знания очень сильно улучшают качество создаваемого кода, а стоят по сути очень недорого. Вне зависимости от языка программирования.
Каким именно образом улучшают? Вам на асме, может, и улучшают, но вот рядовой погромист на рядовых плюсах (с++17) пишет идиоматичный высокоуровневый код, что он сможет у себя улучшить, если освоит как и почему те или иные элементы работают?
Если программист хотя бы приблизительно осознает как его код будет выполняться на самом деле процессором, то он сможет сделать лучший выбор кода для данной задачи. Даже если и с точки зрения языка высокого уровня разницы нет. Да и вообще, согласитесь, что всегда лучше если знаешь что происходит на самом деле. Хотя, если вы считаете что "кто умножает познания, умножает скорбь", то ладно, живите так.
А ведь программист гарантировано не будет знать правду о том, как проц будет исполнять его код. Ибо в другой редакции проца/на другой архитектуре исполнение кода буде проводиться совсем по другому. И ну уж никак не обязательно программисту досконально знать архитектуру всех возможных к применению процов. Ибо повесится он.
Согласен только на знания архитектуры кеширования. Остальное - только забивание головы мусором.
Ибо в другой редакции проца/на другой архитектуре исполнение кода буде проводиться совсем по другому.
Вроде как логично, но все равно неправильно. Код всегда выполняется более/менее одинаково. И соображения, которые работают на одной архитектуре, будут более/менее работать и на всех других. Конечно не в подробностях, но в подробностях вообще никто не знает как работают процессоры, даже те, которые их проектируют и создают.
Код всегда выполняется более/менее одинаково.
Это с учётом того, что ассемблер x86-64 - это компилируемый язык среднего уровня? Реальный-то язык современного десктопного процессора, в который компилируется x86-64, закрыт и, видимо, сильно разный для AMD/Intel.
Реальный-то язык современного десктопного процессора, в который компилируется x86-64, закрыт и, видимо, сильно разный для AMD/Intel.
Лол, он сильно разный даже просто для разных поколений Intel. Мой любимый пример — разное поведение по зависимостям между 128- и 256-битными версиями simd-регистров в зависимости от конкретного поколения микроархитектуры интелов (где-то vzeroupper надо делать, чтобы OOO нормально работало, где-то — нет).
Если программист хотя бы приблизительно осознает как его код будет выполняться на самом деле процессором, то он сможет сделать лучший выбор кода для данной задачи.
Можете пояснить, как конкретно понимание физического уровня до вентилей помогает в написании прикладного кода?
Знакомы ли вы с математической логикой, теорией типов, теорией категорий, и если нет, то почему? Не считаете ли вы, что они тоже улучшают качество кода?
Так работу проца к кешем неплохо бы и знать, - это вполне себе буст даст.
Про кэш достаточно знать, что он есть, у него есть ассоциативность, и что через него синхронизируются разные ядра (поэтому держать два счётчика, дёргаемых двумя разными ядрами, в одном кешлайне не очень хорошая идея). Где здесь физический уровень вентилей?
Один сторонник знания физического уровня и RS-триггеров уже, впрочем, обзывал меня зубрилой потому, что я просто гулю таблички с латентностью разных уровней кэша, ассоциативностью, и так далее, для нужной мне железки, вместо того, чтобы ну вот просто понимать RS-триггеры и выводить эти параметры из первых принципов и электрической схемы процессора. Впрочем, продемонстрировать вывод той же латентности кэша какого-нибудь Skylake из первых принципов и его схемы он почему-то отказался.
Ну и заодно отвечая на ваш соседний комментарий
В эмбединге, где счет на наносекунды, - таки необходимо.
Насчёт эмбеддедов и эмбеддингов не знаю, а вот в HFT, где счёт точно идёт на наносекунды, при написании кода для обычных x86_64, скажем, никакого смысла нет в знании физического уровня до вентилей.
Да, есть FPGA, но FPGA-шники не знают C++ так, как я, например, и не все задачи делаются на FPGA или требуют FPGA.
Насчёт эмбеддедов и эмбеддингов не знаю, а вот в HFT, где счёт точно идёт на наносекунды
HFT - это имеется в ввиду "High Frequency Trade"? Если оно - то там нету наносекунд, тама транспортный уровень все съест.
А вот на управлением мощными электромоторами - очень даже идет, ибо при промахе в 200 нс можно получить неплохой такой феерверк.
FPGA-шники вполне о Си знают - ибо есть комбайны FPGA+контроллер (интерфейный/загрузочный).
HFT - это имеется в ввиду "High Frequency Trade"? Если оно - то там нету наносекунд, тама транспортный уровень все съест.
Транспортный уровень у всех одинаковый, там даже длину кабелей уравнивают от серверов участников до биржевого сервера. Выигрываете вы как раз за счёт наносекунд.
А вот на управлением мощными электромоторами - очень даже идет, ибо при промахе в 200 нс можно получить неплохой такой феерверк.
Ну так как знание вентилей-то помогает?
FPGA-шники вполне о Си знают - ибо есть комбайны FPGA+контроллер (интерфейный/загрузочный).
Им точно было бы неплохо ещё знать следующий уровень - OOP и функциональщину хотя бы на уровне языка ML. Это точно помогло бы писать псевдокод, то есть архитектуру их систем, даже если они в кодировании выше С никогда за всю жизнь не поднимаются.
Ну и раз уж они работают с моторами, то там простая электроника на любительском уровне тоже не помешает. Итого, для FPGAшников полезно знать весь стек.
"Ну и раз уж они работают с моторами, то там простая электроника" - там не FPGA, там специализированный чип. Хотя и FPGA можно, но не имеет смысла большого.
"FPGAшников полезно знать весь стек " - они и так знают то, что им нужно. Включая триггеры. А те, кто портирует Verilog на технологию конкретной фабы, - так и про транзисторы, включая и квантовые эффекты.
Ну, обычный код не улучшают, кроме случая работы с кешированием - там можно раз в 10 ускориться. Но и утверждение что это стоит недорого - сильно спорное.
В эмбединге, где счет на наносекунды, - таки необходимо. В остальных случаях я не вижу значимого смысла.
А про абсолют - ну так водка и есть водка.
И все таки у меня есть ощущение некого самообмана. То, что проходят в университетах про логику работы и вентили настолько далеко от настоящего современного процессора, что общего там только базовая логика. Это как понимание того, как работает сверточная сеть для MNIST-датасета ничего особо не дает кроме базовой математики, потому что современные трансформеры и другие архитектуры очень, очень далеки от базы, и, возможно, действительно переходят черту "магии", понять которую могут очень далеко не все.
Я бы сказал словами классика: "Знать все на свете нерельно", и всегда будет та грань, после которой на своем уровне начинается магия.
В реальности используется многое из того, что преподают в университете. В итоге получается комбайн из многих базовых концепций. И вся техника построена так. Искусство состоит в том, чтобы правильно комбинировать базовые алгоритмы/техники и получать требуемый продукт.
Например, многие изучая код Хаффмана, думают что он не применяется в реальности. На самом деле применяется, но не только он один, потому что от одного его толку действительно мало. Итд ИТП)
Ну я юзаю не более 30% того, что было дадено, то есть большая часть - это просто инфомусор. И в том числе про работу триггера (статичское ОЗУ на них). И это при том, что я еще и проектировщик железа, но к уровню триггера я не опускаюсь.
Код Хаффмана применяю.
То, что проходят в университетах про логику работы и вентили настолько далеко от настоящего современного процессора, что общего там только базовая логика.
Там ровно один курс пропущен. См. книгу Харриса и Харрис.
Кмк, для сквозного понимания работы компьютера (качественного), достаточно Хоровица/Хилла, Харриса/Харриса, потом курса по компиляторам, скажем Essentials of compilers и курса по ОС. Разумеется, там могут подтянуться какие-то ещё курсы (типа TAPL, SICP), но их вполне обозримое количество.
Итого, от транзисторов до верхнего уровня. Для понимания работы транзистора от школьной физики тоже нужен примерно курс.
То есть, вполне реально, если поставить такую цель, выпускать инженеров, понимающих все уровни ЭВМ. Другое дело, что этого почему-то не делают.
Утверждаю, что спектра от Харрис и Харрис до TAPL недостаточно, чтобы понимать все уровни ЭВМ, потому что Харрис и Харрис не объясняет квантмех, лежащий за транзисторами, которые в основе всех этих вентилей, а TAPL не объясняет логико-категориальные основания математики.
Без Ландафшица с одной стороны спектра и какого-нибудь «categorical logic and type theory» Якобса с другой нельзя быть хорошим программистом, ящетаю.
Утверждаю, что спектра от Харрис и Харрис до TAPL недостаточно, чтобы понимать все уровни ЭВМ
Я не призываю тут никого это всё изучать, поэтому не надо ёрничать. А про квантмех, лежащий за транзисторами я, извини за грубость, точно побольше вашего знаю.
Я о другом. Вокруг меня как-то все рассказывают, что компьютер - это вещь непостижимая сама в себе. Ну и знания стандартного выпускника какого-нибудь физического факультета при рассказе про компьютер напоминают известный мем про рисунок совы.
1. Вот кристаллическая решётка, вот дырки-электроны, вот канал MOSFET, так он управляется. Транзистор готов. Это достаточно хорошая модель, дальше там рыть не надо.
2. Из двух транзисторов мы делаем операционный усилитель, из усилителей мы получаем дискретную логику, из 4 логических элементов - D-trigger, дальше счётчик и сумматор.
3. ----------------------------
4. Рисунко ЭВМ из Фигурнова, язык ассемблера.
5. ----------------------------
6. Язык Цэ.
7. ЯВУ высшего порядка.
Так вот, уровни 3 и 5 - это просто Харрис/Харрис и книжка по компиляторам/интерпретаторам.
Соответственно, объём знаний, достаточно цельно покрывающий работу компьютера, велик, но вполне проходим. Замечу, никакой агитации и пропаганды.
А про квантмех, лежащий за транзисторами я, извини за грубость, точно побольше вашего знаю.
Вполне возможно, особенно если говорить про транзисторную часть, а не логическую, например.
Хотя, впрочем, все релевантные дисциплины в Физтехе я сдал на отл или хор (от теормеха с введением в лагранжев и гамильтонов формализм через сам квантмех до какой-то ерунды по моделированию в том числе квантовомеханических процессов, по которой у меня был хор из-за того, что я задиристый засранец). Но да, это не моя специализация (и я приматом был), и уж точно не в моей активной памяти.
Соответственно, объём знаний, достаточно цельно покрывающий работу компьютера, велик, но вполне проходим.
Но не нужен. Потому что пока ты учишься рассчитывать фононы в кристаллических решетках и плазмоны-поляритоны на их границе (ой, надо топологию изучить, кстати, опять математика попёрла), Вася изучает паттерны, методологии разработки, рассуждения о литкод-алгоритмах на интервью вслух, командную работу и софт-скиллы, и нанимается на работу вместо тебя. А ты идёшь со своим пхд по квантам и требованием 5-7 лет опыта работы с этим вот всем в калифорнийский медстартап за смешные 50-70к в год, пока двухлетний выпускник буткампа идёт фронтендером кнопочки перекрашивать за 100-150.
Поэтому смотри, что выходит: у тебя есть куча дисциплин, освоение которых требует нетривиальных усилий, которые не приносят практически никакой пользы лично тебе, и альтернативные издержки которых ощутимо высоки. На обывательско-человеческом языке это называется «неподъёмная задача».
Но не нужен.
Это уже другой вопрос.
На обывательско-человеческом языке это называется «неподъёмная задача».
Я говорю про конкретно наше образование. А мне лично, получается, достаточно написать компилятор и немного поиграться с FPGA, параллельно читая Харрисов. И всё - гешефт закрыт, я в общих чертах понимаю всю ЭВМ насквозь.
пока двухлетний выпускник буткампа идёт фронтендером кнопочки перекрашивать за 100-150.
А если бы он пошёл работать валютной проституткой, то зашибал бы больше и раньше. Но мы ему давать советы тут, пожалуй, не будем...
Это уже другой вопрос.
Это ключевой вопрос, потому что разговор о реалистичности тех или иных сценариев развития всегда неявно подразумевают их оправданность.
А если бы он пошёл работать валютной проституткой, то зашибал бы больше и раньше. Но мы ему давать советы тут, пожалуй, не будем...
Проститутки ассоциируются с криминалом, не более. Говорят, в развитых странах с легализованной проституцией этой стигмы меньше.
Да и все мы занимаемся проституцией, продавая свои мозги, по большому счёту.
нельзя быть хорошим программистом, ящетаю.
Программистом чего? Вообще, то, что умеешь держать сразу много системных уровней, часто помогает в жизни. Естественно, при этом знания достаточно поверхностные, например, без Якобсов, но с Пирсами...
Я подозреваю, что вот всё это хорошо держать в голове при разработке всякой электроники, окрашенной в зелёный цвет. И для космоса.
Вообще, то, что умеешь держать сразу много системных уровней, часто помогает в жизни.
И это естественным образом прокачивается при работе обычным программистом ровно в том объёме, который обычным программистам и нужен.
разработке всякой электроники, окрашенной в зелёный цвет
Работа мечты!
естественным образом прокачивается при работе обычным программистом ровно в том объёме, который обычным программистам и нужен.
Ну нам-то какое дело до обычных программистов?
Работа мечты!
Люди разные.
Ну нам-то какое дело до обычных программистов?
Дело до того, что разговор с них начался, наверное? Вон какой исходный тезис был (самую важную часть выделил жирным):
Это абсолютно необходимо для программирования (не только на ассемблере) и оно обязательно входит в курс обучения в университете. Все кто заканчивал какое-то программирование этого проходили.
Нельзя такое делать!
Дак можно. И не слишком сложно. Просто зачем?
С хорошим таким успехом, очень небольшим количеством багов и прекрасной производительностью.
При этом, когда дело дошло до практики, после ваших деклараций, что код на ассемблере вполне хорош и легко поддерживаем, мы с вами попытались сравнить поддерживаемость кода на ассемблере и моих языках на примере написания парсеров. И вы отказались решать задачу, на которую мы оба согласились, и в которую я, в отличие от вас, таки вложил время и усилия. Вместо этого вы привели когда-то написанный код для какого-то другого проекта, который делает что-то отдалённо похожее, не более.
Как говорится: в чужой монастырь со своим уставом...
Для защиты прихожан от чужаков есть простой линусовский жест: "*YOU* are full of bullshit. $LangName is a horrible language". Но это не иноверцы, два креста носящие, Rust в ядро приглашён. Линус проблемы мягко обрисовывает как конфликт поколений: есть у них "old-time kernel developers", которые Rust не знают и знать не хотят (а когда закончатся - вступайте в наследство).
К тому же в этот раз могут надавить государство и корпорации. В старой истории с C++ у них интереса не было, а сейчас ОАО "Красная шляпа" и прочие могут напомнить, на чьей земле монастырь стоит.
Ах, наш Линус, такой милашка, папа может в си.
ПС: человек который создал, организовал и поддерживает более 30 лет такие важные штуки для каждого программиста как Linux и Git. Дай бог ему здоровья и долгих продуктивных лет,
Это что-то про Вавилонскую башню? Чтобы её разрушить, строителям нужно начать говорить на разных языках?
Вавилонская башня это символ экономического успеха Вавилона и его падения. Слишком большой успех привлек много иностранцев. Вавилон неосилил ассимилировать эту массу. Разные неуправляемые нравы, разные языки очень осложнили жизнь и в конце концов привели к разрушению Вавилона.
Так что, самое главное тут - управляемость проекта.
даже не так,- чтобы начать её строить, надо привлечь дополнительную рабочую силу, а там пошло-поехало, и вот мы видим «бесполезную нетехническую ерунду»
Увы, это удел всех проектов с гигантской кодовой базой и гигантским количеством инсталляций. Никто в реальности не будет их переписывать, какими бы благими намерениями это не было вызвано. Просто из-за лавинообразного нарастания сложности поддержки и дальнейшей разработки.
А могли бы просто взять С++.
Мне даже интересно, когда до них дойдёт, что С++ это неизбежность для ядра, невзирая на тупой хейт Линуса по отношению к крестам.
А что такого дали бы плюсы именно в ядре? Учитывая, что stl и прочих библиотек там нет и не будет. И скорее всего не будет исключений.
Ну я навскидку назову виртуальные функции вместо явного использования указателей на функции и "ручной" реализации VPTR. Синтаксис указателей на функции трудно назвать приятным, но само по себе это погоды не делает.
И ещё RAII вместо goto exit_N (но оно требует исключений, так что вероятно нет).
Шаблоны просто не нужны, в ядре практически нет таких задач. Раскидистые иерархии классов с множественным наследованием — наворотить то можно, но зачем?.. А что тогда ещё?
но оно требует исключений
Лечится optional'ами и expected'ами, если я правильно понял, почему "требует".
не, не лечится. Разве что костылится. См. мой коммент ниже.
возможно, в виде пачки вложенных if
Если всё завёрнуто в optional'ы, то эти if'ы будут неявными (в деструкторе у этих optional).
Ну т.е. да, это всё ещё проверки на каждый чих, но как минимум мы избавляемся от этого goto блока, и от потенциальных ошибок, что какой-то void * передали во free_resource1 вместо free_resource2.
Мы совершенно ничего не теряем, но приобретаем.
И ещё RAII вместо goto exit_N (но оно требует исключений, так что вероятно нет).
Основная идея RAII в освобождении ресурсов в ходе автоматического удаления объекта (поэтому, собственно, в названии идиомы нет ни освобождения, ни уничтожения...).
Почему отсутствие исключений не очень важно:
Не важно в деструкторе, потому что из него в любом случае не следует кидать исключения. Ещё RAII требует, чтобы освобождение ресурсов не могло сломаться, ядро Linux обычно тоже из этого исходит.
А что до acquisition & initialization, то придётся, например, удалить конструктор и собирать объект функцией, возвращающей std::optional (или как-нибудь погрязнее).
RAII без конструкторов не имеет смысла. Замена конструкторов на возврат std::optional только добавит писанины, но не избавит вас от goto (возможно, в виде пачки вложенных if).
Ну, например, вам нужно скопировать данные откуда-то куда-то. Для этого вам нужно выделить память под буфер и открыть два дескриптора. Потом, соответственно, вам надо всё это закрыть и освободить, при любом развитии событий. Если это у вас три вызова new, то всё нормально, С++ за вами приберёт, если один из конструкторов выкинет скажем bad_alloc. А если без new, то привет goto.
RAII без конструкторов не имеет смысла.
Атрибут cleanup (GNU C) считают за RAII. Его используют в systemd.
Если это у вас три вызова new, то всё нормально, С++ за вами приберёт
Если мы вручную вызвали new, то нам вручную и вызывать delete. RAII нет.
Если мы как угодно получили ресурс в конструкторе RAII-контейнера, то нам его и освобождать в деструкторе, фокус на new не нужен.
Замена исключений (в конструкторе) на std::optional (в функции, создающей объект) - это, вроде как, лишь замена одного способа обработки ошибок на другой. if'ы вместо try-catch.
Зарапортовался. Вызов new разумеется спрятан в конструкторе локальной переменной, а соответствующий delete - в деструкторе.
К слову о том, что делает systemd.
В одном файле:
// ...
_cleanup_(memstream_done) MemStream m = {};
FILE *tf = memstream_init(&m);
if (!tf)
return log_oom();
// ... (используем tf, m больше не упоминается)
// _cleanup_ определён как
// #define _cleanup_(x) __attribute__((__cleanup__(x)))В другом файле (а структура MemStream тут):
void memstream_done(MemStream *m) {
assert(m);
/* First, close file stream, as the buffer may be reallocated on close. */
safe_fclose(m->f);
/* Then, free buffer. */
free(m->buf);
}Разбросано по файлам, но memstream_done переиспользуется около 40 раз.
С RAII-на-std::optional было бы что-то в духе этого:
// ...
std::optional<MemStream> m = MemStream::TryCreate();
// Вместо memstream_done - деструктор MemStream
// memstream_init пусть будет статическим методом TryCreate
if (!m)
return log_oom();
// ... (используем m->f)Замена конструкторов на возврат std::optional только добавит писанины, но не избавит вас от goto (возможно, в виде пачки вложенных if).
Зачем?
Maybeи Either … тьфу, optional и expected — это «линейные» монады, их можно разворачивать через co_await. Вполне можно писать код в духе
std::optional<int> getCount();
template<typename T>
std::optional<T*> allocateMem(int);
std::optional<Result> doStuff()
{
const auto count = co_await getCount();
const auto mem = co_await allocateMem<int>(count);
const auto objects = co_await initialize(mem, count);
co_return doSomethingWith(objects);
}
что stl и прочих библиотек там нет и не будет. И скорее всего не будет исключений.
stl это standard template library, для большей части из неё не нужно никаких исключений, выделения памяти и тд, ничего не мешает ей быть в ядре
RAII тоже не требует исключений, оно просто работает и с исключениями тоже ( в отличие от goto)
Факт в том, что нет никаких недостатков от перехода на С++ и стоимость крайне низкая, а вот преимуществ много - уверен, что в ядре очень много кода можно было бы избежать шаблонами или упростить constexpr, в конце концов иметь нормальные енамы вместо тех что с префиксами из-за того как работают сишные, плюс к тому С++ запрещает никому не нужны кривые конструкции из С, такие как typedef без определения типа
Проблема в том, что нельзя просто взять и договориться использовать только некоторый "полезный" сабсет с++, люди будут использовать всё что компилятор разрешит. Придётся возложить работу по копмлаенсу на людей, а это не работает.
с тем как использовать С договорились, как-то используют. Не вижу никаких проблем также сделать с С++, для начала просто переключить gcc в режим С++
На самом деле не договорились, а скорее запретили использовать нововведения. Типа когда-то начали с gnu89, и очень неохотно переходили на новые стандарты. Только в 2022 году перешли на gnu11. В языке C это позволяет не использовать не нужные вещи. В то время как в C++ всё иначе.
Сейчас не возможно заставить C++ программиста программировать на C++98. Это просто бессмыслено. Все самые важные изменения пришли в C++11, а они с собой несут очень много специфичного поведения, которые для стабильности ядра linux, могут иметь отрицательный эффект.
Проблема ещё, не возможно выделить в C++ какой-то особый набор правил типа только C с классами. Некоторые программисты например не знают, что семантика перемещения имеет свои особенности, и без костылей её не возможно применять. А костыли нужны. И часть таких костылей является частью стандартной библиотеки. А это значит, что нужно нести стандартную библиотеку языка C++ в ядро. Стандартная библиотека C++ имеет ряд особенностей, которые, опять же, могут отрицательно сказаться на стабильности работы ядра.
То есть, есть куча нюансов из-за которых просто так взять, и разрешить C++ в ядре нельзя
Все самые важные изменения пришли в C++11, а они с собой несут очень много специфичного поведения, которые для стабильности ядра linux, могут иметь отрицательный эффект.
Например?
Некоторые программисты например не знают, что семантика перемещения имеет свои особенности, и без костылей её не возможно применять. А костыли нужны. И часть таких костылей является частью стандартной библиотеки.
Например?
Ну, только чтобы это было вредно для ядра. Так-то костыли везде нужны, понятное дело.
А это значит, что нужно нести стандартную библиотеку языка C++ в ядро.
Только нужное для используемых вещей подмножество. std::thread для мув-семантики тащить не обязательно.
То есть, есть куча нюансов из-за которых просто так взять, и разрешить C++ в ядре нельзя
Этим аргументом и заботой о нюансах можно парализовать любую работу и любые изменения.
Например?
Шаблонов вполне досточно. SFINAE.
Например?
Копирование данных при неправильно перемещении. Перемещение данных при неправильно копировании. Кейсы редкие, но не невозможные.
Только нужное для используемых вещей подмножество.
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте. Сомневаюсь, что на это пойдут, если до сих пор так не сделали. А я что-то не помню, чтобы для C запрещали использовать что-то из стандартной библиотеки.
Шаблонов вполне досточно. SFINAE.
Было в C++03. C++11 добавило expression sfinae, но это вопрос юзабельности и упрощает метапрограммирование.
Впрочем, как шаблоны и sfinae влияют на стабильность ядра linux?
Копирование данных при неправильно перемещении.
operator=(const Foo&) = delete;
operator=(Foo&&) { ... }Перемещение данных при неправильно копировании.
Это надо как-то отдельно постараться ещё.
Как там с use-after-free дела, кстати?
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте.
Кто сказал?
Напомню, кстати, что ядро написано не на стандартном C, а на диалекте. Апеллировать к отсутствию каких-то ограничений в стандарте плюсов — это снова интеллектуальная нечестность.
А я что-то не помню, чтобы для C запрещали использовать что-то из стандартной библиотеки.
Что, даже thrd_create можно в ядерном коде?
Впрочем, как шаблоны и sfinae влияют на стабильность ядра linux?
А как sfinae работает? Всегда так как задумано?
operator=(const Foo&) = delete;
operator=(Foo&&) { ... }А как это поможет когда нужно и то, и то?
Кто сказал?
Хотите сказать, что нет? Вы прям можете запретить не вызывать отдельные инклюды?
Что, даже thrd_create можно в ядерном коде?
А что, запрещено документально?
А как sfinae работает? Всегда так как задумано?
Это что за аргумент вообще такой? Какой мейнстримный ЯП всегда работает так, как задумано?
А как это поможет когда нужно и то, и то?
А как сишники сейчас справляются с тем, когда нужно и то, и то?
Кстати, на плюсах я могу сделать что-то в духе
// один раз, utility-класс
template<typename T>
struct ForceCopy
{
const T& src;
explicit ForceCopy(const T& s)
: src { s }
{}
};
// ...
Foo(const Foo&) = delete;
Foo(ForceCopy<Foo>) ...
Foo(Foo&& other) ...
operator=(const Foo&) = delete;
operator=(ForceCopy<Foo>) { ... }
operator=(Foo&&) { ... }и использовать как
Foo foo = makeFoo();
//doSmthWithCopy(foo); ниработаит
doSmthWithCopy(ForceCopy { foo }); // работаит
doSmthWithCopy(std::move(foo)); // работаит
doSmthWithCopy(makeFoo()); // работаит
doSmthWithCopy(Foo { ... }); // работаит
//foo.bar(); линтер ругнётся на use-after-move— всё предельно явно, грепабельно и типобезопасно (насколько это может быть безопасно для языков C-семейства).
И линтер действительно ругнётся, например, clang-tidy:
note: Object 'foo' is moved
37 | doSmthWithFoo(std::move(foo));
| ^~~~~~~~~~~~~~
note: Method called on moved-from object 'foo'
39 | foo.bar();
| ^~~~~~~~~Хотите сказать, что нет? Вы прям можете запретить не вызывать отдельные инклюды?
Да, конечно. Например, не имея этих инклюдов в путях компилятора в процессе сборки.
А что, запрещено документально?
Лол. Lmao even. В который раз убеждаюсь, что самые ярые фанаты сишки нихрена не знают о C, а самые ярые фанаты штабильности в ядре нихрена не знают ни о конкретном обсуждаемом ядре. Кекспертиза уровня опеннета.
Читайте https://kernelnewbies.org/FAQ/LibraryFunctionsInKernel . Потом можете погрепать исходники ядра на предмет упомянутой функции. Хотя не, у вас же их под рукой нет, так что я сделаю это за вас:
10:55:43 деанон@deadzxt /usr/src/linux % grep -Rw thrd_create | wc -l
0знаете, что это значит?
Это что за аргумент вообще такой? Какой мейнстримный ЯП всегда работает так, как задумано?
C не просто так стал языком ядра, а C++ не стал. И шаблоны отчасти были тому причиной. У вас странная реакция. Сами задали выпрос. Если вещи очевидны, к чему тогда сам вопрос был.
А как сишники сейчас справляются с тем, когда нужно и то, и то?
Никак. В C нет семантики перемещения.
Да, конечно. Например, не имея этих инклюдов в путях компилятора в процессе сборки.
И вы можете запретить их добавлять? Не можете.
Читайте https://kernelnewbies.org/FAQ/LibraryFunctionsInKernel .
Вот это уже конструктивный диалог. А теперь вернёмся к моему сообщению выше:
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте.
Я об этом и написал. Для реализации на месте нужно будет ести все костыли стандартной библиотеки. Без костылей в виде std::move или std::forward из стандартной библиотеки семантика перемещения не работает. Помимо ни есть ещё целая куча вещей. Если смотреть на ситуацию с языком C++ со стороны, то отказ от него в ядре вполне оправдан
C не просто так стал языком ядра, а C++ не стал.
Например, по личным причинам — ну не нравится Торвальдсу язык, и всё тут. Или по легаси-причинам — просто потому, что в 91-м году с компиляторами и стандартом C++ было всё очень плохо.
И шаблоны отчасти были тому причиной.
Так в чём конкретно проблема со sfinae, можете сказать? Особенно чтоб в C++11 она усугубилась, как вы изначально говорили.
Сами задали выпрос. Если вещи очевидны, к чему тогда сам вопрос был.
Этот вопрос — риторический, и является ответом на ваш псевдоаргумент. Собственно, вопрос к этому ответу, и вы так и не пояснили, в чём конкретно проблемы.
Никак. В C нет семантики перемещения.
Всегда копируют, что ли? Ну вот заодно перемещать научатся. Видите, одни плюсы!
И вы можете запретить их добавлять? Не можете.
Не понял, почему не могу? Не принимаю патч, который добавляет что-то, точно так же, как не приму патч, который сегодня добавляет thrd_create.
Без костылей в виде std::move или std::forward из стандартной библиотеки семантика перемещения не работает.
Это вообще однострочники, их самому можно написать, в чём костыльность и в чём проблема?
Помимо ни есть ещё целая куча вещей.
Вы упорно избегаете конкретики, просто размахивая руками и высказывая общие тезисы.
Так в чём конкретно проблема со sfinae, можете сказать?
Безошибочный подбор правильных реализаций. Для того, чтобы избавиться от ошибочного подбора нужно строить много дополнительного не всегда очевидного с точки зрения понимания кода. Когнитивная нагрузка намного выше. Концепты исправляют ситуацию, но они в C++20.
Этот вопрос — риторический, и является ответом на ваш псевдоаргумент.
Вы могли нормальный вопрос задать с самого начала, или, если вы знали, могли бы сразу дать на него ответ.
Это вообще однострочники, их самому можно написать, в чём костыльность и в чём проблема?
Не однострочники. move как миниму на три строки. так как нужно избавиться от ссылочности перед этим. Их не должно быть вообще в стандартной библиотеке, а должны быть на уровне языка. Но реализацию уже не изменить.
Вы упорно избегаете конкретики, просто размахивая руками и высказывая общие тезисы.
Я привёл примеры. И это не единственные примеры. Я вам не обязан всю стандартную библиотеку нести. Есть вещи типа enable_if они просты в реализации, но их много
Безошибочный подбор правильных реализаций. Для того, чтобы избавиться от ошибочного подбора нужно строить много дополнительного не всегда очевидного с точки зрения понимания кода.
Что непонятно в enable_if_t?
Концепты исправляют ситуацию, но они в C++20.
Повод сразу использовать C++20!
Вы могли нормальный вопрос задать с самого начала, или, если вы знали, могли бы сразу дать на него ответ.
Мог, но имею право выражать их в форме риторических вопросов. А вы, если бы хотели донести свою точку зрения, могли бы ответить и на вопрос в такой форме.
Не однострочники. move как миниму на три строки. так как нужно избавиться от ссылочности перед этим.
template<typename T>
constexpr decltype(auto) move(T&& t) noexcept { return static_cast<std::remove_reference_t<T>&&>(t); }Их не должно быть вообще в стандартной библиотеке, а должны быть на уровне языка.
Почему? Чем std::move выше хуже std::move-магического интринсика компилятора?
Есть ровно одна причина, но она настолько несущественна, что на неё можно забить.
Я привёл примеры.
Нет, вы привели только общие слова (которые с тем же успехом могут быть применены и к C).
Что непонятно в enable_if_t?
Не только в нём, а во множестве дополнительных элементов, которые являются частью стандартной библиотеки enable_if_t один из них. И для того, чтобы использовать их либо нужно использовать стандартную библиотеку, либо нести реализации с собой в код.
Повод сразу использовать C++20!
А там ещё больше особенностей языка C++. С языком C со скрипом переходили на новый стандарт. А тут вы прелагаете сразу с двух ног войди в C++20, который не во всех компаниях ещё используют. В ядро, где очень ревностно относятся к нововведениям
Чем std::move выше хуже std::move-магического интринсика компилятора?
Тем, что должно быть явно вызвано. Даже если передаётся, как аргумент с типом универсальной ссылки. И в примере вы забыли remove_reference_t развернуть, так как без него работать не будет. Это тоже часть стандартной библиотеки.
Не только в нём, а во множестве дополнительных элементов, которые являются частью стандартной библиотеки enable_if_t один из них. И для того, чтобы использовать их либо нужно использовать стандартную библиотеку
Ещё раз, sfinae плохо потому, что оно использует enable_if, который является частью стандартной библиотеки, которую надо нести целиком или реализовывать с нуля? Я правильно понял вашу «логическую» цепочку?
либо нести реализации с собой в код.
Ничего страшного, с кусками сишной библиотеки так и сделали.
С языком C со скрипом переходили на новый стандарт.
Кстати, интересно, зачем.
А тут вы прелагаете сразу с двух ног войди в C++20, который не во всех компаниях ещё используют.
Не во всех компаниях и C используют, и?
В ядро, где очень ревностно относятся к нововведениям
Ну вы ж сами показали, что C++20 полезнее и удобнее, чем, скажем, 17.
Тем, что должно быть явно вызвано.
А откуда компилятору знать, хотите вы тут явный мув или нет? Когда сможете в общем случае определять, нужно ли тут:
void sink(const MyObject&);
void sink(MyObject&&);
// ...
MyObject obj;
if (foo()) {
sink(obj); // вот здеся move?
}
if (bar()) {
otherSink(obj);
}вызывать move или нет, расскажите, мне пожалуйста. А то я могу к этому свести проблему останова, мы с вами вместе опубликуем эпохальную статью, и вы увековечите своё имя. Идёт?
А когда неоднозначностей нет, то std::move вызывать не надо (например, implicit move в return, когда (N)RVO не срабатывает).
Даже если передаётся, как аргумент с типом универсальной ссылки.
Необязательность move в таких случаях делает код куда более чувствительным к рефакторингу, когда добавляется перегрузка функции, и код по-тихому ломается (давая худший перф на ровном месте).
Человек, который в одном комментарии жалуется на неявность трейтов раста и опасливость к изменениям, а в другом предлагающий подобную хрупкую автомагию — это, конечно, смешно.
И в примере вы забыли remove_reference_t развернуть, так как без него работать не будет. Это тоже часть стандартной библиотеки.
Когда говорят, что «X — однострочник», подразумевают, что остальные части языка всё ещё доступны. «X — однострочник на баше» не означает, что весь баш реализуется в одну строчку, или что используемые команды реализуются в одну строчку.
Человек, который в одном комментарии жалуется на неявность трейтов раста и опасливость к изменениям, а в другом предлагающий подобную хрупкую автомагию — это, конечно, смешно.
Вы сейчас про кого? Если про меня, я не жаловался на неясность trait'ов. И автомагию я не прелагал. Вы себе какой-то ошибочный образ в голове построили и пытаетесь с ним дискутировать. Мой вам совет. Выйдите на улицу, Подышите. Вам явно что-то мерещиться.
А откуда компилятору знать, хотите вы тут явный мув или нет?
При наличии только одной функции с аргументом типом универсальной ссылки, перемещение могло выполняться автоматически. Это как вариант. На уровне компилятора можно было добавить интринсинк, чтобы не использовать стандартную библиотеку. Это как раз для тех, кто не использует стандартную библиотеку в проектах
Если про меня, я не жаловался на неясность trait'ов.
Неявность. НеяВность. Вы же рядом:
Rust, из-за наличия trait'ов и макросов может скрывать реализации алгоритмов, что для программистов на C не приемлемо.
И автомагию я не прелагал.
Вы это сделали только что, предложив компилятору автоматически делать move в зависимости от нетривиальных условий. В том числе, тихо и без предупреждений ломать код
std::string s { "я не могу общаться с ретардами, но приходится" };
doSmth(foo);
return s[0];при изменении другой перегрузки. Это напрочь ломает всю идею типизации (обеспечение гарантий компилятором), когда наличие (и последующее удаление) doSmth(const std::string&)означает, что вы хотите именно копировать (или перемещать, неважно, но одно из поведений должно бытья вным) и потом перестать это делать.
Иными словами, если я удаляю эту перегрузку, то я хочу, чтобы компилятор меня ткнул носом в те места, где я на неё опирался, чтобы я подумал, что с этим делать (заменить на мув, переписать алгоритм, вернуть перегрузку). Если вы хотите, чтобы происходило что-нибудь, лишь бы происходило — пишите на джаваскрипте. Это ровно ваш [object Object], так что непонятно, зачем вы undefined is not a function.
Вы себе какой-то ошибочный образ в голове построили и пытаетесь с ним дискутировать. Мой вам совет. Выйдите на улицу, Подышите. Вам явно что-то мерещиться.
Перед тем, как раздавать советы, попробуйте научиться читать и не путать буквы, а затем — помнить, что вы же писали меньше суток назад. Задача со звёздочкой — продумывать, к чему приводят ваши предложения.
При наличии только одной функции с аргументом типом универсальной ссылки, перемещение могло выполняться автоматически.
А если у вас
void foo(auto&&);то надо копировать или перемещать?
А если у вас
void foo(string& s, string&& f);
void foo(string&& s, string& f);то что вы здесь будете копировать или перемещать в вызове, где оба аргумента не rvalue?
А если я не хочу перемещать, в конце концов, то что мне делать? Сделаете std::dontmove?
Предложения «ну давайте мувать автоматически, и копировать тоже автоматически, и вообще» может выдавать только человек, который не писал ничего сложнее хелловорлдов, и с std::move знаком по постам в блогах OTUS.
На уровне компилятора можно было добавить интринсинк, чтобы не использовать стандартную библиотеку.
Очень важная цель, мешающая на практике (нет).
Неявность. НеяВность. Вы же рядом:
Во первых, я не жаловался. Определяющее слово здесь «может». Во вторых, я указал на недостаток, который может быть причиной отказа.
Вы это сделали только что, предложив компилятору автоматически делать move в зависимости от нетривиальных условий.
Я предложил конкретные условия. Когда это могло быть автоматически. Опять же слово «могло» фигурирует.
Перед тем, как раздавать советы, попробуйте научиться читать и не путать буквы, а затем — помнить, что вы же писали меньше суток назад. Задача со звёздочкой — продумывать, к чему приводят ваши предложения.
Лучше бы вы последовали совету, подышали свежим воздухом. Научитесь сначала читать вы сами, прежде чем указывать другим. У вас фантазии в голове
Поразительная вертлявость (хотя первые четыре буквы лучше заменить на «омер»).
Во первых, я не жаловался.
Это неважно. Указывали на недостатки. Показывали как недостатки. Объясняли, почему сишников это не устраивает.
Конкретная формулировка здесь неважна, важно только то, что якобы неяВность определённой фичи раста является недостатком (поводом отказаться, етц) для людей с альтернативным складом ума, и потом говорите, что C++ без ещё более неяВной фичи для этих же людей — плохо, и с неяВной фичей он был бы лучше, и она бы не была недостатком (поводом отказаться, етц).
Шиза.
Определяющее слово здесь «может». Во вторых, я указал на недостаток, который может быть причиной отказа.
Не надо врать. Вы сказали, что эта возможность является причиной отказа. Вы прямо написали, что возможность скрывать детали реализации неприемлема для сишников (а не «может быть неприемлема», например).
Я предложил конкретные условия. Когда это могло быть автоматически.
Угу, только эти конкретные условия недостаточно формализированы, нелокальны, и ведут к на самом деле большим прболемам в поддержке кодовых баз (за что вы так ратовали рядом).
Но тут ведь главное — предложить. Поучаствовать. Высказать. Насколько это осмысленно — совершенно неважно. Хоть код копипасти, хоть автомагией занимайся.
Опять же слово «могло» фигурирует.
Что это вообще значит в данном случае? Типа, может делать, а может и не делать, монетку кидает? Или это ваше предложение — это так, не предложение, а фантазии вслух, уровня «может, на Гаити съездить» — «может, автомувать, если перегрузка одна»?
Лучше бы вы последовали совету, подышали свежим воздухом. Научитесь сначала читать вы сами, прежде чем указывать другим. У вас фантазии в голове
Никаких фантазий. Просто вы патологически неспособны говорить технически точные и однозначные фразы (как это принято в технических обсуждениях), вместо этого растекаясь философской мыслию по древу, а когда вас ловят на этом, вы начинаете играть в слова.
При этом любых вопросов по существу вы избегаете как огня, и в лучшем случае просто переводите тему, а чаще — напрочь игнорируете эти вопросы. c++11 проблема потому что sfinae, но в c++03 с ним всё норм, но код неоднозначен, но в enable_if_t всё просто, но проблема, но надо тащить библиотеку.
дел
Если с другой стороны посмотреть, то когда-то жила идея, что C++ сможет заменить C и почти все на него перейдут. И у Страуструпа, вроде как, жила.
А потом умерла. И уже первый стандарт C++ как бы хоронил идею, требуя поддержку исключений в freestanding-режиме ("bare metal", не hosted). Можно найти высказывания Страуструпа, что C++ в ядрах ОС следует использовать именно с исключениями и в Linux тоже, он ссылался на чей-то эксперимент.
просто взять и договориться использовать только некоторый "полезный" сабсет
Нет, с Си так и поступили. Он тоже много всякого позволяет, но договорились об определённом подмножестве.
Например: The Linux Kernel Is Now VLA (Variable-Length Array) Free
стоимость крайне низкая
))) осталось переучить несколько тысяч программистов, большинство из которых железячники и в эти ваши ООП с паттернами, простите, проектирования, нормально не умеют.
Два вагона книжек "С++ за 21 день" кто оплатит?)
А зачем их переучивать, если то что уже работало не сломается? Если вы начинаете компилировать С код С++ компилятором, то ни-че-го не меняется в коде в 99% случаев
а потом программист С открывает код коллеги на современных плюсах, в целях отладки например, видит нагромождение двоеточий и всех видов скобочек и в ужасе закрывает.
Да им не привыкать.
Учитывая, что stl и прочих библиотек там нет и не будет.
Чем какой-нибудь any_of или for_each плох?
И ещё RAII вместо goto exit_N (но оно требует исключений, так что вероятно нет).
Нет, early return тоже норм.
Шаблоны просто не нужны, в ядре практически нет таких задач.
А если найду всю эту замечательную макросню и void* вместо нормальных типов?
Звучит так, будто есть проблема интерфейсов и нет взаимозаменяемости компонентов. Я полагаю, что одни и те же компоненты должны быть легко заменяемыми реализацией на обоих языках. И вероятно, там не хватает покрытия тестами, чтобы сделать такие подмены безопасными.
Статья названа абсолютно некорректно и лид формирует ложные ожидания. Автор даже не представляется и не говорит, почему ее мнение по этому вопросу может быть значимым и полезным, так же как не говорит он и о том, что это просто ее компиляция и пересказ разных мнений. Так нельзя, это враньё. Selectelну вы чего? Вы же толковые технари, так почему такой кликбейт в свой блог регулярно допускаете? Так же нельзя. Планку держать надо, а не отусом или Максом ракатански становиться
Раз ядро так разраслось, то и поддержка двух языков это нормально, и, скорее всего, прогресс победит и некоторые олды - приверженцы С - оставят свои позиции, дав дорогу молодым растовцам.
Это нормально, когда большой проект поддерживает более одного языка. Это рабочий вариант. Да, в переходный момент будет тяжело, но постепенно всё устаканится.
Кто его знает, может третьим языком будет Python? Лет так через дцать... Не говорю что прям в ядре, но где-нибудь на окраине ядра, на периферии.
приверженцы С - оставят свои позиции, дав дорогу молодым растовцам
вы думаете, что растовцы будут изучать Си? Ибо для переписывание придется это делать.
Это нормально, когда большой проект поддерживает более одного языка.
Это жопа в поддержке. Притом реальная.
Кто его знает, может третьим языком будет Python?
Не будет, он для других целей разрабатывался (в отличие от того-же Раста).
Не говорю что прям в ядре, но где-нибудь на окраине ядра, на периферии.
Ну юзерский интерфейс уже на нем пишут. Норм. На окраину ядра его - да ну нафиг.
Пока мы тут это всё обсуждаем выкатили набор правил о том как будут встраивать раст код в ядро
амбициозный проект с кучей трудностей. наверное стоит упомянуть и ABI, который у Rust не стабилен, а у C может не меняться десятилетиями
Здесь проблема организационно-психологическая в том смысле, что психологические причины нежелания внедрять другие технологии в ядро подкреплены организационными рычагами влияния. Сишники даже плюсы недолюбливают (исторический отсев), плюсовики раст, а значит, сишники раст недолюбливают еще больше. Ну и что, имеют право. Они создали продукт, который работает, они его хозяева. Капыталызм же все-таки на дворе, делай хорошо себе, другим плохо не делай...
Rust в ядре Linux: лекарство или яд? Споры о будущем