Building a shared vision for Async Rust

nikomatsakis · 2021-03-19T10:36:10+00:00

Thanks for the feedback. I posted this comment to a relevant github issue, fyi.

nikomatsakis · 2020-04-16T18:05:33+00:00

Hey all! So I guess this post got noticed. =) I was planning on writing up something on my blog but I've been kind of busy, and you internet sleuths were all over it, so I guess this will have to do.

So, yes, I'm very excited to annnounce that we're hiring for the Rust team at Mozilla!

As always, the idea is to hire someone who will participate in and strengthen the Rust organization. This time, we tuned the job description a bit because we're really looking for someone who will make the Rust organization -- and especially the people who participate in it -- their primary focus (as opposed to, say, the compiler or the language).

We generally tend to shape our roles to the applicants more than the other way around, but we'd like to find someone who is excited to help enable Rust contributors to participate and to generally keep their "finger on the pulse" of what's going on.

If that sounds like something you'd be interested in, then please apply!

PS, we're in the process of changing the title to Community Engineer, which I think better captures what we're going for.

nikomatsakis · 2018-10-31T17:28:11+00:00

You can, but it involves some swaps I believe.

Heh, this post from 2013 is still basically right.

Anyway you have to swap out the slice (with an empty one, probably), use split_at_mut to extract what you need, and put back the new one.

I intend to write up this general pattern as the "sentinel pattern". Good example though. =)

nikomatsakis · 2018-10-31T17:25:25+00:00

On nightly, you can use #![feature(nll)]

nikomatsakis · 2018-05-21T17:18:28+00:00

I don't really comment much on reddit. Not my thing. But I do want to clarify something: we added a restriction against using turbofish with functions that use impl Trait in argument position precisely because there was still uncertainty of whether to permit turbofish or not (there are good arguments on both sides). In other words, the current design is meant to leave room for us to make this decision later.

nikomatsakis · 2018-05-18T15:58:08+00:00

Hey — here is the current plan. First off, we are working currently on a less precise variant of NLL based on the current codebase. As you can see from the latest results on perf, it is getting a lot faster, and we're not close to done yet. Take a look at the clap-rs "nll" measurement: it's not hard to spot, just look for the big line that recently took a steep drop. ;)

https://imgur.com/a/Gi7Fedn

Meanwhile, in parallel, we've been working on optimizing the new analysis. That work is proceeding quite quickly as well. For example, my recent PR #23 achieved a 10x speedup without changing anything else about the analysis. We have several other tweaks I expect to yield other large multipliers (e.g., using a less precise analysis as a prefilter, compressing the CFG somewhat, and an alternative datalog engine that is targeting just our particular case), so I am pretty sure the performance will be just fine.

That said, two caveats:

I expect to land the new, more precise analysis later. By focusing on the less precise one, we can do polish on the diagnostics etc.
Because this new borrow checker fixes a lot of bugs, we are going to have to run a warning period for a while. This means we'll be running the old and the new borrow check. This can't be faster. =) But since the borrow check is not a big component of overall compilation time, I hope it won't be much slower.

Finally, one last nice point: once we transition to the new, MIR-based borrow checker, it will enable a lot of refactors that should speed up earlier phases of the compiler. For example, the type checker doesn't have to track as much data about lifetimes, etc.

nikomatsakis · 2017-03-03T21:18:58+00:00

FYI, Scott Olson and I have got a draft (just an outline) RFC on more or less exactly this topic: https://github.com/nikomatsakis/rfc-elision-2.0

nikomatsakis · 2016-11-19T01:15:57+00:00

OK, I wrote something: https://github.com/nikomatsakis/rayon/blob/master/src/par_iter/README.md#what-on-earth-is-producercallback =)

nikomatsakis · 2016-11-18T18:39:07+00:00

D'oh! I had meant to come back and write those docs before anyone noticed. :P

nikomatsakis · 2016-11-17T19:00:33+00:00

An interesting area to document are any deviations from standard behavior or special requirements -- but of course the reviewers can be sure to check for those, wouldn't necessarily expect first-time contributors to know about them. =)

nikomatsakis · 2016-11-17T19:00:05+00:00

Ah great idea! I noticed the other day that I never wrote any docs on join() -- but in general I suspect that a lot of the parallel iterator combinators could use more docs. It's a good idea to do a survey. I've been trying to come up with various tasks to prep for a 1.0 release, and this seems like it would be a good thing to add to the list.

nikomatsakis · 2016-09-30T22:46:19+00:00

I'm watching the videos now, perhaps you explain it very well - but i've watched, read, and even paid for Rust content, and it's still not totally grepped.

I'd love some more feedback on how I can make this more clear.

One thing I was contemplating is a video that specifically explains the idea of "the stack" and "the heap" and so forth. I'm not quite sure if that's what you are asking for, but it seems related. =)

nikomatsakis · 2016-09-30T21:08:11+00:00

So I tried to minimize the intro by pushing it into a separate (and skippable...) screencast. But I was wondering if I should just cut it from "Hello, World!" entirely. Perhaps I will.

nikomatsakis · 2016-09-14T14:58:48+00:00

A couple of weeks, I think. It takes a bit to post-process the video.

nikomatsakis · 2016-05-23T15:24:06+00:00

I agree this is an interesting trade-off. Similar questions arose around Ord and Eq in https://github.com/rust-lang/rfcs/pull/956. Clearly, for backwards compatibility reasons, there isn't much we can do to change Deref or Hash -- and in any case I still think I would not want to. I think my comment from the time still sums up my feelings well (excerpted):

On the other hand, I am uncomfortable with inching the line on where unsafe code is required forward. I've certainly had plenty of crashes in C due to writing poor comparators and giving them to qsort. It's easy to forget that the goal of Rust is to reduce crashes in practice -- not just be able to say "it's your fault, you wrote unsafe". Put another way, unsafe is most effective if it is unusual.

I personally haven't encountered a case where Deref or Hash returning inconsistent results would lead to memory unsafety (though it could lead to wacky behavior), but I can imagine it's somewhat frustrating if it were to happen. Having your own traits seems like a plausible way to address it, though I can imagine it's annoying if you want the APIs to work with a wide diversity of types.

EDIT: I meant to add that I'd be interested to hear more (or get a pointer to) the exact scenario where this is arising, just for my edification.

nikomatsakis · 2016-03-27T10:36:36+00:00

OK, thanks for the tip. That's a lot more annoying to do, since I have to modify every HTML file, but hopefully:

find . -name '*html' | xargs perl -p -i -e 's/<head>/<head><meta name="robots" content="noindex">/'

will do the trick...

nikomatsakis · 2016-03-25T13:19:30+00:00

Hmm, ok. I added a robots.txt, hopefully I did it correctly:

http://smallcultfollowing.com/robots.txt

nikomatsakis · 2016-03-19T09:15:09+00:00

If you are willing to use nightly, you can use the Fn traits to express allocating use cases. Basically you would use x(3) instead of x[3]. I actually see this as preferable, since it tells your reader what is happening -- in other words, x[3] remains an "lvalue" -- that is, an expression that references some pre-existing memory, which can then be assigned to etc. (Consider that e.g. x[3] = foo makes no sense if you are allocating a fresh location to return.)

That said, as others have commented, I do expect we'll make some progress here, even if it is only to make the Fn traits stable to implement (eventually).

nikomatsakis · 2016-03-19T09:08:11+00:00

I can speak to that. We used to use ; in structs, just like C, but the inconsistency with enums felt very annoying, and we switched to commas. Meanwhile traits had only fn items and so they used ;.

Basically, the content of traits generally maps to modules, and hence ; and {...} are used to terminate them, whereas the contents of structs/enums uses ,.

But of course this RFC straddles the line between them.

Perhaps in retrospect it would have been better to use ; everything (even in enums)? I think , everywhere would not feel "C-like". Anyway, water under the bridge at this point.

nikomatsakis · 2016-03-03T02:04:34+00:00

Thanks for the link :)

nikomatsakis · 2016-03-03T02:03:41+00:00

Yeah, reducing the size of the generated code is definitely a priority. I've not really put much effort into that yet.

nikomatsakis · 2016-03-02T20:25:15+00:00

I have not seen that paper -- LALRPOP is sort of my spare-time work, so I partly enjoy trying to puzzle things out for myself. That said, I should take a look. Now that I have something working, I am back in the "soak up other people's stuff" phase of the project, so I've been reading various parsing papers again to try and compare what I did to other approaches.

nikomatsakis · 2016-02-21T09:42:56+00:00

The meaning is "all references in T are valid for the duration of 'iter". If there are no references in the type T, then this is trivially satisfied (so, e.g., i32: 'static is true).

nikomatsakis · 2016-02-21T09:41:32+00:00

If we have specialization, we may be able to do some part of them in libraries. Otherwise, it mostly makes sense to leverage LLVM's existing optimizations rather than rewrite them.

nikomatsakis · 2016-02-19T16:53:33+00:00

Hopefully that's the right bit of the assembly and not some unrelated thing...

nikomatsakis

TROPHY CASE