Смешивая Эрланг и Хаскель

Если вы купились на парадигму функционального программирования, скорее всего, Вам нравятся как Эрланг, так и Хаскелл. Оба имеют чисто функциональные ядра и другие преимущества, такие как легкие нити, которые делают их хорошо подходящими для многоядерного мира. Но есть и некоторые отличия.

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

Haskell, с другой стороны, имеет самую сложную систему типов любого основного языка. (Где я определяю "мейнстрим" как любой язык, у которого есть опубликованная книга О'Рейли, поэтому Хаскелл считает.) Свое прямолинейное однопоточное представление смотрит главным образом к Erlang и свои облегченные резьбы смотрят даже более светлыми слишком.

Я пытаюсь собрать платформу разработки для остаток моей жизни кодирования и было интересно можно ли было смешать Эрланга и Хаскелла, чтобы добиться лучшей платформы породы. Этот вопрос состоит из двух частей:

1. Я хотел бы использовать Erlang как своего рода отказоустойчивый MPI для склеивания экземпляров среды выполнения GHC вместе. Там будет один процесс Erlang в GHC времени выполнения. Если "невозможное произошло", и время выполнения GHC умерло, то процесс Erlang каким-то образом обнаружит это и тоже умрет. Функции загрузки и распространения горячего кода Erlang будут просто продолжать работать. Этот Среда выполнения GHC может быть настроена на использование только одного ядра или всех ядер на локальном компьютере или любой комбинации между ними. После того, как библиотека Erlang была написана, остальная часть кода уровня Erlang должна быть чисто шаблонной и автоматически создаваться на основе каждого приложения. (Возможно, с помощью Haskell DSL, например.) Как можно достичь хотя бы некоторых из этих вещей?


2. Я хотел бы, чтобы Эрланг и Хаскелл могли использовать один и тот же коллектор гаража. (Это гораздо дальше идея, чем 1.) Языки, которые работают на JVM и CLR, достигают большей массы за счет совместного использования среды выполнения. Я понимаю, что существуют технические ограничения на запуск Erlang (загрузка горячего кода) и Haskell (более высокий полиморфизм) на JVM или CLR. Но как насчет распаковки только сборщика мусора? (Своего рода начало выполнения для функциональных языков.) Распределение, очевидно, все равно должно быть очень быстрым, поэтому, возможно, этот бит должен быть статически связан. А там должно быть будьте некоторым mechansim, чтобы отличить изменяемую кучу от неизменяемой кучи (включая ленивую запись один раз памяти), поскольку GHC нуждается в этом. Было бы возможно изменить как HIPE, так и GHC, чтобы сборщики мусора могли совместно использовать кучу?

пожалуйста, ответьте на любой опыт (положительный или отрицательный), идеи или предложения. На самом деле, любая обратная связь (за исключением прямого злоупотребления!) только приветствовать.

обновление

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

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

в платформе, которую я предложил выше, я бы только написал Haskell, так как шаблон Erlang будет автоматически сгенерирован. Так как долго будет Хаскелл последний? Ну Лисп все еще с нами и не похоже, что он уходит в ближайшее время. Haskell является открытым исходным кодом BSD3 и достиг критической массы. Если само программирование все еще существует через 50 лет, я бы ожидал, что Haskell или какая-то непрерывная эволюция Haskell все еще будет здесь.

обновление 2в ответ на сообщение рвирдинга

согласовано-реализация полной универсальной виртуальной машины "Erskell/Haslang" может не быть абсолютно невозможно, но это, безусловно, будет очень трудно. Совместное использование только уровня сборщика мусора как что-то вроде виртуальной машины, в то время как все еще сложно, звучит на порядок менее сложно для меня, хотя. В модели сборки мусора функциональные языки должны иметь много общего - непредвзятость неизменяемых данных (включая thunks) и требование очень быстрого выделения. Поэтому тот факт, что общность тесно связана с монолитными виртуальными машинами, кажется добрым странно.

виртуальные машины действительно помогают достичь критической массы. Просто посмотрите, как "облегченные" функциональные языки, такие как F# и Scala, взлетели. Scala может не иметь абсолютной отказоустойчивости Erlang, но он предлагает путь к спасению для очень многих людей, которые привязаны к JVM.

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

абсолютно, это имеет смысл для меня. Очень умные люди в команде разработчиков GHC, похоже, пытаются решить часть проблемы с параллельным GC "stop the world".

http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf

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

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

In таким образом, для данного случая использования я мог бы после бенчмаркинга выбрать путь Erlang и запустить одну среду выполнения GHC (с однопоточным GC) плюс один процесс Erlang на ядро и позволить Erlang копировать память между ядрами для хорошей локальности.

в качестве альтернативы, на двухпроцессорной машине с 4 ядрами на процессор с хорошей пропускной способностью памяти на процессоре, бенчмаркинг может предполагать, что я запускаю одну среду выполнения GHC (с параллельным GC) плюс один процесс Erlang за процессор.

в обоих случаях, если Erlang и GHC могут совместно использовать кучу, общий доступ, вероятно, будет привязан к одному потоку ОС, работающему на одном ядре. (Я выхожу из своей глубины здесь, поэтому я задал вопрос.)

У меня также есть другая повестка дня - бенчмаркинг функциональных языков независимо от GC. Часто я читал о результатах контрольных показателей данные, используемые в помощью GHC в Эрланг в ... и интересно, насколько результаты смешиваются с различными GCs. А что если выбор GC может быть ортогональным к выбору функционального языка? Как дорого стоит GC в любом случае? См. это сообщение в блоге Devil advocates

http://john.freml.in/garbage-collection-harmful

моим другом Lisp Джоном Фремлином, который он, очаровательно, дал название своего поста "автоматизированная сборка мусора-это мусор". Когда Джон утверждает, что GC медленный и на самом деле не ускорился, я хотел бы иметь возможность противостоять некоторым числам.