Conrod – A Rust GUI Library

For a good GUI library, you ideally want the layout to be data driven. This means you can draw the entire tree without writing a line of code; this also implies "retained mode" (the opposite of immediate mode).

If it's not data driven, you can't write an editor for it -- or if you do, you end up with something that can write code but that has a hard time re-reading code that you've modified.

Ideally there's more inherited and inferred information, and less parameter noise. A crucial feature of any modern GUI library is the ability to auto-position all the elements, for instance: The placement by "pixel" location is an outdated practice in an age of multiple screen resolutions, aspect ratios, and densities. And getting the layout part right is much harder than getting a few widgets up.

Sorry, but as a GUI library this is not impressing me.

A handy breakthrough in my case was to use Rust's algebraic data type to store each individual widget state within a single container in the UIContext. This is akin to "caching" the state of every widget in one place with a process that is invisible to the user, rather than requiring the user to instantiate large number of objects and work out where they will store widgets, canvases, etc. This approach also makes it really simple to only access certain parts of the state depending on what is needed via Rust's pattern matching and destructuring. I'm yet to come across any kind of widget that is more difficult to store state for than it is in a retained UI (it's even easier for the user of the lib as they don't have to think about it) though perhaps I'm naive in my early days!

All of the widget examples that you have given are already in the plans, I might as well just implement them and do another Show HN instead of rambling in the comments :)

First, to establish what we're not losing by using Rust:

* It can be as fast as C++ (in essentially all cases--all but compile-time metaprogramming related situations, after some in-the-works reforms are implemented).

* It can be as deterministic as C++ (usable in hard realtime systems).

* It has great FFI-level C compatibility.

Advantages over C++:

* It is substantially safer than C++. Outside of unsafe blocks, it is memory-safe and many other forms of undefined behavior are absent, including data races (unlike not only C++, but Java, Go, and most other mainstream languages that support multithreading).

* In a number of cases, it could potentially be faster than C++ by utilizing Rust's much stricter aliasing semantics.

* It should be able to compile much faster than C++, and it can infer much more thanks to its type system.

The above are things that I don't think can be shoehorned into C++ backwards-compatibly. I'm not including features like ADTs because I see no reason C++ couldn't have them.

There are plenty of reasons not to choose Rust over C++, including language immaturity, implementation immaturity, library immaturity, ecosystem immaturity, and lack of familiarity. But language feature for language feature, it offers substantial benefits.