kbenson 159 days ago [-]
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 Javascript, which people are generally very accepting of, even if they don't plan to use it.

I understand the goals of these are often different, and the benefits are also often different, and they have a different set of use cases, but the reception seems markedly different (at least in tone).

I'm not necessarily trying to imply that means anything, it's just something that struck me while noting we now have Git implemented in JS.

dfabulich 159 days ago [-]
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 to Rust, even if it's just for fun or for the author to learn more Rust, C/C++ advocates see it as an attack on their language, and bite back.

test6554 159 days ago [-]
...hey everyone, I made a C/C++ developer blood pressure checker in Rust.
diegoperini 158 days ago [-]
Your entire program should be wrapped by unsafe{}.
jordigh 159 days ago [-]
The only attack I feel is calling C/C++ a language. It's two languages and we don't like each other very much. People who spend a lot of time trying to write good C++ avoid much of C's bread and butter like malloc and free, and the general hatred of C++ from C developers is well-documented.

I happen to prefer C++ to C and D to both.

guessmyname 159 days ago [-]
I have never treated "C/C++" as the name of a single language. I always read it as "C and/or C++".
jordigh 159 days ago [-]
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.
novembermike 159 days ago [-]
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.
jordigh 158 days ago [-]
Even that can be disputed. They typically have quite different domains of applications. Gamedev is seldom done in C; operating systems are seldom done in C++. Their different level of abstraction ends up having them applied to different things.
noobermin 159 days ago [-]
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++.
159 days ago [-]
scoggs 158 days ago [-]
I would assume a lot of recruiter-types or folks just getting their feet wet into programming would assume C++ is just a newer or more powerful "Edition" / "Version" of C.
mortdeus 159 days ago [-]
You can consider them the same in the sense that they are the guys with the biggest cocks on the block.
euyyn 159 days ago [-]
> we don't like each other very much

Hi are you a language?

MikkoFinell 159 days ago [-]
People are actually claiming that Rust is more readable than C?
littlestymaar 158 days ago [-]
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

rkangel 158 days ago [-]
> then Rust wins easily because the type system gives you all the information you need straight in front of you

The trait system can actually make following execution a bit harder (just like runtime polymorphism in C++), because you have to find the allocation to know the concrete type of what you're looking at. C is much clearer from this point of view (but more limited for the same reasons).

littlestymaar 158 days ago [-]
Cough!, void pointer, cough!

Traits are used to express generality, when you need it. If you don't need to be generic over your input, you don't need traits. And when you need it, Rust makes it more explicit than C (and also more performant because it's statically dispatched by default).

MikkoFinell 158 days ago [-]
Which information in particular is missing from the C type system in your opinion?
littlestymaar 158 days ago [-]
The two major important improvements Rust type system brings are :

- the ownership of your object (who is in charge of free-ing it) and the lifetime of the pointers that targets this object. (the whole ownership system & the borrow-checker)

- is some data-structure thread-safe. (the Send and Sync traits)

With those, you can take any Rust code and play with it without having to ask existential questions. Your code will never segfault or exhibit a strange intermittent bug ones you add multi-threading.

Less important but still really convenient on a daily basis:

- will this function mutate the value I give it. (&mut pointers)

- has this variable already been consumed, which means I should not touch it anymore (affine type)

MikkoFinell 158 days ago [-]
> the ownership of your object (who is in charge of free-ing it) and the lifetime of the pointers that targets this object. (the whole ownership system & the borrow-checker)

Having to bear the cognitive burden of making the lifetime explicit in all of the code is a steep price to pay for the benefit of securing the small subset of the code that is actually complex enough to potentially cause a problem. I wouldn't mind having such a feature be optional though, so that you'd enable it for the most precarious parts, something like a safe{} block rather than unsafe{}.

> will this function mutate the value I give it. (&mut pointers)

We already have const. Yes I agree it's better to enable by default.

littlestymaar 158 days ago [-]
> Having to bear the cognitive burden of making the lifetime explicit in all of the code is a steep price to pay for the benefit of securing the small subset of the code that is actually complex enough to potentially cause a problem. I wouldn't mind having such a feature be optional though, so that you'd enable it for the most precarious parts, something like a safe{} block rather than unsafe{}.

It's obviously a learning curve burden but now that I use the language on a daily basis, it doesn't really slows me down. The thing is you don't often need to annotate the lifetimes by hand since the compiler elides the most common case. In practice, the time you need to do the annotation is often what you call «actually complex enough to potentially cause a problem».

Too 158 days ago [-]
Does rust have something like shared pointers? In c++ that's usually a quite easy way to bail out of the cognitive burden of understanding complex lifetimes.
steveklabnik 158 days ago [-]
We have two! Rc is non-atomic, and therefore not threadsafe. Arc is atomic, and therefore threadsafe. The compiler can let you know if you are using Rc inappropriately, so you get some extra speed if you are single threaded.
weberc2 158 days ago [-]
For better or worse, Rust has a lot more built into its type system, including semantics for type safe generics and safe memory management. This makes it harder to write a correct Rust program, but also it makes it harder to write an _incorrect_ Rust program.
Ericson2314 159 days ago [-]
Forrest vs trees..... Sigh
158 days ago [-]
159 days ago [-]
sidlls 159 days ago [-]
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.com for a reason, and that reason is the community on HN has become a caricature of itself.

By the way, this is from a person who made a point to introduce Rust to the team, when even just a year or so ago I'd have preferred C++.

tubs 158 days ago [-]
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.

sidlls 158 days ago [-]
I've seen every single thing I mentioned ("murder, assault, malpractice") applied to C++ programming in comments in Rust threads.
158 days ago [-]
theprotocol 158 days ago [-]
>eliding

Incidentally, I learned this word from Rust docs (lifetime elision). I'd never seen it in any other context.

zeth___ 159 days ago [-]
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.

zaarn 158 days ago [-]
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)

