Сообщение Re[2]: Почему Эрланг от 04.06.2015 11:54
Изменено 04.06.2015 12:04 BulatZiganshin
Здравствуйте, Mamut, Вы писали:
M>- Lightweight, massive concurrency
M>- Asynchronous communication
M>- Process isolation
M>- Error handling
M>- Continuous evolution of the system
M>- Soft real-time
M>Даже если не обращать внимание на свойства собственно самого языка, то в вашем языке/рантайме должны быть первые шесть пунктов, чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать свои параллельные и распределенные вычисления и программы.
чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать параллельные программы, нельзя обойтись без пунктов 5 и 6? по моему, newn просто перечислены свойства которые есть в эрланге (и которые нуджны были имм для их весьма специфических хадач), а никак не то что нужно лично мне в многопоточной программе
M>Начнем с того, что Эрланг изначально разрабатывался для поддержки высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам. Основополагающая работа тут: http://www.erlang.org/download/armstrong_thesis_2003.pdf (почему-то заголовок был сменен на "in the presence of software errors", хотя изначально было "hardware errors").
M>Вот 10 требований к телекоммуникационным системам, для которых разрабатывался Erlang:
собственно, проблема в том, что мне не нужно разрабатывать высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам ака телекоммуникационных систем
соответственно, вопрос "нужен ли эрланг разработчикам свитчей" предлагаю оставить открытым и перейти ко всяким там nginx'ам
M>В большинстве современных языков и рантаймов все эти пункты находятся в сугубо зачаточном состоянии, и их пытаются решить натягиванием на примитивную основу костыли в виде библиотек, пытающихся эту примитивную основу расширить. Где-то это успешно, если сам рантайм хорош. Где-то это не более, чем библиотеки, в которых реализовать тот же supervision tree из Эрланга — это многомесячная ручная работа. При том, что в Эрланге supervision trees реализуются в виде туториала к языку.
всегда мечтал встретить человека, который знаком с большинством современных языков и рантаймов. ты можешь проанализировать свои утверждения хотя бы в контексте ghc/ruby/tbb/ppl/node.js?
M>- Lightweight, massive concurrency
M>- Asynchronous communication
M>- Process isolation
M>- Error handling
M>- Continuous evolution of the system
M>- Soft real-time
M>Даже если не обращать внимание на свойства собственно самого языка, то в вашем языке/рантайме должны быть первые шесть пунктов, чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать свои параллельные и распределенные вычисления и программы.
чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать параллельные программы, нельзя обойтись без пунктов 5 и 6? по моему, newn просто перечислены свойства которые есть в эрланге (и которые нуджны были имм для их весьма специфических хадач), а никак не то что нужно лично мне в многопоточной программе
M>Начнем с того, что Эрланг изначально разрабатывался для поддержки высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам. Основополагающая работа тут: http://www.erlang.org/download/armstrong_thesis_2003.pdf (почему-то заголовок был сменен на "in the presence of software errors", хотя изначально было "hardware errors").
M>Вот 10 требований к телекоммуникационным системам, для которых разрабатывался Erlang:
собственно, проблема в том, что мне не нужно разрабатывать высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам ака телекоммуникационных систем
соответственно, вопрос "нужен ли эрланг разработчикам свитчей" предлагаю оставить открытым и перейти ко всяким там nginx'ам
M>В большинстве современных языков и рантаймов все эти пункты находятся в сугубо зачаточном состоянии, и их пытаются решить натягиванием на примитивную основу костыли в виде библиотек, пытающихся эту примитивную основу расширить. Где-то это успешно, если сам рантайм хорош. Где-то это не более, чем библиотеки, в которых реализовать тот же supervision tree из Эрланга — это многомесячная ручная работа. При том, что в Эрланге supervision trees реализуются в виде туториала к языку.
всегда мечтал встретить человека, который знаком с большинством современных языков и рантаймов. ты можешь проанализировать свои утверждения хотя бы в контексте ghc/ruby/tbb/ppl/node.js?
Re[2]: Почему Эрланг
Здравствуйте, Mamut, Вы писали:
M>- Lightweight, massive concurrency
M>- Asynchronous communication
M>- Process isolation
M>- Error handling
M>- Continuous evolution of the system
M>- Soft real-time
M>Даже если не обращать внимание на свойства собственно самого языка, то в вашем языке/рантайме должны быть первые шесть пунктов, чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать свои параллельные и распределенные вычисления и программы.
чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать параллельные программы, нельзя обойтись без пунктов 5 и 6? по моему, тут просто перечислены свойства которые есть в эрланге (и которые нужны были им для их весьма специфических хадач), а никак не то что нужно лично мне в многопоточной программе
M>Начнем с того, что Эрланг изначально разрабатывался для поддержки высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам. Основополагающая работа тут: http://www.erlang.org/download/armstrong_thesis_2003.pdf (почему-то заголовок был сменен на "in the presence of software errors", хотя изначально было "hardware errors").
M>Вот 10 требований к телекоммуникационным системам, для которых разрабатывался Erlang:
собственно, проблема в том, что мне не нужно разрабатывать высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам ака телекоммуникационных систем
соответственно, вопрос "нужен ли эрланг разработчикам свитчей" предлагаю оставить открытым и перейти ко всяким там nginx'ам
M>В большинстве современных языков и рантаймов все эти пункты находятся в сугубо зачаточном состоянии, и их пытаются решить натягиванием на примитивную основу костыли в виде библиотек, пытающихся эту примитивную основу расширить. Где-то это успешно, если сам рантайм хорош. Где-то это не более, чем библиотеки, в которых реализовать тот же supervision tree из Эрланга — это многомесячная ручная работа. При том, что в Эрланге supervision trees реализуются в виде туториала к языку.
всегда мечтал встретить человека, который знаком с большинством современных языков и рантаймов. ты можешь проанализировать свои утверждения хотя бы в контексте ghc/ruby/tbb/ppl/node.js?
M>- Lightweight, massive concurrency
M>- Asynchronous communication
M>- Process isolation
M>- Error handling
M>- Continuous evolution of the system
M>- Soft real-time
M>Даже если не обращать внимание на свойства собственно самого языка, то в вашем языке/рантайме должны быть первые шесть пунктов, чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать свои параллельные и распределенные вычисления и программы.
чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать параллельные программы, нельзя обойтись без пунктов 5 и 6? по моему, тут просто перечислены свойства которые есть в эрланге (и которые нужны были им для их весьма специфических хадач), а никак не то что нужно лично мне в многопоточной программе
M>Начнем с того, что Эрланг изначально разрабатывался для поддержки высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам. Основополагающая работа тут: http://www.erlang.org/download/armstrong_thesis_2003.pdf (почему-то заголовок был сменен на "in the presence of software errors", хотя изначально было "hardware errors").
M>Вот 10 требований к телекоммуникационным системам, для которых разрабатывался Erlang:
собственно, проблема в том, что мне не нужно разрабатывать высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам ака телекоммуникационных систем
соответственно, вопрос "нужен ли эрланг разработчикам свитчей" предлагаю оставить открытым и перейти ко всяким там nginx'ам
M>В большинстве современных языков и рантаймов все эти пункты находятся в сугубо зачаточном состоянии, и их пытаются решить натягиванием на примитивную основу костыли в виде библиотек, пытающихся эту примитивную основу расширить. Где-то это успешно, если сам рантайм хорош. Где-то это не более, чем библиотеки, в которых реализовать тот же supervision tree из Эрланга — это многомесячная ручная работа. При том, что в Эрланге supervision trees реализуются в виде туториала к языку.
всегда мечтал встретить человека, который знаком с большинством современных языков и рантаймов. ты можешь проанализировать свои утверждения хотя бы в контексте ghc/ruby/tbb/ppl/node.js?