Латера Софтвер corporate blog
Website development
Clojure
Comments 32
+2
Не обращайте внимание на таких, это обычная толстота…
-1
как из разных?
оба крутятся на jvm, и под js kotlin будет скоро тоже

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

Звучит очень коряво. Software transactional memory, SТМ, по-русски, обычно называют программная транзакционная память. Не мог не откомментить.
+1
Статье имхо более подходящее название: "Мнение: Почему стоит уходить с Ruby и RoR на Clojure" :)
0
Вырвано из контекста :)
Clojure идеально подходит для этих целей.
0
Переходить можно с чего угодно, на что угодно. Не нужно быть адептом технологий, нужно знать инструменты. Но в вашей идее есть доля правды: разработчики на RoR зачастую оказываются в ловушке фреймворка, поэтому выход за пределы им «наносит» большую пользу.
+1
Что меня смущает в ClojureScript так это то что несжатый helloworld на нем весит больше мегабайта, в ужатом и гзипнутом виде меньше 100 кб. Ну да ладно, его можно ужать и при росте объема полезного кода поверх рантайма ClojureScript рост размера будет не таким уж серьезным. Но это полбеды, ClojureScript хорош если вы пишите серьезную логику на клиенте, где структуры данных языка и его остальные возможности вам что-то упростят, но если вы как и большая часть людей вокруг делаете фронтенд из кусков всяких фреймворков и компонентов, то есть вероятность что вы просто устанете бороться с тем, что все эти куски заточены под языковые особенности JS а не ClojureScript.
Вот 2 примера кода на ClojureScript и Javascript которые делают одно и то же с использованием фреймворка KnockouJS:
(ns hello-clojurescript)

(defn app-view-model []
  (this-as this
           (set! (.-firstName this) (.observable js/ko "Bert"))
           (set! (.-lastName this) (.observable js/ko "Bertington"))
           (set! 
             (.-fullName this)
             (.computed js/ko 
               (fn []
                 (str (.firstName this) " " (.lastName this))) this))
           (set!
             (.-capitalizeLastName this) 
             (fn []
               (.lastName this (-> this .lastName .toUpperCase)))))
  nil
  )

(.applyBindings js/ko (app-view-model.))

function AppViewModel() {
    this.firstName = ko.observable("Bert");
    this.lastName = ko.observable("Bertington");
    this.fullName = ko.computed(function() {
        return this.firstName() + " " + this.lastName();    
    }, this);
    this.capitalizeLastName = function() {
        var currentVal = this.lastName();     
        this.lastName(currentVal.toUpperCase());
    };

}

ko.applyBindings(new AppViewModel());
0
Для ClojureScript есть библиотеки, исполняющие роль «прослойки», такие как Reagent, Om итп.
0
Функциональные языки в отличие от объектно-ориентированных Ruby и JavaScript предлагают совершенно иной подход к решению задач.
Но когда JavaScript успел стать объектно-ориентированным, позвольте спросить? Скорее его можно назвать мультипарадигменным, так как он включает неплохой набор инструментов как для функциональной парадигмы, так и для прототипной\объектно-ориентированной.
+5
Почему бы не Elixir?
1) Функциональный
2) Работает в проверенной временем и быстрой Beam VM, как бонус простая и эффективная многопоточность
3) От одного из core разработчиков рельс
4) Phoenix — прекрасный web framework похожий на рельсы, но имхо намного круче
5) ОЧЕНЬ быстрый
0
простая и эффективная многопоточность

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

Посмотрел на актуальные статьи (2015), пишут что это осталось справедливым для мелких объектов (до 64 байт), что даёт небольшие накладные расходы на копирование. А сообщения с большими объектами содержат только указатель на объект, который хранится отдельно. Так что, сейчас реализация вполне может быть достаточно эффективной.
+2
Ну извините. Спеки, которой соответствует 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 используются явно.
-1
Если сможете — ткните на какой-нибудь источник или место в исходниках, где описано, что большие сообщения автоматически конвертируются в binaries.
Автоматической конвертации нет. Но и ваше «копирование из кучи в кучу на каждый чих» несправедливо в случае binaries, которыми пользуются чаще, чем может показаться стороннему наблюдателю.
0
Библиотеки. Вы же понимаете, что на джаве их больше, а мы тут биллинг делаем. Это все-таки энтерпрайзненько, хоть мы и стараемся не увлекаться.
+2
Огромное количество пустых высказываний в духе «никогда не поздно узнавать новое», но самый главный секрет так и не открыт — чем clojure лучше старого доброго вполне зрелого common lisp
0
Многие считают (я тоже склоняюсь к этому мнению), что Clojure не совсем и лисп. Так что сравнивать напрямую их не совсем корректно.
А так то кложа намертво привязана к платформе. Например, долго не было функций для работы со строками — мол используйте методы java.lang.String. Такой подход дает и плюсы, и минусы. Из минусов, постоянно придется деражать в голове то, что мы работаем под JVM (как таковой абстракции над ВМ нету). Зато интеграция с другими JVM языками прозрачна и легка. Ну и возможности JVM при должном умении можно использовать на всю катушку.
Ну и кложа более ФП-ориентированная — все такое прям неизменяемое и дружелюбное к concurrency.
0
Есть еще Хаскель ведь, там плюсом статическая типизация, правда, без jvm, но зато рекурсию можно нормально использовать и скобочки на клавиатуре не сотрутся. Хаскельскрипт тоже умеет компилиться в js.
0
Пожалуй, наиболее близкий вариант на JVM — это Scala. Функциональный язык со статической типизацией, нормальной рекурсией и трансляцией в js.
Only those users with full accounts are able to leave comments., please.