Что-то я, граждане, в очередной раз не понимаю, зачем нужен Erlang. Т.е очередная моя история с ним, кажется, близка к фейлу в стиле вступления презентации про опердень
( Read more... )
То что можно на C написать систему с акторами и message passing... Ну можно конечно, Erlang ведь на C написан. Но зачем же это писать самому второй раз?
Быстрый вопрос: можно ли там эволюционировать кластер постепенно, нода за нодой? Чтобы менялись сообщения, их типы, а система оставалась на плаву без необходимости перекомпилировать и рестартовать вообще всё?
Быстрый ответ (не глядя) --- скорее всего нет. Но есть мнение, что вся эта вот машинерия с кластерами, обновлениями и т.п. должна быть вне языка. Что бы ноды кластера можно было писать уже на чём угодно. Привязка к определенному языку это ошибка.
Ну так на C это можно (ASN.1), на Erlang - можно (dynamic typing). А на хаскеле, получается, надо как на C делать (кодировать через расширяемый формат)? Так это же тупо неудобно. На эрланге - удобно.
ASN.1 это очень маленький кусок middleware. Сериализация? Это как раз в CH решено.
Конечно, в нем есть ограничения, свойственные статически типизированному и вообще статическому языку. Это накладывает принципиальные ограничения, с которыми надо смириться. Но еще раз --- я что-то против замыкания на какой-то один язык, всё это (failover, миграция, синхронизация стейтов, messaging) - должно решаться вне-языковыми средствами. В язык должны быть необходимые рукоятки для этого.
По-моему в CH как раз с сериализацией в плане динамики плохо на данный момент, static values привязаны к бинарнику, для перегрузки придётся выходить за пределы CH, т.е. он толком-то не помогает в данном плане
Я думаю, надо уже где-то зафиксировать, что middleware и язык ОБЯЗАНЫ быть разными сущностями.
После этого что-то искать уже необязательно, кмк. Фичи CH продолжают иметь смысл, а вот доращивать его до всего того, что умеет Erlang --- надо серьезно подумать. Особенно учитывая современные тенденции.
Мой ответ лежит в плоскости "если очень хочется, то можно".
Основная проблема с CH находится в районе передачи сообщений и версионирования их передачи и приёма. То есть, если я раньше передавал Budum Int Bool, а начал передавать Budum Int String Bool, то мне не надо принимать такое сообщение в старом клиенте. Проблема в том, что старый клиент может прочитать из двоичных данных строки булевское значение, поскольку сериализация отдана на откуп коду вне CH, в отличии от Эрланга. Экспериментов я не производил, думаю, что проблема должна возникнуть с большой вероятностью, но её легко решить - мы про неё знаем.
Такое может быть только в случае типизированных каналов, но пихнуть сообщение нового типа в старый канал так просто не получится. В обычном же случае отправляется {fingerprint,serialized-message}, где fingerprint отвечает типу сообщения и постоянен между всеми программами собранными данным компилятором (хотя тут могу быть не точен).
пока можно, но с трудом (используя plugins), начиная с ghc-7.8 в RTS появился нормальный unloading, так, что все будет в порядке, просто закачиваешь новую .so-шку и "просишь" обновиться. Но это дело не автоматизировано, точнее я видел один публичный проект, но не уверен, что им занимаются.
В со следующим релизом ghc, будет полее полная поддержка static-values и все станет лучше.
static-values, которые в 7.10 приколочены к бинарнику, правильнее точнее сказать к модулю, т.е. если ты скомпиляешь модуль - раздашь разным бинарникам и они его загрузят, то символы будут одинаковыми. Но в данный момент полноценное решение, которое провернёт все автоматом мне неизвестно.
Вообще существует ещё и другой вариант - раздача llvm-байткода его компиляция и загрузка, я знаю где так делается, но это закрытое решение (не у нас).
То что можно на C написать систему с акторами и message passing... Ну можно конечно, Erlang ведь на C написан. Но зачем же это писать самому второй раз?
Reply
Reply
Reply
писать уже на чём угодно. Привязка к определенному языку это ошибка.
Reply
Reply
раз в CH решено.
Конечно, в нем есть ограничения, свойственные статически типизированному
и вообще статическому языку. Это накладывает принципиальные ограничения,
с которыми надо смириться. Но еще раз --- я что-то против замыкания на какой-то
один язык, всё это (failover, миграция, синхронизация стейтов, messaging) - должно
решаться вне-языковыми средствами. В язык должны быть необходимые рукоятки
для этого.
Reply
Reply
Смотрел ли ты на CH?
Reply
После этого что-то искать уже необязательно, кмк. Фичи CH продолжают иметь смысл, а вот доращивать его до всего того, что умеет Erlang --- надо серьезно подумать. Особенно учитывая современные тенденции.
Reply
Основная проблема с CH находится в районе передачи сообщений и версионирования их передачи и приёма. То есть, если я раньше передавал Budum Int Bool, а начал передавать Budum Int String Bool, то мне не надо принимать такое сообщение в старом клиенте. Проблема в том, что старый клиент может прочитать из двоичных данных строки булевское значение, поскольку сериализация отдана на откуп коду вне CH, в отличии от Эрланга. Экспериментов я не производил, думаю, что проблема должна возникнуть с большой вероятностью, но её легко решить - мы про неё знаем.
Reply
Reply
В со следующим релизом ghc, будет полее полная поддержка static-values и все станет лучше.
Reply
Сложно нарисовать helloworld с перегрузкой под 7.10?
Reply
Вообще существует ещё и другой вариант - раздача llvm-байткода его компиляция и загрузка, я знаю где так делается, но это закрытое решение (не у нас).
Reply
Альтернатива вообще или для этой конкретной задачи? За вообще я не знаю, но я и не знаю,
зачем бы я вообще брал Эрланг для любого своего проекта.
Его легко продать - у него есть репутация в телекоме, он якобы простой, легко
найти людей.
Reply
Leave a comment