Давайте сравним Erlang и Golang

[nekulin]

Я смотрю на erlang и на golang в плане производительности тупого текста go показывает лучшие результаты, но это ничего не значит.
Все таки хотелось бы услышать комментарии про erlang и go.

[Sergey Abramyan]

Да уже много люди писали в интернете, что с erlang дергаться даже не надо на ваш Go.

2013/10/4 nekulin <nekul...@gmail.com>

Я смотрю на erlang и на golang в плане производительности тупого текста go показывает лучшие результаты, но это ничего не значит.
Все таки хотелось бы услышать комментарии про erlang и go.

--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес erlang-russia...@googlegroups.com.
Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу erlang-...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--

С уважением,

Сергей Абрамян

[Николай Измайлов]

Можно конкретнее плз, что писали

4 октября 2013 г., 22:31 пользователь Sergey Abramyan <sa.ab...@gmail.com> написал:

[Sergey Abramyan]

Ну если вы интересуетесь языком, то наверно следите за блогами, рассылками. Почитайте, что Трескин пишет, посты на хабре, а особенно комментарии к ним, жж. Я не пишу на Go, читал документацию, опять же, рассылку, и мое имхо таково, что в нем нет смысла, если рассматривать как альтернативу эрлангу.

Вообще странный у вас вопрос, чего вам не хватает в Erlang?

2013/10/4 Николай Измайлов <nekul...@gmail.com>

[Николай Измайлов]

Я наблюдаю за языками и учу их понемногу. Сейчас увидел что go работает быстрее в 4 раза быстрее http. Но тут нельзя говорить что виноват сам http server может тормозить.

4 октября 2013 г., 22:50 пользователь Sergey Abramyan <sa.ab...@gmail.com> написал:

[Sergey Abramyan]

Все ясно. Попробуйте решать свои задачи, а потом уже думать, что подходит именно для вас.

P.S. Макс, как ты открыл доступ все email которые висели, сразу появилось много подобных постов =)

2013/10/4 Николай Измайлов <nekul...@gmail.com>

[Yuri Zhloba]

Ну что с того, что что-то там работает быстрее, а что-то медленнее? Как будто это "быстрее" решит ваши проблемы, с которыми вы еще не столкнулись, и о которых ничего не знаете :)

4 октября 2013 г., 21:52 пользователь Николай Измайлов <nekul...@gmail.com> написал:

--

Yuri Zhloba

skype: yzh44yzh
phone: +375 44 793 33 73

[Николай Измайлов]

У меня нету опыта работы с erlang поэтому и спрашиваю.

4 октября 2013 г., 22:57 пользователь Sergey Abramyan <sa.ab...@gmail.com> написал:

[Yuri Zhloba]

Например, эти ваши "быстрее" упрутся в базу данных (что чаще всего и бывает) и чо? )

4 октября 2013 г., 21:57 пользователь Yuri Zhloba <yzh4...@gmail.com> написал:

[Николай Измайлов]

Простой бенчмарк через ab  с примером Hello!

4 октября 2013 г., 22:57 пользователь Yuri Zhloba <yzh4...@gmail.com> написал:

[Николай Измайлов]

База это другое, сейчас как раз интересует программная часть.

4 октября 2013 г., 22:59 пользователь Yuri Zhloba <yzh4...@gmail.com> написал:

[Sergey Abramyan]

Ое, на башорг!

2013/10/4 Николай Измайлов <nekul...@gmail.com>

[Николай Измайлов]

Я прекрасно понимаю где узкие места и как их решать. Сейчас интересует производительность самих языков.

4 октября 2013 г., 23:00 пользователь Николай Измайлов <nekul...@gmail.com> написал:

[Николай Измайлов]

мб сразу ассемблер ?

4 октября 2013 г., 23:01 пользователь Sergey Abramyan <sa.ab...@gmail.com> написал:

[Artur Gadelshin]

Только совершенно упоротый человек будет выбирать ассемблер или си, потому что они быстрее. Или го вместо эрланга. Надо быть фанатиком, но это совершенно не плюс. Вам правильно говорят, определитесь, что вы хотите делать и выбирайте средства, исходя из нужд. Язык - это всего лишь инструмент, это не религия. Религией должно быть хорошо написанный код, который выполняет с необходимой скоростью свои функции, архитектура, которая позволяет легко изменять проект под нужны, позволяя вам освободить ресурсы на развитие проекта, на создание новых, на коммиты в опен сорс проекты, которые вы используете.

Попробуйте реализовать ваш проект на обоих языках, сделайте для себя выводы. Если отметите что-то интересное - расскажите людям. А задавать вопрос: го быстрее эрланга, я засекал: переубедите - это какой-то бред. Ну и бенчмарки ваши - это не бенчмарки, это смех.

4 октября 2013 г., 23:02 пользователь Николай Измайлов <nekul...@gmail.com> написал:

[Daniil Churikov]

Ребята, как-то не конструктивно.

Насколько я понял из беглого знакомства с около гошной документацией(доклады, презентации), го скорее замена c/c++ в вашем проекте. Эрланг хорош там, где будет много одновременных действий выполняться, с го я не уверен что все так же хорошо. Если вы делаете тесты, наверное лучше бы что-то более сложное чем отдача константы, какую-нибудь бизнес логику и посмотреть как ядра будут нагружены.

пятница, 4 октября 2013 г., 22:28:57 UTC+4 пользователь nekulin написал:

[Николай Измайлов]

Только совершенно упоротый человек будет выбирать ассемблер или си, потому что они быстрее

 - а  кто из выбирал ?
Или го вместо эрланга

- я думаю тут вовсе разумный выбор. Я же не выбираю C++ и ассемблер

Ну и бенчмарки ваши - это не бенчмарки, это смех.

- я в самом вначале писал, поэтому и создал тему.

4 октября 2013 г., 23:12 пользователь Artur Gadelshin <ar.gad...@gmail.com> написал:

[Николай Измайлов]

У меня ядра грузятся на самом hello больше в 4 раза чем на go

4 октября 2013 г., 23:15 пользователь Daniil Churikov <ddo...@gmail.com> написал:

--

[Артём Семёнов]

Простите, но я совершенно не понимаю что пишет Николай, только лишний раз дергаюсь к телефону, когда приходит письмо — авось что нибудь полезное. Ан нет, всего лишь бесполезный шлак. 

Пятница же.

—
Sent from Mailbox for iPhone

