eteeselink
The Elixir experience on Windows is deteriorating
Hi all,
In the last days, two things happened:
- A blog post titled “They might never tell you it’s broken” made the rounds. It’s about how even makers of popular software might not always be told something is wrong.
- I spent many hours and went through five different Erlang versions trying to run a bog-standard Phoenix app on my brand new Windows 10 box (and I’m pretty experienced with both Elixir and Windows).
If the Elixir/Erlang teams are aware of this, then please feel free to ignore this entire post. But on the off-chance that most Erlang and Elixir committers are on Mac or Linux, here’s me sharing my personal experience:
It appears to me that the Elixir setup experience has gradually deteriorated on Windows to the point that I expect newbies would simply give up. I’ve (helped) set Elixir up on a fair number of Windows boxes over the last 3 years or so, and it seems like a new hurdle is added every next time I try.
Worse, it is my impression that Windows itself is getting increasingly popular among developers again. I worry that my experiences in the last few months are an indication of what any Windows user has to go through to try out Elixir, and that this will hurt Elixir adoption.
This is just too hard. Ideally, running elixir-websetup.exe should be enough to compile and run Elixir code. It used to be, but it isn’t anymore.
To be fair, I don’t think I’m in a good position to help much with this. This post can well be read as the generic “open source user complaining about stuff he’s been given for free”. I just want to make sure that the teams involved are aware that this is going on, because it would suck if everybody thinks that Elixir works great on Windows.
In other words, I’m not sure what the solution is.
If you’re interested in more detail, here’s my experience. Feel free to skip this part, it’s just for context and not important to the core point. Much of the following is from memory, so sorry if I got some details wrong.
When I started on Elixir a few years ago, it was amazing. Get the Elixir installer, it fetches Erlang, copy&paste the magic Phoenix archive incantation and off you go. Awesome!
Then came Phoenix’s Comeonin dependency in Phoenix, which added a NIF compilation requirement, which requires Visual Studio Build Tools (a whopping 4.6gb), but OK. That’s still pretty straight forward, just some hassle. It truly sucks on small computers though, because the build tools are so enormous (4.6gb for a C++ compiler? srsly microsoft?). I wish Elixir had some way to ship NIF binaries from Hex, somehow. BUT! At least this works, and it’s pretty well documented and google-able, even though MS keeps breaking the various download links scattered across the web. This is clearly down to Microsoft making it way too hard to compile stuff for its OS (get this: getting GCC on WSL is faster than getting command-line MSVC running!). But it still impacts Elixir.
Today however, when setting up my brand new laptop, I found myself messing around with five different Erlang versions before I got the right combination of luck. I’m pretty experienced with both Elixir dev and Windows “power usage” yet it took me many hours to get our bog-standard Phoenix backend to compile.
Here’s what I did:
- Elixir websetup installs the latest Erlang. Seems fine, but running
mix local.hexexits without output and without doing anything. I can’tmix deps.getwithout it so I’m stuck. - Hmm,
elixir --versionsays that it was built on OTP 20. Maybe I need OTP 20? Let’s try that. - Nop, didn’t help. Turns out that I was running the 64-bit Erlang, which can’t run crypto code and therefore
mix local.hexcrashes without output. That Erlang bug was closed as a “can’t repro” but I’ve had this exact problem on three clean Windows boxes in the last 4 months. Should’ve taken notes the first 2 times. And I should’ve tried to get that Erlang bug reopened. Will try today. - OK so, apparently 32-bit Erlang is needed. Fine, I don’t think I’ll need 4GB of RAM anyway. Let’s try the latest, 22.1. Uninstall Elixir & Erlang, install Erlang-32bit, reinstall Elixir. Cool, compiling our backend works, run works, but now I’m getting a Postgrex error that some tuple doesn’t implement String.Chars. Some googling around suggests that maybe it’s a thing with the latest OTP. Not sure that’s the same error, but OK, let’s try.
- Ok so, remove build artifacts, uninstall elixir, uninstall erlang, get erlang 22.0, reinstall Elixir, rebuild. Nop, can’t compile! Calendar.ISO can’t be found. Right.
- Let’s try the OTP Elixir was built with then, but now in 32-bits mode, i.e. Erlang 20.3. Uninstall everything again, install everything again, great! Now it works.
Finally, now it works. Of course, IEx is still the only REPL on my box that doesn’t let me press “up” or “down” to go through the command history, but I’ve gotten used to that by now.
Just to reiterate: I’m not trying to complain about something I’ve been given for free. My company exists thanks to Elixir, so I’m deeply grateful. I think that for lack of time to contribute substantial open source back to the community, the least I can do is make sure problems are noted.
I didn’t make this a GitHub issue because I feel that it’s a more general thing, not a specific bug. Much of it might even be specific to Erlang rather than Elixir (but that doesn’t make it impact the Elixir experience any less).
Most Liked
josevalim
This is my last comment in the discussion because I don’t think I am gaining anything from this interaction.
But I want to be clear that we already put a huge amount of effort into the Windows experience every week in. We make sure all features are Windows compatible, run multiple CI environments on Windows, discuss security efforts, etc.
Elixir v1.9 included support for releases and we have written all of the integration code with Windows, spending dozens of hours in development, writing batch files, and testing all of the different integrations (WSL, console, powershell, cygwin, etc). We put more effort developing this feature on Windows than on all other platforms combined.
Have you maybe considered that improving the “Windows experience” is too much for a small team of people that is already developing and maintaining the language for multiple platforms (including Windows)?
I will gladly accept that the work we have done is not enough, but saying “if there is a real interest” or “otherwise Elixir could just drop Windows support for good” is a slap on the face while we are actively working on it. How do you think the installer came to be?!
Ironically, all Linux distributions work on their own packaging for Elixir, without zero input from the Elixir team. Recently, we even made improvements to our process based on pull requests from SUSE users.
For the Elixir team, I can say with 100% confidence that there is no “us vs them” view on Windows. It is always considered in our development and maintenance discussions. I suspect there is no separation for the Erlang team either. But it is extremely unrealistic to expect the Elixir team to address the whole Windows experience, especially when this is handled on other platforms by interested groups, without our input. Still, I have made myself available multiple times and in multiple occasions to anyone who is interested in pushing this forward. If this is not real interest in your opinion, then you should probably come to terms your expectations won’t be met.
michaelkschmidt
In case anyone finds this thread, here is a known recipe for getting Phoenix up and running on Windows:
- Install Chocolatey: Chocolatey Software | Installing Chocolatey
- Launch PowerShell as Administrator and install the packages:
choco install erlang
choco install elixir
choco install mingw
choco install nodejs
choco install postgresql
- Once this is done, open a new unprivileged PowerShell and install Phoenix:
mix local.hex
mix archive.install hex phx_new 1.4.10
From there you can follow the Phoenix Tutorial as normal (Up and Running — Phoenix v1.8.8)
If you are following the tutorial, the Postgres password can be found in the install log (C:\ProgramData\chocolatey\logs\chocolatey.log).
One final note: iex is a built in command of PowerShell as well. To use the Elixir iex, use iex.bat
To get tab completion, use
iex.bat --werl
josevalim
Unfortunately, we don’t have the knowledge required to maintain “elixir-websetup.exs”. So if someone is interested in improving the Windows experience, please do! We would really appreciate it: GitHub - elixir-lang/elixir-windows-setup: Online Elixir Installer powered by Inno Setup · GitHub
Although it is a bit frustrating that the experience got worse. Why code that worked in the past can’t just continue work? ![]()
To be clear:
- Phoenix does not depend on comeonin
- Comeonin has an algorithm (Pbkdf2) that does not have native dependencies. That’s also the algorithm we picked for the Programming Phoenix book precisely because of Windows users
Aye, this is painful indeed. Sorry to hear.
It is the first time I hear about this. So somehow the reports are not surfacing up, thanks for writing one.
I think we can at least do one action here: Ship Erlang/OTP versions in the Elixir installer that are compatible with the precompiled Elixir - this should eliminate at least part of the issue. It has the downside that Windows users will be a bit behind, but if they want to get the latest Erlang, they can always get it in other ways. Thoughts?
However, I am afraid that to use 32-bits by default, we will need to change the installer. I think the installer gives you the option to choose, but it is checked by default depending on your system settings.
Quick question: how did you install Erlang 22.0 on Windows? Did you use Erlang/OTP’s official installer?
Also, please do open up a report on Erlang/OTP about crypto.
Yes, you need to do iex --werl. There is also a USE_WERL environment variable that you can enable to always use werl. Regarding colored output, Windows still does not support ANSI escapes.
EDIT: I also want to add that both the OTP and Elixir team have CIs running on Windows, so it seems most of the issues are in the integration with the moving parts of the OS (crypto, 32vs64bits, etc).
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









