Hacker News Reader

Comment by tanzbaer | Hacker News Reader

Why would I use this over elixir?

From the readme of the project:

> Clojure is a Lisp and as such comes with all the goodies Lisps provide. Apart from these Clojure also introduces powerful abstractions such as protocols, multimethods and seqs, to name a few. [...] It is fair to say that combining the power of the Erlang VM with the expressiveness of Clojure could provide an interesting, useful result to make the lives of many programmers simpler and make the world a happier place.

Also, at this point Clojure is becoming a kind of nice foundational language with multi-host targets. So if you know Clojure, you can now leverage the JVM, various JS runtimes, the CLR, now also the BEAM, etc. So there's that too. So basically, to someone already knowing Clojure it's a nice way to have access to more platforms.

There are a bit different due to the host environment.

Btw, use the iOS version a lot to learn

Another reason might be the "cultural" aspects of Clojure, and their impacts on its ecosystem - in particular simplicity and stability are paramount, whereas the Elixir ecosystem seems to put more emphasis on immediate ease of use and elegance à la Ruby, at the cost of doing some "magical" designs which you tend to not see in the Clojure ecosystem.

How exactly is stability not paramount in Elixir? It runs in the BEAM.

Stability of the language itself is another factor though. Clojure does a really good job avoiding breaking changes in the language.

With the exception of a few project config settings whose legacy variants are still backwards compatible, Elixir is absolutely stable as well.

So not sure what were you saying about Elixir.

If you want a Lisp (although there are multiple Lisps for the BEAM). If you want to help build a new language. If you don’t like Elixir’s syntax (raises hand).

Just curious--what don't you like about Elixir's syntax?

I don't particularly care for the ambiguity that stems from facets of it being optional, nor the way function match arms are defined, nor the :atom or lowercase variable naming syntax. The mixing of do and -> kinda bugs me as well. :shrug:

Though my opinion on the matter is deeply colored and probably unreliable because I'm one of those weirdos that thinks that Erlang syntax is actually quite nice for the most part.

Also, I'm in no position to complain since currently my technical life (what little is left not making slide decks) now revolves around Rust, Agda, and TLA+ (god help me).

I’m also one of those weirdos. I’m a big fan of Erlang syntax: very concise, mostly trivial to read (although list comprehensions can get hairy).

Same here. I’ll take Erlang’s conciseness and readability over Elixir’s prolixity any day.

It's been a while since I looked at Elixir but the different syntax for invoking named functions vs lambdas really left a bad taste in my mouth...

Also I remember trying to do something with the pipe operator that I couldn't get working due to the syntax of the language but which would've been trivial in Clojure using one of the threading macros.

Pardon me for saying it but it sounds like you tried for 5 minutes, gave up because it's not familiar to you, and then said you don't like the pipe operator.

You might have wanted to say something else but this is how you sounded to me. Am I wrong?

I think the more interesting question would be why Clojerl over LFE (http://lfe.io/)?

Yes, there is a community around Clojure that would feel more at home with the BEAM if they could use Clojure there... and this is likely the answer to my first sentence... but once you get to a Lisp it seems like the leap is less far to another Lisp and LFE, I would think, is better established.

So I guess the real question would be, for those outside the Clojerl project, are the benefits Clojure more specifically on the BEAM worth the costs of foregoing a (possibly/likely) more mature Lisp that already exists for the BEAM?

I can think of a few reasons: same language between front and backend, extensive standard library, repl driven development, simplicity, brevity, spec.

With Phoenix + LiveView maybe you won't need the frontend.

It’s a great project, but I doubt it’ll ever reach the maturity and functionality of Reagent, Om, Rum. Fulcro, Datascript, re-frame and Hoplon.

I wouldn't bet against Chris McCord and Jose Valim.

They've done a wonderful job with Phoenix and Elixir. I think this feature liveview will be develop as good as presence feature and eventually will be good enough.

it's such a weird concept to me.. "server-rendered html" is what i was doing most of my webdev career and suddenly it's the "hot new thing"?

anyway i still don't see why i would need it with Clojure if i can have single codebase and language for backend and frontend and render whatever i want at either -end.

Because with LiveView you can throw away 90% of your JavaScript and work almost exclusively with Elixir both on the frontend and the back end.

Right, but I could also throw away 100% of my JavaScript and not have to deal with any of the nodejs/npm/webpack/whatever nonsense if I used Clojure.

Clojure is incredibly popular, and there are probably lots of people that are interested in learning Clojure but scared away by the JVM ecosystem.

There’s no way either statement you’re saying ia true. Clojure is certainly not “incredibly popular.” And if you think many people are scared away from the JVM vs the BEAM, I don’t even know what to say.

Reply on news.ycombinator.com