ryanbrunner 158 days ago [-]
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)
vlovich123 158 days ago [-]
Can you clarify this point? To me it would seem with Rust being able to target WASM/ASM.js that you could indeed target all the same environments JS does.
regularfry 158 days ago [-]
Emscripten means that's not a distinguishing feature from C or C++.
vlovich123 158 days ago [-]
My response was to the last part that there's an environment where Javascript can run but Rust can't. I agree that C/C++ targets are a strict superset but I'll posit that for all the architectures that matter it's the same surface area at which point the calculation for which to use is about ease-of-use, correctness, etc.
hsaliak 159 days ago [-]
You mean wherever there is llvm? It's a large subset, but it is still a subset.
zeth___ 159 days ago [-]
Huh til that rust isn't compillable by gcc.
palotasb 158 days ago [-]
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.
bluejekyll 159 days ago [-]
And with wasm, Rust/C/C++ all can run in the browser too...
fineline 159 days ago [-]
JS in the browser has direct integration to the DOM, networking, various local data persistence APIs, and other IO and sensors (webcam, accelerometer...) etc. Rust can be compiled to run in a sandbox, which can then be integrated via a remote call interface with the JS layer, and thus be indirectly (via JS) connected to the above APIs, but there are currently concerns around the performance of this approach. Rust cannot independently manage a web page which hosts it, without JS. There is some way to go before browsers support practical, accessible and performant front-end web apps in Rust.
zeth___ 159 days ago [-]
Not quite yet. But getting there.
bluejekyll 158 days ago [-]
erikpukinskis 159 days ago [-]
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.

nulagrithom 158 days ago [-]
What are you babbling about? The web is technology. JavaScript is a language. And WASM is shipping in all major browsers already.

You don't have to wait 10 years. You can start using WASM today.

erikpukinskis 158 days ago [-]
It hurts my feelings that you think I’m babbling. I’m trying to be as articulate as I can.

I don’t want to write software just for people with 2 year old iPhones. I write software for everyone, especially people who can’t afford anything but the hardware they’re stuck with. That’s why I’m not going to target WASM.

That’s my point: to me, “The Web” isn’t just modern browsers on newish devices. It’s the whole world as an audience. I think that’s why so many people target the web.

I also think WASM is premature optimization in almost all situations.

That said, I totally support anyone who wants to target it. It’s dope technology. If you love Rust and you want to write browser apps with it, and limit your audience a little, knock yourself out. I don’t think you’re embracing what the web is for, but there’s no law that says you have to.

somenewacc 158 days ago [-]
emscripten can compile to both wasm and asm.js and load them depending on browser support. this seems good enough.
erikpukinskis 158 days ago [-]
Performance won’t be as good as hand tuned JavaScript with native DOM calls.
abiox 157 days ago [-]
webassembly has vastly improved performance in a variety of situations.
abiox 158 days ago [-]
afaik webassembly has shipped in all major browsers - edge, firefox, opera, chrome and safari... including mobile versions.
erikpukinskis 158 days ago [-]
If your audience can exclude the very poor and people with extreme bandwidth limitations ( for updating OS, etc), or you can afford to just tell people “no” then that’s certainly a decision you can make. But you’ll be saying no to a lot of people.
abiox 157 days ago [-]
i'm sorry but i don't quite follow what you're trying to say.
erikpukinskis 156 days ago [-]
I’m getting a lot of pushback in this thread so I’ll put this in the “maybe I’m wrong bucket”.

I’ll wait to talk about it again until after I have experience doing browser compatiblility testing with a WASM toolchain.

noobermin 159 days ago [-]
You're aware that most operating systems have a C API, right? Give me a place C doesn't run where js does.
jakelazaroff 159 days ago [-]
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
sigstoat 158 days ago [-]
pjmlp 158 days ago [-]
Try to use the C API on Android, ChromeOS, Windows Phone, Mbed.
159 days ago [-]
niftich 159 days ago [-]
Languages don't live in isolation. They are products of their time and their fates are tied to their ecosystems. JS is a popular porting target because the browser is a widely-deployed environment, but also because platforms like Node and Electron are in widespread use, and therefore targeting JS enables targeting some frontends and some backends with the same code. This project even takes special care in supporting the differences between execution environments.

Ports to languages that compete in the same solution space are more prone to drawing criticism because, almost by definition, ports are designed to be feature-comparable, yet cross-language rewrites benefit both from the thorough examination that naturally must take place during a rewrite, and the different features offered by the target language. Most arguments about cross-language rewrites are proxy arguments about whether the bulk of the benefit comes from starting over, or mainly from a tool that offers different -- say, more intuitive, or less error-prone -- ways of capturing what the programmer means; intermingled with a fair bit of language favoritism.

