On Fri, Oct 02, 2020 at 04:14:17PM +1000, Dave Airlie wrote: > On Fri, 2 Oct 2020 at 15:01, Jason Ekstrand <ja...@jlekstrand.net> wrote: > > > > On Thu, Oct 1, 2020 at 10:56 PM Rob Clark <robdcl...@gmail.com> wrote: > > > > > > On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig > > > <alyssa.rosenzw...@collabora.com> wrote: > > > > > > > > Implications for the build system vary. Rust prefers to be built by its > > > > own package manager, Cargo, which is tricky to integrate with other > > > > build systems. Actually, Meson has native support for Rust, invoking the > > > > compiler directly and skipping Cargo, as if it were C code. This support > > > > is not widely adopted as it prevents linking with external libraries > > > > ("crates", in Rust parlance), with discussions between Rust and Meson > > > > developers ending in a stand-still [1]. For Mesa, this might be just > > > > fine. Our out-of-tree run-time dependencies are minimal for the C code, > > > > and Rust's standard library largely avoids the need for us to maintain a > > > > Rust version of util/ in-tree. If this proves impractical in the > > > > long-term, it is possible to integrate Cargo with Meson on our end [2]. > > > > > > > > > > drive-by comment: for something like a gl driver that a lot of other > > > things depend on, making it harder for us to depend on other external > > > things is actually a good thing > > > > Generally, I'm a fan in concept. Generally, I feel like rust has most > > of what I like from C++ without most of what I don't like. I > > particularly like it's error handling mechanism, for instance. That > > said, when it comes to things like the borrow checker, my little bit > > of rust experience says that it doesn't actually remove bugs so much > > as move them around. > > > > What's been stopping me is practicalities. Not only build systems but > > the way in which everything in mesa is interconnected. Your > > suggestion for building the entire back-end compiler with C-wrapped > > helpers for NIR->compiler translation may be workable. We might also > > be able to write NIR wrappers sufficient for reading NIR. It's not > > actually that much API surface if all you want to do is read the data > > structure. > > > > I've also thought of breaking off a component like ISL and converting > > it. However, all the nicely contained pieces are also the ones that > > wouldn't benefit as much. :-/ > > > > My feeling is the pieces that would benefit the most are the things > touch the real world, GLSL compiler, SPIR-V handling, maybe some of > the GL API space, but I also feel these are the messiest things to > move to rust. I'm not sure you'd get much benefit from vulkan API > space or touching kernel interfaces as much. Granted a backend > compiler might be the easiest place to experiment. > > I think the problem is you really want to justify that whatever you > introduce using rust is sufficiently better along any axis than c/c++ > to justify the enhanced build time requirements and maintenance, > otherwise someone will just rewrite it in C/C++ to avoid having to > pull a rust compiler into their distro requires. > > Dave.
Hi everyone, I agree with the sentiments already expressed in this thread. Here are some additional thoughts. Since the original email mentioned the borrow checker in particular, my view is that the borrow checker is one tool in Rust's safety toolkit which is certainly useful, but I don't know if it's enough to be the driving force for Rust adoption, at least given other adoption constraints and trade-offs. I have found that other tools like RAII/drop, the closely related smart pointer types, and safe containers (vectors, strings etc.) even without the borrow checker niceties, to be relatively more useful in preventing memory errors. However, these are features that modern C++ also offers, along with a seamless integration story with existing C and C++ code. I find that Rust has an edge in thread-safety, but I am not sure if this is a strong selling point in the context of Mesa, where the current design seems to be well served (for now) by the traditional thread safety patterns. I like Rust more than C++ as a language, as I find it to be cleaner (in part by virtue of being new) and more convenient. I especially enjoy the better integrated functional aspects and the general high-level feel of the language. For both C++ and Rust this comes with a caveat, though: a reduction in the transparency of the cost of the code. I think Rust may be a just bit more opaque in this department, since with C++ we can more readily mentally map high-level concepts to well understood C constructs. Still, and, more often than not, both C++ and Rust deliver their high-level features very efficiently. There is also the question of potentially constraining the pool of contributors by not using one of the well established languages. Perhaps that's not a big deal going forward given Rust's current momentum. One could even argue that using Rust could even attract contributors, although given Rust's relatively steep learning curve, I am not sure we can tell which way the scale will tip. As an aside, as much as I like the practicality and richness of the crate ecosystem, which is one of the strong points of Rust, I do have concerns about its current security model. For example, the crates are not signed and thus vulnerable to several plausible attacks, like compromised github accounts or, even worse due to scale, compromised crate repositories. This is further aggravated by the sometimes large indirect dependency trees. Such concerns are especially relevant to Mesa (and other high-profile projects) since it could be an attractive target for malicious entities. As enticing as it could be sometimes, I would be very hesitant to introduce external crate dependencies at this point in Mesa. All the above is not meant to discourage, but rather underline some of the trade-offs that may go unnoticed in between all the great features that Rust brings and the general excitement about Rust. In fact, I think an experiment in Rust integration with Mesa would be worth a try, in order to figure out in which components it could provide the most benefit, where the boundaries are, and also get a better idea of all the involved trade-offs. Thanks, Alexandros _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev