BTW, speaking of training: Jason's and my book, "Programming Rust" will be available on paper from O'Reilly on August 29th! Steve Klabnik's book with No Starch Press is coming out soon as well, but I don't know the details there.
On Mon, Jul 17, 2017 at 12:43 PM, Ted Mielczarek <t...@mielczarek.org> wrote: > Nick, > > Thanks for kicking off this discussion! I felt like a broken record > talking to people about this in SF. From my perspective Rust is our > single-biggest competitive advantage for shipping Firefox, and every > time we choose C++ over Rust we throw that away. We know the costs of > shipping complicated C++ code: countless hours of engineering time spent > chasing down hard-to-reproduce crashes, exploitable security holes, and > threading issues. Organizationally we need to get to a point where every > engineer has the tools and training they need to make Rust their first > choice for writing code that ships with Firefox. > > On Mon, Jul 10, 2017, at 09:15 PM, Bobby Holley wrote: > > 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. > > From my anecdotal experiences, I've heard two similar refrains: > 1) "I haven't learned Rust well enough to feel confident choosing it for > this code." > 2) "I don't want to spend time learning Rust that I could be spending > just writing the code in C++." > > I believe that every developer that writes C++ at Mozilla should be > given access to enough Rust training and work hours to spend learning it > beyond the training so that we can eliminate case #1. With the Rust > training sessions at prior All-Hands and self-motivated learning, I > think we've pretty well saturated the group of early adopters. These > people are actively writing new Rust code. We need to at least get the > people that want to learn Rust but don't feel like they've had time to > that same place. > > For case #2, there will always be people that don't want to learn new > languages, and I'm sympathetic to their perspective. Learning Rust well > does take a large investment of time. I don't know that I would go down > the road of making Rust training mandatory (yet), but we are quickly > going to hit a point where "I don't feel like learning Rust" is not > going to cut it anymore. I would hope that by that point we will have > trained everyone well enough that case #2 no longer exists, but if not > we will have to make harder choices. > > > > The tradeoffs come when the code is less standalone, and we need to weigh > > the integration costs. This gets into questions like whether/how Rust > > code > > should integrate into the cycle collector or into JS object reflection, > > which is very much a technical decision that should be made by experts. I > > have a decent sense of who some of those experts might be, and would like > > to find the most lightweight mechanism for them to steer this ship. > > We definitely need to figure out an ergonomic solution for writing core > DOM components in Rust, but I agree that this needs a fair bit of work > to be feasible. Most of the situations I've seen recently were not that > tightly integrated into Gecko. > > -Ted > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