noobermin 159 days ago [-]
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.

jcelerier 159 days ago [-]
> 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 Javascript, which people are generally very accepting of, even if they don't plan to use it.

I'll be fair, while I think that both are useless, the second is so far there that I don't even take it seriously - more like a bad joke.

finchisko 159 days ago [-]
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...

bartread 159 days ago [-]
> even though meaningful use case is yet to be shown, but there is chance it will be found

I don't get the Rust-port-hate, but I think you nailed the JS case with this comment. A few years ago my immediate reaction to JavaScript ports (or equivalents) used to be something roughly akin to, "what the eff is the point of that?!?"

Still, enough times now I've found myself needing one of these things later on - the most recent example being something that can play Amiga mod files in a browser - that I've become a bit more broad-minded. Plus, of course these things can be fun learning exercises and, after all, why not?

Really, one of the most canonical examples, for me, has to be Google Docs, which is basically a cut-down Microsoft Office in a browser. Back in the day I thought this was a terrible idea but, you know what? I've used Google Docs quite a lot over the past few years. It's still hasn't replaced MS Office, and probably never will because (as far as I can see) Excel simply can't be beat.

Our main current Google Docs use case is running retros. We have a few remote team members, plus a fairly strong WFH culture, so a shared GDocs drawing makes a great canvas/virtual whiteboard. Granted it's not as good as a dedicated virtual whiteboard app, but it's a very cost effective way of giving everyone write access to a shared drawing/post-it surface on an occasional/periodic basis. The problem with virtual whiteboards is they tend to charge per user, which makes sense if everyone uses them all the time, but becomes cost prohibitive when most people only need the app once every couple of weeks.

There are also plenty of examples for me that still don't seem to make much sense (online IDEs) but, whatever, some people clearly do, and that's cool.

greggyb 159 days ago [-]
> (even though meaningful use case is yet to be shown, but there is chance it will be found)

A thought is a browser-based IDE, with a cloud filestore (OneDrive, Dropbox, Google One/Drive (my new preferred stylization of their product)) for repo and dev environment.

Think of it like a browser-ified version of what you might do with a server and SSH.

We've got a couple JS-based editors/IDEs. We've got many cloud storage options. Now you can put git directly in browser, too. Heck, you could make a SPA and save the whole source as a file on your cloud storage - just open that up in any browser and access other files in that account (or others). Don't even carry a USB around, and still have your custom dev environment on any PC.

komali2 159 days ago [-]
I'm on a team whose primary project is a browser-based IDE.

We are considering this for exactly the reason you said.

Probably won't implement it because the whole "choose your own FS, also it doesn't work on github" thing, but we might plug it into our node server and writeup an API for our client to use.

minieggs 159 days ago [-]
Heck, that sounds like a fun gig.
159 days ago [-]
Boulth 159 days ago [-]
> (even though meaningful use case is yet to be shown, but there is chance it will be found)

One use case is having a repository UI completely in a browser so the backend can be a pure git server with no specialized backend code to display commits, blobs etc.

This way a browser becomes just another git client.

Ajedi32 159 days ago [-]
> 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...

JustSomeNobody 159 days ago [-]
> ... but there is chance it will be found...

Doesn't this completely ignore YAGNI?

steveklabnik 159 days ago [-]
It's often true that you're not gonna need fun, but that's not really the relevant metric.

That is, not every bit of software is created for business purposes, or with good software engineering principles, or anything else. Sometimes, you do things just because you can. Some might even call this "the hacker spirit".

andai 159 days ago [-]
It does, but so does almost all of mathematics :)
krapp 159 days ago [-]
We do what we must because we can.
TAForObvReasons 159 days ago [-]
Without being too reductive, a JS implementation of anything represents new possibilities (running in the web browser or other environments), whereas a rust port doesn't expand the surface area. To give a comparison, critiques of rust ports are similar to the critiques of porting everything to node.js a few years ago -- most of the benefit comes from rewriting and applying lessons learned from the existing implementations.
goatlover 159 days ago [-]
But Rust programs can run anywhere JS can now with web assembly, while the reverse isn't true. JS can only run where there is VM for it.
erikpukinskis 159 days ago [-]
Are you referring to embedded applications?

An app tends to either be embedded or not. Obviously if you’re embedded you’re not going to use a JavaScript implementation of git.

You’re just not going to run Rust on IE8. And you’re not going to run JavaScript on your digital thermometer.

Either way, there’s no confusion about which language runtime, Rust or JavaScript, has a bigger installed base on those respective devices.

specialist 158 days ago [-]
Generally accepting?

I've lived thru null terminated strings, ASN.1, NULL values in SQL, C++, XML, CORBA/COM+, WSDL/SOAP, XSD, event buses, EJBs, ORMs, etc. (I'm forgetting a few dozen, I'm sure.)

You wouldn't believe the grief we XML skeptics got, back in the day. Being right and $2.50 will get you a bad cup of coffee. Pointing out the emperor's nude hardly seems worth it.

JavaScript is another obvious, terrible, avoidable, costly mistake. Only proving that even pigs fly, given enough thrust.

This too shall pass. Just find a way to suffer thru it.

--

When the Bozo Bit finally (inevitably) gets flipped, the former zealots never do a mea culpa.

It's okay to be wrong. We learn thru our failures. But intellectual honesty is kinda important. For example, Ryan Dahl (creator of nodejs) now mostly recommends Go. I can't overstate how impressed I am with his candor, efforts. (He kinda reminds me of Bill Joy.)

Alas, generally, people don't remember when they've changed their mind(s). Which is why, how propaganda works.

This cognitive quirk is the one thing that truly scares, depresses me.

mankash666 159 days ago [-]
The response to js ports are usually favorable as:

1. They're (generally) portable across browsers and backend (nodejs)

2. There exists a much larger JS community than Rust. Given the js community's familiarity with website/webapp design, likelihood of a js port ending up in a real product quickly is high.

Rapzid 159 days ago [-]
It's an odd dichotomy. However my biggest take away from it is this; if you are thinking about wanting to implement something on your platform of choice but think "Ehh, it's already done over there so nobody will be interested in it" reconsider! There will almost certainly be people in that ecosystem that will appreciate the effort :)

I for one am happy about some of this. I've used the javascript ssh2 library(with a nice async/await wrapper you can find if you look for it) heavily for automation from nodejs. It could have been implemented on libssh2 for my needs, but a goal was for browser support soo.. Who am I to argue :D Perhaps web assembly will make it possible to compile something like libssh2 and consume from JS, but that's a long ways off I bet(being viable to adopt, not get working).

pducks32 159 days ago [-]
I enjoy reading libraries like this because git is seemingly ubiquitous. It’s used more than any project I will ever make. And although I know C and C++, it’s source is kinda hard to approach.

Js on the other hand is not for me so I can get a better sense about how it is that git works. I want to see how these fundamental tools are written so I enjoy these ports (even if they’re not perfect).

alistproducer2 159 days ago [-]
I really have to second this. I am an avid source reader and when the project is in JS, dart, php, python and to some extent go it's really easy to quickly grok what is happening. C++, Java, Rust - not so much. Some of it has to with the syntax itself but often it has to do with how much indirection and decomposition is standard practice in the language. If I have to jump around to 5 files to see what a single function is doing, it's hard to grasp the bigger picture.
geocar 158 days ago [-]
This should be expected.

Rust isn't a new machine: It's the same old dumb machine, with some extra manoeuvres that make things "safe" (except when you say "unsafe"). It's not even remotely interesting to anyone who isn't troubled frequently enough by those things that need more safety.

JavaScript on the other hand, is a new machine: It's the most widely distributed networked machine we have, and it's amazing for that.

- You can buy cpus anywhere in the world by putting an ad out there that runs JavaScript and pipes the results back to you.

- You can build and deliver robust software that "runs" on such a wide variety of terminals including desktop workstations, servers, "phones", televisions, wristwatches, entertainment tablets, refrigerators, space satellites, and so on.

- Anybody can learn it. It is so much more inviting and accessible than anything that came before it that people feel very few real barriers to entry.

- It's fast "enough". I work in HPC - massive teraabyte-ram workstations building applications where we need to respond with bids in microseconds, disk seeks are counted for writes, and so on, so whilst there are still some things close to my heart that JavaScript isn't fast enough for, it's fast enough for everything else. Managers love this stuff.

Seeing our favourite applications running on JavaScript paints clearer a world where we can do fantastic new things. People love seeing "X in JavaScript" because they are seeing "X for the future" and the future is cool!

Porting a version control system to rust doesn't: At best, we find additional protection from a specific class of bug. Maybe it's exciting to people who are already excited about rust, but anyone that thinks these things are even remotely the same need to get their head examined.

yoz-y 158 days ago [-]
I do not think that javascript as a language has much advantages for learning than, let's say Lua or Python.

However, the fact that it is linked to HTML and DOM make it very easy to have immediate feedback without installing any tooling or IDEs.

But then, modern JavaScript is quite different from what one can learn just by using the devtools. I think that once one starts to use more advanced js tooling, things get quite worse than in almost any other language.

geocar 158 days ago [-]
You're making a mistake of putting a box around "JavaScript the Language" -- even admitting a concession of "HTML and DOM" you miss the point: Lua and Python do not have billions of devices able to download and run their applications. Python and Lua don't have that by a long shot.
yoz-y 155 days ago [-]
That was my point. JS has a huge advantage in the ecosystem but not many as a language itself.

If we compare pure Node with Python then I think python is better for learning as it has less weirdness to it.

You are right though. Such comparison is only useful as a mental exercise as in the real world the browser and js are intimately tied.

nudpiedo 158 days ago [-]
None of the things you mention are exclusive or innovated by JavaScript by any means, actually everything you say exists since computer networks exist; are you maybe mistaking internet with web?

JavaScript only excels in one aspect: the size of its community which is mostly, but not exclusively, formed by poorly qualified web page prototypers.

geocar 158 days ago [-]
> None of the things you mention are exclusive or innovated by JavaScript

JavaScript is distributed across billions of devices. Nothing else comes close.

If you read my comment as an endorsement of JavaScript instead of an explanation why people care more about its expanding universe than someone dinking around in Rust, then you're making two mistakes.

nudpiedo 158 days ago [-]
Still do not get how you leverage these billions of devices as workers for a distributed workload; it is by all metrics suboptimal or mediocre compared with any other programming platform to distribute workloads. As customer end-point we would be speaking in a different context.