[Николай Измайлов]

Вот именно пятница. Представьте вот пришел с работы и снова вязлся за erlang и go. Хочу визитку попробовать сделать. И что - то захотелось бенчмарк сделать столько запросов выдержит мой сайтик. Смотрю  golang держит в 3-4 раза больше и ядра не грузит сильно а вот erlang все загрузил и обработать может меньше соединений. Дудмаю дальше мб дело в фреймворке ковбои или веб сервере, решил написать в группу мб че полезное скажут. Я конечно понимаю какие плюсы erlang перед go но меня интересует производителость на 1 физической машине с 8 ядрами.

4 октября 2013 г., 23:19 пользователь Артём Семёнов <sev...@gmail.com> написал:

[Артём Семёнов]

Ок. 

—
Sent from Mailbox for iPhone

[Mike Potanin]

В Go извращенный синтаксис - там для возврата значения надо писать непонятный return.

2013/10/4 nekulin <nekul...@gmail.com>

Я смотрю на erlang и на golang в плане производительности тупого текста go показывает лучшие результаты, но это ничего не значит.
Все таки хотелось бы услышать комментарии про erlang и go.

--

[Roman Gafurov]

мне кажется ты просто что-то не так готовишь, поэтому erlang у тебя и сдает

[Николай Измайлов]

Мне тоже, но я просто запускаю ковбой prod ничего больше не делал

4 октября 2013 г., 23:49 пользователь Roman Gafurov <gafurov...@gmail.com> написал:

мне кажется ты просто что-то не так готовишь, поэтому erlang у тебя и сдает

[Николай Измайлов]

Кто нибудь не хочет попробовать ?

4 октября 2013 г., 23:55 пользователь Николай Измайлов <nekul...@gmail.com> написал:

[Gleb Peregud]

Выкладывайте исходники бенчмарка и кто-то может подражает что сделано не так. Рассуждать в вакууме про производительность бесполезно

[Dmitry Demeshchuk]

К сожалению, ни Go, ни Akka не подошли достаточно близко к хорошему решению проблем реализации concurrency и distribution. Например:

- Горутину нельзя закрыть извне.

- Геморрой с приоритезацией сообщений (насколько я понимаю, реализуемо только через вложенные select'ы).

- Нельзя просто так взять (здесь должна была быть картинка с Боромиром) и обратиться к горутине на удаленной ноде.

- OTP (по крайней мере из коробки) в Go пока не наблюдается.

[Николай Измайлов]

Можно вернуть несколько значений вообще супер

пятница, 4 октября 2013 г. пользователь Mike Potanin <mpot...@gmail.com> писал:

[Mikhail Gusarov]

"Голый" erlang практически никому не нужен, а в Go ничего похожего на
OTP по качеству и покрытию задач просто нет. Сравнивать же язык со
специализированной операционной системой достаточно бесполезно.

Если академически сравнить именно языки, то в Go умудрились выстрелить
себе в ногу: допустив возможность разделяемой памяти, они похерили
семантику значений (против семантики мест), и тем самым

1) сильно усложнили любую масштабную разработку (ошибка типа C++: в
любой большой codebase будут применены все возможные механизмы языка,
в том числе и вредные);

1a) Следовательно, применение Go - мелкие утилиты/сервера/сервисы,
ничего крупного. Было бы хорошо, если бы это был осознанный выбор ("мы
хотим делать маленькие сервисы, общающиеся по общепринятым
протоколам"), но, похоже, это нечаянное следствие из сделанных
решений.

2) сильно усложнили работу авторам библиотек и фреймворков (та же
проблема - семантика мест дает очень и очень мало гарантий во время
runtime);

2a) Это понижает шансы получения любого вменяемого аналога OTP, делая
сравнение академическим скорее всего навсегда.

3) сильно увеличили количество сущностей в языке, сделав его более
сложным, чем требовалось.


Best regards,
Mikhail Gusarov.

[Mike Potanin]

В Erlangе с этим тоже проблем не наблюдается, без всяких извращенных конструкций.

2013/10/5 Николай Измайлов <nekul...@gmail.com>

[Alex Chistyakov]

2013/10/5 Mikhail Gusarov <dott...@dottedmag.net>

"Голый" erlang практически никому не нужен, а в Go ничего похожего на
OTP по качеству и покрытию задач просто нет. Сравнивать же язык со
специализированной операционной системой достаточно бесполезно.

Если академически сравнить именно языки, то в Go умудрились выстрелить
себе в ногу: допустив возможность разделяемой памяти, они похерили
семантику значений (против семантики мест), и тем самым

1) сильно усложнили любую масштабную разработку (ошибка типа C++: в
любой большой codebase будут применены все возможные механизмы языка,
в том числе и вредные);

