Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

Interesting to see someone work in Haskell professionally. Jobs in Haskell don't seem be plenty atleast in my area. Could I know what do you work on, and what was the process of obtaining a job there?

Do day jobs in Haskell actually exist? Are you working in academia?

You will enjoy OTP and Beam, But you will miss Ruby plug-ins.

What is ‘meeh’?

Interesting, some of the libraries you mention such as graphql and http, I feel there aren't better libs that exist than absinthe and ranch/cowboy.

Which graphql library do you prefer over absinthe in other ecosystems?

Nice points indeed!

I would also say that the "library" one is basically valid for every language. In general is always a good thing to spend some time analyzing the possibilities before importing an external lib into your application.

What you said about releases is somewhat true, but I’d like to clarify.

It has absolutely changed a decent amount over the last few years. Because it used to suck. It’s not really in flux, more like being improved because everyone knew it sucked. It’s in a much better state now and I’m very happy with it where I wasn’t before.

Also, I would say that “in flux” isn’t a proper characterization because it was always backwards compatible. Nothing broke, they just improved the experience through better methods.

I literally have a Simpsons-Mendoza meme printed out on my desk, except instead of "MENDOZAAAAAA", McBain is screaming "DIALYZEEEEER".

What a god-awful piece of software.

If you're aching for typespecs in Elixir being useful, but are dissapointed with Dialyzer, I recommend checking out my library Hammox: https://github.com/msz/hammox. It's an improved version of Mox, the de-facto mocking library for Elixir, which you can use to automatically assert in tests that your mock calls, or any function calls, fit your typespecs.

I personally found that with rigorous enough usage, I don't even miss having actual static typing anymore ;)

this. I had piloted a project in Elixir a few years ago. It wasn't until I really learned Erlang that it became a pleasant experience. In the end it was replaced by another team in another language.

> If you invest time learning Erlang everything around Elixir will make sense

But this seems like a big issue to me. It probably makes the learning curve high if u basically need to learn 2 languages.

How do you deal with deployments and not losing things you could otherwise persist in Redis or Memcached? Of is your application stateless in that way?

Getting hang of functional programming takes time. Writing code elixir way requires unlearning what you have learning from imperative languages.

My biggest hurdle was being too impatient to learn how to code with immutable data. I banged my head on the desk for two days to get through what I felt was a trivial problem (something with updating files in S3), which I eventually rewrote in python in less than an hour.

Immutability (and the resulting maintainability and predictability) is really appealing to me, though. When I try it again, I think I'll focus on educating myself around the language upfront and not just learning as I go.

Everything else about the language, Phoenix, and the tooling was really nice.

For the same reasons as others have said, I would not pick Elixir for a business, though.

To answer your question, yes. My background is also primarily in Python (after brief flirtations with other languages during and shortly after college). When trying to learn Elixir (or Scheme, for that matter), my primary hurdle has been thinking in terms of idiomatic Elixir. The struggles aren’t with understanding the syntax (even for Scheme) but rather with understanding the typical patterns used such that I can start a project from scratch without heavy reliance on tutorial materials.

In other phrasing, I’ve quickly mastered the “draw three thin ovals” portion but am now stuck at “draw the rest of the phoenix”. Speaking of Phoenix, I also agree about “mix phx.gen” to be more magical than what I’m used to.

I would also prefer having a typed language over the fail fast in production approach.

Especially if your code does not saturate a single CPU core.

Answer is always no. Erlang is not better than Elixir. Elixir is not better than Erlang.

55 / 2.62 (millions of seconds in a month) ~= 20reqs / second

That's not very impressive, you could achieve that easily on something deemed "slow" like Django or RoR

But I guess your load is not constant. How many reqs/sec can it handle in the peak time?

Running 75 million jobs a year would be totally fine. Depending on the configuration and load Oban easily runs thousands of jobs a second, and 75 million breaks down to less than 3 a second.

I’d argue it’s worth the switch, but I’m highly biased!

I write very few fragments and many more raw queries. No ORM is worth the trouble of going too deep into the rabbit hole of learning for the nth time how to write SQL in X.

    EctoCars.Car 
    |> EctoCars.Car.with_color("blue") 
    |> EctoCars.Car.with_transmission("automatic") 
    |> EctoCars.Car.with_engine_horse_power(200) 
    |> EctoCars.Repo.all()

    SELECT c0."id", c0."color", c0."vin_number", c0."specification_id"
    FROM "cars" AS c0
    LEFT OUTER JOIN "specifications" AS s1 ON c0."specification_id" = s1."id"
    LEFT OUTER JOIN "transmissions" AS t2 ON s1."transmission_id" = t2."id"
    LEFT OUTER JOIN "engines" AS e3 ON s1."engine_id" = e3."id" 
    WHERE (c0."color" = $1) AND (t2."type" = $2) AND (e3."horse_power" > $3)

