Author of one of these "markup"-based toolkits here. I believe that Rust might not be the best language syntax to express UI. I am curious why you are so strongly against using a DSL.
When I went to go look for a platform to implement a personal text editor on, I somewhat quickly settled on the vt100 terminal api with kitty extensions, particularly its keyboard protocol. Everything else locks you into, not only a language, everybody codes frameworks these days, nobody writes apis, but also what's essentially already a legacy solution, a framework is going to get updates at the speed of the developer's passion.
Whereas when kovid made the kitty terminal protocol, it got implemented by the next 3 or so new terminal emulators. You don't get this kind of modernization from any other UI solution save browsers. And no way do I want to do web development for my own stuff. I suppose I could target Dillo or something like Servo, but I'd be more inclined to consume the base X11 protocol, as Vidar H did.
My Ruby terminal protocol implementation has smooth abstractions from methods performing the bare VT control calls up to semantic methods with better naming, to flexible and extensible text field abstractions. All the concerns are separated nicely and Ruby lets me scope everything just right, so I can call a debugger anywhere as the necessary logic is scoped module-wide.
I simply cannot imagine having any kind of fun doing this in a static compiled language. And I'll be able to build on top of this to make things that aren't editors.
I looked at Slint a couple years ago when I was evaluating UI toolkits. Looks slick! The only thing that turned me off was needing an additional DSL to define UIs. Trying to learn fewer languages, more deeply, these days. Is it possible to use Slint without the DSL?
Slint does require using its DSL to define UIs, but I'd argue it's not really like learning a whole new language. It's not harder than learning the API surface of any other GUI framework.
I don't think the DSL is any good. It looks weird (like a mix of CSS and classes), and it has a side effect of locking the user to a specific product.
In your article, you mention that an imperative code in Rust looks more complicated, but this can be fixed by adding an "object tree" syntax to Rust, that allows creating trees of objects and link them like this:
This syntax could be used not only for UI, but for describing configuration, database tables and many other things. I think it would be better solution than a proprietary language.
Also I think it would be better if GUI could be drawn in the editor, it would allow to use lower paid developers without expensive computer science education for making UI.
I appreciate the answer, and you taking time to write up your thoughts on it. Your point about the GUI builder working with the DSL is noted. In the egui RAD builder, I am manipulating structs which describe the UI (and which can be exported / imported as JSON) prior to code generation, which amounts to something similar. I still feel I have to context switch less, the back-and-forth is of more concern to me than learning an additional language.
That said, great work! There's plenty of room in the language for more than one solution!
That’s a compelling post. You drew me in by calling SQL a DSL. You’re right, but if you asked me to list the DSLs I use regularly I never would have thought of SQL until now. My thinking was too uptight because I didn’t consider the “domain” in DSL could be something as big as querying structured data. That makes me wonder if Rust is a DSL for the domain of general computing (obviously not in the usual intended meaning of DSL).
Like the person you’re replying to, I am generally averse to DSLs where the domain is a single project because I associate them with previous bad experiences where I spent time learning only to find it totally misses the mark. There’s also the issue of software where I’m the sole maintainer and look at it rarely. If it’s the only place I use Slint, then I’m going to be worried that I need to relearn the DSL in three months when I want to tweak the UI. Although you can probably say the same about any non-trivial framework’s API whether or not it uses a DSL.
All that said, I’ll be a bit more open to DSLs after reading your post, and if I ever need to write a GUI in Rust I’ll give Slint a shot (although that seems unlikely since I don’t typically write Rust or GUIs).
I'm one of the developers of Slint[0], a framework the should be ticking all the boxes for stable, lightweight, and native-style UIs supporting accessibility
> Rust claws at market share but has problems with basic stuff like doubly linked lists, WIP gccrs and memory unsafety,
Doubly linked lists aren’t that important today. Rust doesn’t need gccrs to be useful, and it gives much better memory safety than C++ without needing a GC. So I find your criticism of Rust seems a bit weak. Rust is a strong alternative to C++.
> Doubly linked lists aren’t that important today.
I guess Rust is just not a viable or good language if one cannot even implement easily something as basic as a doubly linked list. Doubly linked list is the bare minimum; if that is not easy to implement, more complex data structures will often be even worse.
Rust, contrary to public claims, often does worse on memory safety than C++, which is a sad state of affairs.
I fear my arguments are way stronger than yours, sorry. Please make it easier to implement data structures in Rust.
On memory unsafe Rust: It tends to come crashing down when unsafe is necessary, for both reasoning about unsafe is harder than in C++, and the rules for unsafe in Rust is an active area of research. Do you know all the intricate rules of unsafe (not all which have been defined), can you reliably predict what is safe and what is not without using Miri? Miri that cannot test all? Are you an expert on aliasing and pinning? Can you describe what tree borrows are?
On doubly linked lists: Sorry, but to implement a doubly linked list in Rust well, you have to go through trials and tribulations. A whole book was written about an epic of implementing doubly linked lists in Rust: https://rust-unofficial.github.io/too-many-lists/ . And if all that is required for a data structure as simple as a doubly linked list, what will then be required for some of the more complex data structures?
Well said, the point of doubly linked lists is not that it is the be all and end all of all data structures. You can possibly workaround that. The real issue is a real program has much more complex data structures, how can you possibly make it work or refactor easily when a simple thing like DLL's are causing so much grief. So, yeah Rust really is unproductive in a massive way. Just useful in small parts where you might really need memory safety (that too, not sure why you wouldn't chose another language).
What my verdigris experience shows is that it is perfectly possible to replace the moc at the cost of slightly uglier macros. And this was using C++14.
I haven't look in details at the C++26 reflection, but I'm sure it would make it easier to make these macro more pretty.
I don’t think any UI framework with a license more restrictive or complicated than full on MIT/BSD is going to be able to compete toe to toe with Electron. It doesn’t matter what the price tag is, if it has one it’s going to lose in a shootout between the two.
The only exception I can imagine is maybe a framework that uses the Unreal model, where it’s free to use under USD$1m/year in revenue and beyond that requires only a modest fee.
For Slint [https://slint.dev], a (native) GUI Toolkit, I've also developed a LSP server that do live preview and editing.
You can try it online at https://slintpad.com : if you click on the toolbar button to enable the right panel, you can edit the properties from the UI, and this is all done through the LSP and can be integrated in any editor that supports it.
cool! how does this work? e.g. how do you know which UI element matches which text element, do you track it while rendering? How do you propagate changes in the UI? do you update the text and then re-render the whole UI?
I use the the code lenses of code action feature of the LSP so that the user can start a preview. The LSP server will then open a native window on desktop.
Every time the users do some change in the code, the editor sends the document and we re-render the preview.
I use the textDocument/documentHighlight request to know when elements are being selected from the code so I can highlight them in the preview.
When selecting an element in the preview UI, my LSP server sends a window/showDocument to position the cursor at the right location. And if the user changes property or do change in the file, we do a workspace/applyEdit command with the changes.
This topic comes up often, so I wrote a blog post explaining why I think a DSL is a good fit: https://slint.dev/blog/domain-specific-language-vs-imperativ...
reply