Live data from Hacker News

A pure JavaScript implementation of Git for Node and browsers

github.com

141–150 of 203 posts

Re: A pure JavaScript implementation of Git for Node and browsers

#141

Earlier quoted context omitted.

I can't begin to describe how sad I am that we didn't end up using mercurial everywhere.

It's really strange to me that nowadays source control seems to be, largely, a monoculture. Back in the day I either used, or knew plenty of people using any of CVS, Subversion, Sourcesafe, Sourcegear Vault, Perforce, AccuRev, ClearCase, along with a few others. Whilst distributed version control is a huge leap forward over many of those older systems, it's odd that nowadays it seems to be git or, well, nothing. I'm…

The irony of a decentralized version control system centralizing SCM usage to a single SCM and to a single SCM hoster, basically. Github dwarfs the alternatives.

Re: A pure JavaScript implementation of Git for Node and browsers

#142
post #10

I think it's interesting how there's two phenomena that seem to be related to me that get posted here and seem to get treated with different responses. One the one hand, we have software originally written in C/C++ being rewritten in Rust (not often, sometimes just conceptualized), and there's often a real push back by some people about how it's a waste and not useful. On the other, we have software rewritten in Java…

By the way, I suppose git can already run in JS, if compiled to WASM.

Re: A pure JavaScript implementation of Git for Node and browsers

#143

Earlier quoted context omitted.

You mean wherever there is llvm? It's a large subset, but it is still a subset.

Huh til that rust isn't compillable by gcc.

That's different. The rust toolchain is compiled by rust, and it relies on LLVM which can be compiled by GCC. But LLVM does not have a backend for every architecture (or even if it does, it might require extra effort from the Rust compiler using it and they have not enabled support for _everything_). Thus not all architectures can be targets for Rust programs.

Re: A pure JavaScript implementation of Git for Node and browsers

#144
post #97

Earlier quoted context omitted.

IMO, this is because there's a general attitude about porting to Rust that porting to Rust, by itself, makes a material improvement in the quality of the software (e.g. reliability, performance, readability), and that these improvements that can't be achieved in C/C++. Entrenched C developers then rise to the debate to defend their language. This debate has happened often enough that any time someone ports something…

I think you're eliding a lot of context here. Specifically the context of overzealous Rust fans. There's a strong, though not universal or even majority sentiment that "writing anything in C or C++ is basically the same as committing assault, murder, professional malpractice or other similar hyperbolic claim" that some Rust advocates engage in. There's a whole meme about the "Rust Evangelism Strikeforce" on n-gate.co…

To provide some supporting evidence for this, a choice comment made a couple of days ago:

> Rust has many benefits and I find it hard to imagine how anyone manages to get any performance-sensitive work done in the cryptocurrency industry with anything else.

Re: A pure JavaScript implementation of Git for Node and browsers

#147
post #77

Earlier quoted context omitted.

Your description is correct for tags, a little off for branches. You don't have to switch to master to create a branch, you have to switch to the branch you want to branch off of, which is the same as git. Also, all branches are visible and accessible from any branch/revision, unlike tags.

Git is not the same in this case. Since git branches are just refs, I can do whatever commits or other changes I want and then assign a branch name. With hg every commit you make must first be done on the branch you want. This, when understood fully, can allow git to be much more flexible when manipulating the tree.

You can rebase mercurial commits to a branch after the fact. As others point out you can also use bookmarks that are very similar to git branches, and you can also commit with no branch or bookmark at all and mercurial won't hide or garbage collect those commits (unless you tell it too). It's actually more flexible than git.

Re: A pure JavaScript implementation of Git for Node and browsers

#148
post #144
post #97

Earlier quoted context omitted.

I think you're eliding a lot of context here. Specifically the context of overzealous Rust fans. There's a strong, though not universal or even majority sentiment that "writing anything in C or C++ is basically the same as committing assault, murder, professional malpractice or other similar hyperbolic claim" that some Rust advocates engage in. There's a whole meme about the "Rust Evangelism Strikeforce" on n-gate.co…

To provide some supporting evidence for this, a choice comment made a couple of days ago: > Rust has many benefits and I find it hard to imagine how anyone manages to get any performance-sensitive work done in the cryptocurrency industry with anything else.

I've seen every single thing I mentioned ("murder, assault, malpractice") applied to C++ programming in comments in Rust threads.

Re: A pure JavaScript implementation of Git for Node and browsers

#149
post #127
post #83

Earlier quoted context omitted.

Javascript runs everywhere where there is a browser. Rust runs everywhere where there is a c compiler, which is funnily enough the sample places that C/C++ run.

I'm not sure on the last point, a lot of architectures, especially niche ones, aren't supported by Rust at all while there are plenty of C compilers for them going around. (have fun trying to get Rust working on 8bit controllers or Itanium/ia64)

I think the point is less that Rust runs everywhere that C runs, and more that there doesn't exist an environment that can run Rust and not run C (which is not true for Javascript)

Re: A pure JavaScript implementation of Git for Node and browsers

#150

Earlier quoted context omitted.

IMO, this is because there's a general attitude about porting to Rust that porting to Rust, by itself, makes a material improvement in the quality of the software (e.g. reliability, performance, readability), and that these improvements that can't be achieved in C/C++. Entrenched C developers then rise to the debate to defend their language. This debate has happened often enough that any time someone ports something…

People are actually claiming that Rust is more readable than C?

It depends what you call “readable” I guess, if you think it as : “I can have a glance at this code and feel comfortable”, then obviously C is more readable than Rust, because Rust has a quite a few specific syntaxes that will feel alien to anyone not accustomed. But I'm not sure this metric is relevant.

And on the other hand, if you call “readable” the ability of someone knowing the language to get on board of an existing project, understanding the control flows and feeling confident to make changes, then Rust wins easily because the type system gives you all the information you need straight in front of you.

The first time I had a look at Servo[1], I was able to change what I wanted (which were quite a lot of thing: a few dozens of lines in something like 5 or 6 different files) in a few hours. And when I compiled it it worked fine. Good luck doing the same with a C project you just discovered. And I wasn't even a professional Rust programmer at that time.

[1] the experimental browser engine form Mozilla

Post reply on HN