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.
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.
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.
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.
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.
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++.
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.
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.
> 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).
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).
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)
> 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.
> 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».
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.
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.
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.
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++.
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'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)
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.
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.
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.
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”.
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.
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.
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.
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
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.
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.
> 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.
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, 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.
> (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.
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.
> (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.
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".
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.
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.
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).
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.
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.
> 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.
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.
> 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
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.
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.
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.
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).
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.
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.
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/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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.)
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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...
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.
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.
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?)
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!
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.
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.)
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 ;)
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?
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.
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.
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.