81–90 of 126 posts
Does wlroots itself present good code quality or it is basically a horrible wrapper to support every Xorg use case?
wlroots is generally highly regarded in the Wayland community, both in terms of technical design and code quality. There's a reason that every Wayland project which started since wlroots has used wlroots, and those who didn't at first eventually rewrote their code to use wlroots.
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,…
C is the lingua franca of UNIX based platforms. Thankfully not all OSes bow to it.
On Windows and Android if I'm interfacing to a Rust/Python/Java (on Windows)/C++ (on Android) library I still do it by going through C.
Earlier quoted context omitted.
wlroots is generally highly regarded in the Wayland community, both in terms of technical design and code quality. There's a reason that every Wayland project which started since wlroots has used wlroots, and those who didn't at first eventually rewrote their code to use wlroots.
Is there any indication that mutter and kwin will rewrite to use wlroots? That would be glorious.
Earlier quoted context omitted.
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.
And just think about what most file and I/O wrappers, that are part of the standard library in most higher level languages, e.g. file objects in python, streams in C++ etc., naturally do: They also just wrap (for example) POSIX file descriptors, which are handles, with their own handles, i.e. the file object/Stream/whatever.
With e.g. std::ofstream, you are wrapping a handle, such as a POSIX file descriptor. So that part of your description is accurate.
However, this is different from what happens with OpenGL. The problem is that if you wrap an OpenGL texture (which is a handle), you end up with some problems because you can only free it with the correct context active, and it might become free for other reasons besides the wrapper being destroyed. So you are no longer wrapping a handle (like std::ofstream), but you are actually creating a new handle-to-handle, and wrapping that, and explicitly managing the lifetime OpenGL resources with a separate object somewhere else.
Of course, you could just wrap an OpenGL texture, explicitly decide not to handle context invalidation, and then be careful to ensure that your objects get destroyed with the OpenGL context active. You lose some flexibility and you have to babysit RAII to be sure it "does the right thing".
So what I'm saying here is that OpenGL textures are not like file handles.
Earlier quoted context omitted.
> 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…
>So why not use it? 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.
Earlier quoted context omitted.
> rust rewrite means you are more likely to invite contributions from a larger community I'd be really interested to know why you think that's the case. Somewhere around 3% of programmers know Rust, while over 20% know C. https://insights.stackoverflow.com/survey/2019#technology Naively, I would have thought that a C project would invite contributions from a much larger community. Sure (as I've personally experienced…
That's not how OSS contributions work. C# is wildly popular in enterprise, and most of New york runs on F#. How often do you see .NET repos on Github?
Well, ok, if we're going by GitHub repos, C has 117k repos with at least one star and Rust has 11k. That doesn't seem to be that different than then number of programmers as a whole.
(FWIW, there are 104k starred C# repos and 2k F# repos, which doesn't seem all that out-of-line with the popularity of those languages as a whole.)
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: https://www.reddit.com/r/rust/comments/biq864/comment/em2kip...
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…
If the model doesn't fit perfectly into Rust's ownership system, I usually just do the checks dynamically and panic, or accept logic bugs (but not memory safety bugs), if things go wrong. Is that admitting failure? Perhaps. But it's also just choosing my battles. I'm trying to keep my code clean and ship, not prove it correct. Memory safety problems are pernicious enough that it's worth significant effort to rule them out, but almost everything else is a judgment call.
Earlier quoted context omitted.
> C++ lets you have as many iterators as you like into the same container While it's true that Rust doesn't let you have multiple mutable iterators, it's worth pointing out that you can certainly have multiple immutable iterators. let items = &[42, 101]; // All products (a*a, a*b, b*a, b*b) for x in items { for y in items { println!("{}", x * y); } } println!(""); // Pairwise products (a*a, b*b) let pairs = Iterator:…
That's really not what I'm talking about. In your example you are using multiple iterators to iterate over the same structure multiple times, but in C++ you can use pairs of iterators to represent ranges. For example, I can have three iterators i, j, and k, which represent two ranges: i..j and j..k. Even if i, j, k are const iterators, it's not pleasant to translate this to Rust. So it's not an issue of whether Rust…
fn main() {
let list = &[0, 1, 2, 3, 4, 5, 6, 7, 8];
let i = 0;
let j = 4;
let k = 8;
let iter_ij = list[i ..= j].iter();
let iter_jk = list[j ..= k].iter();
let pairs = Iterator::zip(iter_ij, iter_jk);
for (a, b) in pairs {
println!("{}, {}", a, b);
}
}Earlier quoted context omitted.
I'm surprised nobody mentioned this yet- a rust rewrite means you are more likely to invite contributions from a larger community.
> rust rewrite means you are more likely to invite contributions from a larger community I'd be really interested to know why you think that's the case. Somewhere around 3% of programmers know Rust, while over 20% know C. https://insights.stackoverflow.com/survey/2019#technology Naively, I would have thought that a C project would invite contributions from a much larger community. Sure (as I've personally experienced…
Also for pure rust projects the development environment is easier to set up: cargo+rustc do everything vs. autotools+make+installing system wide libraries+ccache+gcc (just what I've seen in the wild).