Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
ссылка битая 404 Not Found
The requested resource was not found: malformed package identifier
The requested resource was not found: malformed package identifier
Что значит недавно? Давным-давно можно писать внешние модули (т.н. порты) и даже целые ноды для Erlang на C и Java. Недавно появилось NIF, пока что в качестве экспериментальной возможности. Штука безусловно нужная и удобная, так как пишется не отдельный модуль, и не нода, а просто функция, которую виртуальная машина принимает так же, как функцию Erlang.
Опять же на каких задачах Haskell быстрее? На бенчмарке математика, а в документации прямо говорится: Erlang плохо умеет считать, хотя и поддерживает длинную арифметику. Regexp немного настораживает, но с этим можно жить, благо задача не так часто попадается и не столь существенно влияет на общую производительность.
Это не совсем верно, цель написания внешних модулей на С — добиться максимальной производительности на кусках кода, которые Erlang делает плохо. Те же математические рассчёты. Использовать для этих целей Haskell равнозначно расхожей фразе «шило на мыло». Кроме того, Erlang, хоть и функциональный, но разительно отличается как от С, так и от Haskell. Переписывать же не обязательно, проще написать внешний модуль сразу. А теперь, благодаря NIF, это стало совсем просто и удобно.
Опять же на каких задачах Haskell быстрее? На бенчмарке математика, а в документации прямо говорится: Erlang плохо умеет считать, хотя и поддерживает длинную арифметику. Regexp немного настораживает, но с этим можно жить, благо задача не так часто попадается и не столь существенно влияет на общую производительность.
Я думаю что проще переписывать код с Erlang на Haskell чем на С, потому что оба языка функциоанльные.
Это не совсем верно, цель написания внешних модулей на С — добиться максимальной производительности на кусках кода, которые Erlang делает плохо. Те же математические рассчёты. Использовать для этих целей Haskell равнозначно расхожей фразе «шило на мыло». Кроме того, Erlang, хоть и функциональный, но разительно отличается как от С, так и от Haskell. Переписывать же не обязательно, проще написать внешний модуль сразу. А теперь, благодаря NIF, это стало совсем просто и удобно.
Именно NIF-ы я и имел ввиду, порты и ноды можно было писать — но в статье написано «Недавно появилась возможность использовать С для написания модулей Erlang систем». Хаскел быстрее, парадигма остаётся та же — значит перенос кода происходит быстрее.
По поводу их различий: www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell.
Хотя естественно критические элементы нужно переносить на С.
По поводу их различий: www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell.
Хотя естественно критические элементы нужно переносить на С.
Хаскел быстрее, парадигма остаётся та же — значит перенос кода происходит быстрее.
Можете привести пример? Я не согласен. Erlang слишком ориентирован на параллельность во всём. Для переноса подходят только последовательные участки кода, а тут уже не имеет вес использованная парадигма. Линейный код — он на любом языке практически идентичен.
И опять же я хочу заострить внимание не на переносе, а на изначальном написании критических кусков кода на С.
Для хаскел есть несколько библиотек-расширений для erlang style concurrency.
«И опять же я хочу заострить внимание не на переносе, а на изначальном написании критических кусков кода на С.» — а как же идеология «сначала сделай правильно — и только потом, если нужно быстро»?
И вы сами себе противоречите — неужели в С больше средств для параллелизма чем в хаскел?
«И опять же я хочу заострить внимание не на переносе, а на изначальном написании критических кусков кода на С.» — а как же идеология «сначала сделай правильно — и только потом, если нужно быстро»?
И вы сами себе противоречите — неужели в С больше средств для параллелизма чем в хаскел?
Я же написал, что переносятся последовательные линейные участки кода, никакого противоречия, просто вы невнимательно читали :) Под Erlang прежде всего нужно понимать OTP — платформу, обеспечивающую всю ту вкусную параллельность и стабильность, а не язык. Переносить параллельность в Наskell или C глупо, теряется весь смысл. Посему Erlang-style это именно что style, что-то вроде китайской подделки под швейцарские часы.
По поводу идеологии… Ну вот у меня есть тяжелая математическая функция, думаете есть смысл писать её сначала на Erlang, если и так ясно, что она будет бутылочным горлышком? Преждевременная оптимизация это плохо, но здравый смысл нужно тоже иметь.
По поводу идеологии… Ну вот у меня есть тяжелая математическая функция, думаете есть смысл писать её сначала на Erlang, если и так ясно, что она будет бутылочным горлышком? Преждевременная оптимизация это плохо, но здравый смысл нужно тоже иметь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускоряем работу Erlang системы без замедления разработки