Человек, который в одном комментарии жалуется на неявность трейтов раста и опасливость к изменениям, а в другом предлагающий подобную хрупкую автомагию — это, конечно, смешно.
Вы сейчас про кого? Если про меня, я не жаловался на неясность trait'ов. И автомагию я не прелагал. Вы себе какой-то ошибочный образ в голове построили и пытаетесь с ним дискутировать. Мой вам совет. Выйдите на улицу, Подышите. Вам явно что-то мерещиться.
А откуда компилятору знать, хотите вы тут явный мув или нет?
При наличии только одной функции с аргументом типом универсальной ссылки, перемещение могло выполняться автоматически. Это как вариант. На уровне компилятора можно было добавить интринсинк, чтобы не использовать стандартную библиотеку. Это как раз для тех, кто не использует стандартную библиотеку в проектах
Это станет техническими причинами тогда, когда будут указаны конкретные сценарии, при которых что-то будет неудобно. Потому что программистский фольклор и общий опыт показывает, что так, как предлагают растаманы, таки удобнее.
Это неудобно в конкретной кодовой базе. Этого было достаточно для отказа. Не можете с этим смириться - это ваши личные проблемы.
Писал, мол, что двуязычные кодовые базы сложно поддерживать.
Сложно ему или сложно в принципе? Вот где правильный вопрос. Он указывал не лично себя.
Которое осмысленно настолько же, насколько осмысленно предложение написать собственный форматтер кода для C++ вместо использования существующих, а иначе решить (и высечь на камне), что стиля кода нет никакого.
В отличии от других участников дискусии в переписке ядра, Кристоф дал разъяснения и альтернативы. Опять же, не можете с этим смириться - это ваши личные проблемы.
Для того, чтобы это было ответом на моё «раст показывает свою пользу в крупных проектах» — да.
Пользы в крупных проектах от Rust пока не видно, чтобы так громко заявлять. То, что Rust делает кое какие вещи иначе и удобнее, я лично не отрицаю. Точно так же могут и другие языки. Часть из которых появились недавно. Время покажет что и как будет. В том числе и в ядре linux
Не только в нём, а во множестве дополнительных элементов, которые являются частью стандартной библиотеки enable_if_t один из них. И для того, чтобы использовать их либо нужно использовать стандартную библиотеку, либо нести реализации с собой в код.
Повод сразу использовать C++20!
А там ещё больше особенностей языка C++. С языком C со скрипом переходили на новый стандарт. А тут вы прелагаете сразу с двух ног войди в C++20, который не во всех компаниях ещё используют. В ядро, где очень ревностно относятся к нововведениям
Чем std::move выше хуже std::move-магического интринсика компилятора?
Тем, что должно быть явно вызвано. Даже если передаётся, как аргумент с типом универсальной ссылки. И в примере вы забыли remove_reference_t развернуть, так как без него работать не будет. Это тоже часть стандартной библиотеки.
Например, в отсутствии технических причин? ... В «мне сложно, но мне не нужны помощники»?
Ни один из тезисов не является правдой. Технические причины были указаны - удобство сопровождения. Про сложность Кристов не писал. Надуманное вами.
Ему сказали, что результатам его труда тут не рады, и ему нужно сделать тройной тулуп с переворотом и сплясать, а он, инфантильный эмоционал, отказался тулупиться и плясать, а просто пошёл по своим делам.
Никто не критиковал вклад Гектора в код ядра. Критика со стороны Торвальдса была в действиях Гектора в ситуации с rust кодом в DMA. Но после сообщения Торвальдса поступок Гектора выглядит как выход хлопнув дверью. Взрослые люди так не поступают. Хотя бы пытаются договориться. Дискутировать.
Он это где-то написал, про обиду, про это всё? Или вы сами придумали?
Нет. Я это додумал. И разница с Кристофом в том, что Кристоф дал альтернативное предложение. Он объяснил свою позицию. Гектор же не объяснил. Он лишь написал, что «вера у него кончилась» (это цитата).
Сколько кода на Zig, Nim и Odin в AOSP? Сколько кода на Zig, Nim и Odin в клаудфларовских проксях?
А они там должны быть? У них свои проекты. Может быть когда-нибудь они появляться в AOSP. Rust тоже не сразу там оказался.
На каждый растовский драйвер, очевидно. Потому что без этих обвязок его невозможно написать.
Ясно, понятно.
У этой лишней работы снова нет никаких технических причин.
То же самое можно перенести на ситуацию Кристофом, у него то же нет причин делать лишную работу с поддержкой кода на rust.
Так в чём конкретно проблема со sfinae, можете сказать?
Безошибочный подбор правильных реализаций. Для того, чтобы избавиться от ошибочного подбора нужно строить много дополнительного не всегда очевидного с точки зрения понимания кода. Когнитивная нагрузка намного выше. Концепты исправляют ситуацию, но они в C++20.
Этот вопрос — риторический, и является ответом на ваш псевдоаргумент.
Вы могли нормальный вопрос задать с самого начала, или, если вы знали, могли бы сразу дать на него ответ.
Это вообще однострочники, их самому можно написать, в чём костыльность и в чём проблема?
Не однострочники. move как миниму на три строки. так как нужно избавиться от ссылочности перед этим. Их не должно быть вообще в стандартной библиотеке, а должны быть на уровне языка. Но реализацию уже не изменить.
Вы упорно избегаете конкретики, просто размахивая руками и высказывая общие тезисы.
Я привёл примеры. И это не единственные примеры. Я вам не обязан всю стандартную библиотеку нести. Есть вещи типа enable_if они просты в реализации, но их много
Вопрос в адекватности этих отказов, и мы обсуждаем именно его.
А в чем неадекватность отказа со стороны Кристофа? Он поставил стабильность выше нововведений. Неадекватными пока что только выглядят адепты Rust. Особенно Гектор Мартин. Который ушёл из мейнтейнеров из-за обиды на слова Торвальдса. Опять же чисто эмоциональный поступок. Не прагматика движет, а эмоции. Возможно даже инфантилизм. Но это уже отдельная история.
И есть конкретные работающие продукты, которые выбрано делать на расте. Но это всё, конечно, мелочи и лозунги.
Так и на Zig сейчас проекты пишут. На Nim, Odin. (любой другой новый красивый язык) И что с того? Это нормально, что язык развивается.
Исключительно потому, что отдельный код на каждый драйвер никто не будет делать, и он это понимает.
А зачем делать на каждый драйвер? Достаточно на несколько. Показать стабильность работы кода. Объяснить, доказать верность замены. Можно попробовать так пойти. Но пошли другим путём - сраться в пабликах.
Это что за аргумент вообще такой? Какой мейнстримный ЯП всегда работает так, как задумано?
C не просто так стал языком ядра, а C++ не стал. И шаблоны отчасти были тому причиной. У вас странная реакция. Сами задали выпрос. Если вещи очевидны, к чему тогда сам вопрос был.
А как сишники сейчас справляются с тем, когда нужно и то, и то?
Никак. В C нет семантики перемещения.
Да, конечно. Например, не имея этих инклюдов в путях компилятора в процессе сборки.
Вот это уже конструктивный диалог. А теперь вернёмся к моему сообщению выше:
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте.
Я об этом и написал. Для реализации на месте нужно будет ести все костыли стандартной библиотеки. Без костылей в виде std::move или std::forward из стандартной библиотеки семантика перемещения не работает. Помимо ни есть ещё целая куча вещей. Если смотреть на ситуацию с языком C++ со стороны, то отказ от него в ядре вполне оправдан
В каком месте пытаются? Ему говорят, что обвязки готовы мейнтейнить другие люди.
В том же где ему присылают патч с Rust кодом. Как и вы пишите выше.
Если человек не может выполнять работу сам, значит, нужны.
Он как мейнтейнер всей подсистемы отказал в патче считая, что это навредит сопровождению. Он имеет право на это. Он готов принять отдельный код на каждый драйвер, о чём написал, но не на всю систему в целом. Из-за этого начался конфликт в переписке. Из которой начали писать статьи. Будут ли помогать, не будут. Это уже не важно. Ситуация уже произошла. Решение уже принято.
Уже показало в опыте других компаний, от гугла с андроидом до cloudflare.
Красивые лозунги в новостях многие умеют писать. Это ещё ничего не говорит. Google до сих пор с заменой Java на Kotlin не разобралась у себя. Rust при этом заметно больше лет, чем Kotlin.
Где в процитированной вами фразе написано, что у него уже есть помощники?
Они прописаны в списке мейнтейнеров. Зачем их упоминать, когда они уже есть?
Контекст дискуссии — растобайндинги. Вы говорите, что я не учитываю контекст высказываний, а потом сами берёте и выкидываете этот контекст.
Потому что проблема не в самих растобайдингах. А том, где они располагаются. Кристофу инкриминируют по сути неприязнь языка Rust. В то время как сам Кристов писал, что у него нет негатива против языка. Он против тех изменений, что пришли с патчем и дал вариант решения. Это вариант решения не понравился rust-сообществу. И они разнесли это по интернету, как очередную ситуацию с притеснением языка. Из-за чего Самому Яжефинн Торвальдсу (это ваша цитата) пришлось писать комментарий на это конфликт. Весь конфликт раздут искусственно. Я комментирую, чисто из-за скуки. А вас, как мне кажется, что-то задевает. Ведь Rust'у отказали, какая же несправедливость.
Если человек не может выполнять работу сам, значит, нужны.
Так он может выполнять работу. Свою. Ему чужая не нужна. А ему почему-то пытаются навязать другую работу.
А переход на 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 в одном месте. Пусть попытает счастье в другом.Тем более, что не во всех подсистемах ядра такие отказы есть.
Говорить, что копипаста помогает поддержке — это показывать, как говорится, что иногда старость приходит одна.
А ещё спутником старости для некоторых является деменция.
Копирование данных при неправильно перемещении. Перемещение данных при неправильно копировании. Кейсы редкие, но не невозможные.
Только нужное для используемых вещей подмножество.
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте. Сомневаюсь, что на это пойдут, если до сих пор так не сделали. А я что-то не помню, чтобы для C запрещали использовать что-то из стандартной библиотеки.
Потому что если бы было норм самому, то не было бы «слишком сложно». А если слишком сложно, то помощники не помешают.
А исключение здесь где? То, что помощники могут помочь ещё не означает, что они нужны. И то, что кто-то не хочет делать дополнительную работу, не значит что ему нужны помощники. Взаимоисключения здесь нет. В ту же логику можно принести - зачем усложнять там, где усложнения не требуется. Или зачем исправлять то, что и так работает хорошо.
Я взял переводы по ссылке товарища выше. Конечно, понятное дело, переводы верны, когда надо опровергнуть исходную статью, и переводы неверны, когда из них следуют неприятные для вас вещи
Так вы оригиналы посмотрите, чтобы не терять смысл заявлений. И для более детальной картины всех заявлений Кристофа. Потому что переводы не верны, а дёргать отдельные выражения без контекста - портить суть его слов и своего лично понимания.
Ага. А ещё поддержка большой кодовой базы — это не драйвер написать. И не бинарный блоб для amd влить. И что это говорит о всех тех людях, которые этим занимаются?
Так и Кристов не драйверы пишет. Он сопровождает одну из критических подсистем ядра.
Вы снова врёте: ждать не нужно, потому что люди вполне себе готовы взять на себя обязательства по мейнтейнерству.
А где я вру? Мои слова описывают ситуацию, когда есть кодовая база двух языков, где один язык поддерживается одним, а другой - другим мейнтейнером. И для исправления ошибки кто-то в любом случае будет ждать выполнения работы другого. Вы же не знаете как будет, как будет и сколько это времени займёт. И я не знаю. И Кристоф не знает. Но с точки зрения простой логики зачем создавать сложности на ровном месте и вносить дополнительный процент риска там где он не нужен.
Для этого есть LTS-релизы.
А для тестов и экспериментов отдельный ветки и форки.
Конечно. Царёк в загончике тоже не один. Но царёк опирается на безапелляционный авторитет у прочих членов загончика, который в linux kernel пока ещё хотя бы на словах следует меритократическим принципам.
Все кто находится в загончике чувствуют себя хорошо. И им не нужна помощь. О чём собственно написал Кристоф. Всё остальное, в том числе и эта статья - это всё из-за «вселенской несправедливости».
Что, в ядре линукса и сишные макросы уже запретили?
А C-макросы могут генерировать код? Я вроде думал, что они просто подменяют текст.
На самом деле не договорились, а скорее запретили использовать нововведения. Типа когда-то начали с gnu89, и очень неохотно переходили на новые стандарты. Только в 2022 году перешли на gnu11. В языке C это позволяет не использовать не нужные вещи. В то время как в C++ всё иначе.
Сейчас не возможно заставить C++ программиста программировать на C++98. Это просто бессмыслено. Все самые важные изменения пришли в C++11, а они с собой несут очень много специфичного поведения, которые для стабильности ядра linux, могут иметь отрицательный эффект.
Проблема ещё, не возможно выделить в C++ какой-то особый набор правил типа только C с классами. Некоторые программисты например не знают, что семантика перемещения имеет свои особенности, и без костылей её не возможно применять. А костыли нужны. И часть таких костылей является частью стандартной библиотеки. А это значит, что нужно нести стандартную библиотеку языка C++ в ядро. Стандартная библиотека C++ имеет ряд особенностей, которые, опять же, могут отрицательно сказаться на стабильности работы ядра.
То есть, есть куча нюансов из-за которых просто так взять, и разрешить C++ в ядре нельзя
Она изначально была понятна. Как это меняет суть отказа? В этой части кода ядра важна стабильность. Мейнтейнеры хотят продолжать поддерживать эту стабильность. И для меня лично понятно почему. Если вы этого не понимаете? Штош. Результат отказа всё равно это не изменит
Можете дальше не продолжать, с другим складом ума вам наверное пора в спецучереждение для людей "с другим складом ума"
А то лезут всякие "тупые" в священную башню со слоновой кости.
Вот примеры.
Это я вас так задел
Ну задели, и задели. Если вас это порадует, то можете себе записать ранение. Мало ли вас таких в интернете. Я на себя не проецирую. Лишь указываю на ваши ошибки.
...что аж про "другой" склад ума полезло.
Потому что я работал с чисто C программистами. И у них совершенно другой подход в архитектуре кода из-за простоты языка. Отсюда как раз выходят особенности, как построения кодовой базы, так и её поддержки. Архитектура кода Go или Java, да даже Rust сильно отличается от того с чем работают программисты на C. И именно из-за не соответствия подходов к работе над кодом возникают конфликты.
Я вообще к расту отношения не имею, мне все равно на каких языках ядро написано, лишь бы работало хорошо.
Он писал взаимоисключающие параграфы «мне не нужны помощники, мне норм самому» и «я не хочу мейнтейнить растобайндинги, потому что это слишком сложно».
А где здесь взаимоисключающие параграфы? Вы то же из тех кто не понимает, но «со вселенской несправедливостью нужно бороться»?
Даже больше, оба ваших перевода неверны. И вы просто набрасываете. Как собственно все неравнодушные адепты Rust'а в пабликах, как только переписка всплыла в новостях.
Единственная верная суть в этом, что поддержка большой кодовой базы - это не биндинги написать. Не даром сам Торвальдс дал комментарий. Суть которого сводится к тому, что это не Rust плохой, а программисты на Rust плохие. Плохие для ядра linux. Им нужно меняться. Это был для них по сути совет. Как мальчик, которого бросают в воду, чтобы он научился плавать, не может изменить физику воды. Так и программисты на Rust не могу сломать принятые стандарты разработки внутри ядра linux. Когда-нибудь это произойдёт, но не в ближайшее время.
А пока что, всё то, что происходит вокруг таких новостей и постов - это просто вбросы ради просмотров.
...потому что поддержка соответствующих частей была на энтузиастах этого языка.
Это как раз показывает ваше непонимание. В ядре linux никто не будет ждать, что за дело возьмётся энтузиаст своего языка. Сломалось? Нужно чинить сразу. А лучше вообще не ломать. Отсюда эта неприязнь нововведений. Которая оправдана. Это в махровом энтерпрайзе на поддержке на аутсорсе исправление ошибок могут ждать неделями. Ядро linux - критическое ПО.
Я как раз прекрасно понимаю эту проблему. Кристоф хочет продолжать быть королём в своём уютном загончике, а тут опасно близко подходят люди, могущие показать, что король-то голый.
Вы думаете только один Кристоф работает над DMA? Он там далеко не один. И его решение поддерживают. Бугуртят в основном именно обиженки из Rust загона. В то время как никто им не запрещает работать над ядром, им рекомендуют делать это в контролируемых рамках.
Знаете, как в ядре разные штуки сделаны в окрестности тех же ФС или драйверов? Там структурки с указателями на функции лежат, и эти структурки ровно этим занимаются: скрывают реализации алгоритмов. Или я что-то пропустил, и разные кристофы и анимерабы их уже выпилили?
А что они скрывают? Реализация остаётся реализацией внутри своего же отдельного блока кода, и даже единицы трансляции. Структура определена. Это не макрос или трейт, которые могут быть в других крейтах. Если трейт это ещё более менее определённая штука, то макрос может быть вообще чем угодно. Или я опять что-то упустил?
Если проблема в обвязках, то их точно так же можно откатить или «заблокировать» (что бы это ни значило) без серьёзных проблем для сишного кода. Централизованные обвязки здесь не делают хуже.
Это как раз вы не понимаете. Если было изменение в обвязке, то просто так откатить ей не просто, так как все драйвера будут задеты изменениями, в отличии от изменений отдельного драйвера.
Копирование здесь не делает лучше.
Копирование делает поддержку проще.
Предлагать копипастить, особенно с таким обоснованием, как у Кристофа — это чисто политический манёвр...
Нет там никакого политического манёвра. Это фантазия. Заменят Кристофа - будет кто-то другой. Адепты Rust пусть попытают удачу в этом направлении. Это же не сложно - на собрании выдвинуть свою кандидатуру в мейнтейнеры DMA. Примут ли их кандидатуру? Вот в чём вопрос
То есть вы бросаться оскорблениями можете, а другим нельзя? А не у вас ли ЧСВ? Я здесь вам только оппонирую. Если бы хотели остановиться, то остановились бы. Но я вас задел, ведь. И вы не можете молчать
Вы сейчас про кого? Если про меня, я не жаловался на неясность trait'ов. И автомагию я не прелагал. Вы себе какой-то ошибочный образ в голове построили и пытаетесь с ним дискутировать. Мой вам совет. Выйдите на улицу, Подышите. Вам явно что-то мерещиться.
При наличии только одной функции с аргументом типом универсальной ссылки, перемещение могло выполняться автоматически. Это как вариант. На уровне компилятора можно было добавить интринсинк, чтобы не использовать стандартную библиотеку. Это как раз для тех, кто не использует стандартную библиотеку в проектах
Это неудобно в конкретной кодовой базе. Этого было достаточно для отказа. Не можете с этим смириться - это ваши личные проблемы.
Сложно ему или сложно в принципе? Вот где правильный вопрос. Он указывал не лично себя.
В отличии от других участников дискусии в переписке ядра, Кристоф дал разъяснения и альтернативы. Опять же, не можете с этим смириться - это ваши личные проблемы.
Пользы в крупных проектах от Rust пока не видно, чтобы так громко заявлять. То, что Rust делает кое какие вещи иначе и удобнее, я лично не отрицаю. Точно так же могут и другие языки. Часть из которых появились недавно. Время покажет что и как будет. В том числе и в ядре linux
Не только в нём, а во множестве дополнительных элементов, которые являются частью стандартной библиотеки
enable_if_tодин из них. И для того, чтобы использовать их либо нужно использовать стандартную библиотеку, либо нести реализации с собой в код.А там ещё больше особенностей языка C++. С языком C со скрипом переходили на новый стандарт. А тут вы прелагаете сразу с двух ног войди в C++20, который не во всех компаниях ещё используют. В ядро, где очень ревностно относятся к нововведениям
Тем, что должно быть явно вызвано. Даже если передаётся, как аргумент с типом универсальной ссылки. И в примере вы забыли
remove_reference_tразвернуть, так как без него работать не будет. Это тоже часть стандартной библиотеки.Ни один из тезисов не является правдой. Технические причины были указаны - удобство сопровождения. Про сложность Кристов не писал. Надуманное вами.
Никто не критиковал вклад Гектора в код ядра. Критика со стороны Торвальдса была в действиях Гектора в ситуации с rust кодом в DMA. Но после сообщения Торвальдса поступок Гектора выглядит как выход хлопнув дверью. Взрослые люди так не поступают. Хотя бы пытаются договориться. Дискутировать.
Нет. Я это додумал. И разница с Кристофом в том, что Кристоф дал альтернативное предложение. Он объяснил свою позицию. Гектор же не объяснил. Он лишь написал, что «вера у него кончилась» (это цитата).
А они там должны быть? У них свои проекты. Может быть когда-нибудь они появляться в AOSP. Rust тоже не сразу там оказался.
Ясно, понятно.
То же самое можно перенести на ситуацию Кристофом, у него то же нет причин делать лишную работу с поддержкой кода на rust.
Безошибочный подбор правильных реализаций. Для того, чтобы избавиться от ошибочного подбора нужно строить много дополнительного не всегда очевидного с точки зрения понимания кода. Когнитивная нагрузка намного выше. Концепты исправляют ситуацию, но они в C++20.
Вы могли нормальный вопрос задать с самого начала, или, если вы знали, могли бы сразу дать на него ответ.
Не однострочники.
moveкак миниму на три строки. так как нужно избавиться от ссылочности перед этим. Их не должно быть вообще в стандартной библиотеке, а должны быть на уровне языка. Но реализацию уже не изменить.Я привёл примеры. И это не единственные примеры. Я вам не обязан всю стандартную библиотеку нести. Есть вещи типа
enable_ifони просты в реализации, но их многоА в чем неадекватность отказа со стороны Кристофа? Он поставил стабильность выше нововведений. Неадекватными пока что только выглядят адепты Rust. Особенно Гектор Мартин. Который ушёл из мейнтейнеров из-за обиды на слова Торвальдса. Опять же чисто эмоциональный поступок. Не прагматика движет, а эмоции. Возможно даже инфантилизм. Но это уже отдельная история.
Так и на Zig сейчас проекты пишут. На Nim, Odin. (любой другой новый красивый язык) И что с того? Это нормально, что язык развивается.
А зачем делать на каждый драйвер? Достаточно на несколько. Показать стабильность работы кода. Объяснить, доказать верность замены. Можно попробовать так пойти. Но пошли другим путём - сраться в пабликах.
дел
C не просто так стал языком ядра, а C++ не стал. И шаблоны отчасти были тому причиной. У вас странная реакция. Сами задали выпрос. Если вещи очевидны, к чему тогда сам вопрос был.
Никак. В C нет семантики перемещения.
И вы можете запретить их добавлять? Не можете.
Вот это уже конструктивный диалог. А теперь вернёмся к моему сообщению выше:
Я об этом и написал. Для реализации на месте нужно будет ести все костыли стандартной библиотеки. Без костылей в виде
std::moveилиstd::forwardиз стандартной библиотеки семантика перемещения не работает. Помимо ни есть ещё целая куча вещей. Если смотреть на ситуацию с языком C++ со стороны, то отказ от него в ядре вполне оправданВ том же где ему присылают патч с Rust кодом. Как и вы пишите выше.
Он как мейнтейнер всей подсистемы отказал в патче считая, что это навредит сопровождению. Он имеет право на это. Он готов принять отдельный код на каждый драйвер, о чём написал, но не на всю систему в целом. Из-за этого начался конфликт в переписке. Из которой начали писать статьи. Будут ли помогать, не будут. Это уже не важно. Ситуация уже произошла. Решение уже принято.
Красивые лозунги в новостях многие умеют писать. Это ещё ничего не говорит. Google до сих пор с заменой Java на Kotlin не разобралась у себя. Rust при этом заметно больше лет, чем Kotlin.
Они прописаны в списке мейнтейнеров. Зачем их упоминать, когда они уже есть?
Потому что проблема не в самих растобайдингах. А том, где они располагаются. Кристофу инкриминируют по сути неприязнь языка Rust. В то время как сам Кристов писал, что у него нет негатива против языка. Он против тех изменений, что пришли с патчем и дал вариант решения. Это вариант решения не понравился rust-сообществу. И они разнесли это по интернету, как очередную ситуацию с притеснением языка. Из-за чего Самому Яжефинн Торвальдсу (это ваша цитата) пришлось писать комментарий на это конфликт. Весь конфликт раздут искусственно. Я комментирую, чисто из-за скуки. А вас, как мне кажется, что-то задевает. Ведь Rust'у отказали, какая же несправедливость.
А как sfinae работает? Всегда так как задумано?
А как это поможет когда нужно и то, и то?
Хотите сказать, что нет? Вы прям можете запретить не вызывать отдельные инклюды?
А что, запрещено документально?
Так он может выполнять работу. Свою. Ему чужая не нужна. А ему почему-то пытаются навязать другую работу.
Может быть. Время покажет.
К примеру
Он написал просто
И не потому что они ему не нужны. У него уже есть помощники. Другие мейнтейнеры.
Он этого не писал.
Вот его слова. Он писал не конкретно про байдинги rust кода.
У него уже есть помощники.
Вот когда примут, тогда и приходите. Пока что ваши же слова ниже
относятся и к вам в равно степени. Я же лишь вижу текущую ситуацию просто раздутой из-за нелепицы. Не приняли код на Rust в одном месте. Пусть попытает счастье в другом.Тем более, что не во всех подсистемах ядра такие отказы есть.
А ещё спутником старости для некоторых является деменция.
Шаблонов вполне досточно. SFINAE.
Копирование данных при неправильно перемещении. Перемещение данных при неправильно копировании. Кейсы редкие, но не невозможные.
А такого нет в C++, либо вся библиотека в целом, либо своя собственная реализация на месте. Сомневаюсь, что на это пойдут, если до сих пор так не сделали. А я что-то не помню, чтобы для C запрещали использовать что-то из стандартной библиотеки.
А исключение здесь где? То, что помощники могут помочь ещё не означает, что они нужны. И то, что кто-то не хочет делать дополнительную работу, не значит что ему нужны помощники. Взаимоисключения здесь нет. В ту же логику можно принести - зачем усложнять там, где усложнения не требуется. Или зачем исправлять то, что и так работает хорошо.
Так вы оригиналы посмотрите, чтобы не терять смысл заявлений. И для более детальной картины всех заявлений Кристофа. Потому что переводы не верны, а дёргать отдельные выражения без контекста - портить суть его слов и своего лично понимания.
Так и Кристов не драйверы пишет. Он сопровождает одну из критических подсистем ядра.
А где я вру? Мои слова описывают ситуацию, когда есть кодовая база двух языков, где один язык поддерживается одним, а другой - другим мейнтейнером. И для исправления ошибки кто-то в любом случае будет ждать выполнения работы другого. Вы же не знаете как будет, как будет и сколько это времени займёт. И я не знаю. И Кристоф не знает. Но с точки зрения простой логики зачем создавать сложности на ровном месте и вносить дополнительный процент риска там где он не нужен.
А для тестов и экспериментов отдельный ветки и форки.
Все кто находится в загончике чувствуют себя хорошо. И им не нужна помощь. О чём собственно написал Кристоф. Всё остальное, в том числе и эта статья - это всё из-за «вселенской несправедливости».
А C-макросы могут генерировать код? Я вроде думал, что они просто подменяют текст.
Это понимание приходит со временем.
На самом деле не договорились, а скорее запретили использовать нововведения. Типа когда-то начали с gnu89, и очень неохотно переходили на новые стандарты. Только в 2022 году перешли на gnu11. В языке C это позволяет не использовать не нужные вещи. В то время как в C++ всё иначе.
Сейчас не возможно заставить C++ программиста программировать на C++98. Это просто бессмыслено. Все самые важные изменения пришли в C++11, а они с собой несут очень много специфичного поведения, которые для стабильности ядра linux, могут иметь отрицательный эффект.
Проблема ещё, не возможно выделить в C++ какой-то особый набор правил типа только C с классами. Некоторые программисты например не знают, что семантика перемещения имеет свои особенности, и без костылей её не возможно применять. А костыли нужны. И часть таких костылей является частью стандартной библиотеки. А это значит, что нужно нести стандартную библиотеку языка C++ в ядро. Стандартная библиотека C++ имеет ряд особенностей, которые, опять же, могут отрицательно сказаться на стабильности работы ядра.
То есть, есть куча нюансов из-за которых просто так взять, и разрешить C++ в ядре нельзя
Они даже в ядре linux есть среди мейнтейнеров.
Она изначально была понятна. Как это меняет суть отказа? В этой части кода ядра важна стабильность. Мейнтейнеры хотят продолжать поддерживать эту стабильность. И для меня лично понятно почему. Если вы этого не понимаете? Штош. Результат отказа всё равно это не изменит
Вы «на двачах» учились беседы вести?
Вот примеры.
Ну задели, и задели. Если вас это порадует, то можете себе записать ранение. Мало ли вас таких в интернете. Я на себя не проецирую. Лишь указываю на ваши ошибки.
Потому что я работал с чисто C программистами. И у них совершенно другой подход в архитектуре кода из-за простоты языка. Отсюда как раз выходят особенности, как построения кодовой базы, так и её поддержки. Архитектура кода Go или Java, да даже Rust сильно отличается от того с чем работают программисты на C. И именно из-за не соответствия подходов к работе над кодом возникают конфликты.
Странно тогда видеть вас в комментариях
Видел такое. Даже в C++ видел перечисления наследований
А где здесь взаимоисключающие параграфы? Вы то же из тех кто не понимает, но «со вселенской несправедливостью нужно бороться»?
Даже больше, оба ваших перевода неверны. И вы просто набрасываете. Как собственно все неравнодушные адепты Rust'а в пабликах, как только переписка всплыла в новостях.
Единственная верная суть в этом, что поддержка большой кодовой базы - это не биндинги написать. Не даром сам Торвальдс дал комментарий. Суть которого сводится к тому, что это не Rust плохой, а программисты на Rust плохие. Плохие для ядра linux. Им нужно меняться. Это был для них по сути совет. Как мальчик, которого бросают в воду, чтобы он научился плавать, не может изменить физику воды. Так и программисты на Rust не могу сломать принятые стандарты разработки внутри ядра linux. Когда-нибудь это произойдёт, но не в ближайшее время.
А пока что, всё то, что происходит вокруг таких новостей и постов - это просто вбросы ради просмотров.
Это как раз показывает ваше непонимание. В ядре linux никто не будет ждать, что за дело возьмётся энтузиаст своего языка. Сломалось? Нужно чинить сразу. А лучше вообще не ломать. Отсюда эта неприязнь нововведений. Которая оправдана. Это в махровом энтерпрайзе на поддержке на аутсорсе исправление ошибок могут ждать неделями. Ядро linux - критическое ПО.
Вы думаете только один Кристоф работает над DMA? Он там далеко не один. И его решение поддерживают. Бугуртят в основном именно обиженки из Rust загона. В то время как никто им не запрещает работать над ядром, им рекомендуют делать это в контролируемых рамках.
А что они скрывают? Реализация остаётся реализацией внутри своего же отдельного блока кода, и даже единицы трансляции. Структура определена. Это не макрос или трейт, которые могут быть в других крейтах. Если трейт это ещё более менее определённая штука, то макрос может быть вообще чем угодно. Или я опять что-то упустил?
Это как раз вы не понимаете. Если было изменение в обвязке, то просто так откатить ей не просто, так как все драйвера будут задеты изменениями, в отличии от изменений отдельного драйвера.
Копирование делает поддержку проще.
Нет там никакого политического манёвра. Это фантазия. Заменят Кристофа - будет кто-то другой. Адепты Rust пусть попытают удачу в этом направлении. Это же не сложно - на собрании выдвинуть свою кандидатуру в мейнтейнеры DMA. Примут ли их кандидатуру? Вот в чём вопрос
То есть вы бросаться оскорблениями можете, а другим нельзя? А не у вас ли ЧСВ? Я здесь вам только оппонирую. Если бы хотели остановиться, то остановились бы. Но я вас задел, ведь. И вы не можете молчать