Giving up on wlroots-rs

283 点作者 Bl4ckb0ne大约 6 年前

19 条评论

A 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 correct or to come up with new green-field projects.This... I'm not so sure about. It really depends on what your objective is. For example, if your goal is to learn, you're not going to cause churn, and you're not going to split ecosystems. Working on project you already know well is a good way to learn, because you can focus on the language, not the project.This also isn't exactly a re-write, in my mind. I mean it is, and it isn't. This is because...> The biggest problem when wrapping wlroots was defining the ownership model of the objects that wlroots exposes.The pain here isn't a re-write, it's an integration with an existing system. That's a good reason to not use something different! I also think this is interesting because it demonstrates something that's often said in discussions about Rust, but mostly in the abstract, and that's that Rust's rules influence the design of your system. It will guide you away from designs where the ownership of components is unclear. To many people, this is a benefit, but it can often cause struggles when learning. And, it can often cause struggles in situations like this: where you can't really re-write some external component to fit in the rules.That being said, there should be a way to do the ownership part that makes sense, but I don't know wlroots well enough to comment.That being said> Currently there is 11 THOUSAND lines of Rust in wlroots-rs. All of this code is just wrapper code, it doesn’t do anything but memory management.is also super legit. Managing this kind of thing is a pain. I can certainly understand not wanting to do it.

评论 #19779155 未加载

评论 #19779611 未加载

评论 #19779894 未加载

评论 #19779570 未加载

评论 #19780370 未加载

quietbritishjim大约 6 年前

I know very little about Rust or Wayland (I suppose I'm not the target audience) but I got lost very quickly here:> A Wayland “output” is the resource that represents a display device. Commonly this means it handles a computer monitor. This resource could disappear at any time in the life cycle of the application. This is easy enough to imagine: all it takes is a yank of the display’s power cord and the monitor goes away.Surely even if a physical monitor is connected from a computer, the object representing it doesn't instantly go away? If it literally got freed as soon as the user disconnected the monitor then any access to such an object would be dangerous as you could be accessing an object after it's freed, or even another valid display object that got allocated into that space in the mean time.Instead, I would expect an object in that situation to go into some error state, and even that might only be picked up when you perform certain operations. If that were the case, I don't really see how Rust lifetimes are a problem.Since this was the main summary of the problem for laypeople like me, it made the rest of the article quite hard to follow.

评论 #19779229 未加载

评论 #19779221 未加载

评论 #19779140 未加载

Diggsey大约 6 年前

I 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:<pre><code> 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() } </code></pre> One can do this:<pre><code> fn some_wlroots_callback( ctx: CallbackContext, output_handle: OutputHandle, surface_handle: SurfaceHandle ) { let output = ctx.get(output_handle); let surface = ctx.get(surface_handle); } </code></pre> This is safe, because the lifetime of "output" and "surface" can be bound to the lifetime of the "ctx" (whose lifetime is controlled by the library: the library simply has to make sure that "ctx" is not accessible outside of a callback).edit: Realised you can't tell that there's an implicit lifetime in `CallbackContext` here:<pre><code> struct CallbackContext<'a> { ... }; </code></pre> OR<pre><code> type CallbackContext<'a> = &'a CallbackContextImpl;</code></pre>

评论 #19779479 未加载

评论 #19779886 未加载

ChrisRR大约 6 年前

Interesting to see someone's reasons for moving back from rust to C. Normally it's the other way round.Speaking as a C developer who has dabbled in Rust, It's always good to see the thoughts of someone who has spent a fair amount of time with the language who can give it a fair assessment.

herodotus大约 6 年前

> Way Cooler is a Wayland compositor that was written in Rust using wlcI 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 developed as a better alternative to X-Windows. Way Cooler is a tiling Wayland manager, written in Rust, and designed to be easily extendible. In this article I describe my experience in trying to refactor it, for reasons that will be described below. I will also explain why, in certain instances, C was a better choice for this project than Rust."

评论 #19779672 未加载

评论 #19779508 未加载

评论 #19780746 未加载

评论 #19780201 未加载

pcwalton大约 6 年前

I may be missing something, but what's wrong with the first example? The fact that you can leak an object shouldn't really matter for memory safety if it's just a handle to an object that the server manages. Yeah, it could go wrong, but it won't be unsafe. Object handles are essentially file descriptors, right?In general I think there's a tendency to overcomplicate safety features in Rust. The solution to an overly-complicated system isn't to throw the whole notion of safety out the window: it's to look at exactly what the complexity is buying you. If intricate combinations of Rust features are one extreme of the safety spectrum and C is the other extreme, there's frequently a happy design medium somewhere in the middle.Edit: Looks like oconnor663 over on Reddit had a similar but more specific proposal, which probably works: <a href="https://www.reddit.com/r/rust/comments/biq864/comment/em2kipe" rel="nofollow">https://www.reddit.com/r/rust/comments/biq864/comment/em2kip...</a>

