Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]

On Mon, Sep 30, 2024, 06:24 Alex Bennée <alex.bennee@linaro.org> wrote:

> Stefan Hajnoczi <stefanha@gmail.com> writes:
>
> > On Thu, 26 Sept 2024 at 10:24, Alex Bennée <alex.bennee@linaro.org>
> wrote:
> <snip>
> >> Another potential area for conversion was the VirtIO device and
> >> vhost-user code which could expect to re-use a lot of the crates from
> >> the rust-vmm project. However this did bring up the point of maintainer
> >> buy in. Stefan brought up the example of the simpletrace rewrite which
> >> while it may have brought some advantages he felt he was unable to take
> >> as a maintainer as he was not familiar with Rust at that point.
> >
> > Familiarity with Rust was not the issue with simpletrace. I had
> > already worked on libblkio in Rust and was able to understand the Rust
> > simpletrace patches.
>
> Apologies for misrepresenting the issue there. My notes obviously didn't
> capture that nuance.


No worries. Thanks for taking notes!

Stefan


>
> > It was a question of when rewriting in Rust is appropriate. Surprising
> > maintainers with a rewrite is risky because they may not be convinced
> > by the rewrite after all the work to write it has been done.
> >
> > In the case of simpletrace there wasn't a clear benefit to a rewrite:
> > performance was potentially better in Rust (performance hadn't been a
> > problem for users though) but usability was impacted by converting a
> > scriptable Python module to Rust (requiring users to rewrite their
> > scripts). The rewrite was dropped.
> >
> > What I tried to express at the Rust BoF was: talk to maintainers
> > before embarking on a rewrite.
>
> Yes this is the I think the key takeaway because the project would not
> be able to absorb a bunch of drive-by rust rewrites from well meaning
> contributors.
>
> >> With relative inexperience there was a concern we could inadvertently
> >> introduce technical debt in the code base (C-like Rust vs Rusty rust).
> >> What can we do to mitigate that issue?
> >
> > My suggestion is that every `unsafe` needs a comment explaining why it
> > is safe. That increases the cost of using `unsafe` and encourages safe
> > abstractions.
> >
> > There are plenty of unidiomatic ways of using Rust, but none are as
> > bad as sprinkling `unsafe` everywhere (i.e. writing C in Rust) since
> > that's how undefined behavior is introduced.
> >
> > Stefan
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>

[-- Attachment #2: Type: text/html, Size: 3523 bytes --]