Rewriting Qt in Rust
-
@Pete-Carter I guess I can understand you. If you want it, go for it. It will take long to make it. Java has its GUI part although it is horrible and I never like it.
-
-
@Pete-Carter Interesting. Qt was started in 1991.
-
I just was reminded of this discussion when I read a different discussion (https://forum.qt.io/topic/156733/i-m-struggling-to-run-qt-s-c-examples-please-assist). Someone posted there that there are already Qt bindings for Rust: https://kdab.github.io/cxx-qt/book/index.html
This would make it more unlikely that anybody would rewrite Qt in Rust. I didn't know that there are tools for Rust to connect to C++ directly (I always thought this had to go through C instead). However, it would only help to rewrite Qt in Rust if the reverse is also possible: to write C++ bindings for the Qt lib rewritten in Rust. Is that possible? Because otherwise this kind of switch would loose the entire community (or rather the community would split and C++ programmers would just fork from the existing Qt library).
-
@SimonSchroeder I believe we should slowly shift away from using C and C++ entirely and start using fast safe modern languages like Rust.
C++ and C are buggy ancient languages that caused countless problems, losses and vulnerabilities. We are in 2024, not in 19XX.A good read:
https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ -
@Pete-Carter
This is all very well, but I'm not sure what your point is. As per the theme of this whole topic (or perhaps the other one @SimonSchroeder linked to), Qt is written in C++ and (I do not believe) The Qt Company is going to alter that. One can try "bindings" for Rust if desired/workable. But each time we have a discussion about "wouldn't Qt be better if it were written in Rust/whatever" the fact remains that it is not and is unlikely ever to be. -
The whole point of me talking about this is to urge the Qt devs, who have great experience in GUIs, to build back better. If Qt keeps clinging to the old buggy tech, they will always face problems, and new, safer, hassle free, more productive frameworks will take over.
If your building block (programming language) is flawed, you will have to change it, so that the whole structure becomes better and stronger.
This is my opinion and i am just sharing it. It's just a suggestion for a better future based on my limited knowledge.
-
Rewriting a huge framework is a huge task and costs money.
And if you rewrite Qt in Rust you will make C++ developers unhappy (C++ is still one of the most important programming languages). And modern C++ is not that bad actually, but somewhat complex. Having Qt as a C++ framework and providing bindings for other languages seems to be a good approach. -
-
@Pete-Carter I guess it is more a demand issue than programming language selection. QML and Qt Widgets are parallel. It is doable.
-
@Pete-Carter said in Rewriting Qt in Rust:
C++ and C are buggy ancient languages that caused countless problems, losses and vulnerabilities. We are in 2024, not in 19XX.
Everywhere I have seen these arguments made, C and C++ have been mixed together in argumentation. Yes, you can write plain C code in C++, but you can also use unsafe code in Rust. And considering the tools and knowledge of C++ 20 years ago, C++ and the prevailing programming style (very similar to Java) made it really unsafe. With modern C++ we have unique_pointer and shared_pointer. With proper style at least we don't have use-after-free anymore. The only thing that is missing is a compiler flag to automatically add bounds checks for every array/vector access. (Already included in Herb Sutter's cppfront.) C does not assist you in writing memory safe code, but C++ certainly does.
I would really like to see the statistics for C++ software that started development in the last 10 years separate from older C++ and especially separate from C.
Herb Sutter has a lengthy statement about this whole discussion himself: https://accu.org/journals/overload/32/180/sutter/
@jsulm said in Rewriting Qt in Rust:
Rewriting a huge framework is a huge task and costs money.
And if you rewrite Qt in Rust you will make C++ developers unhappyThis is a chicken/egg problem: It does not make sense to rewrite Qt as long as a lot of software that is using it (also remember embedded/automotive!) in its majority is written in C++ (especially if it is hard to do C++ bindings for a Rust library). Nobody will move away from C++ if a lot of additional libraries for a project are also C++ (if they are C it is a little easier). At the same time, if Qt would move over first to Rust, it would loose its user base, if it is not compatible with C++. And as I said before, people would just fork the current Qt and keep developing it in C++. You cannot easily break this momentum.
BTW: Every rewrite introduces new bugs! This makes it unreasonable to rewrite such a large framework in another language. Qt from the beginning already has a superior approach to memory handling with QObject and the parent/child relationship. It is really hard to make Qt more memory safe when used properly. (I would really like to have a factory function like
T* QObject::make<T*>(...)to avoid writingnewwhich automatically assigns the parent when creating new objects.) -
@Pete-Carter said:
The whole point of me talking about this is to urge the Qt devs, who have great experience in GUIs, to build back better. If Qt keeps clinging to the old buggy tech, they will always face problems, and new, safer, hassle free, more productive frameworks will take over
I really don't get it. All this talk, multiple people giving you examples and counter arguments and you keep repeating the same tired slogans over and over, like some deranged mantra. Is there some Rust indoctrination course out there that repeats those silly talking points? Put down the Kool-Aid. It's just another immature language, like many of them out there. Wait a bit and it will have similar maturity problems to C++.
@SimonSchroeder I know this is a controversial opinion, but I don't get the whole fear mongering about using
new. The only serious benefit of wrapping it inmake*I know is related to exception safety, but I pretty much never use exceptions anyway (apart from the unavoidable std ones), so the benefit is really not there for me. What I would rather have is a user overridableqnewor the like, so I could give Qt my custom allocator and track its memory allocations. It always pains me to have every byte in the app counted and budgeted, except for the unpredictable blob from Qt. It would be very difficult given all the 3rd party dependencies, but one can dream. -
its not worth it to port Qt to rust.
If something is written in c++, it doesn't mean its slow or bad. I personally had a really good experience with c++ AND rust. Qt would be suited with c++ really well. You're gonna shave off like 4ms of performance with rust. -
The suggestion should have been for Qt developers to start a side project written from scratch in Rust. There is no doubt Rust is much more safer, more productive and more modern than C++. It would be nice if Qt developers used their years of GUI experience to make something cool in Rust.
-
@Pete-Carter said in Rewriting Qt in Rust:
There is no doubt Rust is much more safer, more productive and more modern than C++.
There's quite a lot of doubt. And you will need to prove each of these assertions before there's "no doubt". Since you won't, probably because you can't, as there's no good evidence (anecdotes don't count), I'd rather say quite the opposite: there is a lot of doubt.
PS: "modern" isn't a feature, technical advantage or even a tangible or measurable property. Modern literally means more recent, which isn't a measure for anything relevant. Fads are always modern when they balloon, that doesn't make them good or desirable.
It would be nice if Qt developers used their years of GUI experience to make something cool in Rust.
Qt developers have many years (some decade or two) of experience writing C++, does that mean they are as experienced in Rust? Obviously not. Not to mention "GUI experience" means exactly nothing in the sense of programming, you don't write in "GUI", you satisfy a requirement for a user interface in a language (with an API).
-
@Pete-Carter Web development is not object oriented development.Most of the web devs have problems to grasp oop. You seems to have learned only the basis of those languages. therefore you cannot really compare c++ and Rust if you only have an overview of those languages.Normally in c++, memory management is handled by the developer.I hope you know at least the main concepts in c++ that involve memory management because that is the main point between Rust and c++.
-
@Pete-Carter said in Rewriting Qt in Rust:
It would be nice if Qt developers used their years of GUI experience to make something cool in Rust.
I recently heard that because of the borrow checker it would be really hard to write a GUI framework similar to Qt in Rust. Qt (and also many other C/C++ GUI frameworks) rely on sharing pointers to widgets to get anything done at all. I'm no Rust expert, but isn't this against the borrow checker? (Yes, there is a way around this, obviously, as there is already CXX-Qt.)
In that case it would be a lot nicer that non-Qt developers develop a GUI framework which is a lot more natural in Rust. This would mean inventing a new style of writing GUIs. Maybe it is time for a modern GUI framework instead of reshuffling the ideas of the 80s. (At least "more modern" was one of your reasons for Rust over C++.)
-
It would be nice if Qt developers used their years of GUI experience to make something cool in Rust.
There is Slint - a GUI framework written in Rust, created by Qt experts: https://slint.dev
