Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Giving up on wlroots-rs

way-cooler.org

Post reply on HN
Print view View original

121–126 of 126 posts

Re: Giving up on wlroots-rs

#121

Post by pjmlp »

kccqzy wrote: post #75
pjmlp wrote: post #64

Earlier quoted context omitted.

JavaScript and Haskell get to enjoy the productivity of using a tracing GC though.

This doesn't really have much to do with the runtime. Certainly with a GC, programming would be easier, but I'm really talking about abstractions within the language. Rust already has language-integrated support for the Result monad. Rust doesn't have a general `do` syntax, but it has `?` which has made programming with the Result monad much easier. Can we think about the continuation monad and arrive at a new syntax…

It has, because for some of those workflows the borrow checker gets in the way.

Re: Giving up on wlroots-rs

#122

Post by pjmlp »

gpm wrote: post #82
pjmlp wrote: post #66

Earlier quoted context omitted.

C is the lingua franca of UNIX based platforms. Thankfully not all OSes bow to it.

I think it has less to do with OS then you think. It has more to do with compilers/programming languages. 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.

On Android you can do it via the NDK sure, but then again 90% of the OS is exposed via Java APIs, even a basic thing like opening a file requires Java, if you want to do it in a portable, certified Play Store way.

And on Windows, .NET MSIL or COM are much better ways to expose libraries.

Naturally one can still do it in an old fashion way.

Re: Giving up on wlroots-rs

#123

Post by adrianratnapala »

klodolph wrote: post #84
anyfoo wrote: post #56

Earlier 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…

> ... you end up with some problems because you can only free it with the correct context active, ...

I wonder if this is where Rust can actually help. I.e. could the lifetime tracking in the language allow you to construct a library where the unref was guaranteed to happen only when the right context is active?

And if such a library could be constructed, what would the loss of flexibility cost?

Re: Giving up on wlroots-rs

#124

Post by adrianratnapala »

klodolph wrote: post #109
ska wrote: post #106

Earlier quoted context omitted.

They don't behave like file handles - but at a certain distance if you squint at it looks like the same problem. The real issue isn't that OpenGL textures don't behave like file handles, but that neither of them behave quite like objects in your language, which can lead to problems. The specifics of how the behavior differs is I think less important that the fact that it differs. Of course, file handles are not the b…

> …but at a certain distance if you squint at it looks like the same problem… The whole discussion here is about how these things differ in subtle ways. The problem with “squinting” at the problem is you end up e.g. using RAII and then having to redesign your system because RAII doesn’t match, and the problems weren’t obvious when you started out. Not to make too fine a point about it here, but file handles are perfe…

> Not to make too fine a point about it here, but file handles are perfect matches for RAII / Rust lifetimes, unlike OpenGL textures.

Agreed, something like an FD matches RAII very well, but you can open one file multiple times, dup fds and multiple processes can do all this. So the FDs end up mapping in some non-trivial, probably refcounted way to other objects in the kernel.

So it seems with OpenGL, this kind of mapping / bookkeeping layer gets hoisted up into the application framework -- which might be a reasonable choice.

Re: Giving up on wlroots-rs

#125

Post by jandrese »

codedokode wrote: post #113
jandrese wrote: post #17

Earlier quoted context omitted.

I read it as friction between how Rust sees its application model and the real world. Total ownership of a resource can't be maintained if some jackass goes and pulls the physical hardware out from under you. So now the Rust implementation gets crufted up with a zillion checks for unexpected changes to the underlying system that are clunky in Rust because that's supposed to be an exotic condition, not something you'r…

This can also indicate a problem in architecture: if the monitor can go away any time, you shouldn't store long time references to it and instead, for example, call a function to get current default monitor every time you want to do something. Or at least validate those references before usage.

I suspect querying the monitor for its parameters every time you want to blit pixels to it is wildly impractical. EDID runs over a slow serial link, and you have 124.4 million pixels to blit out every second.

The sensible way to handle this is for the system to throw an interrupt when the state of the connection changes, but interrupt handling is something Rust's ownership model struggles to accommodate.

Re: Giving up on wlroots-rs

#126

Post by klodolph »

adrianratnapala wrote: post #124
klodolph wrote: post #109

Earlier quoted context omitted.

> …but at a certain distance if you squint at it looks like the same problem… The whole discussion here is about how these things differ in subtle ways. The problem with “squinting” at the problem is you end up e.g. using RAII and then having to redesign your system because RAII doesn’t match, and the problems weren’t obvious when you started out. Not to make too fine a point about it here, but file handles are perfe…

> Not to make too fine a point about it here, but file handles are perfect matches for RAII / Rust lifetimes, unlike OpenGL textures. Agreed, something like an FD matches RAII very well, but you can open one file multiple times, dup fds and multiple processes can do all this. So the FDs end up mapping in some non-trivial, probably refcounted way to other objects in the kernel. So it seems with OpenGL, this kind of ma…

OpenGL textures point to some refcounted thing, but the handle table is not per-process but per-context, and the contexts are not thread-safe, and the contexts can become invalidated. So it is similar in many ways but there are too many differences in general.
Post reply on HN