Ask HN: What's not great about Elixir? | Hacker News Reader

Ask HN: What's not great about Elixir?

16 pointsverletx6410 comments

This isn't an attempt to bring out some great clash, but I find discussions (in the phase of the language hype cycle that Elixir is probably at anyway) centre around what the language does right, what it does well.

There's not much talk of drawbacks, but in a way I find a discussion of the tradeoffs more informative, both in a way that's more generally language agnostic, (like 'x' language feature is pretty cool, but usually carries these implications because of 'y'), but also just giving me a sense of where the language sits within the tech space.

View on HN

When it's said that Elixir is highly distributed what is sometimes left off is "within a datacenter". BEAM / Erlang / Elixir clusters are not intended to be used/scaled across datacenters due to latency issues.

So if you are an AWS user for example and want to be in multiple availability zones the Elixir distribution model will not scale and you'll have to use the same techniques and tools other languages use for distribution.

With that in mind, I think the whole distribution buzzword is way over hyped since the majority of companies will be leveraging cloud platforms like Azure, AWS, Google Cloud, etc.

I write Elixir code daily because it's an awesome language to write in and not for the distribution features.

you are not supposed to use Erlang built-in distribution in the main path in production anyway.

I only use it for management and non-critical low t-put control flow, never for the high t-put and/or data flow.

For high t-put you need to implement your own protocols over TCP or something like ZeroMQ.

Some major Erlang-based open-source projects (ejabberd, riak, RabbitMQ) use built-in distribution and that's why they usually either slow or fail under high load in production.

When doing CPU intensive tasks, Elixir can be considerably slower than the usual other languages.

I don't know why you're being downvoted. This disclaimer can be found in most Elixir books such as "Elixir in Action" and "Programming Elixir".

Some of Phoenix's best features, like presence and websockets, break the 12-factor application rules. State is stored in the app and nodes require linking together. Most container systems are not set up for this and you have to rely on something like etcd to do orchestration between nodes. That or just move the state back to redis.

I think the positives outweigh the negatives. It's nice to replace a lot of moving pieces in a RoR application with just Elixir and Phoenix.

The main thing I'm having troubles getting used to is the configuration being part of the compilation phase. In a world where so many applications are deployed in AWS and URL/ports/etc are not necessarily known at compile time it makes no sense to me.

You end up having to use tools such as Distillery and Conform in tandem just to be able to configure your app at runtime.

Another thing that worries me a bit is how such a large part of the community comes from Ruby. I wish it was a little more balanced with more diversity in regards to people's background.

Other than that, it is a great language, and I'm having a lot of fun with it :)

I think as the language grows more mainstream traction you'll see people from other languages gravitate towards Elixir instead of just people from Ruby. I do feel like an outsider as I recently moved to Elixir after doing 6 years of C#/.NET and have no Ruby experience.

Deployment can be a bit tricky to figure out. I end up compiling on my production server, which seems extremely unnecessary.

While not addressing the drawbacks per se, I enjoyed reading this in depth comparison between Elixir and Go from an internal language perspective. https://blog.codeship.com/comparing-elixir-go/

Oh those don't come out till a few years later when we figure out it was the worst thing in the world.

Reply on news.ycombinator.com