Aaron posted this on the Rust subreddit, and it kinda applies here too:
----------
Recently we've been discussing a roadmap process for the Rust project. Part of that process is setting a project agenda each year by identifying 8-10 key problems we want to try to tackle across the project, which taken together represent a major increment in Rust's evolution. The linked post lays out some preliminary thoughts on vision statements for the 2017 cycle.
Since the point here is specifically to have a community-wide discussion on the internals forum, please direct comments there rather than splitting across multiple forums!
----------
Since this is on the front page now, I will certainly be reading the replies, but if you truly want to help steer the direction of Rust, commenting on Discourse would be ideal. Thanks!
I love the idea of Rust. One of the issues holding me back from Rust is the GUI system. Unless I copy Servo or Piston, there isn't much else out there. Sad to say I've been trained to enjoy using pointers and a tree of GUI nodes than playing pass-the-word. That said, I can't help but think each developer who considers using Rust has one or two other key "nice-to-haves" (that Rust lacks) holding them back from adopting it.
> That said, I can't help but think each developer who considers using
> Rust has one or two other key "nice-to-haves"
Yeah, this is key. This is one of the reasons why the survey was so important; it revealed where the overlap is between each developer's set of things.
Assuming, of course, you want to use GTK3. Which can be acceptable for Linux applications (and even there GTK3 has a horrible UX compared to GTK2), but it's not something you'd want to use on Windows or OSX.
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.
I've been tinkering with Rust over the past few days
My main gripe (which probably falls into the 'learning curve' element) is it's very dense in syntax, and remembering all the borrowing/ownership and lifetime rules is quite tricky.
Usually when I try and learn a langauge I like to implement a few simple data structures, like a Binary Tree, but I've constantly been hitting hurdles with Rust on this one :(
Writing data structures is a trap when learning Rust; they're much harder than they are in other languages. http://cglab.ca/~abeinges/blah/too-many-lists/book/ is helpful if you want to take that approach, though!
I've been playing with rust, but for me the biggest thing is IDE. I use c++ so I can live with the compile times and learning curve, but the tools are a major stumbling block. Glad it's on their radar!
This may have changed, but, at the time of writing, rr was tied to the terminal gdb interface, which many people understandably don't like to use (i.e. not what they mean by "decent"), preferring the more direct connection to their code of a visual debugger like VS.
That said, rr is amazing and I strongly encourage people with an aversion to gdb to suffer through the text interface (if they don't have access to some visual record/replay debugger, of course).
----------
Recently we've been discussing a roadmap process for the Rust project. Part of that process is setting a project agenda each year by identifying 8-10 key problems we want to try to tackle across the project, which taken together represent a major increment in Rust's evolution. The linked post lays out some preliminary thoughts on vision statements for the 2017 cycle.
Since the point here is specifically to have a community-wide discussion on the internals forum, please direct comments there rather than splitting across multiple forums!
----------
Since this is on the front page now, I will certainly be reading the replies, but if you truly want to help steer the direction of Rust, commenting on Discourse would be ideal. Thanks!