4 ms·

I've considered Elixir as something worth picking up next, but my question is, why would I chose it over Clojure when Clojure gives me similar functionality (ma

I've considered Elixir as something worth picking up next, but my question is, why would I chose it over Clojure when Clojure gives me similar functionality (macros, some concurrency), but much deeper library options?

rubiquity 12y ago
That's a tough question to answer as Clojure is a really great language and Rich Hickey is someone whose every word I'll read or listen to in a video. Someone more well-versed in Clojure than I can probably answer this better, but in my opinion: - Clojure runs on the JVM, so Clojure's concurrency is still sharing memory deep down, whereas Elixir is not. - I would think Elixir has deeper library options than Clojure due to having interoperability with Erlang. I guess in Clojure you get all the Java libraries too, though. - While Leiningen is a much better build tool than other JVM build tools, it still reeks of too much configuration. Mix is very, very simple. - Clojure, for sanity purposes, requires using a very Lisp-specific development environment. Clojure isn't the only language I use so using something like vim-fireplace or Emacs just for Clojure was a bit much for me. I'm happy to be wrong on any of my points above and again I think both Elixir and Clojure are great.
- klibertp 12y ago
  In my experience Leiningen is so much slower for typical, casual use case than rebar and mix that it was a serious inconvenience. I didn't try to solve it by having something like a deamon always running in a background or something like this though, it's possible that this is already addressed. > requires using a very Lisp-specific development environment I'm an Emacs user, so it was very natural for me, but I think it can be a problem for others. On the other hand I hear that there are excellent plugins for widely-used IDEs for Clojure. Actually, as Clojure is a Lisp, the only thing you really need is an editor which handles sexps well. Emacs Paredit is really great for this: http://emacsrocks.com/e14.html http://emacsrocks.com/e14.html but as long as you get similar functionality you can use anything you want.
