Live data from Hacker News

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

1–10 of 340 posts

Ask HN: Who regrets choosing Elixir?

#1
I’ve seen a few Elixir success stories posted here recently. Virtually all comments are from raving fans that have nothing but the best to say about Elixir.

As someone with primarily a Ruby / Rails background, I’m choosing a language for a new API project and considering Elixir. I’m interested in hearing some counterpoints to Elixir, especially in how a smaller ecosystem Of 3rd party libraries slowed down development.

Re: Ask HN: Who regrets choosing Elixir?

#2
I've used Elixir since 2015 and I find Elixir to be unusable for any kind of intelligent domain modelling, but that's primarily because it's dynamically typed and has no concept of real sum types, etc., not necessarily because it's any worse at this than Ruby.

Any codebase beyond fairly small will be harder and harder to work with to an unreasonable degree, in my experience, and any perceived "velocity" gained from the dynamic nature of it is paid for doubly so by the lack of safety you get beyond toy projects.

I'm only slightly more for Erlang as a choice mostly because it's simpler than Elixir and doesn't have as much obfuscation of logic added to it that Elixir does, but in reality it's also a bad choice for any bigger system. The runtime is absolutely great, but the languages on it are generally not good enough.

Re: Ask HN: Who regrets choosing Elixir?

#4
post #2

I've used Elixir since 2015 and I find Elixir to be unusable for any kind of intelligent domain modelling, but that's primarily because it's dynamically typed and has no concept of real sum types, etc., not necessarily because it's any worse at this than Ruby. Any codebase beyond fairly small will be harder and harder to work with to an unreasonable degree, in my experience, and any perceived "velocity" gained from t…

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking, but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages[2] don't reduce this burden much: there isn't an alternative to thorough testing.

[1] This looks fine to me? https://elixir-lang.org/getting-started/typespecs-and-behavi...

[2] I have limited experience with Haskell, but my impression is that the type capabilities do actually allow you to forego testing in a lot of cases. The next best static type system I've used is C#'s, which I used professionally for years, and in C# I think automated testing is still very necessary.

EDIT: I regret even talking about type checking here--that's not my point. My point is that for modeling domains, Elixir's type system is totally adequate. I'll agree that Elixir's type checking could be better, but that's not what the comment I was responding to said.

Re: Ask HN: Who regrets choosing Elixir?

#5
post #3

One counter point to elixir is that there's a significant learning wall to onboard new developers, more so than simpler a language like Go or Python.

I'm not a genius, but I found the opposite to be true. Go and Python seem non-intuitive to me, whereas Elixir felt natural and easy to grok.

Re: Ask HN: Who regrets choosing Elixir?

#7
I've done a fair bit of both Ruby and Elixir. My impression is that Elixir leaves a lot of the legacy cruft behind, and it has a much smaller language feature set (which is IMO big bonus). The language is pretty easy to grasp quickly as a result. There isn't much in the way of quirky syntax or backward compatibility weirdness.

Probably the biggest advantage of Elixir over Ruby is the runtime. The Erlang VM has proper concurrency, and it provides really nice primitives for working with it.

The ways in which Elixir sucks tend to be the same as Ruby: dynamic types, somewhat slow runtime (compared to C, Java, Rust, Go, etc). I'd also add that library support is still a bit weak with Elixir, but it's always getting better.

Re: Ask HN: Who regrets choosing Elixir?

#8
post #5
post #3

One counter point to elixir is that there's a significant learning wall to onboard new developers, more so than simpler a language like Go or Python.

I'm not a genius, but I found the opposite to be true. Go and Python seem non-intuitive to me, whereas Elixir felt natural and easy to grok.

I feel there are dimensions to "ease" and Go and Elixir went different directions on them. Go is very "simple" in that you can look at it and generally easily understand what it's doing.

Elixir and its ilk tends to make it easy to do what you want to do.

In Go you have to re-write things over and over because the abstractions are low, but they're easy to do. In Elixir you can use the built in libs/abstractions, but you have have no idea how they work.

This is a gross simplification of both sides of course, but I often see Go-people arguing a different point than their counterpoint in is trying to make.

Re: Ask HN: Who regrets choosing Elixir?

#9
post #5
post #3

One counter point to elixir is that there's a significant learning wall to onboard new developers, more so than simpler a language like Go or Python.

I'm not a genius, but I found the opposite to be true. Go and Python seem non-intuitive to me, whereas Elixir felt natural and easy to grok.

Because of it's magic.

Debugging it it a nightmare especially when you have to roll up your sleeves and go into Erlang.

Re: Ask HN: Who regrets choosing Elixir?

#10
post #2

I've used Elixir since 2015 and I find Elixir to be unusable for any kind of intelligent domain modelling, but that's primarily because it's dynamically typed and has no concept of real sum types, etc., not necessarily because it's any worse at this than Ruby. Any codebase beyond fairly small will be harder and harder to work with to an unreasonable degree, in my experience, and any perceived "velocity" gained from t…

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…

> They lack static type checking, but I find that a thorough test suite catches most type errors anyway.

Maybe ruby is different than python in this regard, but with python I see a lot of “assert isinstance(arg, dict)” in functions which would not be necessary with type checking.

Feeding an unexpected type into a function, and having it carry on as normal, is really scary.

Post reply on HN