Live data from Hacker News

A pure JavaScript implementation of Git for Node and browsers

github.com

101–110 of 203 posts

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

#101
post #29
post #7

Earlier quoted context omitted.

we should just implement js in js and go full circle already.

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.

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

#102
post #83

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…

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.

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

#103
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…

I think what you're (and I'm) observing is this:

Many people know js People don't understand C++ People sort of know C Very few people know rust

Given that background, this is what I think is happening. A large group of programmers know and work with js, and so, whenever these projects crop up, the mode of comments is somewhere in the positive part of phase space, just by statistics. I personally think it's weird, but I don't drag on people for fun projects, and I usually hold my tongue here since you guys love your web things.

Since fewer people actually grok C++ and even fewer rust, when rust rewrites come out, it's a smaller, more systems/low level oriented set of folks with specialized knowledge, and therefore, they have more to say and shit to sling, and the typical comment is negative.

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

#104

Earlier quoted context omitted.

I have never treated "C/C++" as the name of a single language. I always read it as "C and/or C++".

They are so often spoken of in the same breath in ways that other languages are not, that I think a lot of people do forget that they are not the same thing nor even that culturally close.

Going to be honest, whenever I see or hear someone put them in the same category, it usually colors my impression of said person as essentially never really learning C++.

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

#105
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…

Understand your frustration. But on positive hand, javascript opens new opportunities like using git in the browser (even though meaningful use case is yet to be shown, but there is chance it will be found). On other hand rust implementation brings "just better security" (using sarcasm here for brevity). Yes, it probably could be ported to js (wasm) too, but until somebody does that...

> even though meaningful use case is yet to be shown

There are two existing use cases listed in the README: https://github.com/isomorphic-git/isomorphic-git#who-is-usin...

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

#106
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…

we have wasm now. why is anybody writing anything in javascript ever nowadays? some form of religious self chastisement?

Doesn't compiling a non-JS language into WASM require compiling a fat language runtime as well? That would put the output in couple-dozen-megabytes category.

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

#107
post #42

Earlier quoted context omitted.

A large part, I believe, is the ease of moving a git repository around. Back in the day, the central repository was a choice that stuck you to it for a long time. You literally had to setup the server, in many cases. Git, though? You just install the client and you can get started on a repository in your current directory that can easily transition to a remote hosted one. So, in a way, it is not unlike pathogen sprea…

Mercurial had major projects too. Mozilla still uses it. What it didn't have was GitHub.

Good counterpoint! Oddly, in my mind, Mozilla is not nearly as new dev friendly as the kernel is. I suspect that is just a bias in my thinking, though.

I feel that git was winning a lot of mindshare even before github. I know I certainly was using it before github. Big plus for me was the git-svn bridge that existed. Especially since I was working remotely at the time, it was much faster for me to do checkouts with a git-svn clone than to deal with raw svn checkouts. It wasn't even close. Did git beat Mercurial to that?

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

#108
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…

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?

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

#109

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?

Forrest vs trees..... Sigh

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

#110

Earlier quoted context omitted.

I have never treated "C/C++" as the name of a single language. I always read it as "C and/or C++".

They are so often spoken of in the same breath in ways that other languages are not, that I think a lot of people do forget that they are not the same thing nor even that culturally close.

Eh, I'd call them culturally close. I always read it as "the most common systems programming languages", since that's how the phrasing is usually used.
Post reply on HN