Current state of Elixir on Windows?


#1

Just finished watching Apple’s WWDC event and once again there was no update on MBP hardware. I’m curious what the current state of Windows as a development platform for Elixir is. I’m vaguely aware that Microsoft has added some kind of Bash support, is anyone using Windows successfully for Elixir development? What works? What doesn’t work? Etc.

I’m wondering if something like a Razer Blade would work as a development machine nowadays or if I should continue relegating Windows to just be what I use for gaming.


#2

Mix and iex works fine for me. But, I’m only just messing around (nothing serious, just learning). I usually develop on linux/unix and I plan to do the same with Elixir.

As long as your programs or 3rd party libraries don’t try to reach out to *nix programs or your 3rd party libraries need to be compiled (some have *nix dependencies), you’re fine. I can’t really comment on Hex packages since I have not used it on Windows much yet. But, the standard Erlang and Elixir libraries work fine.

Also, Elixir has a nice installer on Windows that does all the work for you. And not sure if it matters to you, but if you’ve used Node.js on Windows… Elixir support is miles ahead of that. Node.js is just pure trash on Windows.

I’d really recommend installing a linux or unix OS on a virtual machine (I use VirtualBox and it’s free) and develop on that… I do that and it’s the best of both worlds (I’m a gamer too). :slight_smile:

Edit: If you’re going to use a virtual machine, be sure to try out Seamless Mode for ultimate productivity.


#3

Paging @Onor.io ! He maintains the chocolatey nuget package and may know a thing or two hundred about this topic.


#4

Sorry @gregvaughn I just saw your note.

I do development work with Elixir on Windows all the time. I can’t say that I’m doing production code but I’m not writing production code anywhere anyway.

Everything works on Windows–even without the Bash support. There was a conversation over on Slack about one thing not working under the Bash shell on Windows (which is called WSL) but apparently with a later rc build that was fixed.

I use emacs on Windows (not an issue at all) but there are several good editors on Windows with language bindings for Elixir. Using emacs with alchemist I can write my code and test it without an issue.

The main problem I’ve run into is not an Elixir issue–it’s an Erlang issue. The Erlang installer, quite correctly, follows the Windows convention of putting it’s binaries under “Program Files\erl” The space in that directory name (which is a sure sign that most of the MS Windows developers know squat about CLI’s) causes no end of problems. I know, I know–just surround it with double quotes. But then you run into issues if you need double quotes in other places on the command line.

The other main drawback of Windows is support for compilation of libraries. For example, ComeOnIn needs to compile some NIF’s for its library. This can be done with a little bit of effort but it’s nowhere near as smooth as it is with a Linux box. But if you don’t need NIF’s then it’s not a big concern.

Basically I’d say that Windows isn’t a bad place to develop Elixir apps–it’s just not as nice as LInux; even with WSL (which by the way isn’t GA just yet) it’s still a bit clumsy.


#5

I did dabble in Windows until I was getting frustrating compilation errors on libraries, which simply don’t exist on Linux. No doubt that’s my issue, in configuration or some such, but it became tiresome very quickly to try and figure out the problem.

Now, I exclusively do all my work in a VM Ubuntu installation.


#6

I’ll throw my experience in.

I use Debian personally, running Elixir and Erlang software on a fairly hefty server hosting a very large site in addition to using them in a variety of personal projects. Here I use VIM.

At work I use Windows 10 (I accepted being an experimenter with it to see what of our stuff breaks with it) with Atom to program in Elixir. The only issues I’ve had are the occasional elixir package with NIF’s or other native code do not work, so I have to find alternatives. Oh, and Windows socket handling has a 40-200ms setup time (tested in .NET as well, holy hell horrible). Might just be my local machine but I do my performance testing on linux regardless…


#7

The NIF story on Windows definitely needs some work. We’re faced with the choice of either asking someone to install the MS Visual Studio stack for the C compiler or use GNU CC. And I’m not sure about the quality of the GNU CC stuff on Windows although I’ve got no reason to question it.

I can tell you that once you get the MS VS C compiler et. al. on the machine and in the path, everything does work. At least in the case that I tried, it all compiled and worked correctly once my path was set up correctly. YMMV of course.


