Windows is a profoundly annoying development platform for non-MS languages and a fairly rare deployment target so it doesn’t really get much in the way of attention or tooling. The smoothest Erlang experience on Windows so far is running applications via Vapor (a GUI frontend for ZX), but that depends on applications being developed and packaged using ZX, and the only place that works (for now) is on unix type systems!
It also suffers from the stupid blank console window that pops up because the way that Erlang was built for Windows doesn’t let it run as a “windowed” application, and you can’t make this go away, which is stupid but cosmetic… Please fix that, Oh Mysterious Builders of the Erlang Windows Installer… but I digress…
There is a friendly guy out there somewhere who saw my Erltris videos and wants to play with the source a bit, but he is trapped on Windows. Oh noes! While I do plan to add ZX developer features to the Vapor’s interface, I haven’t gotten that far yet so the all-important ZX development cycle of [edit] -> zx runlocal -> [edit] -> zx runlocal is quite painful to get to work on Windows, which basically means that tinkering in a cloned git repo is a no-go.
There is a way to tinker on the source code of a ZX-based project within Windows, but it is a bit hacky and silly-feeling at the moment, and not at all obvious if you don’t know how ZX works internally. I made a video about exactly how to do this for the benefit of our aspiring Erlang GUI programmer and typically if one person contacts me with an issue a dozen other people have already had the same issue, shrugged and moved on, so here it is:
The TL;DW high points, by the numbers:
- Install Erlang for Windows
- Install ZX/Vapor using the “InstallVapor.msi” installer
- The installation lives at
C:\Users\[username]\AppData\Local\zomp\ - Click the “Vapor” icon to run Vapor (the first time takes a bit to source and build everything)
- Click whatever program you want to run from the menu (in this case Erltris)
- Close Erltris
- Source path:
C:\Users\[username]\AppData\Local\zomp\lib\otpr\erltris\[version]\src\
Edited sources in that directory should be re-built if you run the program again (if not you can build them again yourself).
This is not a perfect solution — not by a mile — but it is at least possible to navigate the code structure and tinker with things manually if you know where to find the sources. I will eventually add developer features to Vapor but I’m not that far yet. Ideally I’ll be able to add GUI versions of zx runlocal, zx rundir, zx package, zx verup, and zx create project — then this issue will go away!
…but srsly bro, install a Linux partition (or become a Mac fa…, um, Mac “fan”), it just makes everything so much easier than trying to make the Windows pig fly…
You can run Erlang as a windowed app on Windows and run releases without the console window sticking around. I develop Elixir and deploy on Windows without much friction.
It is also quite painless to develop on Windows for other non-MS languages like Zig, Go, Rust, Python, Julia to name a few.
Oh? That’s not what my most recent communication with the release maintainers indicated, but maybe you know the magic way? Please enlighten me — how do I invoke erl.exe or werl.exe without a window and without running it as a windows service? As for running releases, avoiding releases is the entire point to the tool kit here, but that’s a different issue entirely.
A launch facility must be written to make non-MS languages run properly, and those launch utilities must be built to be aware of the difference between “window” and “console” mode, which the core Erlang binary distribution for Windows is not — unless something magical has happened in R24 that I was simply not informed about and the maintainers didn’t seem to be aware of. Elixir does other things and provides its own launch tooling. The differences are enough that Elixir apps assume that the only thing that will ever exist are Elixir apps and all code will be launched as Elixir apps — which is why it is not possible to use as a peer language next to Erlang and inordinately annoying to try calling from Erlang (and even calling Erlang from Elixir is pretty ugly). Erlang projects aimed at the end-user GUI experience generally have to write their own launch facilities and bundle everything themselves (Wings3D, for example).
ZX/Vapor is a 90% solution for this, but still depends on the underlying runtime, and because erl.exe is not built in window mode the annoying little blank console window will pop up. Rust also had this problem until somewhat recently (with the advent of
windows_subsystemthat has enabled the#![windows_subsystem = "windows"]pragma — until that got sorted out Rust also had this problem). In order to provide the full set of ZX developer features via the Vapor interface it is necessary to re-write all the functions ZX uses that depend on unix builtins in pure Erlang, which is certainly possible but kind of annoying and a very low priority because of how little Erlang development happens on Windows in the first place.Windows assumes that development will only ever be done in a GUI IDE and that all IDEs will cover everything anyone will ever want to do, and for someone with a background in development on a unix system where the core assumptions of the system are radically different and the shell is your “IDE”, this is a major annoyance — especially if the language you are developing for was borne of and has a runtime that itself follows along with those unix assumptions.
Another annoyance with Windows is that the core system is written in C++ and makes OOP assumptions everywhere, which does not fit with languages that don’t have objects. Mapping a C++ object library onto a functional language is a major mess (wxErlang, for example) — hence the enormous amount of effort that went into .NET, which itself is a cross-platform incompatibility block, even today, despite the existence of MONO and .NET being sorta-kinda open sourced (that is “shared source”).
So, no, not everything is rosy and simple and easy in Windows land — you are the beneficiary of someone having come along and solved these problems for you in the specific niches you program in before you ever ran into them yourself.