暂时使用的名字是SixtyFPS： https://sixtyfps.io
他们又搞了门很像qml的UI DSL，这个DSL可以用rust的宏系统在编译时转换成rust代码，然后通过rust编译器统一编译成二进制代码。这样的设计会得到比QtQuick更高的性能。
这个思路我在这里也说过，果然是很好的策略。
不过这样的设计也会引入双语言的问题，就是ui部分是一门语言，主逻辑部分又是另一门语言，虽然SixtyFPS的UI DSL跟rust相像，但不免还是要学习和同时使用两门语言。
对比flutter，jetpack compose，swiftui这三个主流的声明式UI框架，它们的UI和逻辑都是同一门语言。flutter对语言特性的要求是最少的，但看上去并不那么“声明式”；jetpack compose通过编译器插件做转换（如果理解不对请指出）；swiftui在语言上加料，直接在编译器上增加swiftui所需特征支持。可以说都各有取舍，各有爽点和槽点，没有百分百完美。
跟qt使用GPL和商业授权这两种授权模式相比，SixtyFPS加多了一种名为“大使(Ambassador)”的授权，客户可以不交费同时不开源，但需要宣传SixtyFPS。这对中小微企业比较有吸引力，对SixtyFPS自然也有营销的价值。更高的性能、更安全的语言、更普适的授权，我觉得假以时日SixtyFPS很可能会取得比qt更大的发展。再加上SixtyFPS在欧洲工业中心德国，未来更可期。当然中间被qt收购也说不准。
SixtyFPS支持rust、c++、js作为主语言。rust学习有点难度，而且生态还处于拓荒阶段尚待成熟；c++容易出bug，想写稳定需要功夫；js性能慢，脚本语言也不适合写大程序，各有各难点。如果系统有gpu的还是优先选择flutter。高端ap用flutter，低端ap或mcu用SixtyFPS应该是比较实用的选择，特别是flutter刚开始就以支持gpu加速为设计目标，SixtyFPS则相反到现在对gpu加速支持并不完善。即使未来SixtyFPS对gpu加速支持完善了，但高端ap性能强，拿点性能出来支持GC，不用自己管理内存，其实也挺爽的。
离线
SixtyFPS提供了一个简单的上手教程： https://sixtyfps.io/releases/0.1.5/docs/tutorial/rust/getting_started.html
不妨跟斯坦福的CS139课程做对比。斯坦福的CS139课程是教SwiftUI的，开始那几课是写一个记忆力游戏。SixtyFPS的这个上手教程也是写记忆力游戏，正好可以相互对比，看看使用不同的声明式UI库编写应用的差异。
我怀疑SixtyFPS的这个上手教程是故意选择写记忆力游戏这么一个例子，好让大家跟斯坦福的CS139课程内容做比较。当然罗，即使两边都看过后，我还是喜欢SwiftUI多点。
斯坦福的CS139课程可以在 youtube.com 免费观看，教学水平相当的高。每年一更，记得追新。
离线
感谢分享！看了下demo，感觉响应速度非常快，声明式编程还算方便，不过有个问题就是UI还不太漂亮，控件也不多；商业价格29900欧还挺贵的，必须每年都交钱
20万RMB一年，也就一个熟手rust程序员的普通工资水平，真不贵。
想想有哪些公司是需要高性能，低时延，高安全，又不能开源的app的，这些公司很可能是吃军工，航空航天，汽车行业饭的，利润之高根本不在乎这20万。
何况这20万不单单是买license还有技术支持。
普通民用消费市场，没必要非要上SixtyFPS，市面一堆c/c++的ui库，出原型又快，人还好招，消费产品出点bug可以接受。
rust的ui库较大范围替代c++ ui库，我想还有5到10年的路要走。现在可以上手，但不建议立马就用上。
最近编辑记录 jlau (2022-01-06 16:16:14)
离线
改名字了：
https://slint-ui.com
离线