Хипстеры до ядра добрались (модуль ядра на SWIFT)

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

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

Эээ... ШТО? В том же rust тебе не требуется руками указывать время жизни объекта. А вот в C придется, header-only оно или нет.

ссылочный GC мешает портируемости на мелкоконтроллеры: нахрена козе баян?

Так мешает, или тебе просто не нравится наличие GC? Hint: в том же rust есть unsafe указатели.

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

В C++ smart pointer'ы как раз сделали библиотекой (да, они часть стандарта, но это опциональная штука, ты можешь их не использовать).

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

Прости, каким образом? Я вот рад, что в том же Haskell я могу не освобождать руками строку, когда она мне больше не нужна.

Ты лучше export и несовместимый зоопарк компиляторов прокомментируй.

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

Я напомню, что мы говорим про людей, у которых девиз «stable API is nonsense».

ядро - огромный код, который должен собираться стабильно у разных юзеров

То же самое можно сказать про любой другой «огромный код». Алсо STABLE API IS NONSENSE.

на разных платформах

Ахахахахахах. Нет, правда, вот это уже смешно. Ты в курсе, что есть конторы, которые делают бизнес на поддержке {,кросс}компиляторов? Потому что не любой версией gcc можно скомпилировать любую версию ядра под любую платформу.

стандартные либы там не используются, поэтому на изменения в них наплевать.

В лялексе? Да, но это проблема лялекса и его убогой архитектуры. В QNX, например, никто не мешает писать дрова с STL.

а вот сам язык и его конструкции меняться не должны. причём в течение длительного времени.

И в итоге мы имеем килотонны костылей из-за обратной совместимости, которая всё равно где-то неявно ломается. Алсо C и C++ тут не подходят, потому что в них в сам язык периодически вносят изменения, ломающие совместимость. Попробуй код из K&R скомпилировать под c11.

их не пишут на языках-однодневках, в которых авторы ЯП ещё сами не знают, чего хотят.

Что ты имеешь ввиду под языком-однодневкой? Примеры в студию.

Я напомню, что мы говорим про людей, у которых девиз «stable API is nonsense».

А ты в курсе, что при этом речь идет о внутренних API ядра, которые userspace вообще никогда не увидит? Когда Алан Кокс почистил подсистему псевдотерминалов, от чего сломался emacs, это все быстренько откатили в ядре, хотя это emacs полагался на недокументированное поведение некоторых функций.

А ты в курсе, что при этом речь идет о внутренних API ядра, которые userspace вообще никогда не увидит? Когда Алан Кокс почистил подсистему псевдотерминалов, от чего сломался emacs, это все быстренько откатили в ядре, хотя это emacs полагался на недокументированное поведение некоторых функций.

Ага. А причем здесь компилятор?

Ага. А причем здесь компилятор?

Это у тебя надо спросить, зачем ты Торвальдса процитировал.

Это у тебя надо спросить, зачем ты Торвальдса процитировал.

Потому что чуваки согласны с тем, что ради пользы дела стоит ломать API.

Потому что чуваки согласны с тем, что ради пользы дела стоит ломать API.

Зависит от API. Некоторые не стоит. // К.О.

В случае с C уже действительно поздно :) А вот с rust я бы поддержал апдейты языка раз в несколько лет.

В случае Rust 1.x тоже поздно.

Rust 1.0 вышел 15 марта 2015 года. 15 марта 2017 вполне можно что-нибудь сломать.

15 марта 2017 вполне можно что-нибудь сломать

А почем не 1 марта 2017? Или 30 ноября 2016?

P.S. о Rust 2.0: «Several years off, at the earliest.»

Мне нравится 2 года.

Патрик, залогинься.

Хипстеры с Хабра описывают эксперимент по написанию модуля ядра на SWIFT (впрочем таки, как оказалось, на C)

И что тебя удивляет? Подумаешь, модуль. Да и без си они вряд-ли далеко уедут, ибо ядро же, а посему и напишут все основное на нем, а потом сверху, для красоты, обмажут свифтом, чтобы казалось что юзали его.

Бгг.

на python