Why are there no front end languages for desktop GUIs
In a webapp, you have your separation of concerns, a backend that does backend stuff, a server that interacts with that backend and sends stuff to a given frontend, and the frontend which only really knows about and interact with the server. The backends and frontends don't need to be the same languages/stack (in fact, they mostly aren't). Why isn't this the case in the desktop world (ignoring electron), where every GUI seems to be married to it's language without any real room for a clean separation? I wish I could write something with Rust as a backend and have some equivalent of Elm or some sort make up the frontend, and have those communicate through an API like any webapp.
My take is that you're thinking like a web dev, and not like a desktop dev.
Why would you want to use 2 languages? If you use a single language, testing/debugging is waaaay easier.
There may be some places where you'd be inclined to use another language for speed, but that's where the .net ecosystem comes into play. Even then, with proper profiling, you'll usually find that you don't need to switch language.
The frontend-backend pattern is actually very common in traditional GUI programs as well. It just doesn't have a "language" associated with it, because literally all you need is some IPC mechanism for the GUI to interact with its backend. For instance, xcdroast is a pure frontend to cdrecord (now mostly replaced by wodim). See e.g. http://www.catb.org/esr/writings/taoup/html/ch11s06.html#id2...
> Why isn't this the case in the desktop world (ignoring electron), where every GUI seems to be married to it's language without any real room for a clean separation?
I think the separation is in the code itself with View classes or markup like XAML, and checked at compile time. I mean, if you didn't want the client code compiled with the backend code, why not just write a webapp in the first place? otherwise, just write your client app in another tech (gwt, qt, swing, win32) and call rust over HTTP?
A lot of non-network programs work in that way. There are many ways to implement it, from having a background process responding to calls, to spawning new process on button press.
Even if writing it all the in the same language, you could still separate the concerns - having different modules for e.g. fetching data and rendering.
Is there a particular application you are working on?
Every GUI is married to its language, regardless of whether it is a desktop or browser based application. You can 'easily' implement the backend and frontend in different languages and manage the interface through a socket, an API, DB, or MQ.