That sounds like a fun but challenging project: Convert sql to idomatic ecto. Mostly as a way to help people learn ecto better. Probably a long-tail-y issue, but maybe one where a 70% solution is useful?

> Specially now we are using all the hotwire stuff.

Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view?

I do agree that some of the "you don't need redis" and similar are overblown (particularly claims about tasks replacing background jobs), but I think there is truth to these claims in the following sense: Particularly in Rails, Redis gets used not just as a tool, but also to manage shortcomings in the language / runtime. Eg: Hotwire. Ruby doesn't have a good way to concurrently manage stateful connections, so it has to fallback to Redis. Ruby doesn't have a good way to manage inter-process or inter-node communication, so once again Redis steps in to fill that gap.

There's nothing wrong with using Redis, it's a fantastic tool. Using it as a state holder for an event loop through ends up feeling extremely convoluted after you've written a few GenServers (Phoenix channels / liveview).

> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented

Can you give some examples here. This may have been true in the past, but isn't true anymore. I can give an example where ruby is lacking: Performant HTTP libraries, Elixir and Erlang are so good in this space, look at `finch`, `httpoison` etc,. there is first class support for HTTP2 and connection pooling / persistent connections which is very hard to find in ruby.

> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.

Which plugin are you referring to? Is it using dialyzer? Using dialyzer gives you so much static analysis for free as opposed to the default ruby vscode plugin. I have never heard of complaints about tooling. On the other hand, I know lots of developers who love the tooling, mix is great, iex gives you documentation with just `h String`. Plus with language server support, you have really good IDE support in vscode and vim. Look at the number of stars on the `ElixirLS` plugin here: https://marketplace.visualstudio.com/search?term=elixir&targ...

> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc.

Yes, you'll lose data in your cache. Caches are supposed to be ephemeral, not everyone needs their caches to be persisted. However, if your use case requires persistence, you have a lot more options than just sticking it in redis. Plus, `oban` is a high quality background processor with persistence, without the need for adding redis to your stack.

For applications where performance matters, Elixir and Erlang give you lots of tools to build a truly performant app, However, if you don't need those tools, you might be better off building it in something more familiar.

In addition to that, I struggled to find a well maintained library similarly to Devise. Also, many people won’t agree to me, but Ecto is also a kind of pain. I think Phoenix would have been in a better position if there were libraries like ActiveRecord and Devise.

Erlang and Elixir ecosystem has a bunch of unmaintained throw-away projects.

I wrote a bunch of Erlang and Elixir tooling before I realized the most useful projects were thrown over the wall FOSS codebases.

If it's stupid and it works, it's not stupid. Fashionable is for runway models.

> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.

I am using VSCode too and the experience is not as good as with Typescript/Javascript but is not that terrible either. I would compare it with Rust's experience, so far.

> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job.

Of course you need _other_ libraries to achieve some of those things. You do not have a queue built it but there are some very good tools like Oban https://github.com/sorentwo/oban that are basically doing what Sidekiq does, just relying on the main database you are already using. There are also very good libraries for caching that rely on ETS and that simply replaces what you could do with Redis.

> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...

This is partially true. The ability of BEAM to cluster and execute processes inside the cluster, internal communication between actors and so on are not _just_ achievable with k8s, not without a good added complexity.

I strongly disagree with your generalisation regarding the tooling: Mix and Hex are without any doubt some of the most pleasant tools I have ever used. (I personally don't care about IDEs so can't comment on the lsp implementation or idea plugins)

It astounds me how much I hear about the “VSCode extension uses all my CPU” thing.

Yes, the extension uses a ton of CPU for 15 minutes the first time you set it up. It’s building a giant database for type information to give you type checking and hints.

It does this ONE TIME when you first set it up. It explains this. It’s really not a big deal. I’ve found the extension to be great, I’m not really sure what you are referring to there.

I am bummed out to see that this is the top comment. I don't doubt your experiences but I hope that other people do not latch on to this and use it as a strong argument against using Elixir. All of these complaints are skin deep and kinda petty, to be honest.

> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains.

This is a bizarre criticism of Elxir the language. There are a lot of developers out there who prefer a more lightweight editor and do not want the bells, whistles and crutches of a heavy duty environment. I would never complain about a language just because an IDE does not exist for it.

Tooling in Elixir is really some of the best I have ever used as far as the consistency had with mix, hex, hexdocs, etc...

> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier.

You can still use all the same battle tested tools with Elixir... but it is true that there are lots of situations where those things are genuinely not needed thanks to some of the things that come out of the box on BEAM.

"There is no IDE from jetbrains" Is that now a thing that is important? I've only just started using an IDE from them - and I don't see how it's miles better than say vscode?

This whole thing sounds very much "ruby good, elixir bad"

> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...

Yeah, last time I tried to get a hang in Erlang I felt it was trying to solve stuff that is already being solved by my infrastructure in a language agnostic way.

Rails is awesome nothing comes close to being as fun and productive. Tried php and django, not bad but not Rails.

Can you name a few of the libraries you didn't find?

"Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job... Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so..."

I used Erlang for 5-6 years in a production environment in a deployment that wasn't the world's biggest, but did seriously need clustering because we needed more than one machine to handle the load, not just redundancy. This comment leads to my core observation about the entire ecosystem for anyone considering using anything in the Erlang ecosystem.

Erlang started in the late 1990s. Joe Armstrong was brilliant, and I would imagine was also surrounded by some other very smart people whose names I do not know. Despite what I'm about to say, let nothing I say be construed as disrespect for either the language or the people making it.

Let me set some context here. C++ ruled the day, and still looked to inevitably replace all C. Python, Perl, and the entire dynamic scripting language category had just been invented. Java was in the news, but not on your computer yet. Haskell... pre-monadic IO... had just been standardized somewhere in here. Threading was possible but was every bit the nightmare it has been presented as, and you had to be careful spawning more than single-digit threads because of the resource consumption. Open source was just beginning to be A Thing... that is, it had existed in its embryonic form for decades, of course, but it was just beginning to cohere into the Linux world we know now. Machines were still measured in the hundreds of megahertz and the single-digit megabytes of RAM.

Erlang was a far more radical departure from anything else in this era than it is today. There was a lot of academic work on this stuff, and there was a lot of very specialized high-end work on multiprocessing, but it wasn't being done by "mere mortals" and it wasn't very simple. Erlang's designers looked out into the world, and what they saw was a huge jungle, where what maps we had had huge regions that just said "Here There Be Dragons". And they started in, hacking and slashing and slicing their way through, guided by a few intuitions and a whole lot of engineering firepower.

And they largely succeeded in creating a settlement in the wilderness. They grew and managed to pave over the hack & slash paths into roads, built a community, built a pretty incredible VM, built an ecosystem around them. Let this accomplishment not be underestimated; this is a land that had eaten many others in that era.

However, sitting here in 2021, this is no longer a wilderness. Much of the area has been razed, highways driven through it, McDonald's by every exit, and millions of people living here in various bustling metropolises.

And I think what we've found is that where Erlang plopped itself down is OK... but not more than that.

As a consequence of its isolation, Erlang bundles a lot of things into itself that just didn't exist back in the day. It bundles in messaging passing and a network-aware message bus, almost literally decades before anyone else even thought of a "message bus" as a distinct product segment. (i.e., they existed, you could find academic discussion and some early passes at it, but it wasn't really a distinct category yet.) It has a threading environment. It has these "supervision trees" idea which are cool. It has immutability at a time where Haskell was even crazier than it is now. It has a mechanisms for bundling and distributing applications....

    [thing, [_, _, {something, X, [Y, _, Z]}]]

ah, well, another ruby or python enthusiast trying to avoid other models of concurrency at all costs

I worked on an elixir project at a ruby shop for about a year. We had complex distributed system, and were replacing core ruby services with elixir. Ultimately the project was a failure, and was re-re-written in Ruby, and the Elixir devs were let go.

We faced similar issues to you, bad tooling, weak libraries, and very few knowledgeable devs.

Finding people to hack on elixir was extremely difficult, and likely the driving force that killed the project. Having an inexperienced team who had no experience with many of the language features elixir offered created a very difficult to work in code base.

This killed productivity, so management threw resources at it. Code quality dropped further when we were no longer just a group of noobs interesting in hacking on elixir, and became a group of noobs begrudgingly hacking on elixir.

I feel pretty scared from the experience, and wouldn't be interested in using elixir professionally again. Which is a shame, it can be a nice language to write, and some of its tooling like hex is quite nice.

> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...

For what is worth, that's one of the reasons why Elixir exists in the first place. I find the Erlang VM a fantastic platform and there is no reason to restrict it to high availability/distributed scenarios. Elixir developers should be productive and write performant and maintainable applications, even if at the end of the day they are just pushing to Heroku. Especially if you are coming from another dynamic language, such as JS/Ruby/Python.

As I like to say, in the "worst" case scenario, you can use Elixir as you would any other language, and that's completely fine!

If you want/need to go deeper, the abstractions are there to do so, and that's the difference compared to K8s: it is happening one layer inside. The high-level principles of redundancy and availability exist at the library level, so you can look at your connection pool, message queue, http clients, and find the same ideas there. Another area where K8s directly complements Erlang is in helping establish clusters. Overall, they are rather working together rather than stepping on each other toes. I wrote more about this here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...

Rails is very productive but it has problems of its own. Many companies move away from Rails once they reach certain growth milestones.

Erlang (and by extension Elixir) is a concurrent language. You use it when you have non-trivial concurrency challenges. When tackling the right problems, the language shines.

Implementing a simple CRUD application with Elixir is overkill, because you can make your servers stateless and delegate most of the concurrency problems to the database.

> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.

That's my main blocker, proper JetBrains IDE support just makes everything so much easier. I need a debugger.

I tried the plug-in, and kudos to the author but it did not work for me. In the end they're only one person so of course they could not test every single configuration

-

I wonder why JetBrains has not put their weight behind it.

oh boy. where to begin

> We built a few services

So you never really committed to it in the first place. Also, this complicates the deployment problem.

> after a few years some of the original people that introduced it left the company

Probably left for a company that actually committed to Elixir. :P

> and it became very difficult to hire for

In a world where everyone is remote and where 10 Elixir people apply to every job, this product must have been pretty unappealing

> New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elixir.

"We didn't want to pay employees their worth and instead bitched about what we couldn't get without hiring those employees"

(Why couldn't you hire an assortment? One experienced guy and a couple noobs?)

> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented

Alright, fine. Sometimes you have to "roll your own" in this space, still.

> Tooling is just terrible. The VSCode plugin is crap

You should not use the word "tooling" here because VSCode is not an IDE, Elixir should not require an IDE, and moreover, Elixir should not be judged because "there is no good IDE for Elixir". "Tooling" should refer to the support libs and tools that ship with the language, all of which are excellent.

> At that point you're just reinventing your crappy undocumented and untested version of delayed_job.

Spotted the guy who never heard of Oban https://github.com/sorentwo/oban Benefit of the doubt: Perhaps it didn't exist yet.

> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS

This is entirely missing the point. If a bug or runtime error crashes your Ruby interpreter, you better have another one ready to go from a pool (because Rails stacks can take a while to load), and then you better not exhaust that pool! If such an error crashes Elixir, it just restarts the process, which only takes a millisecond because forking an immutable language's state is trivial compared to a mutable language's state.

> Liveview

I actually haven't played with it much yet so can't comment

> In the end, we are back to Rails and much happier

"We can underpay cheap devs again"

You also repurchased entire classes of bugs that are impossible in Elixir such as: mutation bugs, monkeypatch bugs, and concurrency bugs (just forget running your test suites in parallel). Also, these are literally the hardest types of bugs to fix (nondeterministic behavior), and will likely cost you more in the long run than any differential salary you balked at (I have spent entire months debugging something in the Ruby space, you'll remember my comment once this bites you in the *** one day).

Just on the hiring point. There are three companies to my knowledge using Elixir in Toronto. I applied at two and the responses were 1. Not enough professional experience using the language. 2. Very low salary expectations on their end. Pretty bad for Toronto but especially poor for hiring in what is essentially a niche language.

Yeah, I concur. If you’re a ops infrastructure let’s people deploy whatever ever they want in a container, and you can make the devs debug the elixir specific code, then you should be ok. If t try us devs force having to understand Erlang releases, GenServer timeouts, and Ecto based macro errors onto the ops group, everyone is gonna have a bad time.

> I've never had a more challenging system to debug and keep running.

Heh, the core system I put in place at work 3 years ago and is updated daily has never gone down once. Isn't that the point of the BEAM and supervision trees?

It's different, requires to learn a new skillset, but I wouldn't call it "challenging to keep running."

Haha I'm not sure if we know each other since I know the issue you describe in this link. Regardless, I think this is a somewhat weird example since the it should not be DevOps' duty to look at and try to understand an error that stems from Ecto. And our company did face this issue, but this was largely related to the DB optimization and the Postgres instance instead of anything language-specific. If you have bad DB schemas and optimizations you're gonna face the same issue no matter in Java or Go. Saying that you've "never had a more challenging system to debug and keep running" sounds really dramatic as our Elixir apps have been running fine 99% of the time and barely even triggered any on-call incidents.

Interesting, I've had the opposite experience. I get paid a ridiculous amount for Elixir work because finding experienced Elixir devs is so difficult. Most of the job offers I get for it I avoid because I think "there's no way this company is going to last longer than a year paying that much for developers".

Looking for increased pay based on programming language used is going to lead to disappointment more often than not. The best thing that anyone can do to increase their compensation is be aligned with a business, or part of a business where they’re a profit center vs a cost center. The language itself is more about a persons preference and the things that you value as far as day to day working experience.

Why did non devs choose the language of a product ? Sounds like a strange decision. Or it was the contractor's choice with its dev team waiting for years the opportunity to try Elixir.

> They regret it now because no one at our company can work on it

> Sure someone could learn it, but we’ve got more important things to do

If they can't give you 2 or 3 days to learn a language then they don't regret it that much I guess.