Nitpick of the day: Elixir is not purely functional. It’s actually quite the opposite by design.
[Comment removed by author]
There’s only one meaning of “purely functional;” some people are just wrong. It doesn’t meant to say that the language only (“purely”) supports programming with functions, it means to say the language supports programming with pure functions. Elixir and Clojure are primarily functional but do not enforce pure functions. Pure functional languages include Haskell and its family. https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Pure
Great is probably a strong word for a language that doesn’t support parallelism (unless you are on on alternative runtime). Maybe guilds will fix this but they wont be ready in the near future.
-I do enjoy and write quite a bit of ruby
I agree. Ruby has missed the train with its close to no concurrency support. Also, its hyper dynamic and flexible nature, which seems like a productivity boost in the beginning, often end up being a maintenance nightmare, especially since software is getting more and more complex every day.
I also write a lot of Ruby for a living, but I am not blind.
9 out 10 web applications simply don’t need the power that Phoenix and its Erlang underpinnings provide,
Then it must be me, but most of the Rails projects I’ve worked with would have hugely benefited from many of the concurrency and resiliency features that Elixir / Erlang provide.
That number, 9 out 10, is based on nothing more than gut feeling.
and in these cases, developing them with Rails will be much faster.
Why do you think that developing with Rails is faster than with Phoenix? Having programmed Ruby + Rails for many years, I started a project in Elixir + Phoenix, and it took me a pretty short time to get up to speed. From all the new languages I’ve tried in the last couple of years, Elixir is probably the one that you can jump in the fastest (especially if you come from a Ruby background).
Agreed. The application I work at my day job is Rails, but all my web side projects are Elixir and Phoenix. Even ignoring the concurrency aspect, rendering is lighting-fast and my applications are light so I have 3 of them running on my $5/mo Digital Ocean droplet. It’s also much easier to understand and grow an application when you know you can just follow the function chain all the way down rather than worry about a lot of the bloat and overhead that comes with long-running Rails apps.
I appreciate the sentiment of the article, as I think programmers (especially of the kind that read HN/Lobsters) are a bet neophilic (I guess they’ve never heard of the Lindy Effect), a bit of neophilia is necessary in technology to correct for the previous neomania. (h/t Nassim Taleb for introducing these concepts to me via his writing).
I really like this sentiment
All programming languages are exciting. […] There is no linear scale that makes language X better than language Y.
I disagree with that quite strongly. Some languages are better than others. Ruby is nearer to the bottom of the spectrum.
The Blub paradox
The section does reference an “abstractness continuum” and a “power continuum” among programming languages. The problem I have with this is the vague notion of “power”. Languages are made with different intentions. Rust goes to great lengths to be Safe, Erlang goes to great lengths to be easy to distribute. Which would you say is better in general? Even if NASA begins to save lives with rust, I’m sure the 32 engineers who sold whatsapp for $19 billion love Erlang.
There are axes of goodness, sure, and language X can be better than language Y on some axes and worse on others. But it’s a grave mistake to think that there’s some kind of point-buy system where every advantage is matched by an equal and opposite disadvantage. A language can be good on all axes or bad on all axes. A language can be better in every way than another language. And IME these are actually the more common cases.