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

Ичо? Модули ядра на хацкелле, русте и прочих давно пилили уже ради лулзов.

Ишо? В NetBSD вон можно драйверы на lua писать.

Хипстота же.

Скоро появятся (если уже не появились) фанбои «свифтнакаждыйдень». Потом выйдет новый хипстерский язык, и вся эта толпа переедет туда. Кажется последние лет 6-7 всё только так и происходит.

Кстати, всегда интересовало, как оно на деле выходит с модулями на Lua? Он же жутко однопоточный, и в нём даже нет shift/break в циклах, разве можно так жить?

Да, на луа можно писать шустрые вещи, но они выходят шустрыми до тех пор, пока задача не требует ожидания I/O или, не дай Патрег, интернетов, тогда всё встаёт колом, и начинает о_О.

Да, на луа можно писать шустрые вещи, но они выходят шустрыми до тех пор, пока задача не требует ожидания I/O или, не дай Патрег, интернетов, тогда всё встаёт колом, и начинает о_О.

В nginx плагины на луа вполне шустро работают, если без фанатизма

плагины на луа вполне шустро работают

плагины

Я я тут про

драйверы на lua

Кстати, а как оно работает. В плане дрова на луа? Jit?

А я откуда знаю? Я у beastie спросил как раз именно это, но ответа пока нет. Жди, подписывайся на тред или что там обычно делают в этих ваших инторнетах. :3

Ждём модулей ядра на bash

Это ты на опеннете постоянно ноешь про хипстеров?

SWIFT — это Society for Worldwide Interbank Financial Telecommunications, а ЯП называется Swift. Спасибо, кстати, за вброс ссылки на мою заметку.

Чего не знаю, того не знаю. Я знаю только, что оно есть. Но вот, как оно работает — увы нет.

Он же жутко однопоточный

Не проблема, в каждом потоке запускается по интерпретатору

и в нём даже нет shift/break в циклах

че? break всегда был

На MS .NET

На VBA тогда уж.

Нетъ. У меня для этого ЛОР есть.

че? break всегда был

Эт я с недосыпу. Но сдвига всё равно нет.

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

Кстати, во фряху ж тоже вроде завезли Lua в ядро, или я что-то путаю?

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

SWIFT — это Society for Worldwide Interbank Financial Telecommunications, а ЯП называется Swift

++ разница как между iOS и IOS

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

То есть ты считаешь, что Си так и будет использоваться для написания ядер, несмотря на все недостатки?

// не в защиту Lua

Но сдвига всё равно нет.

continue - не?

Ну так Swift, Rust, Go, D - вон сколько кондидатов ему на замену.

Но сдвига всё равно нет.

head = table.remove(t, 1)

Да, многословно, но это же не перл, тут не обвешиваются сахаром по самое немогу

Ответ точно мне предназначался?

Go, D

Garbage collection в ядре – не лучшая идея, наверное.

А, так они по пути Java идут что ли, тогда их вычеркни.
Я имел в виду что на си вечно писать конечно же не будут, что нибудь из свежих альтернатив да выстрелит.

а хипстота вечно лезет со своими свистелками и перделками куда ни попадя.

Почему «настоящие программисты» так не любят новые языки и подходы, даже если у них есть преимущества? Что плохого в коде не на C в ядре?

Прослойка на C

Дальше не читал.

Именно поэтому я и спросил, что зависит от кода на си, который вызывает код на луа. Если реализация говно, то это будет не модуль, а тормоз.

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

У него немного другой принцип действия, не?

Именно таким костылём и приходится пользоваться, но не лучшее решение. Правда, я делаю это хелперной функцией, и вызываю shift(t,n), но всё равно лишнее телодвижение. Даже в сраном баше есть это, а он даже не ЯП.

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

можешь индексы складывать

Не первый год у меня конфиг на lua, я уж многие костыли знаю. Но это всё равно не решение. Хотелось бы видеть решение средствами самого ЯП, а не require("helpers.dirtyhacks").

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

А что насчёт Rust? Там-то такого нет (?), или он не относится к «хипстерским языкам»?

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

само ядро написано на С

Историческое недоразумение.

С задуман как язык, специализированный для системного программирования.

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

в нём нет ничего неявного.

Неявное преобразование типов как минимум. Алсо куча UB, позволяющих незаметно отстрелить себе ногу.

в хипстерских языках полно автоматических сборщиков говна за программистом.

Обычно автоматический сборщик там только один на язык, и он убирает память.

Я правильно понимаю, ты считаешь любой язык, который младше тебя, экспериментальным поделием?

в нём нет ничего неявного.

Ага. Всё неявное в итоге пишется программистом. Типа атомарных переменных, smp-барьеров и механизма подсчета ссылок (сюрприз-сюрприз, в ядре за программистом подчищает написанный руками ссылочный GC).

нет. нужно, чтобы ЯП хотя бы лет десять имел совместимость со своими же собственными компиляторами.

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

Хорошая попытка вывернуться, но вернемся к сути: все крупные проекты самостоятельно реализуют неочевидные вещи, которых нет в C. В том числе ссылочные gc. Как мне подсказывает здравый смысл, проще один раз реализовать их в языке.

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

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

Библиотека подразумевает вызовы. А это значит, что надо руками расставлять obj_get() и obj_put(), что довольно-таки тупо в 16-то году. Ты же не делаешь подобного со стековыми переменными, правда?

это даёт универсальность и переносимость на многие платформы.

Не очень понимаю, как ссылочный GC ограничивает портируемость. Ну да ладно.

там своя специфика и там есть свои реализации разных механизмов. они оптимизированы конкретно под задачи ядра и там используются всеми модулями.

Бугага. Те же атомики там просто потому, что в C их не было.

нет. нужно, чтобы ЯП хотя бы лет десять имел совместимость со своими же собственными компиляторами.

C и C++ под этот критерий не подходят. В C11 выкинули многострадальную функцию gets, чем нарушили обратную совместимость. Компиляторы C++ до C++11 стандарт не умели вообще как минимум из-за отсутствия поддержки export. Плюс несовместимость между компиляторами имеет место до сих пор. Я встречал код без UB, который выдавал разное поведение после компиляции gcc и clang.

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

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