Pull to refresh

Comments 32

Эм? Языки из разных миров, совсем.
Не обращайте внимание на таких, это обычная толстота…
как из разных?
оба крутятся на jvm, и под js kotlin будет скоро тоже

так что кложа остается неудел
и это никакие не «новые технологии» это уже прошлое
Толще надо быть, толще.
А по теме, как минимум static vs dynamic typing. Вам этого мало?
Так не Лисп же.
[сарказм офф]
с помощью софта для транзакционной памяти

Звучит очень коряво. Software transactional memory, SТМ, по-русски, обычно называют программная транзакционная память. Не мог не откомментить.
"к технологиям переднего края" тоже не слишком благозвучно.
Статье имхо более подходящее название: "Мнение: Почему стоит уходить с Ruby и RoR на Clojure" :)
Из статьи не следует почему стоит уходить именно на Closure.
Вырвано из контекста :)
Clojure идеально подходит для этих целей.
Переходить можно с чего угодно, на что угодно. Не нужно быть адептом технологий, нужно знать инструменты. Но в вашей идее есть доля правды: разработчики на RoR зачастую оказываются в ловушке фреймворка, поэтому выход за пределы им «наносит» большую пользу.
UFO landed and left these words here
Для ClojureScript есть библиотеки, исполняющие роль «прослойки», такие как Reagent, Om итп.
Функциональные языки в отличие от объектно-ориентированных Ruby и JavaScript предлагают совершенно иной подход к решению задач.
Но когда JavaScript успел стать объектно-ориентированным, позвольте спросить? Скорее его можно назвать мультипарадигменным, так как он включает неплохой набор инструментов как для функциональной парадигмы, так и для прототипной\объектно-ориентированной.
Почему бы не Elixir?
1) Функциональный
2) Работает в проверенной временем и быстрой Beam VM, как бонус простая и эффективная многопоточность
3) От одного из core разработчиков рельс
4) Phoenix — прекрасный web framework похожий на рельсы, но имхо намного круче
5) ОЧЕНЬ быстрый
простая и эффективная многопоточность

Эффективная — спорно, копирование из кучи в кучу на каждый чих — довольно дорогая операция. Мне куда более импонирует использование immutable-объектов для межакторного взаимодействия, как это делается в akka.
UFO landed and left these words here
По тому, что я читал раньше, beam копировал данные из кучи в кучу при отправке сообщений.

Посмотрел на актуальные статьи (2015), пишут что это осталось справедливым для мелких объектов (до 64 байт), что даёт небольшие накладные расходы на копирование. А сообщения с большими объектами содержат только указатель на объект, который хранится отдельно. Так что, сейчас реализация вполне может быть достаточно эффективной.
UFO landed and left these words here
Ну извините. Спеки, которой соответствует beam'а (в отличии от jls/jvms) я не видел, насколько понял её просто не существует. И в куче разных статей про erlang, написанных в нулевых-десятых годах видел упоминания, что при отправке сообщения оно копируется в кучу процесса-получателя.

В erlang efficiency guide написано:
All data in messages between Erlang processes is copied, except for refc binaries on the same Erlang node.

В общем, я в некоторых сомнениях. Если сможете — ткните на какой-нибудь источник или место в исходниках, где описано, что большие сообщения автоматически конвертируются в binaries. В актуальных исходниках R16B03 copy_struct не копирует refc binaries, как и написано в efficiency guide. В erl_message.c erts_send_message использует copy_struct. Всё выглядит так, будто сообщение копируется вне зависимости от размера, а binaries используются явно.
UFO landed and left these words here
Библиотеки. Вы же понимаете, что на джаве их больше, а мы тут биллинг делаем. Это все-таки энтерпрайзненько, хоть мы и стараемся не увлекаться.
Огромное количество пустых высказываний в духе «никогда не поздно узнавать новое», но самый главный секрет так и не открыт — чем clojure лучше старого доброго вполне зрелого common lisp
UFO landed and left these words here
Многие считают (я тоже склоняюсь к этому мнению), что Clojure не совсем и лисп. Так что сравнивать напрямую их не совсем корректно.
А так то кложа намертво привязана к платформе. Например, долго не было функций для работы со строками — мол используйте методы java.lang.String. Такой подход дает и плюсы, и минусы. Из минусов, постоянно придется деражать в голове то, что мы работаем под JVM (как таковой абстракции над ВМ нету). Зато интеграция с другими JVM языками прозрачна и легка. Ну и возможности JVM при должном умении можно использовать на всю катушку.
Ну и кложа более ФП-ориентированная — все такое прям неизменяемое и дружелюбное к concurrency.
Есть еще Хаскель ведь, там плюсом статическая типизация, правда, без jvm, но зато рекурсию можно нормально использовать и скобочки на клавиатуре не сотрутся. Хаскельскрипт тоже умеет компилиться в js.
Пожалуй, наиболее близкий вариант на JVM — это Scala. Функциональный язык со статической типизацией, нормальной рекурсией и трансляцией в js.
Only those users with full accounts are able to leave comments. Log in, please.