yohanatan 12y ago
Erlang has built-in support for high availability. Such things as 'let it crash' + message passing architecture + process isolation, etc.
adrusi 12y ago
As yohanatan mentions, the OTP ecosystem is build around the notion of letting processes crash. In every other language that I can think of, you try to handle all errors immediately when they happen, whether that be an explicit check like in C or Go, or through some kind of exception system. In Erlang/Elixir, your programs should be designed such that each process performs a small enough task that if it crashes unexpectedly, you can "recover" by restarting it. This idea is complemented by the shunning of side effects. If you do it right, you end up writing wildly different programs in erlang/elixir than you would in other languages. That said, erlang is specialized for a certain kind of problem, and if you're not building large-scale distributed systems, you probably won't as much out of erlang. Clojure is more general purpose.
tramjoe_ 12y ago
Clojure does not give you similar functionality. Read about Erlang and the BEAM VM, and find out for yourself. If you need the unique functionalities there, you'll have your answer.
klibertp 12y ago
The concurrency model of Clojure is different than that of Erlang (and Elixir), especially Erlang is easier to scale to many machines (it's actually built right into the language/VM). But to be honest, I think you should just learn both. Clojure is an interesting language, even if I disagree with some design decisions (no reader macros...), with interesting capabilities and so is Erlang and even more so Elixir, but that's really the end of similarities between them. Error handling, metaprogramming, concurrency and pretty much every other aspect of these languages are different, so learning both is not redundant IMHO in the least.
- kaonashi 12y ago
  Out of curiosity, what use cases do you have for reader macros that tagged literals do not cover? http://clojure.org/reader#The%20Reader--Tagged%20Literals http://clojure.org/reader#The%20Reader--Tagged%20Literals
lucian1900 12y ago
Besides syntax, the semantics are indeed quite similar. The choice is between Erlang's VM and the JVM. The usual reasons apply.
- alco 12y ago
  The differences are more than just in syntax. Elixir is also a standard lib that many enjoy, out-of-the box tooling (even Erlang folks have praised mix, the project manager for Elixir), meta-programming. For example, this code generates a bunch of functions using some compile-time code execution and a macro: https://github.com/alco/benchfella/blob/2513f85eff3886fdf1b362980ce59cf279362e26/test/benchfella_bench.exs https://github.com/alco/benchfella/blob/2513f85eff3886fdf1b3.... Doing the same in Erlang would involve using some 3rd party tool for code generation or doing the whole thing at runtime, in a more verbose way. In short, achieving similar development productivity with Erlang would be quite a challenge.
  - mononcqc 12y ago
    The best version of that test would be done with a tool like QuickCheck, PropEr, or Triq, which would do property-based testing, and allow to get much better coverage and reporting of problem cases. Edit: I assumed this was a test, turns out it's a benchmark. My bad.
alco 12y ago
"Some concurrency" and Erlang-style concurrency are a thousand miles apart. Read this www.erlang.org/download/armstrong_thesis_2003.pdf. No matter which language you are using, this will help you expand your perspective on the subject of building reliable systems.

rubiquity 12y ago

That's a tough question to answer as Clojure is a really great language and Rich Hickey is someone whose every word I'll read or listen to in a video. Someone more well-versed in Clojure than I can probably answer this better, but in my opinion: - Clojure runs on the JVM, so Clojure's concurrency is still sharing memory deep down, whereas Elixir is not. - I would think Elixir has deeper library options than Clojure due to having interoperability with Erlang. I guess in Clojure you get all the Java libraries too, though. - While Leiningen is a much better build tool than other JVM build tools, it still reeks of too much configuration. Mix is very, very simple. - Clojure, for sanity purposes, requires using a very Lisp-specific development environment. Clojure isn't the only language I use so using something like vim-fireplace or Emacs just for Clojure was a bit much for me. I'm happy to be wrong on any of my points above and again I think both Elixir and Clojure are great.

klibertp 12y ago
In my experience Leiningen is so much slower for typical, casual use case than rebar and mix that it was a serious inconvenience. I didn't try to solve it by having something like a deamon always running in a background or something like this though, it's possible that this is already addressed. > requires using a very Lisp-specific development environment I'm an Emacs user, so it was very natural for me, but I think it can be a problem for others. On the other hand I hear that there are excellent plugins for widely-used IDEs for Clojure. Actually, as Clojure is a Lisp, the only thing you really need is an editor which handles sexps well. Emacs Paredit is really great for this: http://emacsrocks.com/e14.html http://emacsrocks.com/e14.html but as long as you get similar functionality you can use anything you want.

yohanatan 12y ago

Erlang has built-in support for high availability. Such things as 'let it crash' + message passing architecture + process isolation, etc.

adrusi 12y ago

As yohanatan mentions, the OTP ecosystem is build around the notion of letting processes crash. In every other language that I can think of, you try to handle all errors immediately when they happen, whether that be an explicit check like in C or Go, or through some kind of exception system. In Erlang/Elixir, your programs should be designed such that each process performs a small enough task that if it crashes unexpectedly, you can "recover" by restarting it. This idea is complemented by the shunning of side effects. If you do it right, you end up writing wildly different programs in erlang/elixir than you would in other languages. That said, erlang is specialized for a certain kind of problem, and if you're not building large-scale distributed systems, you probably won't as much out of erlang. Clojure is more general purpose.

tramjoe_ 12y ago

Clojure does not give you similar functionality. Read about Erlang and the BEAM VM, and find out for yourself. If you need the unique functionalities there, you'll have your answer.

klibertp 12y ago

The concurrency model of Clojure is different than that of Erlang (and Elixir), especially Erlang is easier to scale to many machines (it's actually built right into the language/VM). But to be honest, I think you should just learn both. Clojure is an interesting language, even if I disagree with some design decisions (no reader macros...), with interesting capabilities and so is Erlang and even more so Elixir, but that's really the end of similarities between them. Error handling, metaprogramming, concurrency and pretty much every other aspect of these languages are different, so learning both is not redundant IMHO in the least.

kaonashi 12y ago
Out of curiosity, what use cases do you have for reader macros that tagged literals do not cover? http://clojure.org/reader#The%20Reader--Tagged%20Literals http://clojure.org/reader#The%20Reader--Tagged%20Literals

lucian1900 12y ago

Besides syntax, the semantics are indeed quite similar. The choice is between Erlang's VM and the JVM. The usual reasons apply.

alco 12y ago
The differences are more than just in syntax. Elixir is also a standard lib that many enjoy, out-of-the box tooling (even Erlang folks have praised mix, the project manager for Elixir), meta-programming. For example, this code generates a bunch of functions using some compile-time code execution and a macro: https://github.com/alco/benchfella/blob/2513f85eff3886fdf1b362980ce59cf279362e26/test/benchfella_bench.exs https://github.com/alco/benchfella/blob/2513f85eff3886fdf1b3.... Doing the same in Erlang would involve using some 3rd party tool for code generation or doing the whole thing at runtime, in a more verbose way. In short, achieving similar development productivity with Erlang would be quite a challenge.
- mononcqc 12y ago
  The best version of that test would be done with a tool like QuickCheck, PropEr, or Triq, which would do property-based testing, and allow to get much better coverage and reporting of problem cases. Edit: I assumed this was a test, turns out it's a benchmark. My bad.

alco 12y ago

"Some concurrency" and Erlang-style concurrency are a thousand miles apart. Read this www.erlang.org/download/armstrong_thesis_2003.pdf. No matter which language you are using, this will help you expand your perspective on the subject of building reliable systems.