[hellofunk]

Clojure has its own very effective strategy for multi-threading, and it is not the actor model. The language is built for concurrency and much careful language design was tailor-made for the challenges on modern threaded applications. Rich Hickey investigated the actor model considerably, and decided on a different model. In the core language, you have the choice of using its normal futures/threads with highly efficient and lock-free data structures, or using core.async, which is a model like Go channels. The latter is particularly popular in the community and generally the recommended approach.

Clojurescript offered the first and still (in my opinion) best option for hot reloading via "figwheel" which nearly all Clojurescript developers use. It automatically updates the UI as you code it.

Clojure, on the server, being a proper lisp with a real REPL, lets you poke and inspect and reload parts of the running program with no recompile cycle. A typical workflow there is to reload individual expressions or functions in the context of the running program to alter behavior as you develop.

[oreganoz]

Yeah, that's nice for multi-threading but it does not seem as good for distributed systems. This is why I still don't know if I should invest in Clojure or Elixir.

Can the REPL on the server be used to update production systems with no downtime?

[hellofunk]

Yes you can easily REPL into a live remote server and work with it while it is running. But more typically, the REPL-driven development happens on your own machine while you build, and then you just deploy the whole app. But it can be useful for remote debugging when necessary.

For distributed computing across multiple machines, you are right that the actor model has an edge there. Most applications don't require that, however. There is however Onyx and other tools for this in Clojure:

http://www.onyxplatform.org/index.html

I think the choice between Clojure and Elixir really comes down to how much your particular idea or requirement genuinely depends on the actor model. The vast majority of applications don't specifically require that, in which case you have more flexibility.

[oreganoz]

I was just looking into Onyx right now actually, haha. It's the first result when googling for distributed clojure. Not quite sold on the model, I don't yet know how the internals work so it feels a bit too magic. But I only got a quick peek so it would be unfair to dismiss it.

The vast majority of apps don't require distribution but I'd like to use a model of computation that would support it when needed so as to avoid large refactoring. And, preferably, allow for code reuse with systems that are distributed.

EDIT: Watching a talk about the internals of Onyx made by the creator. I gotta say, I'm liking it more and more.

[hellofunk]

Don't forget that with Clojure, anything you would do in Java or on the JVM using any language, you can do in Clojure. So for example, Scala has Akka, a powerful actor model. And of course, you can use that in Clojure if you want:

https://github.com/gaverhae/okku

(This is just one way to use Akka).

[oreganoz]

Interesting, okku seems completely outdated but I'll try to look out for an Akka integration as it is a really powerful and stable actor model implementation. Has backpressure and all of the other reactive niceties too.

You might just have converted me to clojure, haha.

[jb1991]

I think most Clojure developers will tell you that it is wise at first to just use Java libraries directly, if you can. Look at wrapper libraries to see how the author approached the Java interop, then do it yourself. You are more likely to attain something that is maintainable, flexible and appropriate for your individual style and needs than using what someone else built for the purpose of interop for their needs.