Вышел Erlang/OTP R15B

Например коллекций, по факту, нет.

Каких коллекций - с общим API? Так это не в языке проблема а в непричесанной либе - об этом упоминалось. Язык не имеет препятствий для ее реализации.

Язык не имеет препятствий для ее реализации.

Хе-хе, очень много языков не имеют таковых проблем. Взять тот же CL.

Кстати, слышал что в эрланге есть проблемы с юникодом. Например функции приведения в нижнему регистру или банальное число символов.

Это не полиморфизм, а какая-то херотень. Почему я должен писать в файловый дескриптор какой именно модуль надо вызывать? А если их сотни, а если я ошибусь? Это задача чисто компилятора, когда он видит вызов функции с уже специализированным объектом в аргументе подставить в таблицу вызовов указатель на нужную функцию. Я вообще про это ничего знать не хочу.

Хе-хе, очень много языков не имеют таковых проблем.

Там проблем тоже нет. всякие модули реализцющие всякие коллекции есть.

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

Насчет уделывает, это еще большой вопрос, по части функционала. ngnix тоже проворен как блоха, но вот почему его не используют вместо апача?

А указатели на строки чтобы их портить - это страшнейшая херня для многопоточных програм.

Именно этим все и занимаются, как это не удивительно.

Это не полиморфизм, а какая-то херотень.

Ты просто не знаешь что такое полиморфизм.

Почему я должен писать в файловый дескриптор какой именно модуль надо вызывать?

Ничего ты не должен - я тебе показываю пример реализации ад-хок полиморфизма в эрланге.

А если их сотни, а если я ошибусь?

Какие еще сотни?

