В ядро предлагают добавить поддержку C++

Этого не хватало…

Надеюсь, у Линуса башка болит достаточно сильно, чтобы отказать в притягивании этого геморроя.

Ну то есть RUST это не гемор, а С++ это гемор? А можно объяснить почему?

Rust можно выучить за вменяемое время и не сойти с ума. C++ — нельзя. 99.9% из тех, кто говорит, что знает C++, знает лишь какое-то его подмножество. Действительно знают C++ целиком единицы людей в мире. Это идеальный пример, как не надо проектировать и развивать языки. Видеть это в коде ядра очень не хотелось бы. Скорее всего, если действительно примут, там введут какие-то серьёзные ограничения на то, что надо юзать, что нет, и какому стандарту соответствовать, что несколько сгладит проблему, но это тот случай, когда лучше не давать просунуть даже голову, иначе в итоге со временем пролезет всё.

Ну и Rust даёт какие-никакие плюсы, защищая от некоторых конкретных проблем. Плюсы, даваемые C++ в плане разработки ядра, весьма сомнительны, особенно когда ядро изначально не проектировалось для разработки на C++, а C++ прилеплен сбоку скотчем через десятилетия.

Все это решаемо, но у раста нулевая востребованность, в отличии от с++. А отодвигать с++ это значит тормозить развитие ядра.

Плюсы, даваемые C++ в плане разработки ядра, весьма сомнительны

Что сомнительного в нормальной строгой проверке типов и в замене метапрограммирования на макросах (оно уже есть в ядре) на более адекватную версию с constexpr и шаблонами? Вроде как явный большой плюс и если переезд не будет требовать каких-то сверх усилий, то одного этого на мой взгляд достаточно.

особенно когда ядро изначально не проектировалось для разработки на C++, а C++ прилеплен сбоку скотчем через десятилетия.

Ядро, конечно, не проектировалось для разработки на плюсах, но объектная модель там есть и вроде как каких-то противоречий с плюсами у этой модели нет, т.е. плюсы на неё ложатся вполне нормально.

Вот модель памяти в ядре более навороченная, чем в плюсах, но ничего не мешает продолжать использовать ядерную модель. Со временем сделают свои атомики, соответствующие ей и т.п.

