Hacker News Reader

Here are a few legitimate complaints about Elixir (and in some cases, its host VM, the BEAM):

* No mutation support means that for some CPU-heavy tasks, it's not as performant as languages that allow mutation. Some optimized algorithms that rely on mutation can't be expressed directly in Elixir or Erlang, and instead need to be linked in through a foreign function interface.

* It's not on the JVM so we don't get to piggyback on the thousands of dev-years of VM optimization and ecosystem around it.

* It isn't invented at, supported at, and marketed by a FAANG-type company. Money moves mountains and Ericsson doesn't spend as much on Erlang/BEAM as, say, Google spends on Go.

* Comparison across types is not a runtime exception, so you need to guard against crap like `nil > 1 == true` yourself.

* Erlang standard library, which is idiomatic to use from Elixir in the same way of using Java classes from Clojure, is a bit of a junk drawer of tools. There's good stuff, but you may have to dig for it.

* Elixir still hasn't nailed the balance between creating small, independent pieces of code ("applications" in Erlang-speak) and wrangling them so they can be used as dependencies from monorepos, multi-repos, etc. Umbrella projects were an attempt, I don't like them.

* There is an impedance mismatch between Erlang/Elixir's configuration system and 12 Factor® ENV-style configs. (Full disclosure, I wrote a library for this: https://github.com/appcues/config_smuggler)

* The built-in Elixir code formatter removes trailing commas from multiline lists. I mean, come on!

CPU-heavy tasks may not be constrained as much on mutation as on the host VM architecture. The threading system purposefully prevents a thread from hogging all resources. And since you have to run every computation in a thread (process), there really is some overhead. As I'm sure you know, the BEAM is built for concurrency, not for parallelizing computations.

Take Haskell for example, which is also immutable but doesn't require you to spin up processes to do computations. It handles CPU intensive tasks significantly better, but is a worse choice for highly concurrent low latency soft real-time apps because of the scheduler and garbage collector mechanisms.

Edit: Btw thanks for bringing up that comparison across types issue. Never realized that. What's your solution to it? I'd write guards on functions that filter input based on types, then have a final fallback with no pattern matching that throws an error explicitly.

I don't have a general purpose solution to comparison across types -- it generally takes the form of wrapping whatever might have yielded a `nil` value in a `case` expression. Not a big deal, but in cases where the rest of the computation would be garbage if a `nil` crept in, I would prefer if I could just Let It Crash.

Could you use a nif for the heavy compute tasks?

Yes. Rust with https://github.com/rusterlium/rustler is one popular option.

I’m using rustler currently!

I wasn’t positive if the erlang VM restricted resource access in anyway.

I’m not doing anything CPU intensive, just bringing over a library I’m not smart enough to build in elixir :)

Or maybe, too smart to build. But probably not.

if I may do a bit of self-promotion, even though zig is not ready for prod (yet) I'm writing a nif system for zig that will make that whole process dead-easy.

https://github.com/ityonemo/zigler

These are fair points, but I would say that even though it's not the JVM, BEAM is an impressive piece of engineering with a significant amount of dev-years in it.

>* It isn't invented at, supported at, and marketed by a FAANG-type company. Money moves mountains and Ericsson doesn't spend as much on Erlang/BEAM as, say, Google spends on Go. Indeed it wasn’t. In fact it was designed before any of the FAANG companies existed. And was specifically designed for systems that have downtimes measured in seconds per year.

I can give you my point of view as a seasoned PHP / Symfony dev with a light Elixir experience.

Pros :

- Elixir is fun. It's hard to describe why, but it is. Piping is additive, so are genservers and supervisors (which lead to anti-patterns but still).

- Phoenix is well thought out, documentation is good. Plugs are so simple.

- Websocket support is great, obviously (and LiveView is a gift).

- Ecosystem is not that big, but mostly quality and the automatic hex docs is a great feature.

- Concurrency is obviously good and, most of all, only there when you need it (looking at you, Node).

- Speed.

- Coming from PHP, having the ability to easily run tasks outside the current request is so freeing and eliminates the need of many third party components.

- Testing is good.

- Mix is great.

Cons:

- I don't care about static vs dynamic types but I do miss the type hinting of PHP 7. Typespecs are helpful but not the same (and Dializer reports are not fun).

- As a follow up it's hard to beat the IDE support of popular languages. (the Elixir plugin for Jetbrains' IDEs is good though).

- Not anybody will like functional programming I guess (it did kick my butt at first)

- Phoenix doesn't provide that much. If I compare to Symfony (and I guess RoR, Django etc) it's really noticeable. Authorization/Authentication, Cache, Mails etc. Also I'm not a fan of the templating (again, compared to Symfony's Twig).

