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.

...hey everyone, I made a C/C++ developer blood pressure checker in Rust.

Your entire program should be wrapped by unsafe{}.

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.

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

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

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

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.

> we don't like each other very much

Hi are you a language?

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

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

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

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

[1] the experimental browser engine form Mozilla

> 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).

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).

Which information in particular is missing from the C type system in your opinion?

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.

Forrest vs trees..... Sigh

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've seen every single thing I mentioned ("murder, assault, malpractice") applied to C++ programming in comments in Rust threads.

>eliding

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

Javascript runs everywhere where there is a browser.

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

I'm not sure on the last point, a lot of architectures, especially niche ones, aren't supported by Rust at all while there are plenty of C compilers for them going around.

(have fun trying to get Rust working on 8bit controllers or Itanium/ia64)

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

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.

Emscripten means that's not a distinguishing feature from C or C++.

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.

And with wasm, Rust/C/C++ all can run in the browser too...

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.

Not quite yet. But getting there.

pretty much there: https://www.hellorust.com/setup/wasm-target/

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.

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.

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.

emscripten can compile to both wasm and asm.js and load them depending on browser support. this seems good enough.

Performance won’t be as good as hand tuned JavaScript with native DOM calls.

webassembly has vastly improved performance in a variety of situations.

afaik webassembly has shipped in all major browsers - edge, firefox, opera, chrome and safari... including mobile versions.

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.

i'm sorry but i don't quite follow what you're trying to say.

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.

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

Huh til that rust isn't compillable by gcc.

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

You're aware that most operating systems have a C API, right? Give me a place C doesn't run where js does.

In a browser. Yes, there's wasm, but it has a lot of limitations that don't apply to JavaScript. fineline had a good comment about it upthread: https://news.ycombinator.com/item?id=17088315

Try to use the C API on Android, ChromeOS, Windows Phone, Mbed.

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.

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.

> 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.

Heck, that sounds like a fun gig.

> (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.

> 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...

> ... but there is chance it will be found...

Doesn't this completely ignore YAGNI?

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".

It does, but so does almost all of mathematics :)

We do what we must because we can.

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.

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.

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.

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.

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).

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.

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

Then don't be wrong.

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.

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.

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.

>"runs" on such a wide variety of terminals including [...] space satellites, and so on."

There are satellites running javascript?

Yes! JavaScript is also running in the space station!

I don't get your point at all? Rust works on the web too.

Rust works on the web by converting it to JavaScript.

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.

It is special. The OP admits as such. His question is why.

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.

Arsene Wenger put it quite well recently:

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

Maybe it should be, "Once you are not in danger any more, you love people."

In Soviet Russia, "Once people not in you anymore, danger love you."

or this: "once you don't look as if you are in danger all the time, people love you"

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?)

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.

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.

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)

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.

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.

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.

You don't rewrite in wasm, you compile to it.

well, technically there is a textual format for webassembly... :P

Correct. And you can use different languages not just JS.

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.

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...

It can also enable tutorials and interactive teaching material for git served in web pages.

https://transitiontech.ca/random/RIIR https://github.com/ansuz/RIIR https://github.com/ansuz/RIIR/issues

:-))

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.

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

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.

Because we have to support IE 11.

Some of us don't want to use a C/C++ inspired language for web development when there is a simpler solution offered.

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

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.