Earlier quoted context omitted.
C is the lingua franca of UNIX based platforms. Thankfully not all OSes bow to it.
>Thankfully not all OSes bow to it. Right, just the successful ones.
Not Windows.
Giving up on wlroots-rs
91–100 of 126 posts
Re: Giving up on wlroots-rs
#92Earlier 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…
Ah, I understand. You're referring to how iterators in C++ are generalized indices into their collections. Certainly, Rust iterators have a more constrained purpose.
I personally prefer having separate constructs for iteration and indexing, so I think it's a matter of taste.
Re: Giving up on wlroots-rs
#93Re: Giving up on wlroots-rs
#94Earlier quoted context omitted.
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.
Maybe I didn't explain what's happening in OpenGL properly, because that comparison doesn't work at all. 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…
Incidentally, some of the people working on safe OpenGL wrappers ran into similar issues with the blog post, thanks to similar problems.
Re: Giving up on wlroots-rs
#95Earlier quoted context omitted.
I think we're differing on semantics. > 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.
I agree, but naturally I think that’s the natural interpretation :) Speculating: I think many Rust rewrite projects are criticised under “for the sake of it” when in fact there is a clear decision that Rust is just a better choice in 2019 (i.e. the decision was not political, but the criticism assumed it was). Many of those will nonetheless peter out because forks are hard. Such a result is only a partial judgement o…
> I think many Rust rewrite projects are criticised under “for the sake of it” when in fact there is a clear decision that Rust is just a better choice in 2019
Yes, I think that's true as well.
Re: Giving up on wlroots-rs
#96Earlier quoted context omitted.
Quick answer, without understanding all the details: a weak-pointer-like structure that performed all the necessary locking and checking before giving out access to the underlying SHM. Rust's borrow checking is more or less a formalization of C++'s RAII style; in my experience, solutions for that translate relatively simply.
Rust's borrow checking does not correspond to RAII. A simplified explanation is that borrow checking gives you the guarantee that mutable references are unique and immutable references do not change. Rust's lifetime system is vaguely like RAII, but the C++ type system gives you no way to create an object with lifetimes that don't correspond to some scope. In Rust this is done by moving values, but in C++ this is not…
> but the C++ type system gives you no way to create an object with lifetimes that don't correspond to some scope.
Counterexample: a data member of a class has a lifetime tied to the lifetime of the containing object instance, rather than to a lexical scope.
Re: Giving up on wlroots-rs
#97Earlier quoted context omitted.
Which is fine, everyone has their own taste and every language has its shortcomings, but then why didn't you say that from the beginning? Instead you made up a stupid argument that with wlroots being written in Rust other projects would have had a much harder time to make bindings to other programming languages. Which is of course bullshit since Rust allows you to provide a C ABI, hence creating language bindings is…
>Which is of course bullshit since Rust allows you to provide a C ABI, hence creating language bindings is as simple as with C. No, because C already uses the C ABI. You have to have a separate interface to your Rust code which uses the C ABI, and an uncomfortable transition point between C-land and Rust-land. This is definitely not as simple as it is with C.
That wasn't your argument. Your argument was that other projects have a much easier time to create language bindings for wlroots if it's written in C and know your argument changed to: I have a much easier time to provide a C ABI if wlroots is written in C instead of Rust.
Re: Giving up on wlroots-rs
#98> 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.
So it's way-cooler.com's fault for not explaining what their library/website is about.
Which unfortunately is par for the course on 99% of company blogs, which never explain what the company does without going onto the homepage (which even then is often confusing).
Re: Giving up on wlroots-rs
#99I 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 overl…
Yes, the same concept is discussed in https://news.ycombinator.com/item?id=19779243
Re: Giving up on wlroots-rs
#100Earlier quoted context omitted.
I get the sense that most adopted wlroots because Wayland is a complex protocol. There's no alternative to wlroots so part of the reason everybody uses it is because there's no choice if you don't want to start from nothing.
Wayland is a simple protocol. The complicated part is everything else, like graphics and input and X11 compatibility.
Right, but that still means that getting to a point most end-users would consider 'usable' is quite complex. Especially because the documentation around these things can be lacking.
P.S. I like Wayland and use it everywhere for the record.