Setting our vision for the 2017 cycle
internals.rust-lang.org
internals.rust-lang.org
----------
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!
> That said, I can't help but think each developer who considers using
> Rust has one or two other key "nice-to-haves"
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.)
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 :(
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).