- Also Phoenix speed of development seems slower (I guess the team is small and also currently a lot of work goes on LiveView)

- What I would give to have the cross-build capability of languages like Go, or the simple deployment story of PHP etc.

- Obviously a smaller ecosystem and less support online (StackOverflow is not useful, better luck on the Elixir forum)

- Speed (for some things).

- I do miss the return keyword.

- I do miss constants (modules attributes are not a replacement).

- None of your colleagues want to use it (some people just hate VMs).

I can take a stab at this. For context, my background is in Ruby, NodeJS, a bit of Golang and Java. I've been doing work with Elixir full time for the last 3 years.

I could probably write a novel about the things I like about Elixir, but here's what I'd caution about for someone looking at adopting it over another alternative.

- Elixir is not statically typed and probably won't be. If static types are a tool you value, Elixir's success typing and runtime assertions might feel inadequate.

- Pattern matching requires discipline to not create heinous coupling. Pattern matching is wonderfully convenient for control flow and helps a ton with readability and avoiding deep nesting in complex situations. It's so convenient, though, that it invites reaching through abstractions into data structures in ways that make code brittle. The language doesn't really provide any guards against this, so it requires care and policing to keep things manageable.

- Because OTP is so powerful, it's tempting to avoid industry standard tooling and "just do it in Elixir." This is great for moving fast, but has the risk of pushing problems down to the line to the point that bigger system rework might be necessary. Background processing is a good example here. In Elixir/OTP it's easy to do everything in memory, but once you start needing failover guarantees, or need split out worker processes from a web server for independent resource utilization, you may end up getting rid of the initial implementation and doing the work to move over to a setup similar to what you might using for Ruby or Node anyway.

Learning to be productive in Elixir isn't really a huge investment, even for someone with a strict OO background. It's pretty light conceptually compared to other FP languages, can be written in an imperative-ish style if needed, and has clear, simple patterns for code organization. For every place you would consider mutating, you tend to find primitives that make working with immutable data structures quite convenient.

I've been playing around with Elixir and rewrote a small Rails app in Phoenix to get used to it. In the end, the benefits are not big enough to make the switch

Pros:

- Less magic. It's a lot easier to figure out what's going on under the hood. - Phoenix is an improved Rails. Ecto is more flexible, the generators make more sense and everything is better organized. - FP leads to cleaner code. The difference to a neatly organized Rails (with POROs & service objects) is not big though. - Tooling/Mix is excellent. - Elixirforum is a great place full of helpful people.

Cons:

- Small ecosystem and lower productivity. I often had to spend 1-2 days to write a feature where with Rails I'd download a gem and it's done. - Elixir gets hyped up due to BEAM, OTP, stability, fault tolerance... - however, apart from some very niche cases most of its features can be replicated with background queues, Kubernetes, etc. - Speed & hosting costs. Elixir is a bit faster than Ruby and the footprint is smaller. But a powerful VPS + CDN is so cheap nowadays that it doesn't matter much at my scale. - It's an absolute niche language. There aren't many tutorials, SO answers or solutions for small problems - you often have to figure it out on your own.

Overall I'd say that Elixir is fun to work with and ist well thought-through. At the end of the day I only care about shipping products though. Writing my admin backend in clean FP code is nice, but I rather download a gem like Administrate and be done with it - so I have more time to focus on my core features.

From a business perspective I don't see many cases for Elixir: A small shop is more productive with Rails/JS/Python due to the vast ecosystems - and a bigger company will have trouble finding enough devs.

You'll notice that people who praise Elixir compare it to minority web technologies (Ruby, Python) or ones that are documented for various issues (Javascript).

Absent from these comparisons are the elephants in the web world: the JVM and .net. The JVM in particular is superior in my experience to Elixir in all respects: statically typed languages, battle tested servers and libraries, abundant documentation and discussions, top of the line performance, excellent tooling allowing rapid refactoring and evolutivity, etc...

critical idk. But i can answer your points against.

What if you did not have to choose ? It gives you all of that. There is no "steep learning curve". I had a sysadmin that never did anything functional pushing code to prod in less than a week. This is not a single case. This is the widely reported result across companies switching to elixir.

Regarding rigidity: quite the contrary. In my experience elixir and its take on FP are faaaaar less rigid than an oop one.

I am not going to bad talk any of the languages you offered. I will simply say that i disagree with basically every single one of the characteristics you offer for them.