#8

The same is true for a cygwin or Msys2 environment, but due to their architecture they are fundamentally harder to setup when you want to use them outside of their isolated fake-posix-environment but from a MS-PowerShell or cmd.exe instead. Cygwin and MSys aren’t recognized by configure-scripts of a certain age, but TBH that does not really matter. In an elixir project I do not think that there will be such aged configure-scripts, also they won’t work in any Windows Environment either, since they are basically plain shell scripts.

Also there is the WSL available for a while now. For some reason I can’t install it on my laptop even if I am subscribed in the appropriate MS-Insider channel. But from what I have heard so far, it is much more limited than cygwin and Msys when one trys to use it from outside of bash.

But looking at the current trend, which is also supported by Microsoft, I think it will not be more than about another year, until such stuff will be easy enough and more importantly uniform enough to handle it without too much user intervention and configuring necessary. Maybe even “seamless” as we are used to it from *nix systems.

All current solutions making compilation from the command line possible involve some work to make it happen at all and a lot of work when some dependency is missing. Theres no worth in doing the setup for an enduser, just to use some program.

I’m not even sure if a server admin would be willing to do such config on a server.

At the end, what ever would be done, would be only to make developers life easier (what itself makes it worth the hassle).


#9

If you want nice shell under windows
http://cmder.net/


#10

does it give you auto-complete like werl?


#11

cmder is more or less only a tabbed GUI-Wrapper around cmd.exe and PowerShell.

In theory, you can even define different types of shells in cmder, which all boot into cmd.exe but giving you a different set of environment variables. I used it some time ago as a poor mans RVM.

Also, it should be possible to even configure it for arbitrary executables that are REPL-like. I’ve seen a co-student running a fullscreen GHCi (Haskell REPL) inside of cmder.

In general, throughout my co-students (which use windows) it is used very often to overcome the width-limitation of older windows’ cmd.exe, which had a fixed width of 80 chars.

So, if running cmd.exe in cmder and then calling werl should just work as if you had used werl in a cmd.com window. On the other hand side, by booting into (w)erl directly, it might happen, that some behaviour changes and you need to experiment which one works best.

AFAIK the reason why you need to have werl for autocomplete under windows, while it doesn’t work with erl is due to the way how cmd.exe handles input. This is also the reason why it might behave differently when directly wrapped by cmder.

Also, since we are talking about windows, I have to mention as well, that I used cmder under Win7 and I haven’t used it after upgrading to Win10, since Win10 doesn’t have the 80 char limit anymore, also I don’t use Windows for programming anymore, but for sometimes for LaTeX documents, and LaTeX compilers do a hard wrap at 80 chars anyway, regardless of system :wink:


#12

I currently have 3 bash shells (cygwin), 2 cmd.exe command prompts, and 2 powershell command prompt windows up on Windows 10 at this moment (all using solarized dark as a color scheme, all have a significantly larger width than 80 chars, so Win10 definitely seems to have fixed that). Works well, not quite as well as my home computer (linux) but quite well regardless, Windows has definitely gone further than it used to.


#13

Anyone still curious of the state of Windows, my experience is one of frustration. This type of error happens every time I try and do anything:

** (Mix) Could not compile dependency :fs,
"escript.exe "c:/Users/Mark/.mix/rebar" compile skip_deps=true
deps_dir="c:/_projects/bad_mamma_jamma/_build/dev/lib""
command failed. You can recompile this dependency with
"mix deps.compile fs", update it with "mix deps.update fs"
or clean it with "mix deps.clean fs"

Very frustrating. You just don’t get this in Linux.


#14

There are the occasional libraries that use native code, unless they are built to be multi-platform then you will have issues, regardless the language used. Speaking of, make sure to report that to their issue tracker. ^.^


#15

Elixir is influenced by Ruby, which has historically been bad on Windows, so it just makes sense :smiley:

(Kidding of course)


#16

Very much agreed. I once ran Rails on my older Win7 machine and my life was living hell after I tried to compile only 3 dependent libraries.

Does anyone know if Hex supports binary blobs separated by platform, similar to RubyGems? IMO I’d be perfectly fine if only Windows 10, macOS and several flavors of Linux are targeted.