1a) Следовательно, применение Go - мелкие утилиты/сервера/сервисы,
ничего крупного. Было бы хорошо, если бы это был осознанный выбор ("мы
хотим делать маленькие сервисы, общающиеся по общепринятым
протоколам"), но, похоже, это нечаянное следствие из сделанных
решений.

Cудя по тому, что почти все известные мне применения Go - это небольшие инфраструктурные проекты (Docker, Packer, тысячи их), так оно и есть, и это очень клево - наконец-то эта ниша найдет свой язык. Раньше такие вещи делались на Perl, но Perl в 2013-м году как-то не вызывает восторга, а попытки писать мелкую инфраструктурщину на <других скриптовых языках> выглядят в разной степени нелепо. И я, наверное, никого не видел, кто бы делал подобное на Erlang.

--

SY,
Alex

[Mikhail Gusarov]

Хорошо, что есть такой язык, да. Но одна проблема - это не изначальное
решение, а побочный эффект: бОльшие штуки на нем писать просто страшно
и долго.

Да, лучше, чем перлопитон, но все равно - зачем такому языку
указатели? Интерфейсы?

Best regards,
Mikhail Gusarov.


2013/10/4 Alex Chistyakov <alex...@gmail.com>:

[Max Lapshin]

Николай. То, что вы делаете называется умышленным разведением флейма и никак иначе.

Причем, если бы вы пришли с каким-то интересным материалом, это ещё было бы полезно, но вы просто замусориваете людям инфопоток.

Вы начали свою тему с совершенно пустых слов  «go показывает лучшие результаты» после чего выяснилось, что ваши результаты _вообще_ ничего не стоят, потому что вы меряли с помощью ab.

Любой более менее квалифицированный программист знает, что с помощью ab сегодня можно тестировать только PHP магазин под апачом, и то не факт, что ab справится.

Когда Макс Сохацкий решил что-то померять, он собрал целый репозиторий: https://github.com/maxlapshin/fpbenchmark . А вы — ленивый человек и явно хотите, что бы все вокруг сделали за вас.

[Николай Измайлов]

Любой более менее квалифицированный программист знает, что с помощью ab сегодня можно тестировать только PHP магазин под апачом, и то не факт, что ab справится.

- прям как громко. ab пойдет для простых тестов и не обяз. под apache

Когда Макс Сохацкий решил что-то померять, он собрал целый репозиторий

- на днях соберу

5 октября 2013 г., 10:24 пользователь Max Lapshin <max.l...@gmail.com> написал:

[Dmitrii Dimandt]

On Oct 4, 2013, at 21:24, Николай Измайлов <nekul...@gmail.com> wrote:

Вот именно пятница. Представьте вот пришел с работы и снова вязлся за erlang и go. Хочу визитку попробовать сделать. И что - то захотелось бенчмарк сделать столько запросов выдержит мой сайтик.

Визитку? Сайтик? Бенчмарк? Делаете статический HTML и ставите его за nginx'ом — и все, ВНЕЗАПНО и golang и erlang отсасывают.

Смотрю  golang держит в 3-4 раза больше и ядра не грузит сильно а вот erlang все загрузил и обработать может меньше соединений. Дудмаю дальше мб дело в фреймворке ковбои или веб сервере, решил написать в группу мб че полезное скажут. Я конечно понимаю какие плюсы erlang перед go но меня интересует производителость на 1 физической машине с 8 ядрами.

Вас интересует какой-то, простите, идиотизм. «Я хочу сделать сайт-визитку, на который будет заходить один человек в в месяц, но не могу выбрать между 45k rps и 47k rps, ведь это мне так жизненно необходимо».

Ко все остальным: что же вы ведетесь на троллинг нулевого уровня :)

[Dmitrii Dimandt]

On Oct 5, 2013, at 09:21, Николай Измайлов <nekul...@gmail.com> wrote:

Любой более менее квалифицированный программист знает, что с помощью ab сегодня можно тестировать только PHP магазин под апачом, и то не факт, что ab справится.

- прям как громко. ab пойдет для простых тестов и не обяз. под apache

Когда Макс Сохацкий решил что-то померять, он собрал целый репозиторий

- на днях соберу

Могу только процитировать Стива Виноски из Basho: ваш бенчмарк — не бенчмарк, если он крутится на одной машине в течение 20 минут.

Но даже такие бенчмарки за вас давно сделали: http://www.techempower.com/benchmarks/

[Dmitrii Dimandt]

On Oct 5, 2013, at 09:50, Dmitrii Dimandt <dmi...@dmitriid.com> wrote:

On Oct 5, 2013, at 09:21, Николай Измайлов <nekul...@gmail.com> wrote:

Любой более менее квалифицированный программист знает, что с помощью ab сегодня можно тестировать только PHP магазин под апачом, и то не факт, что ab справится.

- прям как громко. ab пойдет для простых тестов и не обяз. под apache

Когда Макс Сохацкий решил что-то померять, он собрал целый репозиторий

- на днях соберу

Могу только процитировать Стива Виноски из Basho: ваш бенчмарк — не бенчмарк, если он крутится на одной машине в течение 20 минут.

Нашел даже, где он это говорит: http://youtu.be/Y6PG6hkUHPM?t=18m20s

[Николай Измайлов]

Точно давайте сделаем на html а чтоб вовсе не грузить сервер гененировать html будем на javascript нам пофигу на поисковики и сжатие не забудь включить

суббота, 5 октября 2013 г. пользователь Dmitrii Dimandt <dmi...@dmitriid.com> писал:

>
> On Oct 4, 2013, at 21:24, Николай Измайлов <nekul...@gmail.com> wrote:
>
> Вот именно пятница. Представьте вот пришел с работы и снова вязлся за erlang и go. Хочу визитку попробовать сделать. И что - то захотелось бенчмарк сделать столько запросов выдержит мой сайтик.
>
> Визитку? Сайтик? Бенчмарк? Делаете статический HTML и ставите его за nginx'ом — и все, ВНЕЗАПНО и golang и erlang отсасывают.
>
> Смотрю  golang держит в 3-4 раза больше и ядра не грузит сильно а вот erlang все загрузил и обработать может меньше соединений. Дудмаю дальше мб дело в фреймворке ковбои или веб сервере, решил написать в группу мб че полезное скажут. Я конечно понимаю какие плюсы erlang перед go но меня интересует производителость на 1 физической машине с 8 ядрами.
>
>
>
> Вас интересует какой-то, простите, идиотизм. «Я хочу сделать сайт-визитку, на который будет заходить один человек в в месяц, но не могу выбрать между 45k rps и 47k rps, ведь это мне так жизненно необходимо».
>
> Ко все остальным: что же вы ведетесь на троллинг нулевого уровня :)
>
>
>
> 4 октября 2013 г., 23:19 пользователь Артём Семёнов <sev...@gmail.com> написал:
>
> Простите, но я совершенно не понимаю что пишет Николай, только лишний раз дергаюсь к телефону, когда приходит письмо — авось что нибудь полезное. Ан нет, всего лишь бесполезный шлак. 
> Пятница же.
> —
> Sent from Mailbox for iPhone
>
> On Fri, Oct 4, 2013 at 10:17 PM, Николай Измайлов <nekul...@gmail.com> wrote:
>
> У меня ядра грузятся на самом hello больше в 4 раза чем на go
>
>
> 4 октября 2013 г., 23:15 пользователь Daniil Churikov <ddo...@gmail.com> написал:
>
> Ребята, как-то не конструктивно.
>
> Насколько я понял из беглого знакомства с около гошной документацией(доклады, презентации), го скорее замена c/c++ в вашем проекте. Эрланг хорош там, где будет много одновременных действий выполняться, с го я не уверен что все так же хорошо. Если вы делаете тесты, наверное лучше бы что-то более сложное чем отдача константы, какую-нибудь бизнес логику и посмотреть как ядра будут нагружены.
>
> пятница, 4 октября 2013 г., 22:28:57 UTC+4 пользователь nekulin написал:
>
> Я смотрю на erlang и на golang в плане производительности тупого текста go показывает лучшие результаты, но это ничего не значит.
> Все таки хотелось бы услышать комментарии про erlang и go.
>

