Rewriting Qt in Rust
-
in computer engineering there has been this never ending push to reduce the programmer alchemists to the importance of assembly line workers. I got into programming 40+ years ago because I wanted to be artsy and creative, not implement someones OCD directions for minimum wage.
college graduates aren't smart enough to understand the full software stack from physical hardware to business concept then obviously the system is flawed because that gives those who do understand it too much power. I have no use for languages that obfuscate the steps of abstraction from algorithm to electronic switch. If someone understands systems then they can effecitvely and safely program in C or C++ on those systems. Rust seems an attempt to cheapen the art.
-
@Kent-Dorfman said in Rewriting Qt in Rust:
there has been this never ending push to reduce the programmer alchemists to the importance of assembly line workers
Well, of course...why do you think they invented COBOL?
Historically, programmers have been known for being:
- necessary for IT (once IS) departments to function
- expensive/very expensive
- irreverent, sometimes to the point of flaky
Not a combination that endears one to the suits. It's only natural that people would try to obviate this. That they fail most of the time is a historical artifice, and won't keep them from trying.
-
This recent blog post made me think of this discussion :)
-
@Chris-Kawa You have some good points. Can you elaborate on the following:
Lets suppose we give the Rustaceans (pronounced as Rust-Asians) what they want and say that Rust is much better than C++ (23) for the sake of this post.
- Qt uses C++, not-free
- Slint uses Rust, free
- Flutter, free
Why should someone in 2023 still choose Qt with C++ in case of desktop and/or embedded devices over the others mentioned above?
You also said: "Qt also is a full framework with classes for networking and file i/o". However, in case of Linux there are enough C libraries that work on their own hence Qt classes for networking and file i/o aren't necessary.
Finally, one argument that Rustaceans state is that C++ has been trying to solve things by adding other things which complicates everything. What is your take on this?
Not choosing sides, as you are a very experienced programmer which can't be easily found nowadays I want to know your take on this.
-
Lets suppose we give the Rustaceans (pronounced as Rust-Asians) what they want and say that Rust is much better than C++ (23) for the sake of this post
Lets suppose sky turns red tomorrow... what's the point in questions like these? It's not happening soon and I'm really more interested in discussing real world problems and scenarios than hypotheticals. Maybe in couple of years (more like a decade) we can revisit the problem, but currently it's a pipe dream of the Rust people.
Qt uses C++, not-free
Huh? Qt is free, GPL or LGPL. That's how I've been using it for nearly 15 years.
Why should someone in 2023 still choose Qt with C++ in case of desktop and/or embedded devices over the others mentioned above?
I don't think anyone "should". I think they "can" consider it and it "might" turn out to be the best solution for them. It might not. I'm not gatekeeping anyone from making their own choices. Someone might already know C++ and/or Qt, so why switch and pay for the pain of re-learning everything from scratch for little to no benefit? Take me for example - I've been using C++ for most of my life at this point. I've been using Qt since 2008. I know they're not perfect, but I know most of the imperfections that affect me and have years of experience dealing with them. They rarely even bother me at this point and I barely register them when they come up. It's like marriage - sure you can switch for the new hotness, but is that really a long term win? ;) How much time and effort would it take me now to get to know Rust, Slint or any of the other to the same degree? What can I do in them that I can't in the technology I already know? What guarantee do I have that their imperfections wouldn't cause me more trouble than the ones I already know how to deal with? A bit of a sprinkle here and there, so I can join the cultists chanting over syntax? That's not nearly enough to even consider this. Sure, I take a look at them out of curiosity every now and then. I might write some toy program for personal use, but there's no value in seriously switching for me. More of a loss actually, because time and energy is something I have less and less with years.
hence Qt classes for networking and file i/o aren't necessary
Every operating system has a basic set of libraries that are building blocks for higher level libraries. With above mindset you don't need any non-OS provided libraries. Same for UI, be it Qt, Slint or Flutter. There are native APIs for UI after all. The point of all of those libraries is convenience layer over the usually low level and complicated native APIs. If you ever wrote
QWidget widget; widget.show();and then tried to do equivalent in native API you will know the value of it. Same goes for networking, I/O or any other module. Not to mention the cross-platform nature of Qt.
I'm a low level guy, and sometimes seeing what Qt does underneath pains me, but it's usually a lot better anyway than what other frameworks do, like spinning up a web browser, javascript engine and taking up 1GB of RAM just to show a button on the screeen. So what if the API is written in a language with a bit easier syntax? Ugh... it's like they hate the idea of a battery lasting more than an hour, but I digress.Finally, one argument that Rustaceans state is that C++ has been trying to solve things by adding other things which complicates everything. What is your take on this?
It's complicated. C++ is a language on which a large chunk of the world's technology is built. It would be irresponsible to break compatibility for the sake of fixing little inconveniences that got into it over the years. Rust and other younger languages don't have that big of a legacy they need to care about. Most users of those are enthusiasts that don't mind rewriting large chunks of their software when the language changes something. This is prohibitively not true for most of the existing C++ code. So the reasonable approach is to improve the language by adding better facilities than breaking the old ones. Sure, this approach has caveats, making the overall language bigger and more complicated, but there's really no perfect solution to the legacy code issue in general.
Again, I'm not against new languages. I'm against fanboying/fangirling over them, mostly because of how annoying it is. Rust is not perfect and it bothers me when people try to paint it as such. These new things have their benefits, but also their downsides, like every technology. Legacy is a problem of C++ right now. Lack of reach, maturity and stability are just some of Rust's that I know of, even being a complete noob in it. I won't tell people which problem set to choose, but I would like to see more reason and consideration in people picking their solutions, instead of jumping on the new shiny, like a cat on a laser dot. Pick a hammer for a nail and an umbrella for rain. There's no omnitool (not counting the one from Mass Effect).
-
@Chris-Kawa said in Rewriting Qt in Rust:
The point of all of those libraries is convenience layer over the usually low level and complicated native APIs.
The main point of Qt is that its made by a company that sells APIs.
(granted, they are reaching out into services, which personally I hope will be a completely separate unit to avoid it taking away from Qt the libraries, but i digress).
Libraries you can sell to developers need to add value. And the fact that Qt has been around for so long shows that they do. Add value, that is.
The main benefit is one of cross-platform development. Its sooo much faster to write and test on your desktop and then simply deploy on mobile the exact same code. I don't want to even imagine using the Android native APIs. And then get myself a Mac to do the same thing again? Ugh, no.
Anyway, just ranting a little too.
I agree with all the C++ people in this thread. -
@TomZ said in Rewriting Qt in Rust:
The main point of Qt is that its made by a company that sells APIs.
The community can always fork from Qt under the GPL and LPGL. This way you can have Qt as full open source without a company behind it. Having a company putting in any money at all into an "open source" project is a good thing. I know that in reality the dynamics are a lot more complicated.
PS: There have been "forks" from Qt that want to be drop-in replacements in one sort or another:
https://www.copperspice.com
https://github.com/woboq/verdigris
If you haven't heard of those it makes the point for reality vs. the spirit of open source. The community seems to prefer Qt from a company over those two alternative solutions. -
@SimonSchroeder said in Rewriting Qt in Rust:
The community can always fork from Qt under the GPL and LPGL.
why would it?
@SimonSchroeder said in Rewriting Qt in Rust:
This way you can have Qt as full open source without a company behind it.
It already is full open source.
-
@TomZ said in Rewriting Qt in Rust:
why would it?
So that it is no longer tied to whatever TQtC do/don't do. @SimonSchroeder has given a couple of examples which already did this.
-
@SimonSchroeder said in Rewriting Qt in Rust:
One of my main gripes with Qt is that all GUI programming must be funneled through a single thread (explicitly).
Just had to comment to this one, as that made me laugh.
To be clear, this is just about the GUI classes, Qt itself does not in any way restrict you from using threads and off-loading work to worker threads. (Notice the QThreadPool class in QtCore).
Yes, indeed, you are obligated to manually route your GUI updates to the 'main' qt thread. The alternative would be massive locking infrastructure in the GUI framework or a massive amount of overhead of every function needing to move the update to the main thread for you behind the scenes.
You may not like it, but its the most commonly used solution for any generic set of (GUI) classes where the number of classes and methods is quite large.
It feels like you might just not have understood signals and QObject thread affinity if you think this is a problem, really.
Qt allows one of the most beautiful way of moving content from one thread to the other without any efforts on the side of the programmer.All you need to do is connect a queued connection between your data class and your GUI class. The
signals: void nameChanged(const QString&);on one side and thepublic slots: void setName(const QString&)on the other when connected will automatically be a queued connection if your data class (the emitting one) has a different thread affinity than the GUI one.
Nowhere have I seen such a simple way to allow you to introduce multi-threading to offload the hard work so it avoids blocking the GUI updating thread.Edit:
@SimonSchroeder said in Rewriting Qt in Rust:
I'm also annoyed that layout calculations are only done once the widget is shown. Even more annoying is using multiple monitors with different resolutions. I would hope that a modern UI kit would handle this properly in the background. I am even certain that it should be possible to make widget partly overlapping two screens having the right resolution/scaling on each of the two monitors.
Notice that those issues are not Qt issues, really.
They are issues in the graphics layer it builds on top of. The fact that the all graphics systems require the app to reserve a square for the window and draw into that, specifically.
Anything Qt could do would be a major hack and fail for a significant number of users.
-
@TomZ said in Rewriting Qt in Rust:
It feels like you might just not have understood signals and QObject thread affinity if you think this is a problem, really.
@SimonSchroeder understands Qt signals and thread affinity perfectly well! :) [Well I think so anyway!] His comment was what it was, i.e. Qt requires all UI accesses to be done in a single thread, which is a perfectly valid observation to make of as you will. As are your observations :)
-
@JonB said in Rewriting Qt in Rust:
Qt requires all UI accesses to be done in a single thread, which is a perfectly valid observation to make of as you will.
It is a valid observation, what is missing from that observation is what I replied with is that there is no clean alternative solution in any language or any framework known today.
This is a generic problem: how do you keep your stuff free from race-conditions if you have hundreds of classes and thousands of methods. For clarity, I'm JUST talking about the GUI stuff. Which is a small subjection of the whole.
If you find any framework of the size we are dealing with that solves it better, please share.
-
@SimonSchroeder said in Rewriting Qt in Rust:
@TomZ said in Rewriting Qt in Rust:
The main point of Qt is that its made by a company that sells APIs.
The community can always fork from Qt under the GPL and LPGL. This way you can have Qt as full open source without a company behind it. Having a company putting in any money at all into an "open source" project is a good thing. I know that in reality the dynamics are a lot more complicated.
PS: There have been "forks" from Qt that want to be drop-in replacements in one sort or another:
https://www.copperspice.com
https://github.com/woboq/verdigris
If you haven't heard of those it makes the point for reality vs. the spirit of open source. The community seems to prefer Qt from a company over those two alternative solutions.Just one thing: verdigris is not a fork at all, it's a header only library providing an alternative set of macros to define Qt objects as well as signals and slot in a way that is binary compatible with Qt, but does not require moc. You would use that with your standard Qt installation.
-
@TomZ
I just jumped to his defence. I modified my post a bit, don't want anybody to be down on anybody else!I don't know much about what other UIs/toolkits take as their approach. Purely OOI if one used, say, the Windows SDK to access a UI do you know what their requirement is if one uses threads [I do not know but am interested]?
-
When i write Rust code and go back to writing C or C++ (C*), i feel like a retard, i feel unsafe and not confident. C* are buggy languages and have design faults. A compiler should prevent you from making mistakes and if it allowed you to make mistakes, then this is a bug. I think these ancient languages should never be used in 2023. C was invented in 1972, 51 years ago and C++ in 1985, 38 years ago. Lots of things have changed in the last 20 years. The hardware have improved a lot and many things have been built back better. Yet C* are still clenching to old rules for the sake of backward compatibility, and this is the right thing to do in order not to break the existing code.
So i believe that C* should only be used to maintain legacy code, new software should be written in Rust. I see that Rust is the best tool to write C++ like software.
Another thing is learning programming for beginners. Learning Rust is very easy and the tooling for Rust is amazing. The official book is not the best and i see it can be written better for people who have never programmed before. But learning C* is a trouble for beginners. And its very easy for beginners to introduce deadly mistakes in C*. You will need a safe, fast, efficient, productive language like Rust to make learning programming easy and fun for as much people as you can. The more new good programmers you make, the more software will get written and the faster a new safer software world will grow.
So maybe yes it's a stupid idea to rewrite Qt in Rust and i no longer support this. But It would be amazing if the developers of Qt contributed in a new Rust GUI framework like Xilem.
A little more thing to add is that you will always need to build back better from time to time. I think problems in Rust will appear after like 40 years from now and you may need to change things in Rust or build a new language. At this point, a tool can be written to convert the whole existing Rust code to the new language and we may not even need to rewrite anything manually. We should always try to innovate things and not keep sticking to the old stuff.
This is my personal point of view.
-
I do come with a strong Java background and havent used a lot of C++ in the recent years. But I simply cannot follow your arguments you have posted.
@Pete-Carter said in Rewriting Qt in Rust:
When i write Rust code and go back to writing C or C++ (C*), i feel like a retard, i feel unsafe and not confident.
Well, I am out of practice with modern C++ (which means C++14/17/20) but still I don‘t feel scared going back to C++ writing code there. I feel scared when I read Rust code as IMHO it looks really ugly to me.
C* are buggy languages and have design faults. A compiler should prevent you from making mistakes and if it allowed you to make mistakes, then this is a bug. I think these ancient languages should never be used in 2023. C was invented in 1972, 51 years ago and C++ in 1985, 38 years ago. Lots of things have changed in the last 20 years. The hardware have improved a lot and many things have been built back better. Yet C* are still clenching to old rules for the sake of backward compatibility, and this is the right thing to do in order not to break the existing code.
Your argument toward Rust is wrong. If - even at that time - you wanted to have a type-safe language that prevented almost all the stuff that Rust claims to fix nowadays you could have used Ada, invented in the 70ies and still active use in areas that are really critical to human mankind. There is no need to write with the new kid on the block. But writing code in Ada is painful.
So i believe that C* should only be used to maintain legacy code, new software should be written in Rust. I see that Rust is the best tool to write C++ like software.
New software should be written in the language you feel most proficient/productive/safe in or which is available for the (embedded) system your are working on., e.g. I had to maintain a legacy project where the only available compiler was JOVIAL. Man I would have killed for a C compiler :D A friend of mine chose Go for the new implementation of industrial router systems as it gave them the best benefit.
Another thing is learning programming for beginners. Learning Rust is very easy and the tooling for Rust is amazing. The official book is not the best and i see it can be written better for people who have never programmed before. But learning C* is a trouble for beginners. And its very easy for beginners to introduce deadly mistakes in C*. You will need a safe, fast, efficient, productive language like Rust to make learning programming easy and fun for as much people as you can. The more new good programmers you make, the more software will get written and the faster a new safer software world will grow.
Use Java as an alternative. The JVM is easy, reliable and you have a working cross-platform UI OOTB. The debugging experience is super nice, the performance is not bad. And you have millions of other coders to ask for help - not forgetting the available frameworks you can use. Students love it…And I think the same applies to .NET languages nowadays.
So maybe yes it's a stupid idea to rewrite Qt in Rust and i no longer support this. But It would be amazing if the developers of Qt contributed in a new Rust GUI framework like Xilem.
Why should a C++ company with many good c++ coders invest in a language they don‘t really speak? And why should a commercial company invest in a (sort of) competing product? Makes no sense to me.
If you want a cross-platform UI for rust, why not have a look at Slint? They claim to be the rust equivalent for Qt written by people who have worked before on Qt.A little more thing to add is that you will always need to build back better from time to time. I think problems in Rust will appear after like 40 years from now and you may need to change things in Rust or build a new language. At this point, a tool can be written to convert the whole existing Rust code to the new language and we may not even need to rewrite anything manually. We should always try to innovate things and not keep sticking to the old stuff.
I really think you are underestimating here the effort it will need to convert code from one language to another. Here is one sample of a tool that converts JOVIAL code to C code. JOVIAL was created roughly 60 years ago and there are people with huge codebases written with it. You can translate it - but is the result really nice? The sample shown in the link is small but I guess it would have been better to have rewritten it from scratch just by looking at the result. It is ugly. The same would apply to rust in the future.
This is my personal point of view.
Mine as well. If some parts may sound rude - this is not intended but I am not a native speaker.
-
@Pete-Carter said in Rewriting Qt in Rust:
My knowledge in C++ is poor BTW.
Hi,
I have a question:
if you don't have rich knowledge about c++
how can you say that c++ is not good and is dying??
I don't know about rust and don't telling rust is bad or dying -
@AliTurk I started my journey in programing in web development using JS and PHP. Then i started learning Rust and some Java. After a while i wanted to take a look at C and C++ to understand Linux, KDE and other code written in C*. After a while of learning C*, i saw that Rust is much better in everything. So i stopped learning more C*.
My knowledge is C* is just the basic stuff, but i don't have to go deep in C* to know that they are much more cumbersome than Rust. If you start using Rust you will know what i mean, especially if you are a beginner. The package manager (cargo) alone is something that makes Rust amazing. Plus all the dependencies in one place (crates.io) and many other stuff. You really don't feel worried writing Rust code unless you activate
unsafeintentionally.@DerReisende I think that Java and all the other interpreted languages are misused in many places. I believe that any slow resource eating interpreted languages should only be used when absolutely necessary. But developers started using non efficient languages everywhere like in GUIs. The android studio is a very good example for a horrible slow resource eating application that would have been much more efficient if it was written in C++ or Rust instead of Java.
Many programmers just prefer productivity and ease of use of the programming language instead of creating something efficient that will be lightweight on the user's machine. Thanks to Rust we can get the best of both worlds, productivity like python and java, and speed like C++ and C.
-
@Pete-Carter said in Rewriting Qt in Rust:
When i write Rust code and go back to writing C or C++ (C*), i feel like a retard, i feel unsafe and not confident. C* are buggy languages and have design faults. A compiler should prevent you from making mistakes and if it allowed you to make mistakes, then this is a bug. I think these ancient languages should never be used in 2023. C was invented in 1972, 51 years ago and C++ in 1985, 38 years ago. Lots of things have changed in the last 20 years. The hardware have improved a lot and many things have been built back better. Yet C* are still clenching to old rules for the sake of backward compatibility, and this is the right thing to do in order not to break the existing code.
Have to say that if you repeat arguments that people already shown to be false in the same thread, I don't think you are arguing in good faith.
C++ is clearly not your cup of tea, and that's Ok. I don't like Python myself. People have preferences and use what they like to use.
Thanks!
-
@TomZ Trust me, i don't have any problems with C++. I use KDE and many other apps that are written in C++. C++ is my second favorite language after Rust. I just love Rust more cuz it's more convenient and safer, that's all.
