Дэмиен Катц (Damian Katz), основатель документ-ориентированной базы данных CouchDB, развиваемой в недрах сообщества Apache, заявил (http://damienkatz.net/2012/01/the_future_of_couchdb.html), что он выходит из проекта по разработке Apache CouchDB (http://couchdb.apache.org/), чтобы сфокусировать все свои усилия на проекте Couchbase (http://www.couchbase.org/), основанном (http://www.opennet.me/opennews/art.shtml?num=29528) на комбинации технологий CouchDB (http://www.opennet.me/opennews/art.shtml?num=30807), memcached и Membase (http://www.opennet.me/opennews/art.shtml?num=28267). В рамках предстоящего релиза Couchbase Server 2.0 (http://www.couchbase.org/get/couchbase/2.0.0) планируется подготовить близкое по возможностям документ-ориентированное распределённое хранилище, преследующее те же цели, что и CouchDB, но обладающее более высокой масштабируемостью и производительностью, а также больше сфокусированное на потребностях разработчиков и пользователей, но развиваемое вне движения Ap...URL: http://www.h-online.com/open/news/item/CouchDB-creator-dista...
Новость: http://www.opennet.me/opennews/art.shtml?num=32735
Был на Erlang - e один известный проект и тот переписывают на с++. Полное фиаско языка.
erlyvideo в помощь
Это тот который по словам автора используется на
"Например, http://kaban.tv/, http://tvoygolos.tv/ Ещё есть какой-то порносайт, хозяин которого не удосужился мне назвать адрес."
Верх популярности.
Кстати Максим уже наконец то купил себе полную спещификацию RTMP или все также кодит по общим соображениям?
Ок. Не нравится (хотя вполне рабочая штука) - http://en.wikipedia.org/wiki/Erlang_(programming_language)#Projects_using_Erlang - там одних ejabberd и RabbitMQ хватит.
Сколько лет Эрлангу?
Много, и что? До последних лет особой потребности в масштабируемых системах не было, да и сложность софта еще не так давила.Эрланг - очень красивая и практичная штука - только надо понимать, что это на 10% - язык, а на 90 - на редкость грамотно созданный фреймворк, обеспечивающий из коробки всё, что нужно для надежного масштабируемого и долго работающего софта - от протоколирования до обработки нештатных ситуаций и обновления системы без её остановки. Сравнивать это надо с Java EE - ноErlnag/OTP куда проще и удобнее в понимании. И, кстати, одна из его сильных сторон - то, что можно критичные к быстродействию части (или то, что плохо укладывается в функциональщину) переписать на чем-то другом, не потеряв стабильность системы, возможность обновления и т.д.
Родина Эрланга - телекоммуникации. Там где высокая нагрузка, высокие требования к отказоустойчивости и повышенная доступность. ИМХО причина его на сегодняшний день малого распространения - только недавний переход в практическую плоскость (работа с сокетами и i/o) и только недавнее увлечение облаками. Т.е. там где понадобилась изкоробочная параллельность выполнения кода, легкая встроенная в язык масштабируемость на любом количестве нод(!), высокая отказоустойчивость и горячая замена кода без остановки ситсемы -там он и стал востребован. Он разовьет популярность только через пару лет, когда облака станут так же легко доступны как и обычные декстопы. Пока там всё пилится и бурлит. Ваятеся код и отрабатываются десятки нештатных ситуаций.
Там где императивные языки встают в тупик при банальной задаче запуска десятков(сотен/тысяч) тредов с высокой интенсивностью обмена данных между ними - Эрланг справляется на ура, не говоря уже про распараллеливание вычислений между нодами.Про CouchDB - интересный реверанс от основателя, но эрланговская версия БД вряд ли умрет, слишком много потенциала может дать такой NoSQL БД язык Эрланг. А к примеру приложение и сервер приложений внутри БД like couchapp - вообще вкусняшка! Или разворачивать LAMP связку или поднять только одну отказоустойчивую БД. В общем это толькомое ИМХО - изучать и юзать не перестану =)
При всём уважении к эрлангу - он хорошо параллелизуется в первую очередь за счёт толковой архитектуры OTP, во вторую - за счёт параллелизма через сообщения, а уж потом - за счёт своей функциональной природы. В принципе никто не мешает сделать леговесные share-nothing потоки, обменивающиеся сообщениями, в императивном языке, и даже горячее обновление вполне реально. Но для этого нужна соответствующая поддержка стандартной бибилиотекой - и вот этого я кроме OTP нигде не видел.Что до базы на эрланге - как раз модель "эрланг как движок параллелизма + классический компилируемый императивный язык, выполняющий реальную работу", похоже, и победит - учитывая, что обработка данных (хоть строки те же) в самом эрланге всё же медленная, а интегрируется с другими языками он на ура. И сложнсотью при этом управлять вполне нормально.
> При всём уважении к эрлангу - он хорошо параллелизуется в первую очередь за счёт толковой архитектуры OTP, во вторую - за счёт параллелизма через сообщения, а уж потом - за счёт своей функциональной природы.При всем уважении к императиву ваши высказывания никакого уважения не заслуживают. Функциональная парадигма легко параллелится именно по своей природе. И без всяких сообщений. Сообщения как раз таки и нужны для распараллеливания множества независимых состояний в императивной модели. А функциональная модель от этих проблем свободна.
Просто Erlang - не является чисто функциональным языком, как и большинство якобы функциональных языков. Опять-таки при всем уважении к Эрлангу и другим языкам, где функциональность реализована без контроля побочных эффектов на уровне транслятора.
Речь как бы не об этом была (хотя в чистой функциональщине параллелизм, как и всё остальное - на уровне обработки пакетных заданий), а о том, что конкретно в эрланге для реализации параллелизма используется технология, с функциональной парадигмой вообще не связанная.
> Речь как бы не об этом былаО чем именно не об этом?
> (хотя в чистой функциональщине параллелизм, как и всё остальное - на уровне обработки пакетных заданий),
Чушь.
А в чистой рязанщине Гусь Железный да Гусь Хрустальный - тоже сразу пакетом, как и все остальные гуси.> а о том, что конкретно в эрланге для реализации параллелизма используется технология, с функциональной парадигмой вообще не связанная.
Как и в случае всех функциональных языках с побочными эффектами и изменяемыми переменными, в реализации которых используются технологии, с функциональной парадигмой вообще не связанные.
Тавтология. Предмета не знаете.
Речь была вот о чем.Я отвечал вот на это утверждение hummermania:
Там где императивные языки встают в тупик при банальной задаче запуска десятков(сотен/тысяч) тредов с высокой интенсивностью обмена данных между ними - Эрланг справляется на ура, не говоря уже про распараллеливание вычислений между нодами.Здесь он не прав - эрланговские возможности распараллеливания никак не завязаны на функциональную парадигму, о чем я и написал. Имеете что возразить?
Насчёт гусей я не в курсе, а "функциональный параллеллизм" (то есть когда рантайм за счет чистоты может распараллелить выполнение какой-то функции) - штука таки пакетная, вы не можете в середине выполнения этой самой фукции проверить какое-то внешнее условие и изменить поведение - отдали агрументы, получили результаты. Понятно, что это by design, но в реальном мире это часто неудобно, хотя обходные пути придумать можно, конечно.
И да - эрланг impure, что и делает, собственно, его пригодным для реальных задач. А вот насчет изменяемых переменных - я начинаю подозревать, что эрланга вы в глаза не видели. Иначе знали бы, что переменные там вполне себе иммутабельные (чему я, допустим, восем не рад - с его микроскопическими размерами функций мутабельные локальные переменные никаких проблем бы не создали, зато читабельность повысилась бы за счет возможности использования императивных конструкций - хоть циклов тех же.
Функциональная, как и императивная, паардигма - это,знаете ли, не Святой Грааль и не истина, данная свыше. Это инструменты, которые выбирать надо в зависимости от области деятельности, а не молиться на чистоту. Авторы эрланга, к слову, понимали это очень хорошо, поэтому в нём существует масса способов взаимодействия с кодом, написанным на других языках - как посредством сообщений, так и путем создания модулей, которые предоставляют функции, с точки зрения пользователя неотличимые от эрланговских, и это вполне обычное дело (вон, и до автора CouchDB уже дошло). И, разумеется, поддерживается обработка крешей в таких модулях, перезапуск и т.п. Вот это - реальный подход реальных опытных инженеров.
> Речь была вот о чем.
>
> Я отвечал вот на это утверждение hummermania:
> >>> Там где императивные языки встают в тупик при банальной задаче запуска десятков(сотен/тысяч) тредов с высокой интенсивностью обмена данных между ними - Эрланг справляется на ура, не говоря уже про распараллеливание вычислений между нодами.
>
> Здесь он не прав - эрланговские возможности распараллеливания никак не завязаны на функциональную парадигму, о чем я и написал. Имеете что возразить?Он был не прав, но и вы ответили не лучше. Вот это я и имею возразить.
Вы оба с ним стали рассуждать о вещах, к функ парадигме не относящимся, так как будто они к ней относятся.Он попытался противопоставить Эрланг императивным языкам, тогда как у Эрланка ядро тоже императивное, потому и параллелится с помощью сообщений. А вы заявили: "а уж потом - за счёт своей функциональной природы". Из ваших слов получается, что якобы "функциональная природа" плохо параллелится.
В том то и дело, что в Эрланге этой "функциональной природы" попросту нет. Не в укор языку, система хорошая, только те кто не понимают, начинают потом сеять дезу, рассуждая о функциональных языках на примере Эрланга.
> Насчёт гусей я не в курсе, а "функциональный параллеллизм" (то есть когда рантайм за счет чистоты может распараллелить выполнение какой-то функции) - штука таки пакетная, вы не можете в середине выполнения этой самой фукции проверить какое-то внешнее условие и изменить поведение - отдали агрументы, получили результаты. Понятно, что это by design, но в реальном мире это часто неудобно, хотя обходные пути придумать можно, конечно.
О том и речь, что вы не знаете про гусей так же, как не знаете про параллелизм в функциональной парадигме. И рассуждая про "обработку пакетных заданий" и про "функциональщину", так и остаетесь в императивной плоскости мышления.
> И да - эрланг impure, что и делает, собственно, его пригодным для реальных задач. А вот насчет изменяемых переменных - я начинаю подозревать, что эрланга вы в глаза не видели. Иначе знали бы, что переменные там вполне себе иммутабельные
Опять не знаете о чем говорите. "Вполне себе иммутабельные" - вы этим словосочетанием сами подтвердили, сами не заметив как, что они самые настоящие мутабельные. Это вам не живопись где достаточно полутонов.
> (чему я, допустим, восем не рад - с его микроскопическими размерами функций
Это давно известно, что люди с императивным мышлением предпочитают длинный код.
> мутабельные локальные переменные никаких проблем бы не создали,
Они проблем не создают, они делают бессмысленными какие либо разговоры о функциональной парадигме.
> зато читабельность повысилась бы за счет возможности использования императивных конструкций
Если функциональные конструкции для вас не читабельны, лучше вообще в эту область не лезть и спокойно пользоваться императивными языками.
> хоть циклов тех же
Тем более функциональные языки не для вас.
> Функциональная, как и императивная, паардигма - это,знаете ли, не Святой Грааль и не истина, данная свыше. Это инструменты, которые выбирать надо в зависимости от области деятельности, а не молиться на чистоту. Авторы эрланга, к слову, понимали это очень хорошо, поэтому в нём существует масса способов взаимодействия с кодом, написанным на других языках - как посредством сообщений, так и путем создания модулей, которые предоставляют функции, с точки зрения пользователя неотличимые от эрланговских, и это вполне обычное дело (вон, и до автора CouchDB уже дошло). И, разумеется, поддерживается обработка крешей в таких модулях, перезапуск и т.п. Вот это - реальный подход реальных опытных инженеров.
"Чистота" в информатике - это не как в живописи или литературе, на нее не молятся, а есть совершенно конкретные критерии и четкие математически обоснованные механизмы реализации этой самой "чистоты". Вы просто смотрите на информатику с гуманитарной точки зрения. И говорите всякую чушь, к предмету не относящуюся.
> Или разворачивать LAMP связкуLAMP на CouchDB? Гламурно!
Но будет ли тогда это LAMP?
> Родина Эрланга - телекоммуникации. Там где высокая нагрузка,
> высокие требования к отказоустойчивости и повышенная доступность.http://ftp.linux.kiev.ua/pub/Linux/xpandrx/highload_2011.pdf (м-да, чувствую себя малость спамером -- что-то частовато эту ссылку последние дни приходится вспоминать по разным поводам :)
ejabberd остался,
хотя я в последнее время к Prosody присматриваюсь.
Переписывают часть кода написанного на Erlang на C. Невозможно сохранить возможности СУБД уйдя с Erlang, новости надо читать внимательнее. Более того, точно так же поступали и авторы самого языка работая в Эриксоне, переписывая медленно части на асме или С.
Собственно цитата автора:
>> We are moving more and more of the core database in C/C++, while still using many of the concurrency and reliability design principles we've proven with the Erlang codebase. And Erlang is still going to be part of the product as well, particularly with cluster management, but most of the performance sensitive portions will be moving to over C code. Erlang is still a great language, but when you need top performance and low level control, C is hard to beat.Насчет проектов на Эрланге, то их все больше и больше. Среди NoSQL можно назвать отличную СУБД Riak, созданную на принципах Amazon Dynamo.
Также стоит помнить, что функциональные языки на текущих архитектурах процессоров медленнее исполняются, чем их императивные аналоги.
> Также стоит помнить, что функциональные языки на текущих архитектурах процессоров медленнее исполняются, чем их императивные аналоги.Ничего подобного. Это смотря как они реализованы.
Скорее многие разработчики "старой закалки" медленно избавляются от стереотипов на текущих архитектурах их императивного мышления. Ну и отсутствие математической подготовки сказывает, тут уж ничего не поделаешь. Если человек привык мыслить на уровне действий и процессов, и математику еще в детстве не осилил, то это навсегда.
Слишком уж совестливый этот Катц.
достали наверное мужика...
Мда. Думается мне, пришло время переходить на Riak.
Canonical это знали, раз решили отчаливать от ДиванБД в пользу абстрактной БД.
> портирование критичной к производительности части кода на C/C++А сразу то чего на сях не писалось? Не, сначала надо придумать себе проблем, а потом их героически забарывать. В результате будет аццкое месиво из кода, си один хрен понадобились, а вот левых зависимостей зато - будет. Что для NoSQL базы вообще-то минус.
Не ну это тоже бред. Написать чисто на Сях - трудоё[мб]кое занятие. Эрланг, как уже было сказано выше, идеально вписался.
Про зависимости - правда, хотелось бы чисто Си(или ++) решение без эрланга, может быть с меньшей функциональностью. Надеюсь хоть будет выделен чисто memcache кусок и всё остальное в виде дополнений: хочешь слайсы и виды на эрланге, хочешь простенький поиск на Сях.
Левых зависимостей - аж один эрланг. Который даёт удобные параллелизм и надежность, а также хорошо управляет сложностью. А обработку логично делать на более приспособленных к этому языках. Так что тандем очень толковый, думаю, к тому многие проекты придут.