51–60 of 126 posts
Does wlroots itself present good code quality or it is basically a horrible wrapper to support every Xorg use case?
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 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 a…
> it would naturally be to get the advertised benefits of the language
I think "naturally" is doing a lot of work here; this is not "for the sake of using Rust", it's to gain the benefits of the language.
A 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,…
> wlroots brings together over a dozen different libraries and interfaces which are implemented in C.
This is a great argument that it should be written in C, though.
> 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…
Definitely. So often, whole articles and even much of the ensuing discussion will be using project names and acronyms that I don't know about. A sentence or two of context, or even just links going off to the project/acronym the first time it is used, are wonderfully useful for the wider audience.
A 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,…
Rust is the same in this regard, you can bind it to any other language. And it doesn't have the horrible downsides of C. So why not use it?
> wlroots brings together over a dozen different libraries and interfaces which are implemented in C.
That's an issue as well, and this of course runs deep. But starting somewhere should be still possible.
Earlier quoted context omitted.
This is also something that causes some pain when using C++ with RAII. Logically it makes some amount of sense that you have e.g. a C++ wrapper for a texture in OpenGL, and it knows to call glDeleteTextures in its destructor. HOWEVER, the destructor can now only be called if the OpenGL context is active, and the texture may be deleted if the context is lost (which can happen). At some point anybody who's tried to wra…
re: the handles to handles stuff ... I don't think that's so silly really, when you are talking about a resource that in some fundamental sense belongs to a different system (in this case OpenGL). Sure, that system gave you a handle, but if the semantics of managing that handle aren't 1:1 matched with your languages model of things, another level of indirection is a clean way to handle it.
> 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…
1. articles should start with a brief summary of their context, arguments and conclusions.
2. articles should explain their terminology.
The first point I agree with (and believe most do). But the second point is arbitrary, and in my personal opinion, the linked article is fine in this regard (anyone familiar with X-Windows should be familiar with Wayland as a concept, and every single article related to Wayland cannot be expected to explain core abstractions like compositors).
Earlier quoted context omitted.
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,…
> By writing wlroots in C, we make it easy for a half dozen projects to make bindings to other programming languages. Rust is the same in this regard, you can bind it to any other language. And it doesn't have the horrible downsides of C. So why not use it? > wlroots brings together over a dozen different libraries and interfaces which are implemented in C. That's an issue as well, and this of course runs deep. But s…
Because I don't like it, and I do like C. Rust is not the second coming of Christ, it's a programming language and has many shortcomings and tradeoffs.
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: 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…
Earlier quoted context omitted.
I agree and was going to say the same. That there was a huge challenge in writing code to manage memory ownership, is not surprising because memory ownership is so fluid and adhoc in C and its derivatives. And when you are asked to make that ownership explicit, if the original designers hadn't been thinking about it, you get a lot of cases which they would not have considered. I would like to see a compositor written…
Not a wayland, wlroots or rust expert, but dollars to donuts says that it's not "memory" management[1] at issue, but resource allocation on the other side of the graphics driver. Vertex arrays, textures, framebuffers, shaders et. al. all need some kind of allocation strategy, can in the modern world often be shared between process contexts, and they really don't fit well into the metaphors of either C or Rust. But wh…
I've hashed this out extensively when looking at implementing a database kernel in Rust (I’ve had Rust experts among my C++ programmers). Technically it is possible to implement these things in a safe way in both C++ and Rust. However, it comes at a cost of an unreasonably complex and inefficient software architecture in either language, so you would not want to actually do it that way in a sane code base.