The Covert World of People Trying to Edit Wikipedia for Pay - <AUTHOR> http://www.theatlantic.com/business/archive/2015/08/wikipedia-editors-for-pay/393926/?single_page=true <comment><USER2> I recently tried to get involved as an editor but gave up. It can take literally hours out of your day going back and forth with some other editor who decides he or she wants to debate you on the world's dumbest, most pedantic thing ever. One time it literally took 3+ hours to make a change of less than a sentence on some stupid article like a particular model of motorcycle and it required escalating it to dispute resolution. Eventually a few more people chimed in and unanimously supported my position but my several hours were lost.

Articles that are in a niche people care (politically charged subjects) about have pretty strong biases that are impossible to remove because it doesn't matter which side follows the rules or the intended spirit of Wikipedia, all that matters is which side has more people and which side is more vocal. When making community decisions, the number of people voting is all that seems to matter, even if they vote with zero explanation or with an explanation that uses the rules incorrectly.

I gave up after probably 60 hours accumulated editing time, most of it spent not editing but dealing with other users and their bullshit.

<comment><USER3> This seems to be a commonly-aired complaint when these discussions come up.

My guess is that it happens when people dive in to fix something that they "know" is wrong, and feel strongly about - and then get upset when it's reverted because they provided no evidence. No one likes rejection, but some take it far too personally.

If your first foray led to escalating to dispute resolution then maybe you don't have the right temperament. Not everyone is well-suited to being an encyclopedia editor, and there's nothing wrong with that. (Pro tip: Post your suggestions/argument in the "Talk" page first).

While the system is easy enough to use, there are also cultural/social/bureaucratic skills to learn.

BTW: The articles on "politically charged subjects" are the result of years of work and are generally pretty OK, if bland. Undoubtedly you could change them in ways _you_ would find more acceptable, but it's unlikely that those of an opposing viewpoint would agree.

<comment><USER4> > My guess is that it happens when people dive in to fix something that they > "know" is wrong, and feel strongly about - and then get upset when it's > reverted because they provided no evidence.

I think that it is more interesting that the article suggests that this is (at least partially) the result of an increase in paid editing:

" _What changed in his absence, Wood says, is that employees of public- relations firms began to understand the value of a Wikipedia page, and tried going in to make edits themselves, with little regard for the site's standards. The result was that the burden of proof became even heavier on newcomers, and, Wood says, even valid information was getting rejected out of hand by seasoned editors._ "

<comment><USER5> This is a false argument because the number of PR edits is so small in comparison to the total number of edits. The culture is toxic, period. See my other post on this thread.

</comment></comment></comment></comment><comment><USER6> The most enlightening thing in this article is a graph which shows numbers of editors has declined by 25% while articles are more than doubling over past 8 years. There must obviously be breaking point sooner or later where Wikipedia has more garbage then useful bits. My take away is that Wikipedia's model of small tribes of editors is not working and is demonstrably unscalable.

What could be the replacement? How about Stackoverflow style reputations that one must accumulate overtime and then they translate to _privileges_. The beauty of Stackoverflow is not its content but this community model they have sharpened to almost perfection. It feels far more scalable than Wikipedia's arcane model of emulating print world editorial team and beautifully takes advantage of gamification combining rewards with career profile.

<comment><USER5> I'm not really sure why you've been downvoted, as this seems like a non- controversial statement. I am working on a crowdsourced content site, a large part of which is a replacement for Wikipedia's biography and news-based pages (see profile for link). We do gamification (badges for adding certain types of content) and we pay our writers in revenue share. That said, in my experience, the issue is not one of personal reputation, but one of creating a system where quality data can be added irrespective of the quality of the person adding it. The focus should always be on the quality of the edit, not the quality of the editor. This may seem counter intuitive, but a well-designed crowdsourced site does not actually need experts in the subjects it is compiling.

<comment><USER6> I'm surprised at downvotes too. I suspect there are lots of n00b on HN who thinks downvotes is way to express disagreement. I use downvote for not-nice and spammy comments. If I want to express disagreement, I would just put that in reply. But apparently new HN population does things differently.

<comment><USER7> Is pg a n00b? Long ago, he said, "I think it's ok to use the up and down arrows to express agreement."

[https://news.ycombinator.com/item?id=117171](https://news.ycombinator.com/item?id=117171)

<comment><USER6> I'm surprised at that comment because his writings had given me a different impression. PG's view basically means that people with different opinions and minority views would be punished heavily by the community effectively leading to strip them out of all karma. This guideline would encourage people for groupthink and make them hesistant to offer any perspective that might be remotely perceived as controversial. I truly hope pg's above view was transient and has evolved.

<comment><USER8> Doesn't it, though? I see reasonable but unpopular opinions blasted into background color all the time. I make it a point to upvote these posts, even if I disagree with the original opinion, because of this behavior shaping that takes place on HN these days. And if I didn't know better, I'd say it was a conspiracy. :P

</comment></comment></comment></comment></comment></comment><comment><USER9> I'm not sure I can define why I still use Wikipedia. The information is not dependable, and I never know when I'm reading nonsense. But I do use it at times.

If I need accurate information from an encylopedia, I now use Britannica.com (Encyopedia Britannica); it's informative, well-regarded, serious, and succinct. Coverage isn't as broad, of course. I'm not sure how the paywall works but a lot of content is free; I don't have a subscription and generally it's not a problem. Highly recommended.

<comment><USER10> More often than not accuracy is in the eye of the beholder. Only a fraction of the articles in any encyclopedia cannot be disputed. If one relies on only one encyclopedia then one is bound to copy the errors ([https://en.wikipedia.org/w/index.php?title=Wikipedia:Errors_...](https://en.wikipedia.org/w/index.php?title=Wikipedia:Errors_in_the_Encyclop%C3%A6dia_Britannica_that_have_been_corrected_in_Wikipedia&oldid=671820885)) or some specific perspective on historic events, personae and even significance of scientific achievements.

A simple example are WP articles about the same topic in different languages, an even more stark contrast is any western encyclopedia compared to one that was created in a socialist country. I still have access to the latter and, especially for historic events, enjoy reading the other side of the story.

What each encyclopedia should do to nurture critical thinking: put "might be wrong" in bold above _each_ article.

And we could get used to not referring to "WP article XYZ", but instead to "WP article XYZ, Version N" because otherwise our references to those articles are absolutely useless for people who want to do serious research.

PS: I think wikimedia is (was?) on the right track by building some kind of "fact engine" where different, even contradicting versions of the same facts could be registered and some algorithm would then determine which would automatically be included in pages as the "most probably correct". (Sorry, I don't have any links to back that up, this is what one of their devs told me about 2 years ago.)

<comment><USER11> "Can be disputed" doesn't mean there isn't a specific interest group jealously guarding that article to protect a specific POV.

</comment></comment></comment><comment><USER12> At a certain point we need to give up on the idea we can sustain these public spaces without public support - taxes to an extent, laws of the form of "Net neutrality" (that might be free speech) and well plain old public approbrium

In the Edwardian era in UK, London was dotted with gated enclosures, private gardens solely for the rich - During the Second World War the hates were torn down for their metal content, and almost none were replaced, the community gains had been so great. Taxes to pay for the upkeep of the gardens, laws to ensure they could not be re-incorporated.

Somewhere in this is the solution to what Wikipedia has started.

</comment><comment><USER13> This probably happens quite a lot. Not every subject in Wikipedia will have a vigilant editor.

There was an article about ships owned by a major commodities trader dumping poison in the ocean, and they got their PR company to edit the article. I'm quite confident this is actually true because someone (inside) alerted me to the guy's name used to edit Wikipedia, and then showed me the PR company's people page.

Hard to see what can be done about this though. If someone is being paid, they have a lot more time to cleverly word their story. In some cases legitimately, in others not.

<comment><USER3> Yes it's a problem, but perhaps less than you might think.

First, in most cases PR spin has a "smell". Spotting that in an article an editor may dig into the edit history - where the story will be pretty clear of which links are removed, wording changed etc.

There are about half the editors that there were a few years back, but many will work on a very wide variety of articles, and in many cases spotting and resolving "spin" issues doesn't require special expertise - and just highlighting that spin is going on can be useful in itself.

Pro-tip: When reading anything on Wikipedia it's often useful to check the associated "Talk" page for any ongoing controversy, and the "History" page to see what the article said 6 months ago.

<comment><USER14> > First, in most cases PR spin has a "smell"

How do you know?

<comment><USER3> Got me! Re-read as "many".

<comment><USER14> Sorry, can't help but...

[https://en.wikipedia.org/wiki/Weasel_word#Forms](https://en.wikipedia.org/wiki/Weasel_word#Forms)

</comment></comment></comment></comment></comment><comment> rm_-rf_slash While it seems there is little we can do to prevent the influence of money in our politics, truly democratic spaces like Wikipedia remain an important place for knowledge to be shared and verified. If we allow centralized sources of trust to become bought, sold, and politicized, then we risk fracturing into an Internet dark age, where your source of information is a function of your world view. What if instead of one Wikipedia, there was a pseudo version for people who strictly believe in creationism, or a version imposed on residents of Turkey that actively omits and reports to the government any complaints about the prime minister or references to the Armenian Genocide?

<comment><USER15> > What if instead of one Wikipedia, there was a pseudo version for people who > strictly believe in creationism

There is something like that: Conservapedia[0]. Reading it is fairly infuriating. Mostly because it is so extremely one sided and trying to argue an agenda in every single article.

[0] [http://www.conservapedia.com/Main_Page](http://www.conservapedia.com/Main_Page)

<comment><USER16> > Reading it is fairly infuriating

I think you mean hilarious

<comment><USER17> Agreed. I think the problems is that he is reading it the wrong way by taking what is written as factual. Clearly it makes more sense if you consider the articles are written in "the onion" style.

<comment><USER18> Except they aren't. The founder of Conservapedia certainly takes it seriously, and he zealously guards the site to make sure it fits his viewpoint

[https://en.wikipedia.org/wiki/Andrew_Schlafly](https://en.wikipedia.org/wiki/Andrew_Schlafly)

<comment><USER19> Just because he takes it seriously doesn't mean anyone else has to.

<comment><USER18> The point is that it isn't written in an "onion" style like the person I replied to claimed

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> A long article, but what I found most astonishing was an Oxford University Press Medical Textbook plagiarizing from Wikipedia!

[https://cdn.theatlantic.com/assets/media/files/textbook_vs._...](https://cdn.theatlantic.com/assets/media/files/textbook_vs._wikipedia.jpg)

From the article: "He pulled up the page's revision history to identify the offending editor. He saw that the section was co-written in 2006 by two users, Rhys and ChyranandChloe, and that it was updated in 2010. He jumped back over to the textbook and saw that it was published in 2011. It turns out Heilman had it backwards: It was someone on Oxford's side, perhaps Lloyd, who had taken from Wikipedia. (Lloyd did not respond to multiple requests for comment.)"

"The plagiarism was barely concealed. For reasons that remain unclear, some of the original citations from the Wikipedia page dropped out, and were replaced by pointers to other articles—articles that didn't appear to support the claims made in the text, according to Heilman. In that sense, the Oxford textbook did not simply contain plagiarized text from Wikipedia; it appeared to make it less reliable."

"Christian Purdy, a spokesperson for Oxford University Press, acknowledged that some text was copied, but says this didn't qualify as plagiarism. Instead, he called it an "inadvertent omission of an appropriate attribution.""

</comment><comment><USER21> I'm not sure this is really much more of a problem than POV pushers in general. Usually it's pretty obvious when someone is pushing their own agenda, and easily solved (assuming people are actually watching the page in question).

<comment><USER11> If the incumbent editors watching the page are the source of POV, then the mechanism is to prevent the correction of POV rather than to correct POV. There is no mechanism to prevent this.

<comment><USER21> >There is no mechanism to prevent this.

Yes, there is. You can get uninvolved editors to help by posting on various project boards. You can also get admin intervention, arbitration, etc. There are lots of options if you take the time and effort to look for them.

<comment><USER22> And as long as the other side has more time (for example, by being better funded so they can contribute more time or by having more people invested in maintain a bias) it makes is near impossible. Technically grandparent is incorrect because they claimed the mechanism doesn't exist, when the real issue is that it is broken.

<comment><USER21> In my experience the number of funded editors is tiny compared to the army of volunteers. What article is having the issue you mention?

</comment></comment></comment></comment></comment><comment><USER23> As someone who works on tasks reported on the Wikipedia conflict of interest noticeboard, I've been dealing with the paid editing problem for some time. Wikipedia is worth some effort to preserve; it is, after all, the highest rated non commercial site.

Most of the conflict of interest cases are simple promotion of a band/company/product/self by one person, usually someone with no other editing interests. Some are detected automatically by programs which check new Wikipedia content against the web for duplicates. Those are checked for notability, and many are deleted because they don't meet Wikipedia's criteria for inclusion. A few years ago, this was mostly a problem with garage bands; now it's a problem with garage startups. Those are easy to deal with.

Then there are subjects where there's unquestioned notability, and the subject of the article is trying to look good. Those usually involve content that reads like a sales brochure. Sometimes it's well-cited, but to weak sources. A typical example involves a company trying to list every flavor in which their product is available. The usual response to this is to delete promotional language and unnecessary product detail. The result can be a cold but well- cited article about the company's financial history. For individuals, resume inflation can be a problem. The requirement for a reliable source usually deals with that. Wikipedia, remember, is about "verifiability, not truth".

Promotional editing can backfire. Badly. When promotional editing is found, standard procedure is to look in Google for other information about the subject. If this turns up clear negative info, it will probably go in the article and stay there. Criminal convictions, regulatory actions, accident reports, investigative reporting, and criticism by consumer groups reported in the mainstream press tends to displace PR-type material. If the person or company has done something really bad, their article is likely to focus on that. This can result in frantic efforts by a company to make the "bad stuff" go away.

I was involved with the "Banc de Binary" mess, where the company was desperately trying to remove their legal problems. (The SEC and CFTC had booted them out of the US for a long list of blatant securities-law violations. Banc de Binary is not a bank, or a broker; they're an online casino set up to look like a brokerage. They're the "house"; if you win, they lose, and they set the odds.) Banc de Binary at one point offered $10,000 on eLance for someone who could "fix" the article their way. That was noticed and got press coverage. After much discussion on Wikipedia message boards, the article ended up rather negative on the company, all their accounts were blocked, and many people have that article on their watch list in case somebody tries something.

That's unusual; it seldom gets that bad.

That's the blatant stuff. More subtle spin is hard to detect. Minor changes to obscure medical or technical articles to make some product look good are tough to deal with, because they require subject matter expertise. This is a growing problem. But the usual procedures work; if only vendor X is mentioned, a search for a competitor may turn up vendor Y, which can be added to the article.</comment>


Lecture 16: How to Run a User Interview - <AUTHOR> http://startupclass.samaltman.com/courses/lec16/

<comment><USER2> The #1 piece of advice that I took away from this was: ""Who you talk to is just as important as what questions you ask and what you pull away from it."

Nowadays with things like Lean Startup Machine and Startup Weekend (which I do think serve a purpose and are valuable to building habits around customer development), I've seen prospective entrepreneurs get caught up in the MOTIONS of doing customer development and interviews thinking i.e. just getting out of the room and talking to anyone they can find on the street, instead of the real target customer that you've really thought about. I like Emmett's focus on really thinking this part through.

I've published the 31 top quotes that I picked up from the lecture here: [https://medium.com/how-to-start-a-startup/31-quotes-from- emm...](https://medium.com/how-to-start-a-startup/31-quotes-from-emmett-shear- on-how-to-run-a-user-interview-dacf0f09f5d7)

</comment><comment><USER3> Awesome what you're doing here with the video and the transcript. But can we make the transcript not include the pauses? It really throws me off the flow of the takeways when you put all the 'Ums' and 'Ahh's there in the transcript. It doesn't add at all to the message when reading it...

"Um, so, uh - so that was Twitch. And I'm going - I want to give you guys a little bit of a, uh - uh, a little bit of an insight into, uh, with Twitch what that, what that meant going to go talk to users."

I know keeping it real is great and all but for the people who are reading and not watching, it would be awesome if some editing could be used to make the read more succinct.

"So that was Twitch. And I want to give you guys a little bit of an insight into what that meant (when) going to go talk to users."

Minor irk of course, really appreciate what you've done otherwise, thanks.

<comment><USER4> yep it's being edited! should be a lot better now

</comment></comment><comment><USER5> One of the points in the lecture was that you have to be ready to abandon a feature, even if you really believe in it, if user feedback indicates a lack of interest.

But what if it's one of those things (like TiVo and Uber) that people think, in advance, that they don't need -- but it turns out they'll be totally hooked once they try it?

<comment><USER6> Aren't we also encouraged to embrace "disruptive" ideas that change the status quo? No focus groups, full of average people who are content with the default is going to give that much meaningful feedback for game changing features IMO...

<comment><USER7> "These average people who are content with the default" are going to be your customers. My grandpa has an iPhone and his friend uses uber all the time. Both are very conservative and might fall into that realm of 'average people' yet use disruptive game changing ideas.

Get out there and empathize with real people with real problems. You'll find that even the most boring, ho-hum, run of the mill person will be happy to lay down hard cash for your game changing idea if it fixes THEIR problem.

That being said, focus groups are a horrible way to get meaningful feedback. Customer interviews and other more in depth ethnographic techniques are going to deliver what you're looking for.

</comment></comment></comment><comment><USER8> Great lecture!

Coincidentally, my team is building a product that connects startup founders to user interviewees, specified by demographic. Looking for a few founders to test the platform for free before we launch. Let us know if any of you are interested! firstname.lastname@example.com

<comment><USER9> that sounds like an interesting concept, similair to part of what something I am working would like to acheive. Are you providing a structure or allowing 'interviews' to be whatever form/structure the interviewer wants? good luck, its a problem i havent seen solved properly yet!

<comment><USER8> We're providing a structure: Founders enter open-ended questions and reference links. Interviewees answer questions while referring to the company website in an iframe above.

So you can assign tasks then ask usability questions, or gear the interview more generally toward your business concept, how well users understand your site's value prop, etc. Love to hear more about wht you're working on!

</comment></comment></comment><comment><USER10> Thank you! I got the most out of this lecture because the presenter went into detail on just one thing.

I feel that almost all of the startup advice is usually more of an idea with a lot of missing details on how to apply it. And this talk showed how important the details are and how if you just take the typical high-level advice of "talk to users" there are a lot of things you can screw up.

</comment><comment><USER11> May I ask who were Twitch's competitors and how did they differentiate themselves when recruiting users from those competitor sites?

</comment><comment><USER12> This is timely, I have one today.</comment>


Git implemented in Rust - <AUTHOR> https://github.com/chrisdickinson/git-rs <comment><USER3> I love to see people reimplementing existing tools on their own, because I find that to be a great way to learn more about those tools. I started on a Git implementation in Rust as well, though I haven't worked on it in a while: [https://github.com/avik-das/gitters](https://github.com/avik-das/gitters)

<comment><USER4> Are you basing it off anything in particular? Like outside of just going through gits own source code?

<comment><USER5> Just reading source code is a whole different experience than actually implementing something yourself. Implementing something pretty much forces you to "be right" in your understanding, while reading can be anything from "really studying" to skimming.

<comment><USER6> Completely agree, though sometimes you _HAVE_ to go through existing source when you do something wrong. I've implemented libraries based off of specs and white papers, and even then there's some vagueness that doesn't work in practice when there are holes.

Love to see things like this all the same as they tend to solidify protocols/specifications. This of course can have both good and bad results.

</comment></comment></comment></comment><comment><USER7> If you're interested in this, you may enjoy "Building Git" by James Coglan - <USER2> comprehensive book that takes you through reimplementing git in Ruby.

[https://shop.jcoglan.com/building-git/](https://shop.jcoglan.com/building- git/)

<comment><USER8> If you have read this book, would you care to comment about its content and quality?

It is something I am interested in buying but I have not been able to find reviews of it.

<comment><USER9> I haven't read it yet, but I'm lucky to call the author a friend. I read all of his tweets about it while he was building it. I expect it to be of extremely high quality. I've got a lot of respect for his abilities.

The only reason I haven't read it yet is that I think it deserves a lot of attention and I haven't made time yet.

<comment><USER8> Thanks, I bought the book.

Still undecided as to which language to work in, I wanted to use rust but the one part I'm unsure about is possibly where tree like data structures will need to be implemented?

I guess that's tough to do in rust? I will give it a try.

<comment><USER10> Graphs are harder if you try to use pointers to identify neighbors. In Rust, a pointer is not merely an index into memory; it is a statement and guarantee about how that memory will be accessed. These semantics are more than a graph structure needs.

To "get around" this (but see the next paragraph), we usually associate each node to a simple identifier such as an integer (usize), and store all nodes into a Vec. Neighbors are indexed by this identifier rather than a pointer. (Indirection? Maybe. But I'm pretty sure most processors support a base+offset mode just as easily as a direct reference mode.)

Honestly, I think this is good practice even outside of Rust. If you're using pointers, and you want to associate some extra data to a node that isn't part of its graph structure -- a label, say, or some other structure that you're modeling the relationships of -- there's no good way to add that data without modifying the definition of a node. A pointer indexes a _single_ point in memory. An abstract identifier may index any number of points in memory -- just create another table containing the new information you want to associate.

<comment><USER11> There are benefits but they come with downsides: you can have node ids pointing to deleted nodes, and collecting unused nodes is up to you. If you want to avoid fragmentation, you need to recycle nodes and possibly node ids as well. These are things garbage collectors handle.

It's not all that different from a database, though.

<comment><USER10> > It's not all that different from a database, though.

Indeed! I'm tempted to coin a variant of Greenspun's Tenth Rule: any sufficiently complicated program contains an ad-hoc, informally specified, bug-ridden, incomplete implementation of a database engine.

> There are benefits but they come with downsides

Downsides relative to what? The downsides listed are all in common with traditional pointer-based references, so I would argue that garbage collection is rather orthogonal to the question of storing indices instead of pointers. Any allocation comes out of a memory arena of some kind, be it an explicit vector of slots or the implicitly-defined standard heap. The tools for solving these problems are the same in all cases.

Certainly, Rust's references avoid all of the problems you listed. Rust pointers essentially embed the semantics of a garbage collector at compile- time [0], in the domain where ownership patterns can be strictly verified. But nodes within a graph are already a poor fit for the ownership model -- the entity that "owns" a node is really the graph itself, not its neighbors -- so that's the level of granularity at which Rust's references are useful. You need something else within the scope of the graph.

EDIT: On reflection, you might be referring to a language like Java which has an ambient global garbage collector. Indeed, using indices instead of pointers means you're on your own -- you've allocated the memory arena through the standard means, but then you take on the responsibility of managing that memory yourself. This is a fair criticism! Purely in my experience, data modeled as a loose graph of directly-related objects is a lot more difficult to understand and maintain than data modeled indirectly using some form of identifier -- mostly because of the effects I mentioned in my earlier post on associating new information to an entity.

[0] [https://words.steveklabnik.com/borrow-checking-escape- analys...](https://words.steveklabnik.com/borrow-checking-escape-analysis-and- the-generational-hypothesis)

<comment><USER11> Yes, that's what I meant. Cleaning up unreferenced nodes (should you want to do that) would require some kind of mini-garbage collection algorithm. And indeed, git has a gc command to do this, even though reference counting would work for a DAG. It's doable, but it's not what I'd call simple.

But if you know through some other means the exact time when a node should be deleted, you can delete it at that time, and anyone following a soft reference will find that it's no longer there, which may be a way of catching a bug. This is how both databases and entity component systems work. But it does mean that resolving a reference can fail, and you have to handle that somehow.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Also a git implementation in pure OCaml, used for irmin git-based kv storage:

[https://github.com/mirage/ocaml-git](https://github.com/mirage/ocaml-git)

[https://github.com/mirage/irmin](https://github.com/mirage/irmin)

<comment><USER13> Here is an implementation of a Ruby based kv store build on top of rugged, which is built on top of libgit2:

[https://github.com/ioquatix/relaxo-model](https://github.com/ioquatix/relaxo- model)

It's so much fun, but not that practical for scalable websites.

<comment><USER12> >It's so much fun, but not that practical for scalable websites.

Git based kv has a bit different purpose than the regular kv storage. They are intended for communication between entities, running in parallel, sort of transactional memory. They are not intended for users' data storage.

<comment><USER14> That sounds more like a tuple space than a KV store?

<comment><USER12> Not sure, but the idea is that you could not only read and write, but write in parallel so the keys are merged according to the merge rule you've provided.

</comment></comment></comment></comment></comment><comment><USER15> Not really related, but a quick plug for the work that Mercurial is doing to port substantial portions of its main binary to Rust: [https://www.mercurial- scm.org/wiki/OxidationPlan](https://www.mercurial-scm.org/wiki/OxidationPlan)

My understanding is that they want to get it fully ported before Python 2 EOL.

</comment><comment><USER16> I don't see any info about a license.

Strongly recommend using some standard FOSS license before plenty of people add commits and it gets a big mess clearing up the licensing situation later.

<comment><USER17> > Implementing git in rust for fun and education!

Also, not having a license file isn't a messy situation, that means "this project is protected under Berne Convention copyright": the author is the only one holding every rights on the code and every use that is not explicitly allowed is a copyright infringement (unless it's fair use).

<comment><USER18> That sounds nice and all but it's wrong in two major ways.

First: GitHub has a Terms of Service which was somewhat-recently amended to make this license grant explicit:

[https://help.github.com/en/articles/github-terms-of- service#...](https://help.github.com/en/articles/github-terms-of- service#5-license-grant-to-other-users)

"Any User-Generated Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. By setting your repositories to be viewed publicly, you agree to allow others to view and 'fork' your repositories (this means that others may make their own copies of Content from your repositories in repositories they control)."

(Crucially, it doesn't require an open-source license, though.)

Second: even without that, there's such a thing as an implied license:

[https://en.wikipedia.org/wiki/Implied_license](https://en.wikipedia.org/wiki/Implied_license)

Like, if you write something down on a piece of paper, you can't then sue the owner of the paper for copyright infringement.

Similarly, if you upload code to GitHub, and tell it to share your code, you can't then sue them for sharing your code, ToS or no ToS.

<comment><USER19> Pretty much all the TOS says is there's an implicit reproduction license (other users can see & fork the work) and possibly broadcast (the fork itself has the visibility of the original). Not adaptation, not use, not exploitation, …

And that license grant is solely through github as a service, it's unclear that a local clone is even permitted.

<comment><USER18> That's... somewhat true. My main objection is to "the author is the only one holding every rights on the code and every use that is not explicitly allowed is a copyright infringement (unless it's fair use)".

The ToS doesn't say there's an implicit reproduction license, though; it says there's an explicit reproduction license.

The other licenses can still be argued to be implicit. For instance, you have a decent argument that local clones are an implicit license – GitHub provides a "Clone or download" button directly on the repo page, and it's one of the main use cases of GitHub. (Other arguments exist.)

<comment><USER17> > The ToS doesn't say there's an implicit reproduction license, though; it > says there's an explicit reproduction license.

Then it's totally excluded from my claim which aims «every use that is not explicitly allowed». :)

</comment></comment></comment></comment></comment></comment><comment><USER20> Rust seems like a good language for git given its performance and memory- safety, no?

<comment><USER21> Actually any high performance GC'd languages would be fine too because latency is a non-issue for long running git operations (you won't notice if your git clone pauses for 100ms, whereas you will notice if your UI does). Throughput of malloc() and GCd languages tends to be similar when latency isn't a concern.

<comment><USER20> I was speaking more to stability. Rust is designed to be an incredibly safe language without sacrificing any performance; that seems like a good match for a version-control system.

<comment><USER21> Most GC'd languages are also memory safe.

<comment><USER22> FYI, Rust's safety goes beyond that. Its ownership model keeps you safe from data races, unlike, to my knowledge, GC languages.

<comment><USER21> IIRC Rust's safety is provided by affine types; all languages with affine or linear types can provide the same guarantees Clean and Mercury both come to mind of the top of my head (IIRC Clean had "Concurrent" in its name at one point), and I think there are both Haskell and F# variants with either affine or linear types.

In addition there are many other solutions to safe parallelism and/or concurrency, some of which don't require a type system at all; Erlang is famous for safe concurrency and is untyped.

Lastly, there's good old fashioned multiprocessing which can be safe just by not sharing memory.

There is no one feature that is new in Rust, but it has a relatively unique set of features in the non-GC language world; ATS is the only one coming to mind, though I'm sure there are some other niche ones.

I love this combination in rust because latency sensitive operations in GCd languages are notoriously hard to achieve. Lisp was able to be an operating system because nobody needed to run quake at 100fps on a lisp machine. With GC you can pick latency or throughput but can't reliably get both without coding around the GC.

This does mean for me that when considering things that rust is particularly good at, latency sensitive applications stand out; this is not to say it's bad at non-latency sensitive applications, just that one has a lot more choices when latency is a non-issue.

</comment></comment></comment></comment></comment></comment><comment><USER23> I like the changelog. Looks like a zero-effort way to publish something other people could make use of.

<comment><USER24> No, currently they can't as there is no open source license.

<comment><USER25> I used it anyway. Sue me.

</comment></comment></comment><comment><USER26> Can somebody tell me what is behind the recent rewrite-all-the-things-in-rust craze? I get it can have some benefits in terms of security, but it seems rewriting so many things in it just for the sake of it is a bit excessive.

I understand some of these are very likely for educational purposes (like this one and others; it's good for getting more familiar with the language), but it still seems to be a bit of a strange trend (especially since people who don't need to learn are doing it, seemingly just because "yay rust").

<comment><USER27> I scrolled down for this comment.

Actually there's a lot of great reasons to rewrite everything in every language. Git is an especially good piece of software to implement everywhere because it's relatively stable and it's pretty useful.

As for _actual_ reasons, one good example is so you can keep your dependencies in the language, using the language package manager. For Go nobody even questions that this is worth it; it enables painless cross compiling and completely static, libc-free binaries. For Rust that may not be a thing, but you do at least get the benefits that you could integrate Git functionality without having to hack around in porcelain.

This one here is a learning experience by it's own description, but I would suggest people stop complaining about "rewriting everything" in $LANGUAGE. The opposite complaint is often cited as a reason _why to not_ use the language (that, for example, basic programs haven't already been ported.) If we did build an alternate world with feature parity, unit testing, optimizations, in a memory safe language, I doubt many people would be complaining about the strange trend of rewriting things anymore.

<comment><USER26> That's a good point; you're right that it's helpful to be able to interface with such a ubiquitous program natively in a language of choice. I did see a mention on the page of deploying as a crate and using in another program; that seems very convenient.

> stop complaining

Not a complaint; more a question as to why there's a specific move around rust. I appreciate the reply; that's exactly the kind of response I was looking for.

<comment><USER27> Fair enough. There's definitely a lot of folks who do get upset over this stuff, maybe as pushback to the new language hype.

</comment></comment></comment></comment><comment><USER28> I started one in PHP (because why not). It's pretty fun!

</comment><comment><USER29> I would like to see some sources like this that are language agnostic that give you the tools needed to implement your own popular tool. For example, where could I look to find a written description of the way git works from the ground up? Kind of like a "guide to implementing X" type of thing, but without code.

</comment><comment><USER30> What's with all those posts about "X implemented in Rust" today?

</comment><comment><USER31> I'm still waiting on a C64 port.

</comment><comment><USER32> Am I the only one who thinks of this article after reading the whole thread? > [https://overreacted.io/name-it-and-they-will- come/](https://overreacted.io/name-it-and-they-will-come/)

HN discussion: [https://news.ycombinator.com/item?id=19485609](https://news.ycombinator.com/item?id=19485609)

</comment><comment> OpenBSD-supreme >rust this

>rust that

Why re-invent the wheel? Ada is superior. :^)

</comment><comment><USER33> awsm I was really interested in how could one go about implementing git like system. nice work OP</comment>