[derefr]

> Erlang lives mostly in text terminals.

People (outside of Ericsson) just haven't bothered to take much advantage of Erlang's strengths. Erlang speaks network wire protocols very efficiently, so if you want graphical Erlang sessions, you just need to write Erlang applications that act as e.g. X11 clients. Which is what things like Erlang's own Observer application does, complete with the ability to use the graphics toolkit Tk. (Or, if you like, you could expose an HTTP server serving a web-app with live updates over a websocket, like https://github.com/shinyscorpion/wobserver. Or an VNC/RDP server. It's really all equivalent in the end.)

Unlike Smalltalk where the graphical capabilities are part of the local console framebuffer, Erlang's approach allows you to interact with a running Erlang node graphically irrespective of your locality to it—which is important, because, in the modern day, your software is very likely a daemon on a headless server/cloud somewhere.

[jacquesm]

After long searching I've settled on python for hardware control, number crunching and ML stuff (it's really just wrappers around C libraries and GPU kernels) and Erlang for everything else. So far no regrets. I wasn't aware of that software, thank you for the pointer!

[jfoutz]

I've never used it seriously, but the bit pattern pattern constructs look really sweet. I don't write a lot of protocol code anymore. But I remember doing parsing badly on 10-100 bytes to figure out what a message meant. Websocket stuff would get a lot of help from that syntax.

[defined]

> your software is very likely a daemon on a headless server/cloud somewhere

This is true of every Erlang system I have developed, so, I concur.

[goatlover]

Then this could work for Elixir as well, which seems to be a little more approachable for the majority of programmers.