[Dmitrii Dimandt]

Если это будет решать задачу, то почему так не сделать? Вас интересует какой-то сферический конь в вакууме, который к вашей задаче имеет ровно ноль отношения.

Ваш сайт-визитку скорее всего можно написать даже на visual basic'е, и он будет справляться.

[Николай Измайлов]

Ну и люди. Сайт визитка - это что в голову пришло то и написал. Никто не собирался даже ее и делать. Какой дибил будет делать сайт визитку на erlang или go ? Короче из темы где хотелось получить коменты по сравнению языков в производительности получилось гавно!!!

5 октября 2013 г., 12:00 пользователь Dmitrii Dimandt <dmi...@dmitriid.com> написал:

[Dmitrii Dimandt]

On Oct 5, 2013, at 10:03, Николай Измайлов <nekul...@gmail.com> wrote:

Ну и люди. Сайт визитка - это что в голову пришло то и написал. Никто не собирался даже ее и делать. Какой дибил будет делать сайт визитку на erlang или go ?

Так, просто процитирую

«Представьте вот пришел с работы и снова вязлся за erlang и go. Хочу визитку попробовать сделать. И что - то захотелось бенчмарк сделать столько запросов выдержит мой сайтик.»

Уж не знаю, что за дибил это писал

Короче из темы где хотелось получить коменты по сравнению языков в производительности получилось гавно!!!

Комменты вы получили:

- вы не сказали, для какой задачи нужен тест производительности

- сферическая производительность в вакууме никого не интересует

- в зависимости от задачи мы скорее всего упремся в базу данных быстрее, чем в предел производительности языка

- «попробуйте решать свои задачи, а потом уже думать, что подходит именно для вас.»

- «Ну что с того, что что-то там работает быстрее, а что-то медленнее? Как будто это "быстрее" решит ваши проблемы, с которыми вы еще не столкнулись, и о которых ничего не знаете»

- «Только совершенно упоротый человек будет выбирать ассемблер или си, потому что они быстрее. Или го вместо эрланга. Надо быть фанатиком, но это совершенно не плюс. Вам правильно говорят, определитесь, что вы хотите делать и выбирайте средства, исходя из нужд. Язык - это всего лишь инструмент, это не религия. »

- «"Голый" erlang практически никому не нужен, а в Go ничего похожего на OTP по качеству и покрытию задач просто нет. Сравнивать же язык со специализированной операционной системой достаточно бесполезно.»

Полно внятных содержательных комментариев. Определитесь, что и зачем вам нужно, и задайте внятный содержательный вопрос.

[Николай Измайлов]

«Представьте вот пришел с работы и снова вязлся за erlang и go. Хочу визитку попробовать сделать. И что - то захотелось бенчмарк сделать столько запросов выдержит мой сайтик.»

Да это чтоб веселее было, вы ушли от основной мысли "производительность erlang и golang"

5 октября 2013 г., 12:09 пользователь Dmitrii Dimandt <dmi...@dmitriid.com> написал:

[Dmitrii Dimandt]

«Представьте вот пришел с работы и снова вязлся за erlang и go. Хочу визитку попробовать сделать. И что - то захотелось бенчмарк сделать столько запросов выдержит мой сайтик.»

Да это чтоб веселее было, вы ушли от основной мысли "производительность erlang и golang"

Вы задали предельно глупый вопрос и решили проиллюстрировать предельно глупым примером.

Займитесь чтением о осознанием пунктов, что я привел в предыдущем сообщении.

[Max Lapshin]

Парни, вам не кажется, что Николай умышленно строит из себя идиота?

[Mikhail Gusarov]

Бритва Хэнлона не позволяет так предположить.

Best regards,
Mikhail Gusarov.


2013/10/5 Max Lapshin <max.l...@gmail.com>:

> Парни, вам не кажется, что Николай умышленно строит из себя идиота?
>

[Max Lapshin]

Не знаю что это такое, но спорить не буду.

[Mikhail Gusarov]

http://en.wikipedia.org/wiki/Hanlon's_razor

Best regards,
Mikhail Gusarov.


2013/10/5 Max Lapshin <max.l...@gmail.com>:

> Не знаю что это такое, но спорить не буду.
>

[Артём Семёнов]

Переведя на нынешний язык: «Не называйте троллем идиота»

5 октября 2013 г., 13:33 пользователь Max Lapshin <max.l...@gmail.com> написал:

Не знаю что это такое, но спорить не буду.

--

[Dmitry Groshev]

Ответ на пальцах: Go вполне может быть быстрее. Erlang обладает сильным фанбой-фактором, но всё равно во многом говно, и люди это подсознательно понимают, поэтому в топике так много боли и оскорблений.

Более развёрнуто: когда посоны проектировали Erlang, они затачивали его под свою конкретную задачу — быстрая работа с сетью с относительно вычислительно лёгкой логикой. Другими словами, под network-IO-bound задачи (дисковое IO неидеально, прямо скажем). Поэтому в простых бенчмарках вроде «отдать статическую страничку» Erlang будет *относительно* быстрым, но без чудес. Да и в целом он обычно *достаточно* быстрый, весь этот хайп про «супер-быстрый язык» и «невероятная scalability» это в 95% случаев просто хайп.

Почему же люди (а не фанбои) берут всё-таки этот язык? Несколько причин:

-очень простой. Проще, чем питон или руби. Это и плюс (быстро обучаются люди), и минус (нет нормальных средств организации кода кроме callback и/или pattern-matching соплей);

-достаточно мало способов написать код, который полностью ломал бы вашу систему, особенно неожиданно. Есть всего пара опасных мест (навскидку — mail box'ы и таблица атомов), остальное гарантируется виртуальной машиной;

-железобетонная энтерпрайзность. Обратная совместимость на две мажорных версии назад в хипстерский век это круто;

-много средств организации отказоустойчивого кода — те же супервизоры, например. Хотя это пересекается с пред-предыдущим пунктом;

-действительно крутое network io. Если вам нужно перекладывать байтики из одного провода в другой — Erlang будет очень хорош.

Можно, наверное, придумать ещё пяток узких причин, но мне лень :) Надеюсь, я плюс-минус ответил и на ваш вопрос, и на тот, который вы предполагали, как мне кажется.

