To be fair, it's not really Rust's fault. The GUI story in most non-AAA languages is terrible, and in many ways, the GUI story in most AAA languages isn't always that great either, it just so happens that there's one really good solution so people can generally live with that, but there isn't necessarily any "choice".
The problem is that GUIs tend to be written in very sophisticated and complicated C or C++, and the further your idioms/semantics/runtime deviates from that, the harder the binding gets. This is a solvable problem, except that a good GUI is also one of the most staggeringly enormous and complicated things you might want to bind to, such that simply doing a basic mapping of types is an overwhelming project for just one person, let alone getting any functionality going. This complexity also means that your idioms/semantics/runtime don't have to deviate very far at all before the pain is felt in dozens of classes; even something like Python designed to be similar to C for binding purposes requires substantial effort to bind to a GUI, and then substantial maintenance to maintain the binding over time. Then the sheer overwhelming complexity also, in my experience, means that even with binding libraries generally considered to be pretty good, it is fantastically easy to step off the blazed trails and straight into segfaults in languages that aren't supposed to be capable of such things.
Also people tend to be very picky about GUIs (without any comment intended on whether that's a good thing). As soon as you add a requirement like "cross-platform" you narrow the already-thin field down, and goodness help you if you insist on "cross-platform native interaction" or something.
I've seen several language communities float the idea of creating their own widget sets natively, but the scope of the project appears to sit somewhere between "create a new browser" and "create a new office suite", if you want a good one that can be legitimately used as a selling point for the language and is competition for QT or Gtk or native Android or whathaveyou, and not merely something that worked on some guy's Linux box once.
(I've also found that people tend to underestimate the difficulty of creating a new widget library. My suggestion, before anyone suggests how easy it could be, is to sit down and read the full GTK or QT documentation first. Then you can go tell me about things like http://www.fltk.org/ , and I'll observe that yes, that would be much easier to bind, but every time I've seen it suggested someone always almost immediately finds some reason it isn't good enough for them. And my conversations about this tended to predate mobile as an issue... Using something like FLTK requires you to think more like a browser developer back when Javascript wasn't much of a thing, and to bend your app around what it can do, rather than bending the GUI around what you want.)
True, true comments.
For me at least, it's generally nice to find some toolkit in the language you're working in if you want to ease integration and usage (which is why I mentioned Servo and Piston). I've considered writing a GUI library, but even a simple one in Rust is alot of work. As the community grows and the language matures, I expect more people will take on filling in the gaps, so it's only a matter of time before something that suits my needs arises.
The problem is that GUIs tend to be written in very sophisticated and complicated C or C++, and the further your idioms/semantics/runtime deviates from that, the harder the binding gets. This is a solvable problem, except that a good GUI is also one of the most staggeringly enormous and complicated things you might want to bind to, such that simply doing a basic mapping of types is an overwhelming project for just one person, let alone getting any functionality going. This complexity also means that your idioms/semantics/runtime don't have to deviate very far at all before the pain is felt in dozens of classes; even something like Python designed to be similar to C for binding purposes requires substantial effort to bind to a GUI, and then substantial maintenance to maintain the binding over time. Then the sheer overwhelming complexity also, in my experience, means that even with binding libraries generally considered to be pretty good, it is fantastically easy to step off the blazed trails and straight into segfaults in languages that aren't supposed to be capable of such things.
Also people tend to be very picky about GUIs (without any comment intended on whether that's a good thing). As soon as you add a requirement like "cross-platform" you narrow the already-thin field down, and goodness help you if you insist on "cross-platform native interaction" or something.
I've seen several language communities float the idea of creating their own widget sets natively, but the scope of the project appears to sit somewhere between "create a new browser" and "create a new office suite", if you want a good one that can be legitimately used as a selling point for the language and is competition for QT or Gtk or native Android or whathaveyou, and not merely something that worked on some guy's Linux box once.
(I've also found that people tend to underestimate the difficulty of creating a new widget library. My suggestion, before anyone suggests how easy it could be, is to sit down and read the full GTK or QT documentation first. Then you can go tell me about things like http://www.fltk.org/ , and I'll observe that yes, that would be much easier to bind, but every time I've seen it suggested someone always almost immediately finds some reason it isn't good enough for them. And my conversations about this tended to predate mobile as an issue... Using something like FLTK requires you to think more like a browser developer back when Javascript wasn't much of a thing, and to bend your app around what it can do, rather than bending the GUI around what you want.)