I have had the view that safety is typically not the most important goal of a project (user satisfaction is). I have often said that safety can get in the way of writing software that is useful. It's great to see a real-life case with Rust from someone who obviously tried very hard but ultimately had safety get in the way of writing the software they wanted. Hopefully, Rust will evolve to interface with the "unsafe" world in a more ergonomic way.
Giving up on wlroots-rs
41–50 of 126 posts
Re: Giving up on wlroots-rs
#42Interesting post that show some current limitations of Rust, especially when not being able to control the design entirely.
Rust's ownership system makes it harder to deal with the kind of dynamics wlroots exposes... It seems to me that the issue here is that there is no consensus (e.g library) on how Rust should deal with those issues, so if you want to just to provide bindings to a dynamic system you end up writing middle-ware that deals with that kind of dynamics in a Rust idiomatic fashion (taking advantage of ownership) instead of focusing on the task at hand. It somehow destroys Rust's promise of productivity.
A Rust project of mine[1], in an early stage and currently paused, deals with those issues (probably in a way similar to the Handles described in the post) by providing Service smart pointers (i.e, Svc) and a component-framework that helps deal with the dynamics of a service being unregistered (e.g, a monitor unplugged, or a dynamic library unloaded) ; that component framework helps you be sure that if your struct contains a Svc, that service is still available when you're called, or the component reaches an invalid state.
In general, it seems to be an area where Rust's ecosystem is still very early and would benefit from more input (such as this post) and consensus.
Regarding the callback-hell issue, that "dehandle" macro looks very much like async/await, and it looks like it could be implemented either in terms of async/await (still unstable) or generators (even more unstable).
Hopefully similar projects will be more likely to succeed as Rust and its ecosystem mature.
Re: Giving up on wlroots-rs
#43Everything the author and the commentors here have said is completely legit. I'm not looking to start a war. And I completely acknowledge that what I'm about to say might be wrong as I haven't seen the author's code or the code of wlroots.
But I have to wonder if the design decisions of wlroots itself may be dubious. If it's this hard to manage memory safely when you're trying to wrap the API in a language that demands you're kept accountable for memory safety....
Re: Giving up on wlroots-rs
#44I can't speak to every issue which the author might have encountered, but there is a better solution to the lifetime management problem than the two mentioned in the article. Instead of this: fn some_wlroots_callback(output_handle: OutputHandle, surface_handle: SurfaceHandle) { output_handle.run(|output| { surface_handle.run(|surface| { // maybe some more nested layers... }).unwrap() }).unwrap() } One can do this: fn…
I just want to say, having spent a bunch of time writing a context-management framework for embedded targets that I jettisoned because it sucked, this is a great approach I'm excited to experiment with. Thank you for the comment.
Re: Giving up on wlroots-rs
#45A good post, thanks for sharing. > I want to make one (mildly controversial) thing clear: rewriting a library for the sake of only using Rust is not good engineering. Strong agree. > A literal rewrite of a project to Rust is not interesting, it’s not useful, it just causes churn and splits ecosystems. Time would be better spent either working with existing solutions that already have the effort put in to make them co…
I'm surprised to see you agree strongly. A Rust re-write for the political/ideological reason of "only using Rust" seems not good engineering by definition - it is not an engineering decision.
However, most of the time that someone would rewrite for the sake of using Rust, it would naturally be to get the advertised benefits of the language. If you believe you will have safer, more manageable code in pure Rust, you are making a valid choice.
The fact that efforts will be split is unfortunate, and should factor into such decisions. But that doesn't seem a strong argument on its own - if you believe such a change is for the better then there's no way to avoid breaking some eggs.
Re: Giving up on wlroots-rs
#46Does wlroots itself present good code quality or it is basically a horrible wrapper to support every Xorg use case?
Re: Giving up on wlroots-rs
#47A pity wlroots itself isn't written in Rust.
Re: Giving up on wlroots-rs
#48> Way Cooler is a Wayland compositor that was written in Rust using wlc I know it is not easy, but I wish the author could have started with a paragraph that could help someone like me know whether or not the rest of the article would be something I would like to read. How about something like this (and of course I may some of the facts wrong, but I want to be as constructive as I can): "Wayland is a Windows manager…
You weren't the audience of this article. Since he wrote it as a blog post on way-cooler.com he surely was expecting his audience to be people familiar with Way Cooler, Wayland and Rust. He doesn't have a responsibility to dumb it down for you. And anyway it only takes a few minutes for you to get the context. Which you did, good job.
[deleted]
Re: Giving up on wlroots-rs
#49I can't speak to every issue which the author might have encountered, but there is a better solution to the lifetime management problem than the two mentioned in the article. Instead of this: fn some_wlroots_callback(output_handle: OutputHandle, surface_handle: SurfaceHandle) { output_handle.run(|output| { surface_handle.run(|surface| { // maybe some more nested layers... }).unwrap() }).unwrap() } One can do this: fn…
Author here. The problem with that design (which is a great design given what I presented in the article by the way!) is that it doesn't allow you to share handles across callbacks, which is mandatory to do anything interesting. I'm assuming here that you can't use the handles except for that callback context. If you can, then that presents a different problem. https://play.rust-lang.org/?version=stable&mode=debug&ed…
The intent is that handles can be used across contexts (as long as both contexts are from the same instance of wlroots) - the context checks that the handle is valid before unwrapping it. Could you clarify what you mean by it presenting a different problem?
With regards to the leaking issue - that's not actually correct. `Box::leak` does not give you access to the context with the `'static` lifetime, assuming the lifetime of the context is not 'static (that would fundamentally break rust's safety guarantees).
The only potential problem is that the destructor for the context may not run (cf. leakpocalypse). If the implementation requires the destructor to run, then you are right, you should never give ownership of the context object, it should be passed into the callback by reference. If you need access to a context outside of a callback, then you should use the callback-style:
with_context(|ctx| {
... do stuff ...
}
Re: Giving up on wlroots-rs
#50A pity wlroots itself isn't written in Rust.
C is the lingra franca of programming. By writing wlroots in C, we make it easy for a half dozen projects to make bindings to other programming languages. Rust is the only one that seems to have failed, and it's not surprising given the constraints of the language.
wlroots brings together over a dozen different libraries and interfaces which are implemented in C. You'd have to repeat this process a dozen times over, running into the same problems which caused Timidger to abandon wlroots-rs, only more so. And for what? wlroots works great and didn't require shaving a thosuand yaks.