2013/10/4 nekulin <nekul...@gmail.com>

Я смотрю на erlang и на golang в плане производительности тупого текста go показывает лучшие результаты, но это ничего не значит.
Все таки хотелось бы услышать комментарии про erlang и go.

--

[Dmitrii Dimandt]

Тебя пора нанимать на полную ставку давать развернутые ответы :) Ну и встречный вопрос: а что не говно? Всё ведь говно :)

[Dmitry Groshev]

It depends, как обычно.

[Roman Timofeev]

Всем привет!

Я с интересом смотрю на erlang, некоторые идеи из него я утащил в свои
приложения(механизм супервизоров или же концепт let in crash).
Периодически возникает мысль переписать что-то на erlang, но пугает
некоторая бедность в плане библиотек и некоторые вопросы.
Буду признателен ответам или ссылкам в что почитать по тематике вопросов.

>Другими словами, под network-IO-bound задачи

тут всё достаточно понятно, кроме неблокирующего i/o. т.е. с
read/write (readv/writev) скорее всего есть в системе, а как с
специфичными вещами вроде eventfd/splice и менее специфичными как
sendfile ?

>(дисковое IO неидеально, прямо скажем).

а вот тут - нет. допустим, у нас http-сервер и мы отдаём файлы >>
ram(допустим, на машине 2Гб памяти, а на диске - 2Тб аниме).
и вот следующих 512Кб у нас не в page cache. как это будет выглядеть
внутри(то что эрланговский процесс "залипнет" - понятно) и снаружи(
beam) ?

[Max Lapshin]

 пугает

некоторая бедность в плане библиотек и некоторые вопросы.

Что конкретно пугает? Этот миф я слышу ещё с тех времен, когда сел за рельсы.

«мало библиотек, мало библиотек».

Я вот делаю стриминговый сервер и когда сравниваю с Red5, то им _ничем_ джава не помогла вообще.

 

специфичными вещами вроде eventfd/splice и менее специфичными как
sendfile ?

А зачем вообще тебе нужен sendfile?   sendfile — это чрезвычайно редкая штука, которая позволяет

сэкономить несколько процентов процессора ценой чудовищного расходования системных тредов.

sendfile годится разве что маленькие css-ки с диска раздавать быстрым клиентам.

 

ram(допустим, на машине 2Гб памяти, а на диске - 2Тб аниме).
и вот следующих 512Кб у нас не в page cache. как это будет выглядеть
внутри(то что эрланговский процесс "залипнет" - понятно) и снаружи(
beam) ?

В эрливидео здоровенный кусок кода посвящен этой ситуации.

TL;DR   в этой ситуации надо решать проблему ограничения доступа к ресурсам. В эрланге это ок.

Да, давай я сразу поясню, проблемы которые я испытывал с хардами, обычно начинаются где-то 

от 3-4 гигабит раздачи с одного компьютера. При этом, конечно же мы говорим о том, что все

умные и аппаратные рейды уже выкинули из сервера к чертовой матери.

Если вкратце, то схема с пулом тредов как в Beam — оптимальна для обслуживания дисков.

nginx, в котором всегда был aio, сейчас переходит именно на пул тредов, потому что кроме чтения, есть

ещё такие банальные вещи как открытие или просто считывание read_file_info.

Это очень грустно, когда весь сервер залипает на считывании read_file_info с одного HDD.

В итоге проблемы чтения с хардов сводятся к другой проблеме: как правильно утилизировать жесткий диск

на 90% и не выше. Мне до конца это сделать не удалось, потому что я так и не решил проблему

с идентификацией диска на котором лежит файл, но частично проблема решилась.

Т.е. при чтении с диска эрливидео вполне уверенно начинает в какой-то момент либо кешировать на SSD, 

либо отдавать 503.

Такое поведение и есть правильное и никакой либы на джаве ты для этого не найдешь.

Что же касается всяких там сравнений… Ну в эрланге есть либа для mmap. Предлагаю поискать аналогичную для джавы.

[Dmitrii Dimandt]

On Oct 8, 2013, at 08:00 , Max Lapshin <max.l...@gmail.com> wrote:

 пугает

некоторая бедность в плане библиотек и некоторые вопросы.

Что конкретно пугает? Этот миф я слышу ещё с тех времен, когда сел за рельсы.

«мало библиотек, мало библиотек».

Если начинать на Erlang'е делать веб, то все сразу становится очень печально. Я на Lightning Talks в 2012-м году очень коротко по этому прошелся: http://www.scribd.com/doc/99721085/Erlang-Sucks-EUC-2012

Для сурового хардкорного бэкенда в Erlang'е обычно все нормально

[Max Lapshin]

Мне кажется, что эрланг для веба не годится прежде всего в силу своей иммутабельности.

Там, где я в руби напишу:

@author.books  и код автоматически сходит в базу данных, подкачает список книжек и положит его в instace variable объекта @author, там в эрланге я напишу кучу интересного и полезного кода, вывалив наружу все подобные кишки.

Оно полезно для сурового бекенда, но когда надо быстро делать бизнес-логику, начинается беда.

[Dmitrii Dimandt]

Мне кажется, что эрланг для веба не годится прежде всего в силу своей иммутабельности.

Там, где я в руби напишу:

@author.books  и код автоматически сходит в базу данных, подкачает список книжек и положит его в instace variable объекта @author, там в эрланге я напишу кучу интересного и полезного кода, вывалив наружу все подобные кишки.

Ну, это решаемо чуть более расширенным кодом типа Books = find(Author, books).

Другое дело, что (почти) нет фреймворков, это позволяющих. На boss_db (https://github.com/evanmiller/boss_db) еще не смотрел

Оно полезно для сурового бекенда, но когда надо быстро делать бизнес-логику, начинается беда.

[Mikhail Gusarov]

2013/10/8 Max Lapshin <max.l...@gmail.com>:

> пугает
>> некоторая бедность в плане библиотек и некоторые вопросы.
>
>
> Что конкретно пугает? Этот миф я слышу ещё с тех времен, когда сел за
> рельсы.
> «мало библиотек, мало библиотек».
>
> Я вот делаю стриминговый сервер и когда сравниваю с Red5, то им _ничем_
> джава не помогла вообще.

Сильно зависит от того, сколько клея в задаче, а сколько функционала.
Если это сплошной
клей, то без библиотек очень и очень печально (в особенности, когда
клеить нужно что-то обширное).

[Mikhail Gusarov]

Так это и есть отсутствие библиотек.

В голом Ruby @author.books не бывает, нужен active record, который -
сюрприз! - библиотека.

Best regards,
Mikhail Gusarov.


2013/10/8 Max Lapshin <max.l...@gmail.com>:

[Dmitry Groshev]

>Я вот делаю стриминговый сервер

Ключевой момент. Это очень узкая ниша. Каких библиотек нет? Ну, например:

-почта. Год назад, когда понадобилось SMTP, пришлось писать самим — всё существовавшее не работало толком;

-аналоги TagSoup. Распарсить невалидный HTML нечем, удобных модификаторов/CSS-селекторов нет;

-OAuth(2). Удачи реализовывать с нуля!

-миграции для БД;

-биндинги к ImageMagick или аналогам;

-парсер/компилятор Markdown;

-биндинги к Datomic;

-векторная/матричная алгебра;

-CLP (например, core.logic в Clojure).

>конечно же мы говорим о том, что все умные и аппаратные рейды уже выкинули из сервера к чертовой матери

Это для, опять же, крайне узкой ниши линейного чтения больших кусков с диска? В большинстве случаев нужно рандомное чтение/запись мелких кусков (будь то записи в БД или картинки). Удачи тягаться с полкой от какого-нибудь NETAPP'а.

>Такое поведение и есть правильное и никакой либы на джаве ты для этого не найдешь.

JFYI: core.async для Clojure предоставляет first class bounded channels с разными типами буферизации. Велосипедить на этом поведение при перегрузке гораздо веселее, чем пытаться отслеживать длины очередей сообщений, например.

>в эрланге есть либа для mmap. Предлагаю поискать аналогичную для джавы

http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html

Более того, есть ещё, например,

https://github.com/thebusby/iota

аналог который в Erlang'е построить *крайне* нетривиально.

>эрланг для веба не годится прежде всего в силу своей иммутабельности

Clojure иммутабельная и справляется. Scala иммутабельная и справляется. Haskell иммутабельный и справляется. Дело явно не в этом.

[Roman Timofeev]

Добрый день!

> Что конкретно пугает? Этот миф я слышу ещё с тех времен, когда сел за
> рельсы.
> «мало библиотек, мало библиотек».

ок, это весьма спорный тезис и лучше пока оставим его в стороне.

>> специфичными вещами вроде eventfd/splice и менее специфичными как
>> sendfile ?

> А зачем вообще тебе нужен sendfile? sendfile — это чрезвычайно редкая
> штука, которая позволяет
> сэкономить несколько процентов процессора ценой чудовищного расходования
> системных тредов.

а что в ней редкого? кого надо файл отдать клиенту "как есть"?

> sendfile годится разве что маленькие css-ки с диска раздавать быстрым
> клиентам.

sendfile избавляет от double copy в первую очередь. на неблокирующих
сокетах поведение у него такое же, как у write(будет EAGAIN).

>При этом, конечно же мы говорим
> о том, что все
> умные и аппаратные рейды уже выкинули из сервера к чертовой матери.

можно пояснить почему?

> nginx, в котором всегда был aio,

aio он был, afaik, всего на одной единственной платформе - freebsd с
соответствующим модулем.
в linux либо нативное aio(со всеми прелестями в виде O_DIRECT), либо
posix aio(который суть пул тредов).

> потому что кроме чтения, есть
> ещё такие банальные вещи как открытие или просто считывание read_file_info.

и правильно, потому что это stat, который может несколько заблокироваться.

> Т.е. при чтении с диска эрливидео вполне уверенно начинает в какой-то момент
> либо кешировать на SSD,
> либо отдавать 503.

у erlyvideo задача - работать на том, что дал/есть у заказчика и
покупать нормальное оборудование никто не будет.
вопрос ведь в том, как правильно "кормить" дисковую запросами.

что будет с эрланговским процессом/beam когда очередной порции данных
на отправку нет в page cache(т.е. bandwidth дисковой позволяет
обслужить всех подключенных клиентов, но надо как-то минимизировать
высокую latency).

как пример: в мир у нас канал 1GE, диски подключены через iscsi
(1GEx2) и rtt 100ms.

> Такое поведение и есть правильное и никакой либы на джаве ты для этого не
> найдешь.

я не знаю, откуда вы взяли про java.

[Dmitrii Dimandt]

>Я вот делаю стриминговый сервер

Ключевой момент. Это очень узкая ниша. Каких библиотек нет? Ну, например:

-почта. Год назад, когда понадобилось SMTP, пришлось писать самим — всё существовавшее не работало толком;

-аналоги TagSoup. Распарсить невалидный HTML нечем, удобных модификаторов/CSS-селекторов нет;

-OAuth(2). Удачи реализовывать с нуля!

-миграции для БД;

-биндинги к ImageMagick или аналогам;

-парсер/компилятор Markdown;

-биндинги к Datomic;

-векторная/матричная алгебра;

-CLP (например, core.logic в Clojure).

У же говорю, тебя надо брать на полную ставку, писать развернутые ответы :)

А так да — всего этого (и многого другого) нет. Людям почему-то неинтересно это писать. Им интересно писать Riak'и, erlyvideo и распределенные lock'и :)

>конечно же мы говорим о том, что все умные и аппаратные рейды уже выкинули из сервера к чертовой матери

Это для, опять же, крайне узкой ниши линейного чтения больших кусков с диска? В большинстве случаев нужно рандомное чтение/запись мелких кусков (будь то записи в БД или картинки). Удачи тягаться с полкой от какого-нибудь NETAPP'а.

>Такое поведение и есть правильное и никакой либы на джаве ты для этого не найдешь.

JFYI: core.async для Clojure предоставляет first class bounded channels с разными типами буферизации. Велосипедить на этом поведение при перегрузке гораздо веселее, чем пытаться отслеживать длины очередей сообщений, например.

>в эрланге есть либа для mmap. Предлагаю поискать аналогичную для джавы

http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html

Более того, есть ещё, например,

https://github.com/thebusby/iota

аналог который в Erlang'е построить *крайне* нетривиально.

>эрланг для веба не годится прежде всего в силу своей иммутабельности

Clojure иммутабельная и справляется. Scala иммутабельная и справляется. Haskell иммутабельный и справляется. Дело явно не в этом.

On Tuesday, October 8, 2013 11:08:34 AM UTC+4, Max Lapshin wrote:

Мне кажется, что эрланг для веба не годится прежде всего в силу своей иммутабельности.

Там, где я в руби напишу:

@author.books  и код автоматически сходит в базу данных, подкачает список книжек и положит его в instace variable объекта @author, там в эрланге я напишу кучу интересного и полезного кода, вывалив наружу все подобные кишки.

Оно полезно для сурового бекенда, но когда надо быстро делать бизнес-логику, начинается беда.

[Paul Peregud]

> А "распределённые локи" - это о чём речь?

Ulf Wieger опубликовал библиотеку и объявил от этом на erlang-questions сегодня.

2013/10/8 Kirill Zaborsky <qri...@gmail.com>

А "распределённые локи" - это о чём речь?

С уважением,

Кирилл Заборский.

8 октября 2013 г., 15:50 пользователь Dmitrii Dimandt <dmi...@dmitriid.com> написал:

--
Best regards,
Paul Peregud
+48602112091

[Dmitrii Dimandt]

On Oct 8, 2013, at 13:57 , Kirill Zaborsky <qri...@gmail.com> wrote:

А "распределённые локи" - это о чём речь?

https://github.com/uwiger/locks/

Только сегодня анонсировано в англоязычной рассылке

С уважением,

Кирилл Заборский.

8 октября 2013 г., 15:50 пользователь Dmitrii Dimandt <dmi...@dmitriid.com> написал:

[Kirill Zaborsky]

А "распределённые локи" - это о чём речь?

С уважением,

Кирилл Заборский.

8 октября 2013 г., 15:50 пользователь Dmitrii Dimandt <dmi...@dmitriid.com> написал:

[Sergey Prokhorov]

Из списка то, с чем лично сталкивался:

-почта. Год назад, когда понадобилось SMTP, пришлось писать самим — всё существовавшее не работало толком;

https://github.com/Vagabond/gen_smtp вполне рабочий, у меня работает в проекте и на приём и на отправку (хотя код страшненький конечно)

-аналоги TagSoup. Распарсить невалидный HTML нечем, удобных модификаторов/CSS-селекторов нет;

https://github.com/mochi/mochiweb/blob/master/src/mochiweb_html.erl + https://github.com/retnuh/mochiweb_xpath у меня работает в продакшн на значительных объемах (но XPath интерпретатор мне пришлось серьёзно допиливать)

-OAuth(2). Удачи реализовывать с нуля!
-миграции для БД;
-биндинги к ImageMagick или аналогам;
-парсер/компилятор Markdown;

Лично не интересовался, но думаю что это существует (возможно сырое)

-биндинги к Datomic;
-векторная/матричная алгебра;
-CLP (например, core.logic в Clojure).

По моему совсем не ниша Erlang, может чего-то не знаю конечно.

вторник, 8 октября 2013 г., 14:53:09 UTC+4 пользователь Dmitry Groshev написал:

[Dmitrii Dimandt]

пришлось серьёзно допиливать

возможно сырое

Это и значит «библиотек нет» ;) Пилить не каждый и не всякий сможет и захочет.

[Un Lexx]

>Это и значит «библиотек нет» ;) Пилить не каждый и не всякий сможет и захочет.

очевидно что на вкус и на цвет. Однако когда вместо того что бы ныть надо ехать то доехать на ерланге можно. Даже когда библиотек вообще нет(си порты например пока решили все мои проблемы).

9 октября 2013 г., 22:20 пользователь Dmitrii Dimandt <dmi...@dmitriid.com> написал:

[Dmitrii Dimandt]

Дело не в ныть/доехать/при желании.

При желании из из можно сделать что угодно. Но в то время, как в Erlang'е надо будет потратить N времени, чтобы реализовать/допилить/доехать все нужное, можно взять Ruby/Python и доехать за N/10 времени.

Если библиотек вообще нет и все решается C-портами, то Erlang просто становится очень тонким клеем между библиотеками/программами на другом языке. И для большинства задач этот клей вообще-то не нужен :)

А программисты люди ленивые. Когда из 20 нужных вещей надо пилить 9, то лучше сказать «ну его нахер» и взять инструмент, в котором количество пиления сведено до минимума

[Un Lexx]

>И для большинства задач этот клей вообще-то не нужен :)

следует читать как для большинства твоих задач он не нужен.
Думаю врядли кто то будет спорить что у Ерланга есть фичи изза которых он незаменим.  И часто Erlang незаменим именно как клей. Не думаю что это плохо. Часто приходиться в имеющийся проект на чем угодно оклеивать ерлангом для сохранения темпов развития или для сохранения проекта.

А если клей не нужен но его используют и ноюут что нет библиотек то цель явно не в том чтобы доехать.

> можно взять Ruby/Python и доехать за N/10 времени.

Думаю это то же аргумент из категории управления проектом.
в стиле так же можно взять и доехать за N*10 времени. Кстати ровно так же можно перекинуть на оутсорс куда нибудь в азию и жить на  5%.
Не думаю что эффективность организации и управления так уж сильно коррелирует с выбранным языком. В данном контексте ленивых можно просто выкинуть на мороз например. И туда же можно отправить того кто выбрал данную марку "клея" когда вообще был нужен "ацетон".

10 октября 2013 г., 2:01 пользователь Dmitrii Dimandt <dmi...@dmitriid.com> написал:

[Alexander Pavlyutin]

А почему вы сравниваете Erlang и Go? Это разные весовые категории.

Корректно было бы сравнивать Erlang и Inferno, без OTP.

пятница, 4 октября 2013 г., 21:28:57 UTC+3 пользователь nekulin написал:

[Dmitry Groshev]

Уважаемый, вы сейчас спорите с человеком, который не один год зарабывает деньги на том, что пишет на Erlang'е фуллтайм. Мне кажется. в данном случае лучше не спорить, а прислушаться.

[Николай Измайлов]

Хорошие деньги можно заработать даже на php

пятница, 11 октября 2013 г. пользователь Dmitry Groshev <lambda...@gmail.com> писал:

[Dmitrii Dimandt]

On Oct 10, 2013, at 08:25 , Un Lexx <unl...@gmail.com> wrote:

>И для большинства задач этот клей вообще-то не нужен :)

следует читать как для большинства твоих задач он не нужен.
Думаю врядли кто то будет спорить что у Ерланга есть фичи изза которых он незаменим.  И часто Erlang незаменим именно как клей. Не думаю что это плохо. Часто приходиться в имеющийся проект на чем угодно оклеивать ерлангом для сохранения темпов развития или для сохранения проекта.

А если клей не нужен но его используют и ноюут что нет библиотек то цель явно не в том чтобы доехать.

> можно взять Ruby/Python и доехать за N/10 времени.

Думаю это то же аргумент из категории управления проектом.
в стиле так же можно взять и доехать за N*10 времени. Кстати ровно так же можно перекинуть на оутсорс куда нибудь в азию и жить на  5%.
Не думаю что эффективность организации и управления так уж сильно коррелирует с выбранным языком. В данном контексте ленивых можно просто выкинуть на мороз например. И туда же можно отправить того кто выбрал данную марку "клея" когда вообще был нужен "ацетон".

Вас куда-то закидывает не в ту степь. «Выкинуть на мороз, ленивые». Может, вспомним изначальный постулат и как развивался разговор?

1: Библиотек в Эрланге нет/мало

2: Да не, есть

1: Список, достаточно большой, вещей, которых в Эрланге нет

2: Да что вы, вот я тут С-порты заплили и не жужжу

1: То, что кто-то пилит к чему-то порты, не значит, что эти библиотеки в Эрланге появились

2: Ну, ленивых, кто не хочет это пилить, на мороз

:-\

У меня тут, знаете ли, есть сайт, erlanger.ru, который уже 7 лет существует (боже, какой я старый!). Из-за того, что я жутко ленивый, там всего около тысячи новостей по разным аспектам и проектам Эрланга, хотя читаю и принимаю я на порядок больше. Например, только за этот год — 601 неопубликованная новость [1] (объемы новостей по Эрлангу все растут, и растут нелинейно). Так вот, среди этих новостей практически нет новостей про «вот вам простая библиотека для простых задач» из списка, что привел Дмитрий Грошев. Распределенные файловые системы? Нейропрограмирование? Embedded Erlang? Xen? Распределенная конфигурация? Распределенная статистика? Сервера разного калибра и назначения? Статьи для начинающих (ирония судьбы, да)? Да всего этого — хоть лопатой греби.

А захочешь чего-нибудь простенького — «нууу вызвай xxx через os:cmd», «ErlyDTL хватит для всех», «проект в альфа версии и not production ready», «да, я тут на коленке написал, но там список TODO длиннее меня» и т.п. :) А набираешь в гугле «ruby/python/java/go/haskell  <все что угодно>», и тебе выйдет по три-пять версий этого самого «что угодно». Библиотек в Эрланге нет. А то, что есть — четвертый слайд тут: http://www.scribd.com/doc/99721085/Erlang-Sucks-EUC-2012

[1] Скриншотик http://i.minus.com/ibnoa6Wy8NA1TB.png

[Un Lexx]

>Уважаемый, вы сейчас спорите с человеком

я способен и слушать и спорить - мир он не черно белый.

> 1: Библиотек в Эрланге нет/мало

> 2: Да не, есть

> блабла

> 2: Ну, ленивых, кто не хочет это пилить, на мороз

 

в моем понимании речь шла в контексте топикстартера о   Erlang и Go
  аргумент "о бедности библиотек"  который обсуждали  Roman Timofeev и  Max Lapshin

в итоге  выяснилось что для каких то ниш
 * библиотек нет;

 * а для каких то вполне достаточно библиотек;
 * библиотек нет и есть порты.

И я продолжаю думать что данное обстоятельство не может быть решающим при выборе в пользу Go.

>:-\

ну а че делать то? в языке нет нужного функционала - писать сами не хотят сделать порты с другого языка то же

на мороз не демократично по вашему? не по комсомольски? :)

10 октября 2013 г., 14:34 пользователь Alexander Pavlyutin <alexander...@gmail.com> написал:

--

[Max Lapshin]

Я из своей узкой ниши ещё что могу сказать.

Эрлангом часто затыкают дыры. Написали кусок кода на похапе, отскейлились до 50 машин, потом ценник стал слишком большим, надо что-то делать.

Дыры эти порой бывают очень требовательные. Когда я говорю, что тяжело будет найти библиотеку для шедулинга дисковых запросов, способную эффективно работать на 10 гигабитах, я сравниваю с конкурентами. У всех всё самописное, никаких готовых штук.

Поэтому когда речь идет о веб-сайте, тут всё понятно. Рельсы, гитхаб, поехали и приехали. Про эрланг речь возникает

в тех редких, крайне нелюбимых бизнесом ситуациях, когда нужно влезать в кишки. Там очень часто вообще мало чего готового 

бывает. А то, что лежит в каком-то репозитории пакетов для клевого язычка готовое, подчас написано

студентами в рамках дипломной работы. Годится для ноутбука, но не для той задачи, для которой выбирают эрланг.

Вот такой фактор ещё есть.

[Mikhail Gusarov]

В этом смысле эрланг похож на другие узкоспециализированные штуки,
типа того же CFEngine: местами криво и неуклюже, ничего готового нет,
все руками, но другое на тех задачах, которые решает инструмент,
просто не работает.

Best regards,
Mikhail Gusarov.


2013/10/12 Max Lapshin <max.l...@gmail.com>:

[Alex Chistyakov]

2013/10/12 Mikhail Gusarov <dott...@dottedmag.net>

В этом смысле эрланг похож на другие узкоспециализированные штуки,
типа того же CFEngine: местами криво и неуклюже, ничего готового нет,
все руками, но другое на тех задачах, которые решает инструмент,
просто не работает.

Про CFEngine это сейчас хорошо было.

А на каких таких задачах нет ничего готового, кроме CFEngine, и ничего другое просто не работает?

--

SY,
Alex

[Mikhail Gusarov]

К примеру - серверный парк из несольких тысяч серверов плюс несколько
тысяч клиентов. Сервера и клиенты любые - Solaris 8, старый AIX, куча
BSD и разнообразных Linux, начиная с прошловековых серий, на клиентах
разнообразные версии Windows. Начать с того, что тупо синхронизировать
на них всех время (да, в Windows это делается другим способом штатно,
но не все там делается штатно в принципе).

Что-то другое вызовет огромный геморрой по возгромождению клиентской
части на этот зоопарк и еще кучу серверов на поддержание серверной
части.

И да, это из жизни.

Best regards,
Mikhail Gusarov.


2013/10/12 Alex Chistyakov <alex...@gmail.com>: