Clean Rust Off campaign


#1

Project Proposal: Can we clean up the entire internet of ‘wrong Rust’ codes at once?

A few days ago, Rust-lang announced the first 1.0 stability promise, after years of radically fast changes. So I think a lot of people will pay attention to it, because Rust language promises a whole new level of programming experience.

I’m one of those who were attracted by that promises and fancy features.

Alas, however even though Rust-lang has reached it’s 1.0 stability, the accumulated garbage written in older style of syntax still remain in the entire internet, and leads new comers into trouble. They just don’t compile.

People including me learns programming by ‘searching’, not by official manual. So the existing, old-style of codes scattered in the Internet keeps beginners scared away because they just don’t compile.

There needs to be a certain and urgent remedy for this, if Rust community wants to grow fast enough.

Here’s my campaign idea:
“Clean Rust Off” campaign. – contact all blog writers and stackexchange writers and send an request to update their codes compatible with Rust-1.0.

I think we need to do it intensely in short period of time, say 2~3 months, because so many newcomers are banned out by old wrong blog posts, even at this moment.

Any idea about this?


#2

Concerning Stack Overflow, there is discussion on the topic at: http://meta.stackoverflow.com/questions/288033/editing-rust-questions-answers-to-reflect-the-fact-they-only-apply-to-a-deprecat


#3

I have a feeling that the people who answer frequently on Stack Overflow are willing to update our own out-of-date code; I certainly am. Just leave a comment on our answer and we can probably update it soon-ish.


#4

I somewhat feel historical concerns. I do agree that outdated code will hinder proper Rust learning, but it would be appreciated if we collect those old codes to some golden place before purging them all together. Those historical materials would help someone write a chronicle on Rust’s history someday. (Something like http://brson.github.io/archaea/)


#5

While we’re at it, it might be a good idea to polish the Rust benchmarks on the shootout ( shootout.alioth.debian.org ). These are commonly cited as comparisons between the speed of languages, but as Rust is in its infancy, the current benchmark code probably isn’t optimal – three of the benchmarks haven’t even been written for Rust!

However inaccurate benchmarks are, people still put stock in them, after all. Improving regex-dna is likely to be really slow (it’s sort of a contest; Rust needs a new regex library) but the others are probably wide open.


#6

What’s a contest exactly? And why do we need a new regex library as opposed to, say, improving the one we have?


#7

What’s a contest exactly?

A contest, as defined on the benchmark game, is a competition for speed where not all programs have to use the same algorithm – by contrast in the other benchmarks all programs are required to use the same algorithm. However, for regexen there are very few algorithms to speak of and DFA-constructing algorithms are always the fastest, so it’s not as bad as it seems.

And why do we need a new regex library as opposed to, say, improving the one we have?

IIRC currently the regex library uses an NFA. Making Rust competitive on regex-dna requires using a different algorithm, which for practical purposes means rewriting the library. You could still use the same function prototypes, of course; my point is it’s significantly harder than the others, and it’s worth mentioning because regex-dna is currently the benchmark Rust does worst at by a large margin.


#8

I agree with the first half but very much disagree with the second half! For example, RE2/C++ uses a DFA but also has a full NFA simulation implemented (along with other optimized engines, like a “one pass” NFA that is more efficient at tracking captures for some regexes). All of these engines can be included in the same regex package, which can pick and choose which to run based on the regex itself and what the user wants to do (test for match, location of match, location of captures).

Have a look at the regex issue tracker to get a rough idea of our plans. :slight_smile:


#9

As someone with some SO experience, do you have any advice to give for suggesting edits to posts?

For example, this answer references old methods like ‘c_str_to_bytes’ which do not exist in current rust. I attempted to submit an edit, but it did not go well.

As a general rule, is it better to try and get in touch with the original post author rather than submitting edits? I’ve done very little contribution to stackoverflow so I’m not really aware of any ‘best practices’. I’ll spend time fixing incorrect things when I see them, as long as it’s not just wasted effort. Unfortunately I don’t even have the reputation to comment asking for answers to be updated…


#10

Yeah, editing an answer that drastically is generally frowned upon. The main reason is that reviewers can’t be sure that you and the original author had the same intentions. Changing someones meaning is a no-no when that user could then be on the hook for negative points later on :smile:

If you feel like updating the answer, I’d suggest two paths:

  1. Add a comment to the original answer letting them know it is out of date. This helps future people who stumble on the question to know that the answer might not be accurate any more. This is a lightweight solution if you can’t provide corrected code yourself for whatever reason.

  2. Add your own answer with the corrected code. State that the other answer works for an older version of Rust, and clearly state the version you tested with. It may be nice to reference this answer in your comment from #1.

When you add an answer, the question gets bumped to the top of the active list. Those us us that are super active check that list every so often and will see those. You can get some easy points that way sometimes!


#11

Due to recent events on stackoverflow, there’s now more discussion going on at chat.stackoverflow.com