а с шаблонами код получается один (ну да пара-тройка классов хелперров в 4-6 строк, от которых в рантайме (да и в бинарнике, вангую, но кстати не уточнял этот момент) не останется и следа.

Какие хелперы имеется в виду? Что они делают?

Так еще и тот профит что неявное преобразование типов не проканает и в тот метод который ты защитил шаблонами попадут исключительно те типа которые ты разрешил

Я так и не понял, каким образом защищаются типы? Как разрешить только нужные тебе типы?

99.9% из тех, кто говорит, что знает C++, знает лишь какое-то его подмножество. Действительно знают C++ целиком единицы людей в мире.

Тоже самое касается и раста. Причём с ним ситуация может быть ещё хуже, т.к. в нём иногда вылезает ub из llvm, про которое вообще никто не знает.

Для изучения, раст, разумеется проще. Но если мы говорим об полном познании всего языка с учётом всех возможных нюансов поведения, то объём требуемых знаний будет сопоставим, т.к. языки делают примерно одно и тоже довольно схожим образом (я на расте не пишу, так что могу что-то не учитывать, но для меня пока выглядит так).

Действительно знают C++ целиком единицы людей в мире.

Ну так и что? На С++ создаётся масса полезного софта, очевидно что не этими единицами людей. Значит, для написания полезного кода на С++ не нужно знать С++ целиком. Так что слабый аргумент, точнее вообще не аргумент.

Как разрешить только нужные тебе типы?

Концептами. Ну или sfinae, если стандарт древний, но лучше концептами.

Какие хелперы имеется в виду? Что они делают?

Хелперы - это просто так принято называть вспомогательные сущности в коде, которые используются в работе той сущности которую предоставляет библиотека.

Вот пример std::is_member_pointer (https://en.cppreference.com/w/cpp/types/is_member_pointer) и хелперов на которых она реализована

  template<typename _Tp>
    struct __is_member_pointer_helper
    : public false_type { };

  template<typename _Tp, typename _Cp>
    struct __is_member_pointer_helper<_Tp _Cp::*>
    : public true_type { };

  template<typename _Tp>
    struct is_member_pointer
    : public __is_member_pointer_helper<__remove_cv_t<_Tp>>::type
    { };

(https://github.com/gcc-mirror/gcc/blob/master/libstdc -v3/include/std/type_t...)

Я так и не понял, каким образом защищаются типы? Как разрешить только нужные тебе типы?

Передаваемые типы проверяются на этапе компиляции, не в рантайме, компилятором. В принципе это будет работать даже для полиморфизма т.к. компилятор всегда может понять что этот тип наследник или базовый... Но для полиморфизма скорее всего нужно будет добавить сравнение через is_convertible

//что-то типа
template <typename T> using RequireOnlyCharOrWideCharSymbol =
typename std::enable_if<metaOr<
        std::is_same<T, char>,
        std::is_same<T, wchar_t>
>::value>::type;

//дальше это можно использовать при объявлении ф-ии или класса, пример для класса
template <typename SymbolType = wchar_t,
          size_t BufferSize = 0,
          typename = TemplateMagick::RequireOnlyCharOrWideCharSymbol<SymbolType>>
class SomeClass {
...

Таким образом SomeClass можно будет актуализировать только нужными типами данных, при том что например внутри он бы смог работать и с другими типами над которыми определены тот же набор операций, что используется внутри методов класса SomeClass, но допустим по предментой области это было бы непонятно что - то вот как раз можно исключить, и это более короткий, на сколько мне известно, способ чем делать специлизации шаблонов или перегрузки ф-й.

Ну и соотеветственно если в метод суются нужные типы то код компиляется и работает, если нет то на этапе компиляции будет выдана ошибка, хотя формально код бы смог скомпилироваться и работать. Т.е. это просто искусственное ограничение области применения своего кода получается.

Правда для для того чтобы это работало нужно опираться на класс MetaOr - например у меня он свой, ну как сворй - грубо говоря это копипаст из STL из GCC. Почему так - потому что например тот же std::is_same это стандартная ф-я библиотеки, а мета ф-ии логических операторов (н.у. т.е. and, or времени компиляции а не рантайма) на момент когда я эту тему изучал не были стандартными (хотя всюду где я их смотрел были реализованы одинаково), ну и я решил их просто закопипастить в свой хедер и когда мне надо подключать его к своим проектам и опираться на этот хедер, чем опираться на код, который в другой реализации STL может быть изменен, например вместо __or_ станет называться _or_, хотя тело будет скорее всего тоже самое, т.к. там базовые вещи и как-то по другому их реализовать скорее всего нельзя.

На его предложение уже положительно откликнулись Jiri Slaby из SUSE, а так же David Howells из Red Hat, который и написал эти патчи как шутку 6 лет назад.

Линус тоже отнесётся к этому предложению положительно. Положит на него… сами знаете что.

Например, объекты, их форматы и всю обвязку. Например, вызов метода объекта потребует обращения к таблицам в рантайме.

Но это не точно, т.к. не факт, что предлагают в ядре писать на классах. Хотя и не запрещают, да и никак запретишь, если плюсы позволяют.

А, еще отлаживаться по с++ шаблонам это наверное вообще невозможно.

ИМХО с++ тащат скорее-всего ради килотонн шаблонов.

PS. Я как раз си-шник.

Например, объекты, их форматы и всю обвязку. Например, вызов метода объекта потребует обращения к таблицам в рантайме.

Для обычных объектов в плюсах это реализовано так же, как и в сишке. А если ты имеешь ввиду виртуальные функции, то их реализация в сишке точно так же потребует обращения к таблицам в рантайме. Только без шансов девиртуализации со стороны компилятора.

Но рантайма лишнего здесь никакого не будет. Буквально точно такой же код.

А, еще отлаживаться по с++ шаблонам это наверное вообще невозможно.

Если имеется ввиду отладчик, то в нём шаблоны вряд ли чем-то будут отличаться от обычных функций.

Если ты про ошибки компиляции, то с концептами сообщения об ошибках вполне понятные и портянки на несколько экранов не ожидаются.

9.9% из тех, кто говорит, что знает C++, знает лишь какое-то его подмножество.

Везде повторяют этот блуждающий по интернетам спич, но не все понимают его смысл. Фраза «знать С++» больше про умение на нем писать. Это задача из разделов CS, относящихся к проектированию систем. На сишке, расте или гошке можно городить линейные простыни кода из пункта A в пункт B. В плюсах нужно описывать вычислительную машину нелинейной системой классов, или это будут не плюсы. «Правильно написанный» на плюсах код хорошо читается, понимается, производителен и вообще прекрасен. Чтоб такое выдавать, нужно хорошо проникнуться. И «хорошо читается и понимается» оно только для тех, кто проникся концепцией, и сходу строит ту самую нелинейную систему в голове, просматривая код. Для остальных это выглядит как язык инопланетян.

Вангую, что проекты в системном программировании, которые не перейдут с Си/C++ на Rust, будут вытеснены проектами на Rust. Это всё равно что противиться замене опасной бритвы триммером. Мы конечно уважаем навык отдельных брадобреев и понимаем, что у триммера ручка другой формы, но в массе не стоит занесённых инфекций.

Это всё равно что противиться замене опасной бритвы триммером. 

скорее, бензопиле с безопасными зубьями ;)

Вангую, что проекты в системном программировании, которые не перейдут с Си/C++ на Rust, будут вытеснены проектами на Rust. 

Судя по примерно нулевым начинаниям новых проектов и «потужной» рекламе в уже существующих — очень смелое заявление :) Пока больше похоже на выживательную стратегию паразитов, чем на какую-то активную конкуренцию.

замене опасной бритвы триммером

Не вопрос когда триммер изобретут. Раст и его продвигатели, это команад жуликов, пытающихся продать обычную бритву, замаскированную внешне под триммер.