#17

You joke, but I truly believe this is one the main reasons Ruby never broke through to become a truly mainstream language. Back in 2006, I remember reading articles suggesting it was on roughly equal par with Python, newer and smaller but growing rapidly and perhaps on course to surpass it.

Then I tried to learn web development (and RoR) over CNY vacation in 2008. It was horrible. Things kept breaking, people online told me to buy an expensive mac or setup virtual box. I went the virtual box route and then had all kinds of other problems getting my video card to work properly, set the resolution for X window, get the networking setup, etc. In the end I spent the whole 10 days not making a single site and feeling like an idiot. I didn’t come back to webdev until 2012!

At the same time, other newbies were learning python or php pretty much unhindered by those concerns and becoming competent devs with no need to learn Rails.

I see Elixir headed down the same path Ruby took and frankly, it’s a major drag on adoption when just hashing a password is a huge ordeal for Windows users, who still comprise the vast majority of developers.


#18

Uh, I dev’d on Windows with Elixir for about a year before I finally convinced my job to let me use linux full-time (I friggin hate windows, for a large variety of reasons that are not relevant here, manage to convince 2 others so far to switch to linux too interestingly!), and I had no such issues? I had no difference in my actual ‘dev’ work with elixir on windows or linux, even bcrypt and such all compiled fine (yes windows sucks for doing ‘Real Work’ on, but once you figure out how to setup your environment it is not hard, and I learned all that multiple decades ago, and as far as I can tell windows utter horror of setting up a dev environment is not related to elixir or anything else, it is just that windows is bad with it, even installing a .NET dev environment takes up ~15 gigs and takes hours as I learned recently, in comparison setting up erlang/elixir took about 10 minutes, download a couple installers (wut?) and run them, and set up atom, which I already had for other reasons).


#19

I don’t subscribe to that point of view. It’s pretty much painless setting up PHP, Java or Python on Windows. Actually in the case of several more ML-focused Python and R setups it’s easier to get set up on Windows than deal with the horrors of the less and less well supported gtk dependency chain on a Mac.

I personally have found the Windows support a bit poor for multiple popular NIFs. The password hashing library, for example, involved looking through github issues to find a solution last year. Based on the comments both there and on SO, it has clearly been a source of pain for many people.

If you can describe how to get Gigalixir working in my VSCode + powershell dev environment, I’ll do it and make a video showing others how to do the same thus making the ecosystem easier to use for future newcomers.


#20

And Elixir has the same ease as those as well, Elixir installs and runs quite fantastically on Windows (even easier I’d say considering pip and such have to be installed separately).

No clue about mac, but on linux those are generally just a single-command installs, so far far easier than even on windows.

I have not, you generally need mingw installed (or VC’s tools, which are free too), which I do (but I needed that for C/C++ work anyway so I already had it), but NIF’s are not elixir, those are external binaries, just like when you have to compile a C extension for Python, you need your C build environment set up for those too, same for Rust nif’s you will need Rust’s build environment set up too, or using Rust extensions to Python, you need rust’s build environment for that too. What you seem to be saying is that you dislike how difficult it is for ‘other’ languages dev environments to get setup, not Elixir’s, Elixir’s was blissful ease as far as windows gets.

I tend to stay away from SO as I find it fairly hostile and full of very bad information, but I’ve not seen or experienceed that. As long as you have a proper C/C++ build environment set up then it installs just fine, but that makes sense as bcrypt is a C library, not an elixir library, and you’d have the same issues compiling it as a python extension or a .NET extension or whatever else, this is entirely not an elixir thing.

Only used VSCode once (it was lacking many extensions that I really needed to get work done, not touched it since), and as for powershell, well, ew… ^.^;

(Any shell that binds a command name of ‘wget’ that is not compatible with ‘wget’ needs to burn, that was a stupid stupid stupid design decision on their part, cannot even use a ‘wget’ that exists on the $PATH that does actually work because of that, need the full path to it, which changes on different windows installs…).

But yeah, as for Gigalixir, submit a PR, from a cursory look it seems like it would actually be very simple to add support, so you should do it as you use windows and can test. :slight_smile: