Conrod – A Rust GUI Library
blog.piston.rs
blog.piston.rs
On one hand, I'm enthused that Rust, arguably the only serious contender to C++'s throne, is gaining traction.
On the other hand, I'm scared that respectable projects like Qt (~6M lines of C++, man-millenia of work!) will be considered "obsolete" by the coming generation and another cyle of wheel reinvention will begin, tossing away man-centuries worth of polished, working code on the sole ground that it's C++.
It's not like C++ is going anywhere anytime soon, (Some serious infrastructure reportedly still runs on COBOL after all!) but what if we could finally settle down on a technology for a certain kind of problem and focus all our energy on building new stuff? Wouldn't that be grand?
I wonder whether there's another industry that keeps reinventing itself every 20 to 30 years and still gets away with it.
It's worth being concerned about losing the lessons learned from Qt, but this is a kind of false dichotomy between the old and the new.
With that said, I don't think those lessons will be lost anyway. Qt can't (and shouldn't!) last forever or remain in its current form. C++, though it will live for a long time yet, will eventually fall out of favor, and large sections will eventually be purged from Qt as the project matures. The man-years that went into the portions that were, or some day will be, removed have taught Qt developers and users a great deal.
Qt developers and users will bring knowledge and wisdom to new projects that will compete with Qt (directly or indirectly). Some projects will survive and some won't. Some will be much the same as Qt, while some will be completely different from the start. Conrod, as it happens, is an approach to a different kind of GUI development (see this comment: https://news.ycombinator.com/item?id=8244224).
This, of course, doesn't include developers who do their own things without ever using Qt. Hopefully, they will encounter blog posts and articles about some of those lessons, as well as attracting developers who've learned some of these lessons.
This isn't a case of getting away with reinventing the industry. In this nascent stage, computer science, with all the renegade hackers and developers, is still a necessary occurrence when new languages and frameworks are invented.
C++11 and C++14 have done a lot to enable users to write clean, efficient code. I probably would not be using C++ today if I were forced to write in C++03 style. I am still not convinced that C++ has gotten any easier to learn over time. But for those who know how to use it well, no language ranks better in allowing users to write clean, efficient, and portable code.
No, what worries me much more is the fact that there is no antialiasing on the "Envelope" in demo video.
Besides, probably it will surprise or even scare you, but Qt isn't the only, the first or the last GUI framework, there're many more, and new are created all the time. …And not even single actually good one invented still, but that's another topic. So there isn't any reason to think of that Conrod thing as something more than "just another one GUI framework". At least, until it would turn out to be somehow superior to ones that already exist. And if it will turn out to be superior to, say, Qt, then Qt should go to trash and I couldn't care less about all that "man-centuries" of yours. But, realistically, it's unlikely to happen, so everything we could hope for is some less complicated, useful for just some subset of GUIs micro-framework. In fact, it would be already very nice by itself, since it would spare Windows-developers of the pleasure of 30Mb cross-platform "Hello worlds" using Qt.
Qt is excellent for its epoch, but if you've read the source you will know that we should not treat it as sacrosanct. Algebraic types and explicit lifetime declarations and macro syntax extensions could all do wonders for it.
I imagine that as soon as Rust hits something like version 1.5, we will start to see semi-automatic converters from C/C++ to Rust, something similar to the C-to-Go effort underway to get to a self-hosted Go compiler.
Qt will probably take 5 years to be ported in a decent way, but I am pretty sure that a sizeable part of that codebase will be translated without too many problems, given its relative clarity.
Does anyone consider Ada another contender to C++? Statically strongly typed, safe manual memory management, wide-spectrum, hard real-time & embedded capable.
If Rust wants to become a real systems programing language, it needs OS vendor support, not HN cheering.
I have worked for quite a few real-time safety-critical systems, including one of the domains you mentioned. I have ex-colleagues who now work for other such domains. I assure you, that Ada is rarely ever seen. It's just C all the way, and usually running without an OS. I used to see job openings for Ada programmers some 15-20 years ago, but I haven't seen anyone use it in any of the firms I worked at. The only thing that seems to be changing these days is a creeping in of Matlab/Simulink-generated C code.
Add to https://github.com/rust-lang/rust/wiki/Community-libraries#g... ?
Glad to see Rust getting more traction. I'm not a huge fan of the syntax, and I'm personally putting my chips in the purely-functional space--but it's the most promising as far as a practical C++ replacement with much better semantics, which is sorely needed.
https://github.com/PistonDevelopers/rust-dsp
It only has a basic DSP-chain atm on top of a PortAudio IO callback, but hoping to contribute some synthesis, sampling and effects work soon! Especially now I have some widgets to design instruments with :)
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 :)
It's not about whether you can do it. It's whether it's useful to do it that way. You've got a cool tech demo, but you're working on something that won't ultimately be useful. Sorry.
Re pixel positions: Tooling is planned for easier widget placement... As I mentioned in the article, the project has barely had three weeks worth of work poured into it - perhaps it's best not to try and declare the project as useless when it's barely even out of the womb ;-)
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.
But more complicated ones, with resizable widgets/layouts, selection changes, scroll view positions and widgets which display a lot of data, or layering/parenting of widgets make things a lot more complicated.
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.
* Pending some in-the-works reforms, and not including implementation-specific features like labels as values (https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64).
Incidentally, some of those Rust programs are written for multicore:
binary-trees Rust ≈ CPU Load 96% 86% 92% 92%
fannkuch-redux Rust ≈ CPU Load 100% 100% 100% 100%
regex-dna Rust ≈ CPU Load 59% 79% 80% 59%
Rust was designed to be memory-safe. That means, unless you explicitly mark a section of code as "unsafe", it isn't possible to have segfaults, have buffer overflows, use memory after freeing it, etc. A very significant amount of software bugs - famously, Heartbleed, but also a huge proportion of other security bugs in everything from servers to web browsers - can't happen under Rust code. The point is to have a much more secure programming language, as in resistant to attacks, while still being as fast and as usable as other C-style languages.
The reason Mozilla are developing this is for Servo, a new browser engine which should be far safer than existing ones - although it's also useful for pretty much any other code, as it wipes out entire classes of bugs with not much effort. If you write in a C-like language today, you could pick up most of Rust (lifetimes included) in a couple of days of playing with it.
I am past caring if it is a totally native looking toolkit, just as long as it looks good/consistent across all platforms with hardware acceleration I am good to go.
Well, given those bullet points, Servo might meet your needs :)
In general we're not going to think about blessing packages as "official" unless it gets to the point where some package becomes mature and overwhelmingly dominant in its space (think Rack in Ruby or async in Node); we'd prefer to focus on making it easy to upload and share Rust packages via Cargo to build up an ecosystem.
With that said, the last time I heard, the reason for Rust's existence (Servo) did not have any plans for implementing anything outside of the browser rendering & javascript engine. So, no browser chrome, which would be the only reason I can think that they would develop an "official" UI toolkit.
I would love for someone involved in the project to correct me, though :)
Go I suspect is intended for more service related stuff, backend, server, processing, etc.
Though I'm not 100% sure about this.
The good side of it, is that you can also bind a web rendering engine totally coded in Go or bind the webkit rendering to the compositor backend..
I hope i get there soon..
* http://labs.opendns.com/2013/10/04/zeromq-helping-us-block-m...
* http://skylight.io : the gem you install to monitor your app is written in Rust.