Therefore, if you included it, the data wouldn't lead to meaningful conclusions. I feel like this was pretty obvious from the article and that the explanation was enough. For example, substituting node for js seemed to work well enough.
I think there is a lot more vertical movement and the horizontal stuff might be a sideshow without considering overlap or experience with C or JavaScript as significant in how one transitions between purely competing languages.
But JavaScript's real problem for the analysis might be that its competition is largely excluded since the walled garden apps rarely have related code on GitHub, even if their language is present.
The only good thing about it is that the language is easier to write a compiler for, as it is basically a portable macro assembler, specially the K&R C variant.
1. The fact that fewer people are choosing C for other projects doesn't mean they can't or won't learn it for kernels.
2. Nobody has yet to produce a language that is clearly superior to C for systems programming. Otherwise, we would be seeing movement towards that language instead of Java and Python.
The other thing to remember is that these are GitHub projects; the vast majority of them are not going to be kernels but application software or libraries. That would explain the moves from C to Java and Python; it's easier to write applications in those languages.
I would argue Rust already has.
https://github.com/helena-project/tock
https://github.com/redox-os/tfs
https://github.com/intermezzOS/kernel
The biggest application example:
https://github.com/servo/servo
And some self promotion:
https://github.com/bluejekyll/trust-dns
----
I encourage all programmers to check it out. You may discover like me, that Rust is a compiler and language which guards against all the hard learned lessons I've had over my career. It's an amazing language to program in.
This isn't scientific: http://benchmarksgame.alioth.debian.org/u64q/rust.html
tomsmeding's comment?
Your statement "Rust has been shown to…"?
The website you point to?
(What is "This isn't scientific" even supposed to mean?)
So how do we justify this JavaScript as forced labor argument?
The programmer can decide to do webapps that run atop C and get assistance from a backend that ultimately runs on C. The programmer can use backend frameworks that deliver incantations in JavaScript much like their downcalls to C.
If the migration were toward metal we would be hearing that C has to be excluded. Really how the Buffalo herd is moving does matter in a discussion of what ditches they are stuck in in the middle Savannah.
Please explain how to make a slippymap[1] in C.
For srs, I'm making a hobby project at the moment that needs a dynamic, interactable map on a webpage, and as a long time noscript user it galls me a little to use JS. The only compromise I can come up with is re-hosting the JS libraries I use and ensuring they don't have their own dependencies so that users only need to enable my domain for the site to work.
If you can tell me how to do the same thing in C, I'll swap to it immediately.
The same way Doom has been compiled and run in the browser.
https://github.com/kripken/emscripten/wiki/Porting-Examples-...
I guess that meets the criteria of "programming for the web but not making github commits in javascript", but it doesn't really solve my problem. Oh well.
There are still systems that lack full C++98 compliant compilers, for example (mostly embedded stuff).