Rust 2021 edition to arrive in October with 'more consistent panic' and other new features The Rust 2021 Edition Working Group has scheduled the new version for release in October, with what it says are small changes that amount to a significant improvement. This is the "third edition of the Rust language," said Mara Bos, founder and CTO of Fusion Engineering and a Rust Library Team member. The previous editions are …
It means the same as it does in the Linux kernel - "the program has entered a state it should not be in and therefore it is better exit with this error message and a stack trace and let the programmer figure it out than blunder ahead into undefined and potentially bad behaviour."
They do have a crater (dot io). It's for testing your compiler changes on every single public piece of Rust code that's out there. To avoid turning your email inbox into a smoking crater after you accidentally broke everybody, I presume.
My sole achievement during the lockdowns has been to get reasonably fluent in Rust. The one thing I'm finding it lacks at the moment is decent desktop GUI support. Thanks to the borrowing concept of memory management, it doesn't make it easy to map the APIs of common GUI libraries like GTK or Qt.
Otherwise, I love the language and the community around it. Seems much friendlier than certain communities, with a healthy awareness that no language is perfect or can't learn from others.
Most of my GUI programming is done in C, which is a systems level programming language just as Rust is. Arguably, C is lower level than Rust, being lipstick on the assembly language pig ;-) The problem is that GTK has its own reference counting for memory management of its widgets, and that doesn't map nicely to Rust. Qt is a superset of C++, and that brings its own problems. There are projects that try to create a more idiomatic Rust API for GUI programming, but they tend to build on drawing APIs so they have the problem that afflicted Java with its Swing API - a look and feel that's not quite native.
I've programmed GTK in Rust and it is almost directly analogous in terms of effort as it is to C. You can take a C example (or a Python one) and it's a 1:1 call relationship. The problem is that isn't saying much because GTK is so low-level that it's a very wordy API to deal with and some of it is plain nasty, such as void casting types in some places. The best approach is design the UI in Glade and restrict the code to hooking up signal handlers. But Glade and the XML format sucks too and it's a pity there isn't a more high level declarative format for GTK akin to QML.
If you're writing a lot of Java windows that are essentially rows and columns of labels,data values and a few Buttons, i.e. similar to the type of screen layout that used to be common on greenscreen mainframe terminals or using 4GL packages to program PCs, try using the se.datadosen.RiverLayout layout manager.
If RiverLayout is a good fit with what you're trying to do, you'll find it makes laying out a Panel much easier than it would be with a standard Swing layout manager.
Refer to Are We GUI Yet? (https://www.areweguiyet.com/)
There are quite a lot of UI frameworks but I don't think the platform has coalesced around a desktop UI framework although there are plenty of viable ones for games.
And on the desktop you can write apps in GTK or Win32 with about the same level of effort as it would be in C or C++. I've written GTK apps with Rust before and the problem isn't the bindings but the documentation for GTK which tends to be out of date and tools like Glade which suck.
I think Rust could benefit from something similar to QT. i.e. a UI where signals are bound to handlers via an actor framework and where the UI is expressed in a higher level language that can be styled. Sort of like QML or XAML.
I wouldn't want to use QT through bindings even though they exist in various states for various languages. I think it is sheer folly for reasons obvious for anyone familiar with QT.
I don't think it is possible, at least not easy and fast. A sufficiently abstract api that allows multiple parts of the UI to react to changes in state or messages is intrinsically incompatible with the single ownership model.
You have to copy or use mutexes to work around that and peeps want the UI to be snappy.
Most user interface APIs have patterns which aren't dissimilar from actor frameworks to begin with. e.g. they post / send messages to a handle and one or more threads are running message pumps that dispatch the message to an associated handler.
So my "vision" for Rust UI framework would be nothing radical. There is a proven actor framework called actix that could be the basis of the signal / slot call mechanism akin to QT and a declarative UI markup language akin to QML. It might even be possible to embed chunks of Rust in the markup for button handlers and such like and use a compile-time processor to generate the code.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
