Proposal: Spend most of the beta period *not* writing new features

[Manishearth]

1.0 is going to be the first major impression Rust is going to make on the programming communities.

As such, we should make it a good one.

We have nearly 300 ICEs, 150 rustdoc bugs, 200 diagnostics bugs, and we still need a lot of documentation coverage; though Steve has made some awesome progress on that front. These are all going to hurt newbies who try to use Rust.

Perhaps we should, after one point in the beta period, all consciously focus on improving these before working on new features? Fix all the bugs, papercuts, and improve UX in general? Rustdoc and diagnostics in particular are areas where we could do a lot better, though I bet there are more.

Of course I’m not calling for a feature freeze, we should still allow gated features (and leftover feature changes for 1.0) to land, but an informal, long, “Let’s try to polish everything” period would be nice to have.

[brson]

I pretty much agree. Fixing bugs, adding polish and making crates compatible with beta are the most important things we can do right now.

It’s difficult to redirect everybody’s efforts at once, but those looking to make the biggest impact right now can’t do better than tackle the bugs in @Manishearth’s links.

[cmr]

I’ve started assigning rustdoc bugs to myself to start tackling. Rustdoc needs a lot of love. A bunch of language features have been added that it only hackily knows about, and its architecture around inlining docs from other crates and collecting multiple crates into a single directory has numerous bugs. I’m happy to take the lead on cleaning up rustdoc.

[Manishearth]

I’m happy to take the lead on cleaning up rustdoc.

Thanks!

I myself am quite concerned about rustdoc (and diagnostics, but less so), because there are a lot of things it just misses, and a lot more things it’s very confusing about. If I have to click the “src” link to understand something, either the documentation or our way of displaying it are wrong and the current state of docs is a bit of both.

I’ll try to help wherever I can, but I don’t see myself having much free time for another month at least

[tomjakubowski]

That’s great to hear! Regrettably I’ve had much less time available to squash rustdoc issues recently; I’m so glad that someone (the original author of rustdoc-ng, at that!) is taking the reins going into the beta period

Accurate and readable API/reference documentation, not just for std but for community-written crates, is enormously important and I wholeheartedly support putting new features on hold to focus on making rustdoc better for 1.0.

[gnzlbg]

What are new features? I would consider it extremely valuable if someone would take on writing a natvie rust debugger (the moment you want to inspect the value of e.g. enums, structs, … gdb and lldb break, they won’t support native rust expressions anytime soon). Is this a “new” feature?

Is improving compilation speed or improving the performance of rust programs by working on compiler optimizations “a new feature”? I consider these to be as valuable, as with 1.0 a lot of people are going to judge rust, with micro benchmarks, compilation-speed benchmarks, and so on.

I would say “spend most of the beta period not writing new language features, but improving the 1.0 experience”

[Manishearth]

I would say “spend most of the beta period not writing new language features, but improving the 1.0 experience”

Pretty much what I meant. I used “feature” in the #![feature(..)] sense. Sorry about the ambiguity.

[aturon]

“spend most of the beta period not writing new language features, but improving the 1.0 experience”

FWIW, this is definitely what the core team plans to do! And thanks @Manishearth for the broader call to action

[Manishearth]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.