ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Christoph Hellwig <hch@infradead.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	ksummit@lists.linux.dev
Subject: Re: [TECH TOPIC] Rust
Date: Sun, 19 Jun 2022 08:56:46 -0400	[thread overview]
Message-ID: <2513dc4528c71d34d400c104e91ada6517869886.camel@HansenPartnership.com> (raw)
In-Reply-To: <Yq70keAYGQQmyJLm@pendragon.ideasonboard.com>

On Sun, 2022-06-19 at 13:04 +0300, Laurent Pinchart wrote:
> On Sat, Jun 18, 2022 at 11:13:59PM -0700, Christoph Hellwig wrote:
> > On Sat, Jun 18, 2022 at 11:42:07PM +0300, Laurent Pinchart wrote:
> > > All previous topics but this one are technical. To restore the
> > > balance a bit (and also because I believe it's important to the
> > > success of this project :-)), I'd like to also discuss the impact
> > > on the kernel maintenance at large, beyond just the maintainers
> > > who opt in to be early adopters of rust in their subsystem.
> > 
> > Yes.  That is I think the most important point.
> > 
> > I've played around with rust a bit for userspace project, and there
> > is things I like a lot like strict type safety and the ownership
> > model, and things I detest like verbose and unlogic syntax, the
> > cargo cult of vendoring libraries instead of a sane shared library
> > and versioning model (althought that should be largerly irrelevant
> > for the kernel), and compared to many other languages it seems
> > overall rather sane.

This is more or less my assessment from playing with rust as well.

> > But I'm really worried about the impact on the kernel, as interface
> > between languages are a real pain, and so far I'm not convinced at
> > all that this pain is worth the gain, even if that could change in
> > the future.
> 
> One point I'd like to explicitly address, as it seems to be very
> relevant to me when it comes to whether or not the pain is worth the
> gain, is how we'll deal with the fact that the rust compiler will
> tell a non-negligible [*] part of the kernel developers that they
> don't have the skills to write kernel code. Will we have a credible
> option to offer there to help people improve their skills set, and
> how will we deal with the fact that some people will be left on the
> side of the road ? Or would we acknowledge what may be the elephant
> in the room that this would actually be a good thing for the kernel
> code quality ? What about the impact on a community that is already
> overworked and prone to burn-out ?
> 
> [*] I have no way to quantify this at the moment, maybe I'm overly
> pessimistic, and the number will likely vary depending on areas,
> probably impacting BSPs differently than mainline.

I don't think that's a huge concern.  After all rust isn't going to
penetrate every subsystem all at once ... and realistically it will
only penetrate some subsystems if there's the ability to review it.

I really doubt anyone at the maintainer or reviewer level of the kernel
doesn't have the ability to learn rust (now whether they have the
desire to is quite another matter) and I'd be surprised if we can find
any kernel developer who only speaks C.  I think the biggest problem
with rust is that there's definitely an anti-C bias in the language. 
What I mean by that is if you look at Java they chose to be as close to
C where possible to make the language easier to learn.  Rust seems to
have taken the opposite view and picked a lot of things which could
have been C like (typing, function calls, returns, mutability, etc.)
and done them differently just because they wanted to be different from
C.  That does cause issues for C people because you tend to trip over
the anti-C biases in the language and are constantly having to look the
basic syntax up.  This really increases the learning curve going from C
to rust, which gets annoying very fast, but it's not insurmountable.

All that said, I expect once we start getting rust based patches, it
will quickly become apparent where the rust receptive subsystems are
and I would expect reviewers in those subsystems will quickly become
rust fluent.  This doesn't answer the pain vs gain aspect, but I
suspect we won't know that until we actually try.

James



WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: [Ksummit-discuss] [TECH TOPIC] Rust
Date: Sun, 19 Jun 2022 08:56:46 -0400	[thread overview]
Message-ID: <2513dc4528c71d34d400c104e91ada6517869886.camel@HansenPartnership.com> (raw)
Message-ID: <20220619125646.PC0Ja5O6wmDKeCIxefO-7o6Au-WfSR4Ie3t-Sp0XRZo@z> (raw)
In-Reply-To: <Yq70keAYGQQmyJLm@pendragon.ideasonboard.com>

On Sun, 2022-06-19 at 13:04 +0300, Laurent Pinchart wrote:
> On Sat, Jun 18, 2022 at 11:13:59PM -0700, Christoph Hellwig wrote:
> > On Sat, Jun 18, 2022 at 11:42:07PM +0300, Laurent Pinchart wrote:
> > > All previous topics but this one are technical. To restore the
> > > balance a bit (and also because I believe it's important to the
> > > success of this project :-)), I'd like to also discuss the impact
> > > on the kernel maintenance at large, beyond just the maintainers
> > > who opt in to be early adopters of rust in their subsystem.
> > 
> > Yes.  That is I think the most important point.
> > 
> > I've played around with rust a bit for userspace project, and there
> > is things I like a lot like strict type safety and the ownership
> > model, and things I detest like verbose and unlogic syntax, the
> > cargo cult of vendoring libraries instead of a sane shared library
> > and versioning model (althought that should be largerly irrelevant
> > for the kernel), and compared to many other languages it seems
> > overall rather sane.

This is more or less my assessment from playing with rust as well.

> > But I'm really worried about the impact on the kernel, as interface
> > between languages are a real pain, and so far I'm not convinced at
> > all that this pain is worth the gain, even if that could change in
> > the future.
> 
> One point I'd like to explicitly address, as it seems to be very
> relevant to me when it comes to whether or not the pain is worth the
> gain, is how we'll deal with the fact that the rust compiler will
> tell a non-negligible [*] part of the kernel developers that they
> don't have the skills to write kernel code. Will we have a credible
> option to offer there to help people improve their skills set, and
> how will we deal with the fact that some people will be left on the
> side of the road ? Or would we acknowledge what may be the elephant
> in the room that this would actually be a good thing for the kernel
> code quality ? What about the impact on a community that is already
> overworked and prone to burn-out ?
> 
> [*] I have no way to quantify this at the moment, maybe I'm overly
> pessimistic, and the number will likely vary depending on areas,
> probably impacting BSPs differently than mainline.

I don't think that's a huge concern.  After all rust isn't going to
penetrate every subsystem all at once ... and realistically it will
only penetrate some subsystems if there's the ability to review it.

I really doubt anyone at the maintainer or reviewer level of the kernel
doesn't have the ability to learn rust (now whether they have the
desire to is quite another matter) and I'd be surprised if we can find
any kernel developer who only speaks C.  I think the biggest problem
with rust is that there's definitely an anti-C bias in the language. 
What I mean by that is if you look at Java they chose to be as close to
C where possible to make the language easier to learn.  Rust seems to
have taken the opposite view and picked a lot of things which could
have been C like (typing, function calls, returns, mutability, etc.)
and done them differently just because they wanted to be different from
C.  That does cause issues for C people because you tend to trip over
the anti-C biases in the language and are constantly having to look the
basic syntax up.  This really increases the learning curve going from C
to rust, which gets annoying very fast, but it's not insurmountable.

All that said, I expect once we start getting rust based patches, it
will quickly become apparent where the rust receptive subsystems are
and I would expect reviewers in those subsystems will quickly become
rust fluent.  This doesn't answer the pain vs gain aspect, but I
suspect we won't know that until we actually try.

James



  parent reply	other threads:[~2022-06-19 12:56 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-18 20:33 [TECH TOPIC] Rust Miguel Ojeda
2022-06-18 20:42 ` Laurent Pinchart
2022-06-18 20:42   ` [Ksummit-discuss] " Laurent Pinchart
2022-06-18 20:44   ` Laurent Pinchart
2022-06-18 20:44     ` [Ksummit-discuss] " Laurent Pinchart
2022-06-18 20:49   ` Miguel Ojeda
2022-06-19  6:13   ` Christoph Hellwig
2022-06-19  6:13     ` [Ksummit-discuss] " Christoph Hellwig
2022-06-19 10:04     ` Laurent Pinchart
2022-06-19 10:04       ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 12:56       ` James Bottomley [this message]
2022-06-19 12:56         ` James Bottomley
2022-06-19 13:19         ` Jens Axboe
2022-06-19 13:19           ` [Ksummit-discuss] " Jens Axboe
2022-06-19 13:53           ` Laurent Pinchart
2022-06-19 13:53             ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 14:27             ` James Bottomley
2022-06-19 14:27               ` [Ksummit-discuss] " James Bottomley
2022-06-19 14:45               ` [MAINTAINER SUMMIT] Are we becoming too fearful? [was Re: [TECH TOPIC] Rust] James Bottomley
2022-06-19 14:45                 ` [Ksummit-discuss] " James Bottomley
2022-06-22  9:59                 ` Linus Walleij
2022-06-22 10:57                   ` Laurent Pinchart
2022-06-22 12:01                     ` Linus Walleij
2022-06-22 12:09                       ` Laurent Pinchart
2022-06-22 23:13                 ` NeilBrown
2022-06-23 11:37                   ` James Bottomley
2022-06-25 12:03                 ` [Ksummit-discuss] " Mauro Carvalho Chehab
2022-06-25 11:45               ` [Ksummit-discuss] [TECH TOPIC] Rust Mauro Carvalho Chehab
2022-06-25 14:15                 ` James Bottomley
2022-06-25 16:18                   ` Mauro Carvalho Chehab
2022-06-25 22:29                 ` Linus Walleij
2022-06-26  2:52                   ` Theodore Ts'o
2022-06-26  3:18                     ` Al Viro
2022-06-19 13:49         ` Laurent Pinchart
2022-06-19 13:49           ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 19:08           ` Geert Uytterhoeven
2022-06-19 19:08             ` [Ksummit-discuss] " Geert Uytterhoeven
2022-06-19 20:57             ` Matthew Wilcox
2022-06-20 13:53             ` Linus Walleij
2022-06-20 14:08             ` James Bottomley
2022-06-21 15:11           ` Dan Carpenter
2022-06-23 10:58             ` [TECH TOPIC] Why is devm_kzalloc() harmful and what can we do about it Laurent Pinchart
2022-06-23 11:24               ` Dan Carpenter
2022-06-23 11:31                 ` Laurent Pinchart
2022-06-21  9:49 ` [TECH TOPIC] Rust David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2513dc4528c71d34d400c104e91ada6517869886.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=hch@infradead.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).