评论 #19782164 未加载

mcguire大约 6 年前

"A Wayland “output” is the resource that represents a display device. Commonly this means it handles a computer monitor. This resource could disappear at any time in the life cycle of the application. This is easy enough to imagine: all it takes is a yank of the display’s power cord and the monitor goes away. [Except it can't; it can only disappear between callbacks?] This is basically the exact opposite of the Rust memory model. Rust likes to own things and give compile-time defined borrows of that memory. This is runtime lifetime management that must be managed in some way."Something leads me to believe that there is something very wrong with the architecture of wlroots-rs. The output should be attached to a callback parameter or something, maybe? I don't know enough about Wayland to say, but something ain't right.

评论 #19779504 未加载

kccqzy大约 6 年前

This code<pre><code> 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() } </code></pre> is just screaming continuation monad. You see the same code pattern in early Node.js code (sometimes leading to callback hell). In the JavaScript world, the problem was solved using Promises, and then async/await syntax. But more fundamentally, this is an instance of the continuation monad at work.The continuation monad transformer is defined as<pre><code> newtype ContT r m a = ContT { runContT :: (a -> m r) -> m r } </code></pre> and is nothing more than just a function that takes a callback. If this were Haskell, one could just write<pre><code> stuff = runContT $ do output <- ContT (run outputHandle) surface <- ContT (run surfaceHandle) -- and then maybe some more nested layers -- etc </code></pre> Granted, continuation code can easily be misused to produce an incomprehensible mess in Haskell (its full generality can be compared with goto), but with Rust's FnOnce trait, the scope for misuse is considerably reduced.

评论 #19780418 未加载

lucideer大约 6 年前

Question (for any more knowledgable readers here) from someone with a somewhat shallow understanding of the topics discussed:Does this end up being primarily a negative reflection on the general structure of:(a) Rust(b) wl-roots(c) Wayland(d) all three(e) none of the above, it's merely the incidental reality of trying to write code that's compatible/usable across multiple language ecosystems and none of the 3 projects can do much to improve this situation.

评论 #19779032 未加载

评论 #19779255 未加载

评论 #19779297 未加载

评论 #19780858 未加载

simag大约 6 年前

Interesting 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<T>) 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<Foo>, 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.[1] <a href="https://github.com/magnet/socrates-rs" rel="nofollow">https://github.com/magnet/socrates-rs</a>

4bpp大约 6 年前

How does Rust handle these problems in the context of file I/O? I'm sure there is an axiomatically idiomatic (official) implementation of it as part of the language distribution, and at the same time file handles seem conceptually very similar to display handles and should have similar failure patterns (space can run out, a disk can fail, a plug-and-play disk can be yanked out at any time...).

评论 #19779577 未加载

newnewpdro大约 6 年前

I only skimmed the article, but the description of outputs and their asynchronous lifecycle making things complicated just made me think of what's become known as the ECS pattern in game development.Your outputs sound just like entities in a game. They come and go as they please, and you often have multiple references to them from myriad places since entities may interact with many parts of the game.I suspect if you investigated the established techniques for implementing ECS-style games in rust, you might find some simpler and established solutions for your troubles.

josteink大约 6 年前

Personally I think Rust is a great language. That said it may not be great for everyone nor a great fit for every problem.Sometimes trying and admitting failure is a perfectly rational and valid option.

Lowkeyloki大约 6 年前

Everything 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....

ac130kz大约 6 年前

Does wlroots itself present good code quality or it is basically a horrible wrapper to support every Xorg use case?

评论 #19780029 未加载

vectorEQ大约 6 年前

good ol C :). Thanks for sharing these experiences. Happy to see some example of the places where rust still falls a little short / is a bit too restrictive for system programming. a lot of people deny this, but there's plenty of situations where you just want plain old C for it's straightforwardness to implement your own design. if you want to do it the 'rust' way, you find yourself restricted in all kinds of ways. if you can live with those restrictions it's great, but sometimes you just get stuck. Good luck on the rebuild in C!

mempko大约 6 年前

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.

shmerl大约 6 年前

A pity wlroots itself isn't written in Rust.

评论 #19780023 未加载

scoutt大约 6 年前

> When the benefit at the end of the day is just so I don’t have to write C, that doesn’t really make it worth it.This line not only summarizes the content of the article, but I'm afraid it may also describe the actual situation of porting C/C++ code to Rust.