Please do not label other’s different of interpretation as interpretation mistakes: I believe your opinion is factually wrong.

geocar 157 days ago [-]
> Still do not get how you leverage these billions of devices as workers for a distributed workload

Happy to alleviate some of your ignorance by typing more slowly.

I buy ads.

I can get access to devices anywhere in the world, do network testing, and on the last mile which is cost prohibitive for any other distribution channel.

> Please do not label other’s different of interpretation as interpretation mistakes

Then don't be wrong.

nudpiedo 155 days ago [-]
And is via Ads the way you distribute workload across devices? Do not call that distributed computing.

Actually I prefer to ignore your practices.

> Then don’t be wrong.

Whatever, the pound for you if that makes you happy.

bo0tzz 158 days ago [-]
>"runs" on such a wide variety of terminals including [...] space satellites, and so on."

There are satellites running javascript?

geocar 158 days ago [-]
Yes! JavaScript is also running in the space station!
Laaas 158 days ago [-]
I don't get your point at all? Rust works on the web too.
geocar 158 days ago [-]
Rust works on the web by converting it to JavaScript.
InTheTop2 158 days ago [-]
which converts it to binary. You really haven't made a point in the thread. You think JS is special and you like it. Don't pretend that means something.
geocar 157 days ago [-]
It is special. The OP admits as such. His question is why.
verletx64 159 days ago [-]
Arsene Wenger put it quite well recently:

"Once you are not a danger any more, people love you."

colordrops 159 days ago [-]
Maybe it should be, "Once you are not in danger any more, you love people."
j1vms 159 days ago [-]
In Soviet Russia, "Once people not in you anymore, danger love you."
resource0x 159 days ago [-]
or this: "once you don't look as if you are in danger all the time, people love you"
taeric 159 days ago [-]
Two questions/thoughts. First is if this is just confirmation bias on your point.

Second is if this is not so much that there is a smaller group that are pushing back, but a larger group that is excited. (That make sense?)

gkya 158 days ago [-]
I dislike JS and the current culture around it because of technical insophistication, but I should concede that JS people are better at this: they make the replica and do not bother you, whereas the Rust community is evangelical, they open issues on repos saying "stop using your shitty lang and rewrite this in Rust." The two are very different attitudes.
steveklabnik 158 days ago [-]
Do you have real examples of that? I hear people say this happens more than it happens; I’ve only seen it maybe twice ever.
gkya 158 days ago [-]
I havent made any bookmarks about that but I recall such things appearing here time to time, in threads and as posts.

