For me, the biggest benefit is being able to produce an initial POC that I can learn from before writing my own code. And, as you pointed out, it’s also brilliant for refactoring work.

I sous vide now and then, about twice a week for 6 hours each, so around 12 hours a week. That works out to roughly 15 years of usable machine time for the average person.

Not bad at all.

Fair enough. While it does touch upon `memoized DOM`, you're correct; it might not be sufficient for readers to grasp the full implications unless they're well-versed in these kinds of libraries. For a deeper dive, you can check out this subpage: https://imba.io/guides/rendering. BTW, I don't have any affiliation with this library whatsoever.

> I just wonder, whether a new language is necessary to achieve this.

To achieve compression, no. But to achieve DOM reconciliation without a v-dom, yes.

[0] https://github.com/hyperfiddle/electric

A better example would be Java/Clojure.

You do understand this is just your subjective opinion and not a universal truth, right?

You are basing your argument as if it was a fact that Elixir is “cleaner” (whatever that means) and that there was a thing called “software-testing-revolution” which Erlang was never a part of. Both are subjective and, frankly, plain BS.

> if you are truly dedicated to the craft of software you probably should want them to learn Elixir

Oh boy, I don’t even know where to start... so you’re basically implying that Erlang programmers are not “truly dedicated to the craft of software”? It would be laughable if it wasn’t just sad.

This is the Ruby world mentality that just rubs me the wrong way. Not even worth carrying on with the discussion.

Clojure also doesn’t have auto currrying, but makes up for it by giving you 6 variants and creating a consistent default library for sequences and associative structures.

So, the pipe first operator is just a dirty hack.

Clojure is way more consistent in this regard:

  - thread first (->) when operating on maps.
  - thread last (->>) when operating on sequences.
  - as-> "choose your own adventure".

Comments URL: https://news.ycombinator.com/item?id=25770136

Points: 3

# Comments: 0

The Elixir implementation inverts the classical order of piping last in functional languages to the detriment of it. IMO a language should either support pipe last AND currying by default or supply a multitude of thread operators like Clojure does (->, ->>, as->, etc). Elixir's is just middle-of-the-road-weird.

The post does read more like venting than a structured critique, but a few of his points are still valid.

Every time I hear someone praising Elixir, it's never about some Elixir-specific feature but usually about something that Erlang has provided for ages like pattern matching, lightweight processes, supervisors, the preemptive scheduler. Given this, I'm sure you can appreciate how bittersweet this can be for an Erlang developer.

To me Elixir is just a more complex, verbose and less elegant version of Erlang so it kinda frustrates me when newcomers would rather learn Elixir than plain Erlang.