Our great sponsors
-
redux-rs
An attempt at a uni-directional state flow written in Rust, heavily based in redux-js. (by jaredonline)
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
slint
Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
post--activation-atlas
Using feature inversion to visualize millions of activations from an image classification network, we create an explorable activation atlas of features the network has learned which can reveal how the network typically represents some concepts.
From the first paragraph:
> ... Architectures that work well in other languages generally don’t adapt well to Rust, mostly because they rely on shared mutable state and that is not idiomatic Rust, to put it mildly. ...
The author doesn't mention Redux (the architecture), which is surprising. There are three principles[1]:
1. The global state of your application is stored in an object tree within a single store.
2. The only way to change the state is to emit an action, an object describing what happened.
3. Changes are made with pure functions.
In other words, the components of an application never mutate the state tree directly. Rather, they emit actions which re-generates the state tree without mutation.
This style of state management is compatible with Rust's ownership model. The emphasis on pure functions means that it's not necessary for your application to hold multiple mutable references, which I'm guessing underlies the "generally don't adapt well to Rust" part of the claim.
[1] https://redux.js.org/understanding/thinking-in-redux/three-p...
[2] https://github.com/jaredonline/redux-rs
What are your thoughts on Sycamore?
https://github.com/sycamore-rs/sycamore
Ok I'm not Raph but, FWIW, my 3d sculpting app is written using SwiftUI (https://sculptura.app), which is not a view around a database (in fact it was previously UIKit... SwiftUI is so much better). I recently implemented a piano-roll editor in SwiftUI: https://github.com/AudioKit/AudioKitUI/tree/main/Sources/Aud.... I have little doubt a DAW could be implemented in SwiftUI easier than with UIKit or AppKit.
> The problem is that it requires shared mutable access to that state, which is clunky at best in Rust (it requires interior mutability).
I don't see the problem with using interior mutability (Rc> or Arc>)
With Slint [1], we just embrace it, and rely on interior mutability for the shared state, and that works well.
[1] https://github.com/slint-ui/slint
What about various libraries that don't use a virtual DOM and have vastly better performance than React, for example https://www.solidjs.com or Svelte ?
Very insightful post. Although my work is mainly about audio not GUI, I still learn a lot from your idea. For my audio work, I also use declarative style and diff algorithm for updating the audio graph. But when rewriting it, I found sending messages is also very convenient:
https://github.com/chaosprint/glicol/tree/main/rs/synth
As I said, there is still some way to go. Will further study this post when I got more spare time.
Okay. That said, are there any particular conclusions or implications from this approach for that use case?
For that matter, are you next going to extend this simple exploration toward more complexity (eg. more widget types, more interactions, more layout constraints, etc.) or toward more data?
As I've followed your efforts in this area, the power and utility of selecting the right motivating example has been coming into focus. The parallels with a startup's MVP are fairly clear, the parallels to selecting a (dissertation) research topic a bit handwavy (in part because guidelines for the latter are extraordinarily vague). So far you haven't really chosen a new motivating end-user application since suspending development of Xi. There are lots of directions you could go, from making an equivalent to Processing, to creating a game engine, or eventually restarting Xi development with an eye toward exploration and visualization of large codebases, etc. Personally I'm starting to become intrigued by the need to dig into large neural nets and the representations encoded within (related subtopics: latent spaces, feature vectors, orthogonality):
https://distill.pub/2019/activation-atlas/
Meanwhile, I've been casting about for a proper (Rust) motivating example app/library of my own, and the closest I've come so far is something like a HTML + CSS rendering engine, though not targeted at the Web per-se, but instead at ebooks (esp. EPUB), a much smaller set of required functionality.
In theory a desktop ebook library + reader app with features like MathML support, advanced typography, and visualizing connections between millions of works and annotations seems like it would be a better fit with the direction you're (currently) going than any existing framework.