Rewriting Qt in Rust
-
What do you think about rewriting Qt in Rust ?
I think rewriting Qt in the Rust programming language will improve security and productivity a lot.
-
@Pete-Carter You mean you're volunteering to do it?
A lot of code patterns in Qt don't translate to Rust well or at all, like all the pointer based passing and assigning of objects.
It's also a lot of code, you know, and 3rd party dependencies on other C++ libraries like chromium. For the amount of work needed (couple years at least I expect) there's very little benefit I see. I'm not market expert, but I don't see any financial incentive for Qt Company in it. I'm guessing it would have to be a community fork, and that's a loooot of maintenance done for free, for which I doubt would be enough interest. -
@Chris-Kawa I am just seeing what people will say about my idea. I was thinking that the Qt developers have lots of experience regarding GUIs and if they create a pure Rust GUI library, it will be a very good one.
Maybe an independent project can be created alongside Qt, like you said, a fork. The existing promising Rust GUI libs such as Iced have very poor documentation.
-
@Pete-Carter The Rust community would certainly benefit from such a port, but you can't talk about it like it's a flip of a switch that would give you Rust Qt next week.
It's a very large library. You could talk about bindings (I think there are some projects that attempt that), but even that is a lot of work (see Pyside for example) and simple bindings give you absolutely no benefit, because you're still just calling the code written in original language.
Maybe my imagination is limited, but rewriting entire Qt to Rust I just can't see happening. It's too much work with next to no benefit. One or two language features here and there that help with productivity a bit is a non-argument to me when we're talking in the scales of the effort and manpower that is required.
-
@Chris-Kawa I agree with everything you said, except the part "It's too much work with next to no benefit."
My knowledge in C++ is poor BTW.
Now in 2023, you cannot keep using a language invented in 1985. Lots of things have changed since then. Also C++ is a buggy language and that costed a lot of money due to the faulty design. So i think in terms of security, using Rust will eliminate any possible memory bugs. You feel confident writing code in Rust and you are sure you will never make mistakes cuz the compiler prevents you from doing so.
Rust was made in the first place to solve the existing problems in C++.
Not to mention the amazing official package manager Cargo and the full tool-chain that comes with Rust.
Here are some projects that started using Rust for its many benefits:
https://blog.torproject.org/announcing-arti/
https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/
https://doc.redox-os.org/book/ch01-06-why-rust.htmlSo all i am suggesting is for Qt developers to use their experience in creating a parallel Rust GUI library or contribute in an existing one. I think the Rust ecosystem will grow and dominate no matter what, but having experienced GUI developers helping will make it grow much faster.
-
@Pete-Carter said in Rewriting Qt in Rust:
using a language invented in 1985.
Ok, then try to compile Qt with a compiler from 1985...
If you want a Gui written in Rust then start with it.
-
@Pete-Carter said:
Now in 2023, you cannot keep using a language invented in 1985
I can, I do and I don't see it changing any time soon.
Lots of things have changed since then
Including the C++ language. The original "C with classes" and C++23 are very different languages you know.
C++ is a buggy language
That's quite a bold statement. You sure it goes well with "My knowledge in C++ is poor BTW"?
You feel confident writing code in Rust
I feel very confident writing C++ code. I would write terrible Rust code and it would be full of bugs.
you are sure you will never make mistakes
Bwahaha. Sorry, that's funny :) Sure, keep telling that to yourself. I'm sure bug-trackers of Rust projects are all completely empty :)
full tool-chain that comes with Rust
You seem to be living in a bubble, so sorry for bursting it. Try to write and deploy a AAA game for a Sony console using all of its advanced APIs in Rust and its full tool-chain. I dare you :)
So all i am suggesting is for Qt developers to use their experience in creating a parallel Rust GUI library
That's quite a different thing from rewriting Qt in Rust.
Sure, if someone has the expertise in Rust to write a GUI library, also large amounts of time and incentive to do so, by all means. Sounds like a cool project to work on. -
@Chris-Kawa Chris is right. C++ is a much different language now than 1985. And current Qt has not used full features of new C++.
-
Look, I don't want this topic to turn into another language war, because it leads to nowhere. I'm not trying to diss Rust.
I understand Rust needs a good GUI library. That's clear. Cross platform UI is a big challenge for any language, because it's an enormous undertaking and requires a lot of expertise. I also understand that the roots of Rust are in compute and that there's not enough UI experts in that community to start such a project, so they're looking to interest C++ (and other languages) programmers, that have decades of experience. That's all fine. Crosspollination is beneficial to everyone and learning and using multiple languages is just personal growth.
But here's the deal - Rust, Carbon and all these other communities seem to have some sort of savior complex and that's honestly annoying. Whenever I see them entering a discussion with C++ crowd it goes something like "Your language is awful and needs to die. I'm here to save you from it. Come join the right cause" with expectation that they'll be greeted as messiahs and thanked for it. It's like the pointless political discussions - trying to "win" by calling the other side stupid as your leading argument.
C++ professionals don't need saving. They are doing fine and half the world is running on technology they know well. They're fine, really. C++ doesn't need to die either. It's evolving, it has wide spread support, lots of tools and ecosystems. It's doing fine.
It's ok to try to attract people to Rust. I've looked at it, written some hello world examples and it looks interesting. But in my work it's just a curiosity. It's nowhere near being in a state where I could transition to it even partially, or have any incentive to put in the enormous amount of work it would require. Despite of what the "get-rich-quick" crowd would like you to believe not all the tech is just blockchains, servers and clouds. There are a lot of C++ based industries Rust has not even a foot in the door and it won't anytime soon. Maybe in a decade or couple when it catches up to C++ ecosystems in those areas, sure, who knows. But by that time it's gonna have the same amount of baggage as that thing it tries to replace.
I'm just saying "Rust good because C++ bad" is very much a Rust crowd echo chamber mantra. For me personally it works like a red cape on a bull. Rust is an interesting emerging language with long way to go. That's it. Would be fun to engage with it if not for the presumptuous crowd it sometimes attracts.
-
-
Of course i am not trying to tell everyone to ditch C++ and only use Rust, this is impossible due to the huge amount of C++ code used in the industry. Yes there are others who think that any language other than Rust is trash, i am not one of those.
-
What i am trying to do here is to spread the idea of "Build Back Better". This will happen by checking for existing problems and solve them in the best possible way. Patching a language to keep it breathing for longer is good but it may not be the solution. For instance, you will have to give up on many improvements to keep backward compatibility.
-
I don't think anyone will disagree that Rust has solved nearly most of C++ problems, and that Rust as a language and tooling is much better overall than C++, anyone who used both languages for a while will clearly notice that. I have used both languages and experienced the great difference in security, compiler messages and ease of use, although I have not dived deep in C++. That's why Rust has been the most loved language for 6 years now according to stack overflow surveys. And the percentage of love is increasing every year.
- Its absolutely correct that the ecosystem of Rust is nowhere near C++. This is cuz C++ has been living for much longer. So i see that the best thing to do is to keep working with C++ while improving the Rust ecosystem to make it mature ASAP.
-
-
@Pete-Carter said:
What i am trying to do here is to spread the idea of "Build Back Better".
Build back from what? I'm not a US citizen, but I believe this term referred to post-pandemic recovery plan. C++ didn't have any world shattering event that requires us to recover from. Since 2011 standard it's been steadily improving and generally doing pretty well. The amount of tooling that got developed for it in that time is also significant. New platforms, libraries, IDEs, toolchains, package managers, sanitizers, profilers and much much more. The ecosystem is richer than ever and it's not stopping.
Patching a language to keep it breathing for longer is good but it may not be the solution
See, you keep talking about C++ like it's some sort of wounded animal that needs to be put out of its misery. It's not. It's doing fine and evolving at quite a rapid pace.
I don't think anyone will disagree that Rust has solved nearly most of C++ problems
Ha, there's your bubble thinking again. I think there's quite a number of people that would disagree :) For isolated example my two biggest problems with C++ are compilation times and dependency management. I don't know Rust well, but from what I read the first one is also a big problem in Rust, so switching does nothing for me. As for second - it's true that Rust has well integrated package manager, but so what if it has easy packages but doesn't have packages I need? And guess what - C++ people are not sleeping. There are couple of C++ package managers that start to gain momentum. Sure, there's not a perfect one yet, but as an example - I've been using vcpkg for the last two years or so and I am pretty confident that with the pace they're improving it's gonna be a solved problem in just a few years. If not by that one then by another. When that happens I'm good. I really don't need Rust. I might play around with it but I don't need it. Obviously I'm just a single person and needs of others vary, but come on, "solved nearly most of C++ problems"? I won't believe you're that naive.
That's why Rust has been the most loved language for 6 years now according to stack overflow surveys
Wow, 5746 people like Rust on SO. Cool. I'm very happy for that miniscule fraction of population.
So i see that the best thing to do is to keep working with C++ while improving the Rust ecosystem to make it mature ASAP
That's the thing - not everyone is as convinced as you that C++ needs Rust. C++ is doing fine and doesn't need Rust to mature fast. It's cool for that community if it does, but personally I'm good either way. I don't check "is Rust good yet" website every day when I wake up. I don't think about it much at all and I'd wager I'm not the only one.
-
First of all, Qt is huge and most people will think of different things when talking about porting Qt (to Rust or anything else). I use QWidgets to compile for Windows, Linux, and macOS. Others mostly see the use of QML. Some think of Android and iOS when talking about Qt (because it can do that as well). Qt has also long been drifting away into automotive. Besides the pure GUI part of Qt there are many other modules like monetization, etc. Qt also is a full framework with classes for networking and file i/o.
From today's perspective it would be quite stupid to develop a library which does everything in the same way as Qt. Qt solved a lot of problems back in a time when there wasn't a good (enough) standard library. With version 6 Qt is moving closer to the STL. I would hope that the creators of Rust were smart enough that string, container, file and network classes are good enough that they don't need a Qt-port replacement.
It would be nice if Qt were to reinvent itself in C++. Today we got smart pointers. This could easily replace Qt's memory management solution using parenting. Common advice in modern C++ is to (almost) never use
newwhich doesn't work with Qt. One of my main gripes with Qt is that all GUI programming must be funneled through a single thread (explicitly). This was fine back in the days when Qt was invented and computes only had a single core. In theory it would be easy to have a dedicated GUI thread running in the background and the programmer does not have to care to make GUI calls within that thread. Certainly, for performance reasons one should think this through for an optimal solution. 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. C++ also needs to evolve in a way that we can get rid ofmoc. Hopefully, Rust has a solution for this already in place.Don't get me wrong: Qt is currently the best toolkit out there for the kind of software I write, but it is far from perfect or modern. Writing a GUI toolkit for Rust is a good idea and you can certainly borrow and learn from Qt. But, for a modern GUI toolkit you should certainly not port Qt to Rust. Design a new toolkit with modern ideas and modern solutions for modern problems.
-
I don't have any use for rust in the first place, so I see no value in it. IMHO, rust is another solution in search of a problem. Idle hands are deadly hands and when smart kids are bored they wreak havoc that has bad long term consequences.
Rust solves no problems for me. it just does things differently...the new cool way...
-
@Kent-Dorfman (Disclaimer: I haven't used Rust.) I do think that Rust solves one problem (from what I've heard): By default you don't have a problem with dangling pointers. Can anyone confirm that this main claim of Rust holds up? You can still explicitly write unsafe sections where you are allowed to shoot yourself into the foot. Probably a bad thing is that you can't use any C libraries if you want to stay on the safe side of the fence exclusively. That would be a major problem.
As long as this is the only problem that Rust solves, I agree that it is not worth switching. It has become very easy to write "safe" code in C++. I haven't had any problems with dangling pointers in new C++ code in years. As long as you use modern C++ and modern approaches (no non-owning raw pointers) you are quite safe. So, the only difference between C++ and Rust is that Rust is more explicit about this because it drops backwards compatibility. For C++, however, it comes back to programming style. Once modern C++ becomes a habit you will automatically avoid this kind of problem. Yes, C++ allows you to shoot yourself into the foot (as does Rust, but it makes it harder). If your habit tells you to keep the gun in the safe, accidents don't happen (unless you get out the gun).
Is there any other problem Rust solves compared to C++?
-
@SimonSchroeder As far as performance goes, Rust is both fast and memory-efficient: this is what I read.
-
@JoeCFD Rust, like C++, is a systems level language, so they are as fast and memory efficient as the user can make them to be. It doesn't have any inherent overhead like virtual machine, interpreter or garbage collected languages. I'd guess any differences with C++ would come down to compiler maturity, which I'd expect to be more or less converging by now. The backend is often shared anyway and sure, one or the other will come up wits some optimization in the frontend, but that's usually something that gets ported to other languages with time too. It's not like compiler guys are sleeping or not sharing.
Rust, learning from the past and not weighted down by legacy code, has better defaults than C++ e.g. move instead of copy by default, immutability by default and some memory management concepts like ownership or borrowing. Those are embedded in the language, where in C++ they've been added with time often in form of traits, new constructs or standard library additions. The value of Rust depends on how good or poor C++ you write, and can vary from game changing to insignificant.
IMO the memory problems in C++ come down mostly to poorly educated programmers that we see more and more. From what I observe the ChatGPT generation can shoot themselves in the foot even with a pillow, so if your company has this problem then switching to Rust might be beneficial (if you can actually manage to switch), but the more experienced professionals you have the faster cost/value perspective of switching is diminishing.
-
@Chris-Kawa Memory problems in C++ can be handled much better now than before. It may not a big deal anymore. Have not tried Rust and not sure how faster it is, for example in a sparse matrix solver.
-
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 :)
