Здравствуйте, Sorantis, Вы писали:
S>здесь описывается возможное скрещение этих двух языков. S>Идея довольно интересная. мне показалось что результатом окажется MS Erlang. или я не прав?
Может пояснишь, что под MS Erlang подразумеваешь? Будут ли реализованы след. вещи:
* "одинаковая" отсылка сообщений как внутри одной ноды так и по сети
* достаточно мелкая гранулярность параллелизации
* selective receive
* OTP (в основном интересна инфраструктура супервайзоров и "поведений")
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Sorantis, Вы писали:
S>>здесь описывается возможное скрещение этих двух языков. S>>Идея довольно интересная. мне показалось что результатом окажется MS Erlang. или я не прав?
К>Может пояснишь, что под MS Erlang подразумеваешь? Будут ли реализованы след. вещи:
К>"одинаковая" отсылка сообщений как внутри одной ноды так и по сети К>достаточно мелкая гранулярность параллелизации
Уже есть в Axum
К>selective receive
Вместо этого есть несколько протов в одном канале.
Хотя тоже несет свои недостатки.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Курилка, Вы писали: К>>Может пояснишь, что под MS Erlang подразумеваешь? Будут ли реализованы след. вещи:
К>>"одинаковая" отсылка сообщений как внутри одной ноды так и по сети К>>достаточно мелкая гранулярность параллелизации G>Уже есть в Axum
Покажи, плз, особенно про гранулярность интересно (e.g. могу ли я написать "вечный цикл" который "убъёт" ноду?).
К>>selective receive G>Вместо этого есть несколько протов в одном канале. G>Хотя тоже несет свои недостатки.
Что есть "несколько протов"?
У одного канала может быть несколько слушателей? И к чему тут "вместо" тогда?
G>А что есть OTP?
Open Telecom Platform — наработаная библиотека примитивов и инфраструктуры для создания соотв. приложений. Эрланг обычно пишется Elang/OTP
+ ещё интересно как с дотнетовской памятью решается вопрос (F# же не запрещает mutability)
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Курилка, Вы писали: К>>>Может пояснишь, что под MS Erlang подразумеваешь? Будут ли реализованы след. вещи:
К>>>"одинаковая" отсылка сообщений как внутри одной ноды так и по сети К>>>достаточно мелкая гранулярность параллелизации G>>Уже есть в Axum
К>Покажи, плз, особенно про гранулярность интересно (e.g. могу ли я написать "вечный цикл" который "убъёт" ноду?).
Да, можешь.
Гранулярность обеспечивается асинхронными функциям (у которой стоит модификатор asynchronous).
К>>>selective receive G>>Вместо этого есть несколько протов в одном канале. G>>Хотя тоже несет свои недостатки.
К>Что есть "несколько протов"?
Взаимодействие агентов в axum ощусществляется через "каналы", канал состоит из нескольких типизированных портов.
G>>А что есть OTP? К>Open Telecom Platform — наработаная библиотека примитивов и инфраструктуры для создания соотв. приложений. Эрланг обычно пишется Elang/OTP
А что конкретно там есть?
А то я по erlang не спец.
К>+ ещё интересно как с дотнетовской памятью решается вопрос (F# же не запрещает mutability)
Ну а Axum запрещает там, где mutability может помешать.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, Курилка, Вы писали: К>>>>Может пояснишь, что под MS Erlang подразумеваешь? Будут ли реализованы след. вещи:
К>>>>"одинаковая" отсылка сообщений как внутри одной ноды так и по сети К>>>>достаточно мелкая гранулярность параллелизации G>>>Уже есть в Axum
К>>Покажи, плз, особенно про гранулярность интересно (e.g. могу ли я написать "вечный цикл" который "убъёт" ноду?). G>Да, можешь. G>Гранулярность обеспечивается асинхронными функциям (у которой стоит модификатор asynchronous).
Т.е. гранулярность "ручной величины"? Под мелкую не тянет.
Не очень здорово
К>>>>selective receive G>>>Вместо этого есть несколько протов в одном канале. G>>>Хотя тоже несет свои недостатки.
К>>Что есть "несколько протов"? G>Взаимодействие агентов в axum ощусществляется через "каналы", канал состоит из нескольких типизированных портов.
Это не объясняет почему ты ими заменяешь selective receive, точней из этого описания ничего толком сказать нельзя.
G>>>А что есть OTP? К>>Open Telecom Platform — наработаная библиотека примитивов и инфраструктуры для создания соотв. приложений. Эрланг обычно пишется Elang/OTP G>А что конкретно там есть? G>А то я по erlang не спец.
ну читай про супервайзоры, стандартные поведения.
И ещё вопрос (не про ОТП, а про сам эрланг) — линки между процессами можно построить на базе этих каналов?
Если нет, то с реализацией аналога ОТП должны быть большие проблемы.
К>>+ ещё интересно как с дотнетовской памятью решается вопрос (F# же не запрещает mutability) G>Ну а Axum запрещает там, где mutability может помешать.
Т.е. только на границах между процессами?
И GC дотнетный? Т.е. мы не можем как в Эрланге просто взять и "выкинуть" весь хип процесса?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Курилка, Вы писали:
К>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, Курилка, Вы писали: К>>>>>Может пояснишь, что под MS Erlang подразумеваешь? Будут ли реализованы след. вещи:
К>>>>>"одинаковая" отсылка сообщений как внутри одной ноды так и по сети К>>>>>достаточно мелкая гранулярность параллелизации G>>>>Уже есть в Axum
К>>>Покажи, плз, особенно про гранулярность интересно (e.g. могу ли я написать "вечный цикл" который "убъёт" ноду?). G>>Да, можешь. G>>Гранулярность обеспечивается асинхронными функциям (у которой стоит модификатор asynchronous).
К>Т.е. гранулярность "ручной величины"? Под мелкую не тянет. К>Не очень здорово
Да ну. Как раз наоборот, незачем вычисление синуса запускать через механизм переключения задач.
К>>>>>selective receive G>>>>Вместо этого есть несколько протов в одном канале. G>>>>Хотя тоже несет свои недостатки.
К>>>Что есть "несколько протов"? G>>Взаимодействие агентов в axum ощусществляется через "каналы", канал состоит из нескольких типизированных портов.
К>Это не объясняет почему ты ими заменяешь selective receive, точней из этого описания ничего толком сказать нельзя.
selective receive насколько я понял нужен для передачи разных типов, через один "порт". В Axum для этого разные порты создавать надо.
К>И ещё вопрос (не про ОТП, а про сам эрланг) — линки между процессами можно построить на базе этих каналов? К>Если нет, то с реализацией аналога ОТП должны быть большие проблемы.
Они только так и строятся.
К>>>+ ещё интересно как с дотнетовской памятью решается вопрос (F# же не запрещает mutability) G>>Ну а Axum запрещает там, где mutability может помешать. К>Т.е. только на границах между процессами?
нет
К>И GC дотнетный?
да
К>Т.е. мы не можем как в Эрланге просто взять и "выкинуть" весь хип процесса?
А в чем смысл такой операции?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>Т.е. гранулярность "ручной величины"? Под мелкую не тянет. К>>Не очень здорово G>Да ну. Как раз наоборот, незачем вычисление синуса запускать через механизм переключения задач.
Т.е. 1 процесс приводящий райнтайм в даун — это нормально?
Надеюсь ты помнишь, чем была плоха кооперативаная многозадачность в начальных версиях майкрософтовской ОС.
А синус у тебя, видимо, на F# пишется ручками.
К>>И ещё вопрос (не про ОТП, а про сам эрланг) — линки между процессами можно построить на базе этих каналов? К>>Если нет, то с реализацией аналога ОТП должны быть большие проблемы. G>Они только так и строятся.
Кто и как строятся? Раскрой.
Что под линками подразумевается: я запускаю процесс (где-то "там"), хочу перехватывать "умирание" его, т.е. в таком случае мне придёт соответсвующее сообщение в мейлбокс. На этом супервайзоры построены.
К>>>>+ ещё интересно как с дотнетовской памятью решается вопрос (F# же не запрещает mutability) G>>>Ну а Axum запрещает там, где mutability может помешать. К>>Т.е. только на границах между процессами? G>нет
Очень полный ответ
К>>Т.е. мы не можем как в Эрланге просто взять и "выкинуть" весь хип процесса? G>А в чем смысл такой операции?
Ну прикинь: у тебя действительно сильнопараллельная задача, процессы создаются тоннами. Как думаешь чей гц будет работать быстрее? Который просто "выкидывает" хипы умерших процессов, или дотнетный?
Здравствуйте, Курилка, Вы писали:
К>Т.е. 1 процесс приводящий райнтайм в даун — это нормально?
Ну не факт что полный даун. В Axum задачи раскидываются на все свободные ядра.
К>А синус у тебя, видимо, на F# пишется ручками.
Ну пусть это будет вычисление производной.
К>>>И ещё вопрос (не про ОТП, а про сам эрланг) — линки между процессами можно построить на базе этих каналов? К>>>Если нет, то с реализацией аналога ОТП должны быть большие проблемы. G>>Они только так и строятся.
К>Кто и как строятся? Раскрой. К>Что под линками подразумевается: я запускаю процесс (где-то "там"), хочу перехватывать "умирание" его, т.е. в таком случае мне придёт соответсвующее сообщение в мейлбокс. На этом супервайзоры построены.
Ну агент сам должен сообщить о своем окончании
К>>>>>+ ещё интересно как с дотнетовской памятью решается вопрос (F# же не запрещает mutability) G>>>>Ну а Axum запрещает там, где mutability может помешать. К>>>Т.е. только на границах между процессами? G>>нет К>Очень полный ответ
Ага. По этому поводу надо спеку читать.
К>>>Т.е. мы не можем как в Эрланге просто взять и "выкинуть" весь хип процесса? G>>А в чем смысл такой операции?
К>Ну прикинь: у тебя действительно сильнопараллельная задача, процессы создаются тоннами. Как думаешь чей гц будет работать быстрее? Который просто "выкидывает" хипы умерших процессов, или дотнетный?
А дотнетный хоронит с почестями?
В GC .NETа уборка мусора ничегоне стоит, затраты только на перемещение живых объектов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>Что под линками подразумевается: я запускаю процесс (где-то "там"), хочу перехватывать "умирание" его, т.е. в таком случае мне придёт соответсвующее сообщение в мейлбокс. На этом супервайзоры построены. G>Ну агент сам должен сообщить о своем окончании
Дак он-то умер уже, как он сообщит? Надо как раз смерть отловить.
Ну или ещё вариант — "отвалилась" нода, тётка-уборщица выдернула шнур сетевой (ну это для шутки, а так думаю сам можешь вариант придумать реалистичный)
В общем до Эрланга есть, что "дотягивать". Думаю, пара десятков лет промышленного использования языка даёт эрлангу солидный задел.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Курилка, Вы писали:
К>>>Что под линками подразумевается: я запускаю процесс (где-то "там"), хочу перехватывать "умирание" его, т.е. в таком случае мне придёт соответсвующее сообщение в мейлбокс. На этом супервайзоры построены. G>>Ну агент сам должен сообщить о своем окончании
К>Дак он-то умер уже, как он сообщит? Надо как раз смерть отловить. К>Ну или ещё вариант — "отвалилась" нода, тётка-уборщица выдернула шнур сетевой (ну это для шутки, а так думаю сам можешь вариант придумать реалистичный)
Axum в распределенной среде работает через WCF, там его средствами всякие фейлы будут отлавливаться (если будут — не знаю как оно внутри устроено)
К>В общем до Эрланга есть, что "дотягивать". Думаю, пара десятков лет промышленного использования языка даёт эрлангу солидный задел.
Ну естественно, Axum — вообще экспериментальный проект.
Hello, Sorantis, you write:
S> здесь описывается возможное скрещение этих двух языков. S> Идея довольно интересная. мне показалось что результатом окажется MS Erlang. или я не прав?
То оказывается, что Эрданг — это не только асинхронные сообщения и share-nothing (то, что сейчас все подряд называют Erlang-style concurrency), а, в первую очередь, грамотная обработка возникающих ошибок:
Erlang started with just this pure process and copying everything. The reason for copying was error handling. Error handling was central.
...
We can't stop our systems and globally check they are consistent and then relaunch them. We incrementally change bits and we recognize that they are inconsistent under short time periods and we live with that. Finding ways of living with failure, making systems that work, despite the fact they are inconsistent, despite the fact that failures occur. Error models are very sophisticated. When I see things like Scala or I see on the 'net there's this kind of "Erlang-like semantics", that usually means mailboxes and message boxes, it doesn't mean all the error handling, it doesn't mean the live code upgrade. The live upgrade of code while you are running a system needs a lot of deep plumbing under the counter — it's not easy.