%/интерфейс
-module(abstract).
do_this(#desc{module=M}=D) -> M:do_this(D).
do_that(#desc{module=M}=D) -> M:do_that(D).

%реализация str
-module(str).
open(Data) -> #desc{module=str, data=Data}.
do_this(#desc{data=D}) -> "eto string:" ++ D.
.....
%реализация int
-module(int).
open(Data) -> #desc{module=int, data=Data}.
do_this(#desc{data=D}) ->  D * D.

......

> DInt = x:open(5).
> DStr = x:open("str").

> abstract:do_this(DInt).
25
> abstract:do_this(DStr).
"eto sring: str" 

Чем это отличается от твоих классов с интерфейсами?

Меня удивляет другое: единственное, что хорошо сделано из коробки —процессы. И ради них терпеть остальную архаичность платформы? Как-то это глупо.

ngnix тоже проворен как блоха, но вот почему его не используют вместо апача?

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

А в явсе динамик есть - он на эрланге пишется. Я для наших сервисов завалить явс с трех машин не смог- ошибок на сервере нет, начинает ложиться httperf раньше.

Сейчас есть реализованная морда к геобазе (три гига растянутые в памяти) - так узким местом пока является ядро - война идет с тем что ядро воспринимает весь этот поток соединений как syn-flood, а сервису хоть бы хны - он не жаловался.

Меня удивляет другое: единственное, что хорошо сделано из коробки —процессы. И ради них терпеть остальную архаичность платформы? Как-то это глупо.

Так erlang'о-заменителя в этой нише нет, вот и весь ответ.

. И ради них терпеть остальную архаичность платформы? Как-то это глупо.

По сравнению с чем?

Если сравнивать «архаичность платформы» с C/++ - так эта «архаичнось» - апофеоз прогресса. Если область применения - высоконагруженные сетевые сервисы - так в жабонете тоже не найдешь готовых решений. Если на сервере есть многопоточная обработка - то жавашарповская стандартная библиотека с мутабельными данными - тоже идет лесом - она в принципе не применима. Кунгфу со всякими мьютексами и реентрант локами тоже нефига не простое - начиная от повзможных дедлоков, и заканчая деградацией проихводительности из-за большого количества тьютексного кода - эти проблемы с полпинка не решаются. Так что как не крути недостатки в прочих платформах тоже есть и они зачастую перевешивают недостатки не очень удобной либы. Либу в крайнем случае можно свою написать. А написать на жабашарпе платформу подобную эрланговской - значительно дороже. На C/++ вообще феерический звездец.

Единственное чего мне на самом деле действительно не хватает в эрланге - это статической типизации.

Если на сервере есть многопоточная обработка - то жавашарповская стандартная библиотека с мутабельными данными - тоже идет лесом - она в принципе не применима.

стандартная библиотека с мутабельными данными

Здесь бы не помешали примеры, какие пакеты *только* меняют объекты.

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

уже года четыре в хайлоаде .NET используется.

highload и .NET нельзя использовать в одном предложении, у них нет ничего общего, эти понятия антагонистичны.

наличием препроцессора

Убогого препроцессора.

и нормального синтаксиса.

Вспоминается бессмертное «Кому и кобыла - невеста».

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

А кто запрещает на Яве (или Си) делать нити, которые общаются по каналам/очередям и не имеют общего state?

А как выглядит реализация open для объекта состоящего из массива строк неизвестного размера?

но меня еще ни разу на жабке не приперали проблемы с классической синхронизацией,

Это потому что ты не писал достаточно высоконагруженных сервисов где слово «synchronized» убивает производительность ниже плинтуса. Не сам вход в монитор естественно, а типичное лобовое решение «если два метода мутируют один список поставим слово synchronized». И там начинается такое кунфу с непересекающимися мьютексами.... А памяти сколько выжирается на копиях мутабельных структур....

о если будет необходимость, я также могу заюзать и экторы и немутабельность.

Которых ты не найдешь в стандартной либе:) О чем и поинт. В erlang нет жабских коллекций - но в жабе нет эрланговских типов данных вообще. А попытка их создать упреться в отсутствие tailcall оптимизацийти красиво сделать - не выйдет. Потому что немутабельные структуры ходят вместе с рекурсией рука об руку.

А кто запрещает на Яве (или Си) делать нити, которые общаются по каналам/очередям и не имеют общего state?

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

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

Опять эта мифическая библиотека с немутабельными структурами. В жабе такой проблемы нет.

Что проще, взять *готовую* библиотеку легких потоков или в одно рыло дубасить удобные эрланговские функции. Очевидно, первое.

Ты, кстати, так и не ответил, как в нём привести юникодную строку к нижнему регистру.

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

Зачем? Держи свои мутабельные данные в рамках одной нити, и будет тебе щастье.

фреймворком мессенджинга

И симпеляцией диструбных гестронов.

А как выглядит реализация open для объекта состоящего из массива строк неизвестного размера?

Точно так же.

Вообще несморя на то что это эмуляция ооп с виртуальными методами - это вообщето не для того используется - такой ифгней как эмуляция ооп повсеместная никто не занимается в эрланге. Это используется больше в виде аналога паттерна factory + полиморфизм по opaque данным. Таких «объектов» на самом деле - крайне мало в любой программе.

Это потому что ты не писал достаточно высоконагруженных сервисов где слово «synchronized» убивает производительность ниже плинтуса.

Доо. Лоровские эксперты по высоконагруженным сервисам веселят сегодня изрядно. Хочу только заметить, что точно такие же примитивы синхронизации, в виде мьютексов, спинлоков и прочей фигни использует ядро любой операционной системы.

Код покажи, как специализировать функцию open по произвольному типу Т, а не виляй попкой.

В жабе такой проблемы нет.

В жабе такая проблема есть. Я 8 лет писал серверные решения (не веб приложения) на жабе высоконагруженные. Там она в полный рост.

Что проще, взять *готовую* библиотеку легких потоков

Дело совсем не в легких потоках. ForkJoin и вперед. Дело в shared nothing.

Ты, кстати, так и не ответил, как в нём привести юникодную строку к нижнему регистру.

Да - там с этим беда. Строки - это конечно бич эрланга:) Сторонние либы. https://github.com/freeakk/ux

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

анонимус не осиливает прочитать дальше одного предложения?

Это можно сделать. Я это делал неоднократно. После этого остаетс такое же ощущение как после mallocа для строки в си. А именно «как за%69ло в ручную закатывать солнце».

Код покажи, как специализировать функцию open по произвольному типу Т

Во первых эрланг динамический язык. а во вторых facepalm.parametric_polymorphism.

open это _конструктор_. Полиморфные конструкторы - это да ...трава.

Или ты под «спициализацией по типу» хотел оверлоадинга? Тогда - динамический язык.

Держи свои мутабельные данные в рамках одной нити, и будет тебе щастье.

А попадут они туда как?

l = List(1,2,3,4) //мутабельный список.
f1(l) 
f2(l) //мне тут уже торба или нет?

Сто лет никто это не делает в ручную. Полно библиотек на эти темы с готовыми каркасами приложений. Какой нибудь ACE уже лет 15 наверное, если не больше. Ты просто программировать не умеешь, мой милый друг, вот и хватаешься за всякие модные погремушки, не понимая сути того, что под линукс, лучше чем на С++ не напишешь, поскольку в оптимизацию его библиотек вбухано сотни тысяч человеко-часов элитных программистов.

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

О - мой милый друг - снипет кода выше, язык любой из набора C/C++/java/C#, класс List соответствующе стандартный мутабельный - что в нем лежит в строке 3, при вызове чужой функции f1?

что под линукс, лучше чем на С++ не напишешь,

на С++ не напишешь

obvious fix.

Банальное число символов -

1> length("Δ๗あ叶葉").
5
2> "Δ๗あ叶葉".
[916,3671,12354,21494,33865]

А вот перевод в другой регистр самим писать надо или взять уже написанную :)

ИМХО проблемы не языка, а стандартной библиотеки.

Полиморфные конструкторы - это да ...трава.

А что такого страшного? Не понимаю. Чем vector<int> сильно отличается от vector<const char**>?

Держи свои мутабельные данные в рамках одной нити, и будет тебе щастье.

А попадут они туда как?

Ты серьезно?

f2(l) //мне тут уже торба или нет?

Если ты не понимаешь, что делает f2, то да, тебе торба.

f3(NULL) // мне чехол или как?

А что такого страшного? Не понимаю. Чем vector<int> сильно отличается от vector<const char**>?

Каша полная.

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

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

так наглядней полиморфизм..

-module(z)

f(x) -> x;
f(y) -> y.

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

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

Сидел пару дней назад изобретал do-notation

Так вроде как уже: erlando

Если ты не понимаешь, что делает f2, то да, тебе торба.

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

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

Если взять открыть спеку сантехников по javabeans обычный whitepaper лохматого 98? года. чт мы видим там в разделе event handling и всяких property listeners? А видим мы там вот подобный код:

Vector v;
synchronized(this.handlers) { v= this.handlers.clone() }
for(h: handlers) h.event(e).

А почему так? Потому что без synchronized - имеем race conditions, ConcurrentModificationException и прочие радости жизни. Засинхронизировать сам for нельзя - потому что это обозначает точку сериализации всей многопоточности - тормоза, фактическая однозадачность. В результате жрем память на каждый чих. И это оправдано - потому что проблема не надумана. 

На немутабельных структурах - вообще нет таких проблем - race conditions отсутствуют чисто семантически.

Возьми любое приложение - банальный вебапп и посчитай сколько раз клонируется список объектов начиная с какого нить гибернейта где он поднял его из базы через все слои которые их фильтруют и и перекрашивают и до генератора HTML который по нему еще проедет. Почти гарантирровано на всех этих уровнях - clone/for. А потом где память, где процессор. А на немутабельных ленивых структурах будет всего 1 for для последовательной обработки. Память наместе, процессор холодный, отклик быстрый.

f3(NULL) // мне чехол или как?

И да - nullы не нужны.

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

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

Ну и зачем тогда ты предлагаешь нам этот отстой вместо надежных и проверенных временем фреймворков типа явы или с++.

потому что C++ отстой в принципе, а в жабе своих проблем не связанных с ипизаией хватает. И да - я не предлагаю - мне в принципе все равно как там кто мучается пожизни.

Я понимаю, то что ты называешь модным словом полиморфизм есть банальная «перегрузка функций».

Так вроде как уже: erlando

Ага - да - я тоже подобную сделал. Только там сделали монадную, а я делал просто для either. Ну зато с parse_transform разобрался:)

Я понимаю, то что ты называешь модным словом полиморфизм есть банальная «перегрузка функций».

Садись - 2.

С++ конечно не идеален, но работа идет в нужном направлении, и популярность его растет, вот новый стандарт недавно вышел. А такие детские проблемы роста, как отсутсвие порта под win64, там отсутствуют еще с прошлого века.

к стати - демонстрирует. Ребят из rabbitmq тоже достал badmatch и каскадный case.

и популярность его растет.

http://www.tiobe.com/index.php/paperinfo/tpci/C__.html

Да уж.