Regarding how much productive... Well the most extreme example is whatsapp doing it all with 8 backend engineers. All of whatsapp. Recently RocketMortgage had equivalent results. In the case of rocketmortgage, it was wihtout any prior experience in the ecosystem. This was for Erlang, but all the companies using elixir report equivalent results. PagerDuty and Bleacher Report are probably the most visible one.

So in the end... do what work for you ? I do think you are missing the point a bit with your argument, which is what i will fight. But if other languages work for you, great for you :)

> I will simply say that i disagree with basically every single one of the characteristics you offer for them.

I am confused by this response. You disagree with remarks like go being faster than python?

no i disagree with go being good at concurrency and being good for web stuff for the go example. It is one of the worse experience i know. It is like trying to use C to do it.

> doing it all with 8 backend engineers

Wait, what? Whatsapp had 25 backend engineers in 2016, and they use almost exclusively Erlang, not Elixir. They’ve said many times that the Erlang platform has allowed them to do a lot with a small team, but let’s not turn their story into an urban legend...

Source: https://www.youtube.com/watch?v=87lW4Llsj7E (2:20)

I'm in the weird position of being too angry about Elixir to make a "meaningful" criticism of it any more.

I'd love to contribute, but I don't know how to phrase anything other than a useless rant.

And I would love for the contribution to boil down to anything else than:

> life without a static type checker is hard when you're writing a server. That needs to stay, like, on.

Which is, arguably, not necessarily a jab at Elixir itself.

Sorry.

If you can somehow add typing to Elixir, I'm sure the community will accept it happily. Though it needs to be compatible with the Erlang ecosystem.

But if you're angry at a programming language, you probably need a holiday :-)

Okay, so is "after using elixir for too long, I really need a holiday" a more contrasted version than the hype ;) ?

curious, why are you angry? Since I've adopted Elixir where I work, I'd like to know so that I can avoid those mistakes.

This post is worth reading:

https://ferd.ca/ten-years-of-erlang.html

Is Groovy really a contender?

It is a decent language, but it's development sucks. Maybe I'm missing something. I use it for Jenkins pipelines and it does not even has an editor with code completion. I must run it through an interpreter to find simple syntax errors, like a missing parenthesis. Looks like I'm developing in the 80's.

I am 99% sure intellij idea has syntax validation and autocomplete for groovy.

It does, but it highlights many things as issues which compile just fine.

The Groovy compiler feels like a half-baked product, just as the language. It cannot decide if it wants to be a statically typed language or a dynamic one.

It happens all too often that I have to manually cast stuff because the compiler cannot deduct the type of an expression. Seriously, it feels like writing Java pre-1.5 (before Generics).

At the same time, your code might just compile, and you'd get a runtime error because you forgot to rename an attribute that you referenced, and due to some dynamic wizardry Groovy tries to retrieve it anyway.

It is the very opposite of the Erlang universe, where the more time I spent the more impressed I got. So really no comparison between the two, forget Groovy if you have more than a toy project. Java on the other hand... will soon have it's fibers thanks to Project Loom...

> your code might just compile, and you'd get a runtime error because you forgot to rename an attribute

The eclipse plugin has a pretty good approach in that it underlines things that cannot be deterministically type checked (that is: it can't prove they are wrong, but it can't prove they are right). It does a fair bit of type inference, so once you get used to that it's reasonably low amount of pain that comes from this type of problem.

> I use it for Jenkins pipelines and it does not even has an editor with code completion. I must run it through an interpreter to find simple syntax errors, like a missing parenthesis

It's sad that so many people form their perception of Groovy from what they encounter inside Jenkins.

I do full application development with it inside Eclipse and it is fantastic. None of the above applies. It's basically the same as developing in Java just 30% of the code size.

One piece of advice: go for Erlang, not Elixir. The syntax is much nicer, and you get a really mature environment. Also, 90% of Elixir is Erlang anyway.

I don't know too much about Elixir, but for implementing web services just use the tech you know the best - these days you should be able to scale almost indefinitely regardless of the stack you choose.

But if you have a problem that resembles a telephone exchange (eg. no UI, lots of concurrent IO intensive - but not CPU intensive - tasks that have soft-realtime requirements) give Erlang a chance. Even if you end up using some other technology it will really influence your professional development in a good way.

Elixir is much better in the respect that it makes it easy to do the right thing. Code organization, documentation, https, unit testing, even deployment, live reload when web developing, all work out of the box in elixir/phoenix in ways that aren't as convenient or pretty in erlang. Elixir in many ways adds cheddar to the broccoli to get the kids to eat it.

can elixir compete with the seven other programming languages you named?

It can and it has, for several years now.