на каком языке должен быть переписан Linux?

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

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

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

Соответственно, что делать дальше? Дальше - написать с нуля нормальную объектную ОС, с софтварной изоляцией, GC, и прочим. Какой язык? Лисп, в идеале, но даже C# / Sign# сойдет.

На финском

Ruby

С - опасный, багообразующий язык

Как обычно плохому танцору мешают яйца. Язык тут оказывается баги образует...

Тут проблема в том, что тот кто может это всё сделать - того и линукс с сями устраивает.

А те кого не устраивает и кто хочет «нормальную объектную ОС», те не смогут.

те не смогут.

Плюсую.

И кому будет нужна эта ОС без прикладного ПО?

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

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

Поэтому нужно с умом создать новый низкоуровневый ООП ЯП с собственным компилятором. И только потом браться за ОС, параллельно обкатывая новый ЯП в прикладном ПО.

в том числе из крупных корпораций

Вот это болото точно не авторитет.

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

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

Кто и когда? Хочу услышать эту кулстори.

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

Metaprog.

Когда Метапрог будет готов, можно будет автоматически конвертировать сишный код в Метапрог-диаграммы.

Common Lisp?

погодь, а метапрог разве не транслируется потом обратно в си?

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

Ок, а как насчёт изначального аргумента? Сможет метапрог исправить ошибки в изначальном коде, из-за которых си и ругают?

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

Ведь выразить мысль можно на любом языке (естественном и программирования). А вот создать мысль язык не может: нужно сознание.

Другими словами, если уж переписывать, то лучше начать с выбора команды людей.

Код будет визуализирован, а с визуальными диаграммами должно быть проще работать, особенно коллективно.

Ну это такое. Если метапрог не даёт гарантий безопасности сгенерированного(!) кода, то Linux на нём переписывать не нужно.

При условии идеальной работы транслятора диаграмм в Си баги могут быть только в диаграммах. А при условии идеальной работы обратного транслятора (Си в диаграммы) баги могут быть только те, что изначально были в коде ядра или другом транслируемом коде.

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

Кстати, возможно, Метапрог в будущем будет транслироваться не в Си, а в машинный код или LLVM IR.

Вообще, я слышал, что весьма сложно даже спеллчекер для современного С сделать водиночку, не говоря уже о полном разборе синтаксиса и трансляции куда-то. Уже есть наработки?

Есть транслятор из диаграмм в Си, а также есть парсер сишных инклюдов на основе castxml. Смотри мои темы.