On Tue, Jul 11, 2017 at 4:57 AM, Nicholas Nethercote <n.netherc...@gmail.com
> wrote:

> On Tue, Jul 11, 2017 at 11:15 AM, Bobby Holley <bobbyhol...@gmail.com>
> wrote:
>
> > If I were the owner of that module I would consider implementing a policy
> >> something like the following:
> >>
> >> "When a person writes a new compiled-code component, or majorly rewrites
> >> an existing one, they should strongly consider writing it in Rust
> instead
> >> of C or C++. Such a decision will depend on the nature of the component.
> >> Components that are relatively standalone and have simple interfaces to
> >> other components are good candidates to be written in Rust, as are
> >> components such as parsers that process untrusted input."
> >>
> >
> > I think this is pretty uncontroversial. The high-level strategic decision
> > to bet on Rust has already been made, and the cost of depending on the
> > language is already sunk. Now that we're past that point, I haven't heard
> > anyone arguing why we shouldn't opt for memory safety when writing new
> > standalone code. If there are people out there who disagree and think
> they
> > have the arguments/clout/allies to make the case, please speak up.
> >
>
> As Gibson said: "The future is already here — it's just not very evenly
> distributed."
>
> The paragraph you wrote is obvious to you, but I suspect it's not obvious
> to everyone -- Mozilla has a lot of contributors. There may still be some
> Firefox developers who think that Rust something that other people do, and
> that isn't relevant to them or their component(s). There may be some
> Firefox developers who are interested in Rust, but feel intimidated or
> uncertain about using it. There may be some developers who are keen to use
> Rust, but haven't realized that we are past the experimental stage.
>

(Picking a somewhat random response to reply here...)

It would be really nice to have IPDL codegen support for rust.  I
considered using rust for my current task, but decided not to since I
would've had to build even more boilerplate to work with IPC c++ actors.  I
would've ended up with more glue code than actual functional code.

Another advantage of building rust IPDL codegen targets would be that we
could build service oriented code in the parent process in rust.  This
would be an incremental improvement that could offer additional safety in
the parent process without having to tackle webidle, cycle collection,
etc.  In particular, PBackground parent actors already cannot interface
with xpcom since they are OMT and would be a good candidate here.

Anyway, I think fixing these kinds of integration pain points would
accelerate our ability to use rust in gecko.  I would hesitate to make any
kind of mandates until these issues are addressed.

Thanks.

Ben
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to