Comment by noodletheworld
10 hours ago
The website developer docs.
Look, bluntly, you can’t have your cake and eat it to. Either it’s a rust library or it’s not.
If you’re not writing your ui in rust, then even if parts of it are implemented in rust, it’s not a rust ui library any more than a js library like calls a c backend is a c library.
I really really wanted to like slint and absolutely did not.
> Domain Specific Languages like Slint offer a great alternative to traditional GUI toolkit APIs.
No they don’t.
If you can arbitrarily assert something so can I.
A DSL needs it clear the minimum bar of “why is this not just using a real programming language?”.
UI programming is tricky, but declarative approaches have almost universally failed, because there’s always some edge case logic that needs a full programming language to handle it.
The few UI DSLs that Ive seen work (eg. blueprint) exist a) as stand alone languages, and b) fill a niche that an existing language doesn’t.
What does your DSL do that is unique? Why was using js like qt quick not good enough? Why not just use rust?
The issue I have with it is you’ve never articulated why it exists.
Good DSLs like those implemented using clojure (1) are additions to the language that can natively be mixed into the existing language ecosystem.
You could have done the same in rust using proc macros; but instead you’ve chosen (as far as I can tell) to chase the non-rust UI market with a custom DSL.
Well.. you want an opinion? There you go. I don’t like slint, sorry. It’s not a rust UI library. It just happens to be implemented in rust, in my opinion.
(1) - https://clojure-doc.org/articles/cookbooks/growing_a_dsl_wit...
> Either it's a rust library or it's not.
It is one. Your app is a Rust program that depends on a crate. The UI compiles to Rust code, and we also have the `slint!` proc macro.
> there's always some edge case logic that needs a full programming language
Right, and that language is Rust. The DSL only describes the GUI. You operate it from Rust.
> Why was using js like qt quick not good enough?
QML was the inspiration. I worked on Qt and wrote QML bindings for Rust before (qmetaobject-rs). Slint is a new take on it, compiled ahead of time, no GC, strongly typed.
> The UI compiles to Rust
Right, so not rust.
Languages that compile to c are not c.
Languages that compile to rust are not rust.
> QML was the inspiration
Yes, except you invented a new programming (1) language unnecessarily.
Whatever.
We'll have to agree to disagree.
If the programming language you write is not rust it is not a rust ui library.
Slint requires you to write your UI in slint. I havent used it much, but Ive used it enough to know that this:
> The DSL only describes the GUI
Is about as disingenuous as you can get.
Thats like saying that javascript only describes the GUI of a website, a backend rust website is really just a rust application. Really you're building in rust. React is really a rust UI library at heart. <—- obviously BS.
(1) - https://docs.slint.dev/latest/docs/slint/guide/language/conc...
>A DSL needs it clear the minimum bar of “why is this not just using a real programming language?”.
No, a DSL only needs to be better than the language itself to write a layout in. UI is a whole different beast than anything else, where deep nesting is common, layouts flow in many ways, and more. Rust is simply not appropriate to make that pleasant.
Take a simple layout like you'd declare it in Kotlin using Compose:
Kotlin naturally has trailing lambdas, method references, has the advantage of being a GC'd language so memory management is out the window.
In pure rust ?
}
What a delicious piece of trash. Since you've said no macros, you're carrying an additional variable everywhere (Composer is a Compose system, but you have the same thing in every UI library that does the same. Call it Context, whatever you want). You have shitty lambdas that need to pass the scope too (because Modifier.weight() only works on a ColumnScope). You have no named parameters, and the only way you would would be crap like having a ButtonProps struct. You have impl Fn() + 'static written in your code. And then if you start to want to do some actual work like "clicking on the button increases a counter", you're suddenly spamming Arc::clone, |move| Rc's everywhere in your code because Rust is simply not a good language for UIs.
(And if you want to go the old school way of simply managing yourself a widget tree, good luck, not only is it always full of bugs, it's also an unmaintainable garbage fire.)
Clojure is not a good language for DSLs either, and the post you've linked is just jerking itself off saying "look i can convert some clojure into the exact bash equivalent by only changing one thing" when it's the exact reason why every single clojure project ends up reimplementing the wheel twelves times and is a piece of shit unmaintainable kludge of whatever code the local genius wanted to commit in this morning. Good languages have constraints.
So yes: DSLs _always_ offer a better alternative. QML is a good DSL, and using Javascript is not the reason why.