Code in the project looks really well done. It just needs semicolons ;) I don't get the whole no semicolon movement, especially when you probably have to work with C/C++/C#/Java at some point and it means retraining your brain. Also semicolons help visually distinguish commands from control. 2 spaces I can definitely get behind!
A pure JavaScript implementation of Git for Node and browsers
111–120 of 203 posts
Re: A pure JavaScript implementation of Git for Node and browsers
#112Re: A pure JavaScript implementation of Git for Node and browsers
#113Earlier 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.
You're aware that most operating systems have a C API, right? Give me a place C doesn't run where js does.
In a browser. Yes, there's wasm, but it has a lot of limitations that don't apply to JavaScript. fineline had a good comment about it upthread: https://news.ycombinator.com/item?id=17088315
Re: A pure JavaScript implementation of Git for Node and browsers
#114Earlier quoted context omitted.
In Mercurial (circa 2016) Tags and branches were stored inside the repo itself, which meant you had to switch to the master branch to create a new branch or create a tag. If you created a tag in a branch the tag was visible only when you were in that branch. It caused numerous headaches trying to figure out why a tag didn't get pushed upstream. Git correctly treats this as metadata and stores it outside of the source…
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.
Re: A pure JavaScript implementation of Git for Node and browsers
#115Earlier 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…
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.
You mean wherever there is llvm? It's a large subset, but it is still a subset.
Re: A pure JavaScript implementation of Git for Node and browsers
#116I 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…
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…
[deleted]
Re: A pure JavaScript implementation of Git for Node and browsers
#117Earlier quoted context omitted.
Just wait for the Electron browser...
Mozilla has used their rendering engine to render their UI for YEARS. Not sure if they're still using XUL with their latest few updates though.
XUL is still alive but XBL is at least going away now. XUL will probably eventually go away too.
Re: A pure JavaScript implementation of Git for Node and browsers
#118JavaScript: Because that's what we know.
Possibly; but as someone who maintains a NodeJS native addon in C++, I frequently _dread_ new releases of NodeJS that invariably break my bindings. A shim library called "NaN" has done so much to help with this; I would have given up sooner.
Having libraries implemented purely in the language from which the library is implemented solves many many headaches, irregardless of JavaScript or not.
Re: A pure JavaScript implementation of Git for Node and browsers
#119Earlier 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.
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.
Re: A pure JavaScript implementation of Git for Node and browsers
#120Earlier 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.
And with wasm, Rust/C/C++ all can run in the browser too...
When people say “The Browser” they mean “that thing which is on literally every computer where you instantly load that one kind of software”.
People think the web is a technology, or that JavaScript is a language.
They’re not. It’s not. The web is an idea: it’s the idea that every computer in the world already has the runtime on it that can run your next app. Whatever that is—whatever that runtime is—that’s “The Browser”.
WASM is not that. Maybe in 10 years.