(Edit: there are nearly 4.5k issues with their title containing rewrite rust on github: https://github.com/search?p=2&q=rewrite+rust&type=Issues)

kbenson 158 days ago [-]
Well, from just the repo language panel in the left, it looks like the vast majority of those are issues including those words on rust codebases.
steveklabnik 158 days ago [-]
Out of those 4.5k issues, 1000 are closed. 2600 of them are on Rust repositories. Clicking on the first other one, "shell", the very first result is on the Rust RFCs repo. Let's look at the first page overall:

https://github.com/TOTBWF/SteamCurses/issues/16 is someone who is making an issue on their own project because they are interested in a Rust re-write.

https://github.com/acrisci/i3-style/pull/38 is someone who has a PR open on their own project to re-write in Rust.

https://github.com/mintsuki/storm/issues/2 is someone being obnoxious, sure. Not serious, but you could also say it's annoying.

https://github.com/tkaden4/karat/issues/2 is someone on their own repo.

https://github.com/jezen/is-thirteen/issues/582 is already on a joke project, so it's also a joke.

https://github.com/dadrian/whereiszakir/issues/4 is someone on their own project.

https://github.com/adangert/telegram-events-bot/issues/1 does seem like an actual random person making a real suggestion.

https://github.com/spencereir/pharbot/issues/1 is being meme-y so probably not serious, still annoying.

https://github.com/ansuz/RIIR/issues/35 is on a repo specifically to track this phenomenon. It has 35 issues open. Many of which aren't actually examples of people saying this.

https://github.com/jezen/is-thirteen/issues/497 is a second issue on the joke project above.

------------------------------

So, yes. Out of 900 possible issues, in the top 10, one may be a serious request, and two are shitposting, which may be annoying as well, admittedly, but is just as likely to come from people complaining about this as from "The rust community" broadly.

At that level, it's effectively noise.

159 days ago [-]
maxxxxx 159 days ago [-]
Let's hope that the current "let's rewrite xxxyyyy in JavaScript" will soon be "let's rewrite it in webassembly". This makes much more sense to me.
wffurr 159 days ago [-]
You don't rewrite in wasm, you compile to it.
maxxxxx 159 days ago [-]
Correct. And you can use different languages not just JS.
abiox 158 days ago [-]
well, technically there is a textual format for webassembly... :P
a-dub 159 days ago [-]
It's open source. If you don't like it, don't use it.

Rewriting git in Javascript seems pretty useless to me, but who knows, maybe it was a fun challenge for the author.

a-dub 159 days ago [-]
On second thought, it looks like it's meant to be a plug-in for an IDE that's implemented in JavaScript.

I suppose that makes sense, kinda...

159 days ago [-]
invaliduser 159 days ago [-]
It can also enable tutorials and interactive teaching material for git served in web pages.
invaliduser 159 days ago [-]
Is this the same dynamic that one can observe between java and scala developers?

Anyway I can see how converting a "native" program to a web environment can add a lot of value, as you can embed it in a webpage and execute it locally, saving some server load.

downer55 159 days ago [-]
No, because the JVM is (almost) always in the picture. There's a difference between interpreted execution and execution proper.

With languages that compile to an executable binary that is platform specific, for targeted CPU architecture and chipset, dependency hell promises a degree of shelf life and planned obsolescence.

This injects an aura of fear into each and every event in whatever arms race we hear about. When will the next time be one too many? When will an industry skill set cease to possess currency?

With a runtime in the picture, there's always a shim for portage, to alleviate the fear.

Other languages are frequently regarded as "bare metal," not only as a matter of implementation, but at a matter of psychology and mind set.

Things are different these days with much broader virtualization practices being widespread, but there's always the pedantic nature of technical people raising an eyebrow and asking "why on earth" for some things, but not others.

mortdeus 159 days ago [-]
we have wasm now. why is anybody writing anything in javascript ever nowadays? some form of religious self chastisement?
krapp 159 days ago [-]
wasm isn't quite ready yet. It requires a javascript layer for interacting with the DOM, which is slower than plain javascript, and it doesn't support features like garbage collection which would make it a good target for some languages.

Also, javascript is plaintext and doesn't require a compile step, even though for some reason (cough Node) javascript development usually does, which makes it much more convenient for its original intended use case (a scripting language for the web) than wasm.

always_good 158 days ago [-]
It's funny how everyone damns web technology for changing too fast.

But now that wasm is slightly available, the same people wonder why it's not self-evident that everyone should've jumped ship immediately to such fledgling tech that isn't even a drop-in replacement for Javascript.

TeMPOraL 159 days ago [-]
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.
dragonwriter 158 days ago [-]
> Doesn't compiling a non-JS language into WASM require compiling a fat language runtime as well?

Not necessarily. For a language with a large runtime that is either irreducibly large (perhaps because you need to support unrestricted eval) or for which you don't wish to spend the effort to allow your build toolchain to bundle only as much as your program actually uses, sure.

regularfry 158 days ago [-]
Because we have to support IE 11.
MrL567 158 days ago [-]
Some of us don't want to use a C/C++ inspired language for web development when there is a simpler solution offered.
amelius 158 days ago [-]
By the way, I suppose git can already run in JS, if compiled to WASM.
CMCDragonkai 159 days ago [-]
This project started when I, wmhilton and another guy started talking on an issue on the js-git repository. Because development on js-git stopped. We all started independent projects to port Git to JS. The third guy did one in type script, wmhilton started this. I began by trying emscripten first with libgit2. While it compiled and simple things worked, I needed to overload its filesystem functionality but it was embedded and complex to do. At any case my git project stalled as I was stuck solving another related problem (indexing highly dynamic tree data). In the mean time wmhilton continued and produced a wonderful project. I talked him earlier on about the fs functionality, since earlier I developed the js-virtualfs to support a git in js. And later he changed the codebase to support fs plugins. So if you want to use this isomorphic-git in the browser or electron, I recommend my js-virtualfs library as its the most comprehensive port of nodes fs api to an in-memory fs. Thanks to wmhilton I can probably stop my git project and just build on top of his.
wintorez 159 days ago [-]
"Any application that can be written in JavaScript, will eventually be written in JavaScript." -- Atwood's Law
mkirklions 159 days ago [-]
5 years ago I'd be like: Noooooo

Today: My body is ready

fb03 159 days ago [-]
we should just implement js in js and go full circle already.
tlrobinson 159 days ago [-]
Done, by Brendan Eich, in 2004: https://github.com/mozilla/narcissus/
bpicolo 159 days ago [-]
madeofpalk 159 days ago [-]
securityfreak 159 days ago [-]
Best tech talk ever!
EMRZ 159 days ago [-]
Just wait for the Electron browser...
bartread 159 days ago [-]
Given the somewhat non-awesome performance and resource requirements of some of the Electron apps out there, waiting might end up as the defining experience of an Electron browser.
RandallBrown 159 days ago [-]
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.
yoklov 159 days ago [-]
XUL is still alive but XBL is at least going away now. XUL will probably eventually go away too.
moogly 159 days ago [-]
Brave is built on Electron, IIRC.
roywiggins 159 days ago [-]
samatman 159 days ago [-]
I have done this.

In continuation passing style.

AMA.

ryanackley 159 days ago [-]
I did something similar a few years ago. https://github.com/ryanackley/git-html5.js. A lot of the links don't work in the README anymore. It was more of a "this would be cool!" project rather than a library I wanted everyone to use for the next 20 years.

One of things that scared me is the responsibility that bugs in something like this could be catastrophic to someone's work. As I built my git library I realized a lot of the network protocol validation exists in the git client. For example, one bug I introduced caused a force push of a shallow copy of the tip of master intermittently. The server would happily accept it without any kind of "are you sure?" or -f flag. That spooked me.

avar 159 days ago [-]
To elaborate on that: There's receive.denyNonFastForwards=true on the server which will deny --force no matter what the client says, and major hosting sites like GitHub and GitLab have "protected branches" which allows protecting say "master" against this, while allowing it on topic branches.

What you ran into is that there's nothing in the protocol itself that makes the client say "this is a forced push". The client just says "update this ref from A->B", and it's expected that it's already read the ref advertisement to see what A is, and whether it can move to A to B with --force or not.

egeozcan 159 days ago [-]
I can't begin to describe how sad I am that we didn't end up using mercurial everywhere.
bartread 159 days ago [-]
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 surprised Mercurial hasn't made more headway than it has.

But maybe git is just "good enough" for most people? I suppose that's where I land on it. It has it's frustrations, like anything else, but I can live with them.

taeric 159 days ago [-]
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 spread. Low barrier to get started combined with basically frictionless ability to spread out. Even the hiccups people used to have only slowed individual level adoption. (Complaints about the UI and such.) The spread of currently successful repositories was not really slowed by those events.

I'd be highly interested in if anyone has something like this modeled.

I'd also appreciate challenges to my point. Mercurial, I believe, should have had similar strength in spreading. It just didn't have the bootstrapped successful project like git. (The kernel, is what I'm thinking of.)

pseudalopex 159 days ago [-]
Mercurial had major projects too. Mozilla still uses it. What it didn't have was GitHub.
taeric 159 days ago [-]
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?

pseudalopex 145 days ago [-]
Git was popular in some influential circles before GitHub, but it only became a monoculture several years later. hgsubversion came out in 2008, after git-svn but before most people were using any DVCS. Also, SVK was around before git-svn.

You might be underestimating how much support Mercurial had in the late 2000s. Mozilla, Sun, Google, and Microsoft all picked Mercurial over Git. Even GitHub published hg-git so people could use the Mercurial client with Git repos. Some ecosystems gravitated to Git (Linux, Perl, Ruby) and some gravitated to Mercurial (Windows, Java, Python).

By 2010, DVCS comparisons consistently cited GitHub's UX and network effects as significant advantages for Git. Atlassian, Google, and Microsoft all added Git hosting in 2012. By 2015, Python, Google, and Microsoft moved to GitHub because everyone else was on GitHub.

I think the landscape would look very different if GitHub hadn't come along when it did or had added Mercurial support instead of Subversion.

Already__Taken 159 days ago [-]
Sometimes it's just worth getting everybody on board rather than having the perfect tool.

Maybe in 50 years there will only be one package format for applications across the major operating systems. One can dream.

oblio 158 days ago [-]
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.
bb88 159 days ago [-]
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 repo itself.

krupan 159 days ago [-]
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.

drchickensalad 159 days ago [-]
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.
krupan 158 days ago [-]
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.
1wd 158 days ago [-]
If you don't want mercurial named branches then don't use them. Use mercurial bookmarks instead. They can do everything a git branch can do. Mercurial also has anonymous heads that actually allow Mercurial to be much more flexible than git.
lsiebert 159 days ago [-]
Git does default to the current HEAD, but it allows you to specify a start point if you want to. Doing this with git branch might be useful if you have changes you haven't committed and can't git stash for some reason.

See man git-branch and man git-checkout for details.

AntiRush 159 days ago [-]
There's a pretty full functioning project from several years ago (seems actively maintained) that has similar goals here:

https://github.com/creationix/js-git

I think it was initially crowdfunded.

robertkrahn01 159 days ago [-]
Used it, works great. Also really good to understand what git really "is".
fithisux 158 days ago [-]
What I really find interesting is the move to an untyped language for large project while all people talk about the virtues of type systems, Scala Haskell SML and so on.

It seems Lisp was not mambo jumbo after all.

wheaties 159 days ago [-]
First thing I looked at was "did they implement git diff?" The answer is "no." That's something you're going to want to see in a port. I use it daily.
preordained 159 days ago [-]
JavaScript: Because that's what we know.
ndesaulniers 159 days ago [-]
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.

ndesaulniers 158 days ago [-]
> Having libraries implemented purely in the language from which the library is implemented

Err, meant to say:

Having libraries implemented purely in the language from which they are used ...

tuananh 158 days ago [-]
NAPI has ease that pain.
harrisreynolds 158 days ago [-]
I spun up a quick dashboard of this project at Chart.ly [1].

A couple interesting points. Will Hilton is the main guy driving the bus on this project. And... Sunday and Monday are his most productive days.

Keep up the good work!

[1] https://chart.ly/github-dashboard/isomorphic-git/isomorphic-...

ronjouch 159 days ago [-]
Looking at this rewrite I was wondering, but didn't find an answer in the project README: would emscripten successfully compile Git to js/wasm?
mr_toad 159 days ago [-]
Git has its claws deep in the file system. On the browser side, JS and wasm have very limited access to the file system. You’d need to somehow bridge that gap. (It looks like isomorphic-git is using indexdb, and not the file system).

There’s probably other dependencies (ssh, http, an editor for commits) that need to be resolved to get expected functionality.

jvilk 159 days ago [-]
You're right; when it is running in the browser, isomorphic-git does not have access to the operating system's file system. Instead, it uses BrowserFS [1], which emulates a file system abstraction on top of arbitrary storage backends. It supports IndexedDB, localStorage, and Dropbox, among others. (Disclaimer: I am the author of BrowserFS.)

[1] https://github.com/jvilk/BrowserFS

viraptor 159 days ago [-]
There's still a bit of bash hiding in the git commands if I remember correctly. That wouldn't be trivial to compile.
iguessthislldo 159 days ago [-]
I was going to write: "Simple, we just make a bash compiler", but I realized this might have already been done and to my horror a quick google search confirmed this, or more technically a sh to C transpiler: http://www.linux-magazine.com/Online/Features/SHC-Shell-Comp...
juancampa 158 days ago [-]
I've been using this library for a few months and want to give props to wmhilton who's been incredibly responsive with the couple of issues I've encountered.

The thing I like the most is that the API matches very closely to git's CLI, so if you know git, you know isomorphic-git.

I gave other libraries a try before settling on this one (spent a whole daying playing around with the optios). IIRC I decided to use isomorphic-git because the alternatives were either abandoned or simply broken.

chuckdries 159 days ago [-]
A few years back, the company I’m currently at started working on NodeGit because a pure JavaScript implementation they tried (not this one? Idk I wasn’t there) was far too slow. Right now, we’re working on a git server in rust that takes commands and passes data over TCP that ideally could enable git usage in the browser for like hosted development environments and such.
overgard 159 days ago [-]
This is pretty cool! I'm curious if emscripten/webassembly on the canonical git implementation was considered though? (Or is the environment just too different?)
jgalentine007 159 days ago [-]
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!
always_good 158 days ago [-]
You're dramatizing the mental overhead needed to not write semicolons. Every serious project uses a linter that can add or remove them based on some flag.

I don't use semicolons. It's an unnecessary character. Life moves on.

I'd say Rust has worst of both worlds, if you want to compare it to something, where having or not having a semicolon can mean two different things (return the value or return void). That's an example of actual mental overhead that semicolons can create that still bites me after more than a year of Rust. And it's not something that tooling can necessarily fix for you unlike Javascript ASI.

Using semicolons in Javascript just to keep my brain trained for semicolons in other languages is probably the worst reason to use them I've heard yet. And every time someone finds out I don't use semicolons in IRC, they seem angry about it. So I wonder how much I avoid semicolons just for the sport of it, now.

jgalentine007 152 days ago [-]
Yeah, you're probably right on the mental overhead. I guess it is just best to use a linter and whatever style guide you prefer (most argue for semicolons.)

Using semicolons to stay in rhythm with similar languages that mandate them might be the worst reason, but it is a reason none the less (I literally spend equal amounts of time coding in C++/C#/Java/Javascript, so there is no need to 'think' in my case.)

I too like to do things out of spite.

martin_drapeau 159 days ago [-]
With something like this, GitHub will soon become my web app’s database (pending that PR). So awesome...
Boulth 159 days ago [-]
I wonder how it works in practice. I've worked with git.js (old and ugly, but works) and js-git (looks nice but is quite complex).

git.js even has a repository browsing demo (think gitk) that works in a browser.

Did anyone use isomorphic git? Does it support smart http protocol?

indescions_2018 159 days ago [-]
One possible usage is peer net broker for WebRTC. But really I'd like to setup my own private AWS C9. Secure access to a dedicated instance. From any computer / browser. With offline caching. And a rich browser terminal ;)
abritinthebay 159 days ago [-]
Very clever! I particularly like the bring-your-own-filesystem approach.
wheresvic1 159 days ago [-]
If anything this is a wonderful example of good engineering. Although on the server-side would it not have been easier to delegate commands to the native git binary?

Well done!

ihsw2 159 days ago [-]
Perhaps but there's an existing SDK that is the backbone of many Git libraries: https://libgit2.github.com/

Of which there is an existing Node package that links to it: https://github.com/nodegit/nodegit

The caveat is that it stopped being a pure-JS library that boasts in-browser support.

159 days ago [-]
the_duke 159 days ago [-]
Soon, there will be a rewrite of the Linux kernel in Javascript.

Finally, a way to run Linux in your browser!

stdclass 159 days ago [-]
hathawsh 159 days ago [-]
That's a fun place to type "rm -rf /" ;-)
pducks32 159 days ago [-]
With the craziness of Js build tools and build configurations, I love seeing how different project stuff use it. I like how they use both webpack and rollup and even name the rollup export as “for-future”.

I write a lot of isomorphic libraries for work and it’s not as easy as one might think it is.

andrewpmartinez 159 days ago [-]
Definitely. This GIT example reminds me of what some people are doing with the Web Crypto API (see PKIjs). Things I would never have considered a little as a few years ago.
rashthedude 159 days ago [-]
Why oh why?
Dirlewanger 159 days ago [-]
"Everything that can be written in JavaScript will eventually be written in JavaScript"
lcfcjs 159 days ago [-]
Why not? Don't be rash, and actually read the link.
edem 158 days ago [-]
Just one question: why do we need this? Apart from the intellectual masturbation, this does not make sense whatsoever. Not to mention that writing a Git in a language such as Javascript is just asking for trouble in the long run.
ingmarheinrich 158 days ago [-]
.. but why?
jlebrech 158 days ago [-]
stop writing stuff in javascript (says someone who writes stuff in js)
chimmy_chonga 159 days ago [-]
Linus Torvalds would hate this
hestefisk 159 days ago [-]
Why? It’s a clever hack.

They did it because they can.

chimmy_chonga 158 days ago [-]
well, this joke didn't go over well ha.

The man went on rants about C++ I can only imagine what he has to say about JS