Комментарии 35
Я так и не понял чем Elixir лучше Erlang.
Потому что, по-моему, автор хотел сказать, что Феникс и Эликсир лучше, чем Руби и Рельсы.
Эрланг тут не при чем.
Эрланг тут не при чем.
Синтаксисом. Ну это субъективно конечно.
Субъективно синтаксисом все языки для BEAM (виртуальная машина Erlang) уделывает LFE. Только его на 90% один человек пишет в свободное время, поэтому с экосистемой большие проблемы.
Субъективно мне синтаксис LFE кажется многословным(хотя reader macro могут это поправить), местами уродливым(LFE WAT U DOING STOP IT MAH EYES R BLEEDING https://pbs.twimg.com/media/CJ4qaE7W8AAwOnD.png), местами очень неудобным(no name reuse in patterns). Очень приятный лисп для BEAM был joxa, но он заброшен.
BTW, Elixir страдает от некоторой неконсистентности синтаксиса и смешивать его в одном проекте с erlang кажется довольно сомнительной затеей, и я говорю не об interop, а именно о его инфраструктуре в целом.
BTW, Elixir страдает от некоторой неконсистентности синтаксиса и смешивать его в одном проекте с erlang кажется довольно сомнительной затеей, и я говорю не об interop, а именно о его инфраструктуре в целом.
не рекомендуешь мешать эрланг и эликсир?
Это же может быть приговор эликсиру. Разделение коммьюнити на модных гламурных хипстопидоров и бородатых инженеров, которые не могут работать вместе.
Это же может быть приговор эликсиру. Разделение коммьюнити на модных гламурных хипстопидоров и бородатых инженеров, которые не могут работать вместе.
Я недостаточно хорошо с ним знаком, чтобы не рекомендовать, да и каких-то значимых проблем быть не должно по идее.
Сомнения мои из-за того, что у него есть помимо языка и библиотеки есть еще и инфраструктура, и как ее использовать вместе со сложившейся инфраструктурой э-га — непонятно. Свой менеджмент проектов, свой логгер, свой шелл — мне пока не очень понятно даже как это просто деплоить, не то что, как это в эрланговый проект включать.
А вообще, про использование эликсира из эрланга у тебя должно быть уже больше понимания, чем у меня, ты же собирался попробовать использовать Ecto.
Сомнения мои из-за того, что у него есть помимо языка и библиотеки есть еще и инфраструктура, и как ее использовать вместе со сложившейся инфраструктурой э-га — непонятно. Свой менеджмент проектов, свой логгер, свой шелл — мне пока не очень понятно даже как это просто деплоить, не то что, как это в эрланговый проект включать.
А вообще, про использование эликсира из эрланга у тебя должно быть уже больше понимания, чем у меня, ты же собирался попробовать использовать Ecto.
А насчет разделения коммьюнити — мне кажется очевидным, что не смогут. Но может быть, какой-то процент хипстопидоров одумается и отрастит бороды.
наличием ORM на самом деле.
В силу определенной специфики эрланга, сделать на нем удобный ORM чертовски сложно.
Всё остальное, честно говоря, так себе различия.
В силу определенной специфики эрланга, сделать на нем удобный ORM чертовски сложно.
Всё остальное, честно говоря, так себе различия.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
для начала вокруг Эликсира проталкивается лживый хайп по поводу какой-то связи между эликсиром и руби. При том, что никакой связи то нет
НЛО прилетело и опубликовало эту надпись здесь
Учитывая, что разрабатывает Elixir один из ключевых разработчиков Rails и работник ruby-центричной компании platformatec… Даже если ему очень захотелось бы не оставить никакой связи с языком, у него бы это не получилось. А если серьезно, ряд элементов синтаксиса у него явно позаимствован из руби.
string interpolation разве что.
Всё остальное больше обманка. Можно было сделать язык частично совместимым с руби, что бы частично шарить минимальный код (например, какую-нибудь авторизацию), но он отказался.
В итоге получился очень сложный язык, который непонятно как интегрируется в основную экосистему и уже оттягивающий силы. Зачем-то вместо реюза кода из эрланг народ уже понесло писать свои json библиотеки и прочий подобный стафф.
Всё остальное больше обманка. Можно было сделать язык частично совместимым с руби, что бы частично шарить минимальный код (например, какую-нибудь авторизацию), но он отказался.
В итоге получился очень сложный язык, который непонятно как интегрируется в основную экосистему и уже оттягивающий силы. Зачем-то вместо реюза кода из эрланг народ уже понесло писать свои json библиотеки и прочий подобный стафф.
Забавно что автор поставил unicorn который славится своей текучестью и потом аргументировал тем что rails утекает.
Еще сначала сказал «в свое время Ruby уделал всех», а потом стал расписывать, какое Rails говно.
Собсна, 99% кодеров на рельсах до сих пор думают, что это и есть ЯП.
Собсна, 99% кодеров на рельсах до сих пор думают, что это и есть ЯП.
Полностью поддерживаю. Чуть больше года назад все наши рельсовые приложения перевели с пумы и юникорна на пассажир и с тех пор проблем реально не видели. Это идеальной решение для работы нескольких приложений на одном сервере, которое может похвастаться единством глобальной конфигурации, но раздельным контролем состояния приложений и общим логом, который, при желании, можно настроить чрезвычайно гибко. С памятью пассажир работает очень хорошо, ни разу не было чтобы на одно приложение скушалась вся память если есть параллельно работающие приложения.
А что касается сабжа, может у Elixir и есть будущее, но как правило практически все определяется сообществом — если сообщество будет активно развиваться, мы получим в итоге хороший инструмент. А пока рельсы живы, здоровы и развиваются, реальные боевые приложения на других платформах писать пока не тянет.
А что касается сабжа, может у Elixir и есть будущее, но как правило практически все определяется сообществом — если сообщество будет активно развиваться, мы получим в итоге хороший инструмент. А пока рельсы живы, здоровы и развиваются, реальные боевые приложения на других платформах писать пока не тянет.
Самая шикарная фраза:
Если говорит о затратах на управление пакетами в проекте, то на это у меня уходит не более 1% времени. Если у автора управление пакетами это одна из главных причин продуктивности, то мне кажется что-то в этом не так.
Есть, конечно, всякие решения: SBT, Maven, Ivy,- но все они заставляют меня морщится, когда мне нужно импортнуть чью-либо чужую библиотеку. Может, Ruby меня испортил, но управление пакетами в нём – одна из основных причин моей продуктивности.
Если говорит о затратах на управление пакетами в проекте, то на это у меня уходит не более 1% времени. Если у автора управление пакетами это одна из главных причин продуктивности, то мне кажется что-то в этом не так.
кроме чуть более простого синтаксиса и возможности поиска шаблонов
except with slightly better syntax and the ability to do pattern matching.
Я долго пытался понять, какие шаблоны можно искать в Play… Такие вещи как паттерн матчинг лучше не переводить.
Тестирование – главная парадигма сообщества Ruby, поэтому неудивительно, что большинство рубистов не трогают многопоточность, поскольку её практически невозможно тестировать, а её баги очень сложно воспроизводить.
После этих строк, перестал читать.
Я 85% времени трачу, на то, чтобы понять, что делать. 10% времени трачу на то, чтобы что-то сделать. Остальное утекает, ruby же.
Каков процент стартапов, которые доживают до того момента, когда нужно задуматься о производительности? Какой процент стартапов из этих задумывается о производительности из за кривых рук?
Каков процент стартапов, которые доживают до того момента, когда нужно задуматься о производительности? Какой процент стартапов из этих задумывается о производительности из за кривых рук?
Тут вопрос не в кол-ве успешных стартапов, а в том, что в ближайшее десятилетие рост вычислительных мощностей будет достигаться за счёт увеличения кол-ва ядер. Представьте, допустим через 5 лет, 128-ядерный процессор на самом дешёвом VDS. Как использовать его наиболее эффективно? Многие задумываются об этом уже сейчас…
Поэтому знание функциональных языков программирования становится практически обязательным для любого уважающего себя программиста.
Поэтому знание функциональных языков программирования становится практически обязательным для любого уважающего себя программиста.
Некоторой части стартапов вполне хватит и одного процессора на веб-интерфейс (а в статье, вроде, веб-разработка в основном рассматривается).
Помимо многопоточности вопрос использования 128 процессоров можно решить запуском нескольких процессов. Эффективность будет меньше, но вполне вероятно, что она будет приемлемой для конкретного проекта.
Помимо многопоточности вопрос использования 128 процессоров можно решить запуском нескольких процессов. Эффективность будет меньше, но вполне вероятно, что она будет приемлемой для конкретного проекта.
Зачем тут вообще привязываться к стартапам? Некоторой их части и CMS какой-нибудь вполне хватит. Вопрос не в этом, а в том, в каких проектах лично Вам, как программисту, будет интересно участвовать. Суть нашей работы выбирать инструменты, лучше подходящие под задачу. Но осознанно выбирать мы можем только из тех инструментов, с которыми знакомы.
Поэтому на мой взгляд тут главный вопрос в том, интересно ли Вам иметь в своём личном арсенале инструмент, хорошо подходящий для эффективной работы в многоядерных системах и имеющий проверенные возможности для обеспечения отказоустойчивости. Если неинтересно, то ok, никто ж не заставляет. А если интересно, то имеет смысл уделить время изучению Erlang и Elixir.
Поэтому на мой взгляд тут главный вопрос в том, интересно ли Вам иметь в своём личном арсенале инструмент, хорошо подходящий для эффективной работы в многоядерных системах и имеющий проверенные возможности для обеспечения отказоустойчивости. Если неинтересно, то ok, никто ж не заставляет. А если интересно, то имеет смысл уделить время изучению Erlang и Elixir.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Статья по ссылке немного устарела, даже если следовать ей всеравно могут быть ошибки (эликсир 1.1.0)
Лично я сделал git checkout d59bebd. Так как среди билдов этот последний был удачным (https://travis-ci.org/phoenixframework/phoenix/builds), если же делаю чекаут v0.8.0 как в статье или последней (v1.0.3) версии появляются ошибки.
из readme:
тогда все работает
Лично я сделал git checkout d59bebd. Так как среди билдов этот последний был удачным (https://travis-ci.org/phoenixframework/phoenix/builds), если же делаю чекаут v0.8.0 как в статье или последней (v1.0.3) версии появляются ошибки.
из readme:
$ cd installer$ mix phoenix.new <cloned_phoenix>/splurty --dev$ cd <cloned_phoenix>/splurty$ mix phoenix.serverтогда все работает
Язык Ruby и фреймворк Rails полностью поменяли способ создания веб-приложений.
Очень сильное утверждение. Мне кажется тот же Python повлиял не меньше и у него не течёт память… :)
Я очень люблю Ruby on Rails. Он поменял способ создания веб-приложений в годах 2005–2014. Думаю, что Elixir и Phoenix произведут такой же эффект в годах 2015–2025.
Эх, честно сказать я ничего революционного в Ruby on Rails не увидел. Хотя, не исключаю, что мое мышление устарело, а может потому, что я из Enterprise. Идеи Rails мне нравятся, но революции в этом нет и сказать, что он поменял способ создания веб-приложений в годах 2005–2014 я не могу. Сейчас J2EE очень не плохие идеи имеет, но и они не революционны. Так что сомневаюсь, что Elixir и Phoenix что-то изменят. Просто будет один из вариантов для студентов что-то попробовать «простое» и новых идей для J2EE.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я ставлю на Elixir