Speaking as someone that does a substantial amount of desktop development, I have to disagree with this point of view. Concurrency, not resiliency, is probably the bigger story of what the BEAM has to offer desktop development. This isn’t to say that resiliency is a minor concern in user facing desktop applications, but concurrency can color all the user interactions and not just the badly behaving ones.

If we look at common desktop development paradigms, meaning GUI event driven programming, we typically have some assemblage of “widgets” which sit there waiting for an interaction. The nature of the interaction can vary… so, for example, a user may check/uncheck a checkbox widget setting it, or I may set it programmatically, or either case could set it to a tertiary state. Such an action will change some internal state in the widget object itself, but also typically result in signaling other interested parts of the application that the interaction took place, perhaps along with the resulting state. The other parts of the application which received that signal may themselves change the state of the other widgets in the UI, internal state, or even programmatically change the original checkbox state, all of which can cascade into another whole set of signals and signal responses… etc. until some bottoming out condition is reached.

These widgets sitting around with independent state and independently waiting for a user interaction, and the internal state related logic of the form, again waiting for interesting signals to decide what to do, sounds an awful lot like agents sending and receiving messages. Sure an event loop looks and feels more like Pub/Sub to a GUI developer, but in the end the notion that you have some program sending messages to none or more interested other programs feels like BEAM processes sending messages to each other.

And good, well considered concurrency can very much influence the user’s experience of an application. The snappiness and responsiveness of a user interface can depend heavily on if widgets and display elements can send their signals and move on while other parts of the program process as instructed by responding to those signals: stop-the-world interactions are often times negatively felt by users. This isn’t to say you can be careless and the concurrency is a cure all: it’s a necessarily element, though not sufficient on its own.

Resiliency can be also important in a GUI, too. I work with ERP systems and the one in which I deal with that uses Qt/C++/JavaScript is a good example. I often times find end users with their desktop client open and a dozen or more independent forms open: may a couple items are up, the customer, a sales order, current stock levels, etc. They do this because they need to research, they were in the middle of task 1 and urgent task 2 came up, etc. It is conceivable, particularly when dealing with data tables in the UI for example, to take a reference to a row in the table, refresh the table (meaning all the row objects are destroyed and new ones are created), and then try to operate on the just deleted row object. In the C++ this usually crashes the application meaning that all the forms the user had open crash, including ones which might have incomplete work product or that they simply spend the time to open for whatever they were trying to accomplish: in the end it’s a pretty crappy user experience. Now, with BEAM like resilience the bigger likelihood is that the task referencing the now deleted row just finishes (no shared mutable state), but in the worst case the widget crashes, or even the form crashes, but the whole application doesn’t need to crash. Sure there are ways to fix this in Qt/C++ and ways to screw it up with the BEAM… the real question between the two is how easy and in which direction does the development environment push you?

Finally, I should caveat this saying while I think at a shallow level of analysis the BEAM seems like it would be compelling to build a desktop framework around, it’s not clear that the details support that conclusion. Maybe the way the BEAM implements scheduling or the serial nature of a single processes message passing make it inappropriate to drive the event loop, etc of such a framework. I haven’t done that analysis, but it seems like something that technically would be reasonable to investigate.

In the end I don’t think we’ll see any progress along these lines. GUI frameworks are a big lift and I just don’t see enough momentum in the community to push that direction. I don’t think the obstacles are technical or that the BEAM has nothing to offer desktop development. I think the biggest barriers are sociological and demand driven.

this seems to not have been mentioned but Wings3D is a desktop app written mostly in Erlang. See a post from 2009.

https://github.com/dgud/wings

Interestingly (maybe?) there was a PoC project that allowed one to run a QtQuick / QML gui with logic in a BEAM language. The idea was to have messages from the “business logic” in the BEAM bridged over into the QtQuick runtime, and vice versa so that bound events from the QtQuick runtime (keep in mind that changing values of bound variables are, from a mental model perspective, events themselves) could appear as messages in the BEAM code.

This bridging actually worked fairly well, with it feeling relatively “native” on both ends. It never went beyond PoC as a curiosity, but it did demonstrate the plausibility of this approach. It would mean not requiring a U/X library written in e.g. Elixir while keeping all the business logic there … with all the benefits and interesting possibilities of both worlds being available.

I do think this would provide a lot of interesting possibilities, including:

• a sharp separation of business logic from UI
• painless multi-threaded business logic for desktop apps
• painless recovery from errors in business logic (which is such a pain in desktop apps)
• a very easy pathway to network services, allowing easier integration of online services with desktop applications
• inter-application communication between apps via message passing, which could be done via local sockets or by simply tying all the desktop apps together into a local BEAM cluster. Both would require some thought as to safety (stability, security, ..), but would be within reach.

Besides having the resilience of the BEAM as wlel as the pleasure of writing functional code with an OO UI, I believe it would allow for patterns that are currently hard to achieve, such as transparent movement of application state between machines (including application code itself), interaction across the network without requiring intermediate web services (at most a reflector service, which itself could be a simple BEAM application) …

There are a lot of possibilities here. Should desktop innovation become a useful area of interest again at some point, this is one of the ideas I have sitting around waiting to be dusted off