Interview with Rustam Aliev about Erlang GUI Programming with Epona

Interview with Rustam Aliev | LinkedIn

Erlang actually has powerful GUI programming abilities with epona as we learn with Rustam Aliev.

Why did you need a gui library / framework for erlang?

It was a rainy night, with lightning flashing, thunder rumbling, and wolves howling in the misty plains. I was sitting in my man-cave testing yet another hypothesis for optimal register allocation for an obscure CPU architecture. Some of the results looked promising and I thought I might be able to publish a paper on them. Therefore, I needed a visualization tool with just the right amount of interactivity: you push a button – you get another distribution graph, and so on.

It was Erlang I was using for math. Odd choice? Not at all: it’s fast enough if you cook it right. But how to attach a GUI to it?..

wxErlang was my first and obvious choice. Well… I had some experience with wx, but the very idea of manually describing each window element seemed kind of revolting at the time – I needed a lot of elements for time series, and I needed some of them to be buttons, and some of them to be edit lines, and frames, and groups, and so on, all depending on internal values.

I wasn’t sure if I could easily build such an interface with wx. And I decided to whip up a prototype in Qt, which I know better. NIF? Nah, I was fed up with NIFs by then. So – a port? Why, let’s try it…

…One thing led to another; by the morning I had a working server in Qt, accepting commands through stdin and outputting events to stdout. It was time to test it with open_port/2 function. Which I did – achieving my first Qt GUI from an Erlang program.

It seemed surprisingly easy to build a GUI this way, declaratively & very straightforwardly. Somewhere between “a piece of cake” and “a no brainer” is easy.

I named it ‘Epona’ because I was replaying Ocarina of Time again back then.

I toyed with my new creation for a while – it worked. I tried implementing a Minesweeper clone – it worked. “Wow,” I thought, liking this approach very much over wx. All that’s left was to just wrap it up as a gen_server, because no matter how declarative you are, you’ll still need to contain some state and receive some messages from the GUI, and OTP approach is the best.

Finally, I had a binary system:

• a Qt-based server (qt5_eport), which you can compile and put into your $PATH;
• and under-1k-sloc Erlang gen_server module (the eponymous epona.erl), which you can run as a part of you process tree and just call epona:batch([gui elements]) to build a desired GUI.

Each component would do it’s job, and they communicate just fine – not unlike e.g. X windowing system in Unix.

So it goes.

Is erlang good for graphics programming?

I’d say Erlang is good for almost anything… but that would make me sound like a fanboy, right? So sticking to the truth, the answer really depends on what you consider “graphics programming”.

• if we’re talking of a static picture – sure, just use any graphics library bindings like ESDL2;
• if it’s an animated scene you want, it’s still easy because an animated picture is basically a series of still pictures. SDL, OpenGL, even Vulkan bindings are all there… The quality of those bindings is another topic though;
• and if you need GUI specifically, it’s really only different because any real-world GUI cannot be stateless.

To operate a GUI, you’ll need to control its state: all those buttons with pressed/unpressed/disabled status, edit lines with their contents, items selected in lists, ad infinitum. It is a complex task. No one loves complexity (unless it’s some puzzle videogame).

For the Epona, the trick was to correctly divide the complexity into two components: Erlang handles well one part of GUI complexity, and Qt does the other part. Each piece of technology is productive in its own way, and, working together, they achieve The Goal.

An added bonus for me was that I could stop caring about low-level details. Calling all those x:new() or y:get() or z:load() or whatnot… it’s too boring. Once you’re in the problem-solving mind frame, it’s usually not very comfortable to attend to those details. Let GUI server care about that, I say. (It doesn’t mean you cannot care for details at all – it means you have to care only when you really have to.)

So, back to the question – yes, Erlang can be proper good for this kind of task. For what it’s worth, people use Erlang to build compilers, to solve math problems, to implement game server back-ends and real-time chats – what’s so special about GUI, huh?

What kind of applications can you make in epona? Are they cross-platform?

Well, as long as the target platform has OTP and Qt5 support, you’re probably fine. I never get to test Epona on e.g. AtomVM, but I’m pretty sure AtomVM is intended to be used on hardware where you cannot run Qt anyway.

It can be ported to use Qt6 or, probably, Qt4. My guess is one wouldn’t even have to modify the Erlang part at all for that.

Elixir or LFE or any other Erlang-companion languages could be used with Epona. Basically, any language which has an open_port/2 compatible function is fine.

I had no need to support pictures (like PNG or SVG files), so Epona is unable to load those yet, but it should be pretty easily implementable. Lots of properties and event handlers are not covered too.

QtQuick/QML is out of consideration because that would be redundant. I haven’t tested it with right-to-left or hieroglyphic languages. No QPainter access. No QtOpenGL or QVulkanWindow or other fancy stuff. It’s doubtful one can use Epona for real-time application, unless stdin/stdout speed is enough.

Thereby – just a widget-based, cross platform GUI, that’s it.