Какие языки хороши для написания операционной системы?

а при чем тут это? чем то, что ты сказал, мешает ос «прислуживать» прикладному по? я, собсна, весь тред такую мысль и толкаю, а уважаемый оппонент связывает все вместе просто потому. что «так же логично, _по-моему_»

чем то ... мешает ос «прислуживать» прикладному по?

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

Lisp

А давай не ты будешь решать, что и кому «позволительно».

Ок, я никого не отговариваю писать драйвера с HOF и LINQ (и с тёплым ламповым оверхедом), я просто констатирую тот факт, что пока, в силу объективных причин, это делают только в прототипах (вроде Singularity или House).

Подождём пока 64-битные 32 ядра с over 1TB RAM войдут в наши дома :)

прошу заметить, всё же, что мы говорим не о GNU/Linux, а о некой абстрактной ОС, которую хочет ТС.

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

Просто если исходить из такого определения, то 5 DVD дисков Debian-а это тоже «ОС» - вопрос OP теряет смысл, так как становится эквивалентен вопросу «на каких языках кроме С, С++ и ассемблера можно писать приложения вообще» (очевидно, на любых на которых получается приблизиться к решению ТЗ). Хочется более чёткого определения, например - OS = boot loader + kernel + init scripts + shell + *utils + lib* + [optional] cc. То есть только то что обычно включается в релиз BSD или минимальный дистрибутив GNU/Linux (например, LFS, arch или stage3). Тогда можно разделить области разработки - system development (а именно - kernel development и OS development) и application development (например, game development).

Кто мешает реализовать GC аппаратно? В этом случае отпадают языки без GC :)

Кто мешает реализовать GC аппаратно?

Кто-то мешает захватить штурмом главные офисы Intel/AMD.

В этом случае отпадают языки без GC

Я не проверял, но ходят байки, что reduceron на FPGA уделывает существующие CPU.

А ты научись точнее выражаться.

Кто-то мешает захватить штурмом главные офисы Intel/AMD.

А зачем захватывать штурмом главные офисы Intel/AMD?

Я не проверял, но ходят байки, что reduceron на FPGA уделывает существующие CPU.

Ну что угодно уделает что угодно другое на каких-нибудь задачах.

А зачем захватывать штурмом главные офисы Intel/AMD?

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

Чтобы они начали продавать эти самые аппаратные реализации GC (что бы это ни значило).

А зачем им тратить деньги на выпуск того, что никто не будет покупать?

А зачем им тратить деньги на выпуск того, что никто не будет покупать?

Я тоже думаю что это незачем. Лисп-машины с гетерогенной (нелинейной) памятью уже существовали одно время. Сейчас любая гетерогенность делается на гомогенной (линейной) памяти.

С другой стороны, нельзя с уверенностью отрицать, что для ФЯП не может появиться чип (например, то что программирует reduceron), наличие которого на MB было бы полезно для этих ФЯП.

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

В reduceron банальный stop and copy, что уполовинивает память и тормозит пропорционально объему памяти. Я уж не говорю о том, что оно не сможет работать с виртуальной памятью как следует.

Нет особого смысла аппаратно ускорять GC. Вот выделить одно процессорное ядро исключительно для GC было бы можно.

Оверхед GC (весьма незначительный по нынешним меркам) уравновешивается многочисленными преимуществами от его применения. На системном уровне от него может потребоваться real time отклик, но и это не проблема, сейчас полно hard real time GC.

сейчас полно hard real time GC.

Именно hard? Можно список из нескольких?

Где-то в книжке в одной... Б. Хук, «Художество портабельного программирования», например, ОС рассматривалась как первоначальный слой абстракции (или даже - унификации абстракций) - и соотвтественно, первоначальный «слой портабельности». Дедовские способы на «голом железе» по-своему неплохи (ниши-то железячные никуда не делись), но прикладной мейнстрим от этого стремился уйти... И таки ушел: в 90-х многие проги содержали в том или ином виде самописные компоненты осей защищенного режима(или разновсяких расширителей), у каждой своих, друг с другом не совместимых. Это всех достало :)

Вот выделить одно процессорное ядро исключительно для GC было бы можно.

Прямо в ядре? Приложение должно вызывать gc() как системный вызов, или ядро само должно чистить кучи приложений которые этого хотят?