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
