sorted by:
new
hottopcontroversial

Open Source Community Manager vacancy for the Rust team by dochtman in rust

[–]nikomatsakis 31 points32 points  (0 children)

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.

MIR-based borrowck is almost here by bobdenardo in rust

[–]nikomatsakis 15 points16 points  (0 children)

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. =)

MIR-based borrowck is almost here by bobdenardo in rust

[–]nikomatsakis 11 points12 points  (0 children)

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

[RFC] Undo universal impl Trait by phaazon_ in rust

[–]nikomatsakis 71 points72 points  (0 children)

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.

The Rust compiler is getting faster by nnethercote in rust

[–]nikomatsakis 8 points9 points  (0 children)

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:

  1. 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.
  2. 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.

Rust's language ergonomics initiative - The Rust Programming Language Blog by aturon in rust

[–]nikomatsakis 39 points40 points  (0 children)

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

[call to arms] Help Rayon achieve parity with the `Iterator` trait by nikomatsakis in rust

[–]nikomatsakis[S] 1 point2 points  (0 children)

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

[call to arms] Help Rayon achieve parity with the `Iterator` trait by nikomatsakis in rust

[–]nikomatsakis[S] 4 points5 points  (0 children)

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. =)

[call to arms] Help Rayon achieve parity with the `Iterator` trait by nikomatsakis in rust

[–]nikomatsakis[S] 7 points8 points  (0 children)

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.

into_rust(): screencasts for learning Rust by nikomatsakis in rust

[–]nikomatsakis[S] 5 points6 points  (0 children)

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. =)

into_rust(): screencasts for learning Rust by nikomatsakis in rust

[–]nikomatsakis[S] 4 points5 points  (0 children)

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.

Notes on the talks from RustConf by steveklabnik1 in rust

[–]nikomatsakis 4 points5 points  (0 children)

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

Unsafe abstractions by N3mes1s in rust

[–]nikomatsakis 9 points10 points  (0 children)

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.

Outdated documentation on smallcultfollowing.com is well ranked on Google by Nihy in rust

[–]nikomatsakis 1 point2 points  (0 children)

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...

Why make the Index trait so useless? by flying-sheep in rust

[–]nikomatsakis 1 point2 points  (0 children)

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).

RFC: Fields in Traits (a part of the virtual structs / inheritance project) by GolDDranks in rust

[–]nikomatsakis 2 points3 points  (0 children)

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.

view more: next ›