Спасибо за статью, интересно. Только возникает один вопрос: а почему развитию выделено так мало времени? 10% хватит чтобы быть на гребне волны в столь быстро меняющейся сфере как IT?
Да тут вроде разговор, что не GIL'ом единым и транзакционной памятью можно решить проблему многопоточности в приложениях. Как пример – BEAM.
А elixir тут как пример альтернативного языка для BEAM.
А смысл?
Запас энергии намного меньше чем у пневматики (PCP или баллонной), и восстановить её в поле не получится (в отличие от «переломок»), масса сравнима, а надёжность у пневматики скорее всего будет выше. Плюс для приемлимой кучности пулю нужно будет закрутить, а как тут это сделать не очень понятно.
Тогда может удобнее было бы попробовать сделать через rebar escriptize, и собрать один бинарник, в котором будет cowboy, sync и cowboyd? Его можно будет либо класть в /usr/bin, либо в корень проекта. И не нужно будет тянуть никаких зависимостей.
Довольно неоднозначно.
С одной стороны – да, возможно такой проект в случае вэб разработки может быть полезен.
С другой же, в любом случае нужно делать скелет проекта (через шаблоны ребара, либо ручками) и дописать в шаблон лишние 20 строчек не такая уж проблема. Зато будет сильно проще и потом можно будет сделать reltool сборку.
Ну ок, понятие удобности очень субъективно, не хочу тут спорить.
Думал, может есть ещё какие-нибудь причины.
Хочу лишь сказать, что большинстве функциональных языков (хаскель, окамль, лисп) объект изменения обычно идет последним аргументом и думаю, это не зря. Поэтому факт того, что в элексире сделали наоборот очень смутил и лично меня оттолкнул.
Я вижу, Вы неплохо знакомы с эликсиром и наверное сможете ответить на мой вопрос.
После беглого изучения меня в ступор ввёл один факт, почему в стандартно библиотеке все вызовы функций привели к стандартному виду, что объект изменения (список, рекорд или другой контейнер) находится на первом месте? Это же очевидно неудобно при написании кода, и обычно делают наоборот.
Например, я совершенно не понимаю как писать List.foldl([5,5], 10, fn (x, acc) -> x + acc end)
10-15 к на среднестатическом сервер (2.3 xeon, 4gb ram) можно выдержать другой схемой.
Каждая комманда посылается на сервер, который в свою очередь держит в памяти состояние пользователя и при запросе клиента валидирвует запрос и производит транзакцию (в памяти). И когда пользователь выходит, либо когда совершаются действия с золотом(реалом), состояние дампится в базу.
Хорошая статья, но с одним не соглашусь, что нужно перед тимлидом молчать если с ним не согласен. Тимлид тоже человек, ему свойственно ошибаться, и как раз такое прямое выражение своих мыслей очень способствует наставлению на путь истинный. Но, разумеется, тут нужно знать меру и не начинать спорить и давать выход эмоциям, т.к. это приведет к конфликту.
Если люди в команде будут молчать, то качество системы не превысит уровня лида, а если будут влиять на разработку, то превысит.
Это все из личного опыта, граблей и шишек.
Спасибо за статью, интересно. Только возникает один вопрос: а почему развитию выделено так мало времени? 10% хватит чтобы быть на гребне волны в столь быстро меняющейся сфере как IT?
А как же умные и трудолюбивые, у которых выделено время на чтение хабра в статье развитие? ;)
А elixir тут как пример альтернативного языка для BEAM.
Это изначальный постулат.
Такой язык уже есть, elixir.
Запас энергии намного меньше чем у пневматики (PCP или баллонной), и восстановить её в поле не получится (в отличие от «переломок»), масса сравнима, а надёжность у пневматики скорее всего будет выше. Плюс для приемлимой кучности пулю нужно будет закрутить, а как тут это сделать не очень понятно.
rebar escriptize, и собрать один бинарник, в котором будет cowboy, sync и cowboyd? Его можно будет либо класть в /usr/bin, либо в корень проекта. И не нужно будет тянуть никаких зависимостей.С одной стороны – да, возможно такой проект в случае вэб разработки может быть полезен.
С другой же, в любом случае нужно делать скелет проекта (через шаблоны ребара, либо ручками) и дописать в шаблон лишние 20 строчек не такая уж проблема. Зато будет сильно проще и потом можно будет сделать reltool сборку.
Думал, может есть ещё какие-нибудь причины.
Хочу лишь сказать, что большинстве функциональных языков (хаскель, окамль, лисп) объект изменения обычно идет последним аргументом и думаю, это не зря. Поэтому факт того, что в элексире сделали наоборот очень смутил и лично меня оттолкнул.
После беглого изучения меня в ступор ввёл один факт, почему в стандартно библиотеке все вызовы функций привели к стандартному виду, что объект изменения (список, рекорд или другой контейнер) находится на первом месте? Это же очевидно неудобно при написании кода, и обычно делают наоборот.
Например, я совершенно не понимаю как писать
List.foldl([5,5], 10, fn (x, acc) -> x + acc end)Каждая комманда посылается на сервер, который в свою очередь держит в памяти состояние пользователя и при запросе клиента валидирвует запрос и производит транзакцию (в памяти). И когда пользователь выходит, либо когда совершаются действия с золотом(реалом), состояние дампится в базу.
А так по большей части в релизе внутренние переработки и оптимизации, и более понятный список изменений в рассылке erlang.org/pipermail/erlang-questions/2013-February/072592.html
Как же можно с ним так?!
Если люди в команде будут молчать, то качество системы не превысит уровня лида, а если будут влиять на разработку, то превысит.
Это все из личного опыта, граблей и шишек.