Biggest challenges in setting up a desktop Elixir development environment

Perhaps we as community need to do something to make it easier to install Elixir on the various desktops.

What do people think? What are the pain-points getting Elixir installed and an environment configured.

Is the fact that you have to install both Erlang and Elixir to have a development environment an inconvenience?

Primarily, interested in the experience on Mac, and Windows - for Linux you’ve got the choice of asdf/kerl/distro packages/erlang solutions packages so I don’t think it’s such an issue.

Anyhow, any feedback welcome.

1 Like

On macs one can use asdf as well. Brew does work for just installing “a” version. It doesn’t do version management like asdf though.


yep, asdf is actually the preferred way to install it for us.

@bryanhuntesl I think installing Erlang and Elixir to your machine is a pretty straight forward ask if you want to use Elixir, right?

The main issues I’ve seen with installation problems is not following the asdf readme. There are a couple of steps that do make a difference. Also, the order as well, installing Erlang first (with a certain OTP version), then Elixir (with a matching OTP version).

I have seen issues where mixing brew with asdf caused some pain, but was never able to duplicate and folks resolved on their own after using asdf. Once folks started using only asdf, issues went away.


I generally start each project with a Vagrantfile that sets up a VM that will reflect my production environment (Ubuntu, postgresql etc) then I am good to go. And when I screw up my development machine I can just revert the file and rebuild the VM.

I also rebuild the VM pretty much every morning. I even have a make target that deletes all the build artifacts, and the existing vagrant VM and rebuilds it all from scratch. That takes about 10-15 minutes

If you’re using asdf I think the biggest pain point is installing erlang, since it installs from source and compilation takes a good 20+ minutes. I’m sure there’s others as well, but that’s my largest pain point.


There is another problem for me - differences in versions. In ASDF you need to be aware of the version of Erlang and version of Elixir that you are using. In most cases you can use Elixir compiles with older Erlang version, but other way around can fail. That is why I started using Nix, as it makes such mismatches impossible.


I’ve thought about this before - the long compile time for Erlang on a local box. Maybe something could be done to pre-compile Erlang for consumption by an asdf plugin. The only annoyance is the fact we can’t use the same docker infrastructure we use for RPM/Deb/AMD/86 Linux. Still maybe there’s an trustworthy OSX build service somewhere.

The .tar.gz files on are precompiled. Though they are only available for major and maintenance releases, not patches.

As of OTP-23.1 (to be released soon), we will also include a prebuilt tar.gz with all releases (major, maint and patch) on github.


Only 20 minutes? That’s very nice, maybe I should try it sometimes. For comparison, I think Erlang/OTP has similar scope as OpenJDK, which will take hours to compile. I am willing to bet that nodejs is not going to be faster.

I’m using asdf (with git clone) + homebrew on macOS and it works well for me.

  • Elixir - use precompiled with specific OTP (e.g. 1.10.4-otp-23)
  • Erlang - compile… but it’s not that bad (it took 15min on my 2016 MacBook Pro 15-inch)

I found more challenges on setting up IDE/editors could be tricky (which deserves a separate thread)

  • IDE/editor may not detect asdf correctly, or versions in .tools-version automatically
  • IDE/editor may not handle elixir+erlang combo as SDK nicely (e.g. jetbrain)

Hmm that’s an interesting point - asdf doesn’t have the concept of transitive dependency at all. There are analogues to the Erlang/Elixir situation too, Java/Scala is an obvious one that comes to mind.

Ah, you are referring to the erl -> beam compilation, I was referring to the c/c++ -> native code.

Yes this is an issue - specific case :

  1. Using Visual Studio Code and Elixir language server plugin.
  2. VS Code/ELS uses whatever you’ve set as your global Erlang/Elixir via ~/.tools-version.
  3. Check out a project that needs to be compiled with an earlier or later version and has a local .tools-version.
  4. Fails to compile, VS Code/ELS uses global .tools-version, ignores project specific one.

And people are only using asdf anyway because of all the backwards/forwards compatibility issues between R16 and R20. Doesn’t seem to be an issue in Erlang from the last 2 years thank goodness.

1 Like

CircleCI offers macOS/Xcode build environments. Whether they meet your definition of “trustworthy”, I can’t speak to.

I’m happy to assist however I can in getting builds running there if needed.

1 Like

I’ve had a great experience using Windows Subsystem for Linux (WSL) and VSCode for windows development. You get all the compatibility of Linux with a smooth Windows integration.

You just run “code .” on the VM and everything after that is pretty seamless.

I’d like to use Phoenix/Elixir and Live View on Windows 10.
Nobody mentions issues with Windows.
Should that worry me, in the sense that maybe nobody uses Windows for development in Elixir? :wink:

Thanks for your input.

I use kerl to install Erlang, multiple version, and use . kerl/release/activate to activate specific version
I use kiex to use Elixir, multiple version, and use kiex use 1.9.4 to select version

I use VS Code with Elixir plugin, but auto-complete works sometimes only.

From what I can tell, there’s a decent number of users on Windows, and the Phoenix team has made fixes specific to windows (npm not supporting --prefix comes to mind). So I’d expect development on windows to work fine.

We could add support for precompiled binaries to the asdf-erlang plugin. If a precompiled version is available on we could just download it, and if not revert back to compiling Erlang manually. I know this isn’t the primary issue being discussed on this thread, but it could possibly help improve asdf-erlang support for windows.