I do agree. There is, however, the problem of fragmentation that is a result of legacy code and the insistence of large corporations to be protective over their IP. As such, fragmentation is as much a consequence of protectionist behaviour as it is of technological challenges.
RISC-V is a large step in the right direction for this run-anywhere aspiration. A large part of the fragmentation is due to hardware incompatibilities. x86-64, and ARM. Based on what I can see, there's a large drive from future-thinkers on RISC-V to overthrow the problem of vendor lock-in and the resultant fragmentation it causes. As such, a project like Libre GPU roadmap could be very successful.
Stated otherwise, there could be 'one ISA to rule them all', and its large-scale success could solve a lot of the fragmentation problem. Based on what I can see from the RISC-V ecosystem. This is exactly what a whole bunch of vendors are planning on doing.
A browser engine written entirely within Rust should do 10x better on the security front, conservatively speaking. I have no idea how/when that would happen, but it could?
A browser engine written entirely within Rust should do 10x better on the security front, conservatively speaking. I have no idea how/when that would happen, but it could?
This exists:
And there's a Rust GUI framework based off of its rendering engine (early stages of development):
Iām actually about to build a simple desktop app using this crate. I love the ideas behind it. In a perfect world youād be able to use something like this to write an app for web, mobile, and desktop all at once with a crate like this in rust, but itās still early, so you never know!
You seem to assume that all browser security problems are memory safety issues. They aren't. Many of them are inherent in running basically arbitrary e.g. JavaScript from various sources, while others are an unhealthy combination of bad habits of web developers and obscurities in web-related technologies stemming from backward compatibility or misdirected standards. Neither of these are easily mitigated using a memory-safe language.
You seem to assume that I assume that all browser security problems are memory safety issues. I don't. Having said that, about half of them are memory related, and most of the more serious issues are memory related. The whole gamut of browser related problems given here PentesterLab: Learn Web App Pentesting! should be of little concern for a GUI implementation. Unless you're suggesting a GUI implementation should somehow be able to solve those problems as well? It should be obvious that the GUI library and webpage building is not the same thing.
After digging around a bit yesterday trying to assess the current state of affairs in rust gui development, I found this. So now Iām wondering if there is any reason not to just invest in making integration between rust and qt as seamless as possible? I mean, qt is already well established, qml is really nice, it works pretty much everywhere , theyre even working on wasm support.
Is there some sort of technical merit that I am unaware of or simply too ignorant to understand in creating a new ui framework for rust from scratch as opposed to just making rust <ā> qt interop as idiomatic as possible from the rust developersā perspective?
For instance, after watching this video, Itās clear that while this approach to using qt with rust can work, there are still holes that need to be filled to make typical development easier, things like making the lib macro based, better integration with cargo, etc.
As I said before, Iām definitely not a gui programmer, so Iād love to be better informed on the pros and cons of this approach so I can understand why or why not it may be suitable. At this point, it seems like the easiest approach though, Iām just wondering why it doesnāt seem to be being taken into consideration? I mean, it worked for python.
Itās not that it is not taken to consideration. The Rust-Qt-Binding-Generator is really great and just to throw in another approach qmetaobject also is. The main problem i see with Qt is deployment/dependencies and it feels alien programming it with Rust. I am used to Qt & C++ for work and i really like Qt/QML even though i have to use C++ ā a language i never really warmed up to ā but the combination is quite useful and both complement each other. We use Qt specifically to create cross platform application and building versions for macOS / Windows / Linux can get tricky (unfortunately quite tricky on Linux, the system i primarily use at work and private). And the same applies when you try to make the same with Qt & Rust. It just feels weird if you are used to the simple build system cargo provides. The first time i tried Azul or OrbTk it just felt right to me to just call cargo run and it does exactly this: run. I really donāt want to fiddle with the hole Qt libraries if i can avoid it. So the more āpureā Rust the GUI lib gets, the more happy i get because cargo can do its magic.
Also Qt is closely intermeshed with C++ and to OOP to some extend and i just donāt feel like thatās the way i want to program applications with Rust. Qt has the big advantage to be very mature but that does not mean its still the way āweā want to program. I think with Rust we have the great opportunity to bring fresh air in this field, especially if you bring things like Flutter into the game which i really like atm. It just feels like a ābetterā way to achieve my goals, iāve never felt so productive. And i want something like this feeling with Rust. Yes there are mature Frameworks out there that you can use today but why not try to do it better? I was used to write mobile application with their respective ānativeā sdkās and i was ā for a long time ā against things like react native, ionic, xamarin, titanium ā¦ etc. because they felt suboptimal. With flutter things dramatically changed for me. We shipped our first mobile app this week with flutter and weāre all quite happy with the result. We donāt know if we change our hole mobile story in our company to flutter any time soon, but it made a good impression. I donāt think i will ever write ānativeā mobile applications again for private projects ā the same āshiftā that happens with C++ -> Rust. I think i havnāt touched C++ for almost two years now in private projects since Rust fully took over the game (same happened to Python, Java, C#, D ā¦ Rust replaced them all)
If things are dramatically better in some departments/tooling it can really drive people away from things that are ājustā mature but lack the ājoy of programmingā part. Flutter is really a joy opposed to activities, intents, xml ā¦ navigation controller, segue, storyboard shenanigans. And i hope Rust can do the same thing with Qt, its mature but what if we can do better?
Thanks a lot for your response, as someone not versed in gui development in general, what you say makes a lot of sense, especially after checking out orbtk. I really hope this project stabilizes in the near future and becomes a way to create mobile apps completely in rust. I've had an idea for a little app I want to make for quite a while now, but mobile dev just isn't my thing,
For those of us just following along but not really wanting to deal with code yet, itād be really helpful if there were screenshots of the examples. I know thatās asking a lot, as you already have a screenshot on the front page. But I think itād help sell your toolkit if it was clear what widgets were supported and what they looked like.
The visual design of the widgets in the example are not finished now. But our design team will continue their work tomorrow. I will upload more screenshots after it is finished and implemented. I hope next week.
I will also write some lines about OrbTk on reddit in the next days.
.