Are you satisfied with Elixir or do you regret choosing Elixir?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarLint - Clean code begins in your IDE with SonarLint
  • SaaSHub - Software Alternatives and Reviews
  • Akka

    Build highly concurrent, distributed, and resilient message-driven applications on the JVM

  • oban

    💎 Robust job processing in Elixir, backed by modern PostgreSQL

    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 it.

    > 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). 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 hire 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).

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts