| Sorry in advance if this post come across a bit harsh but I think there is a fair bit of misconception in your post. First and foremost I think it's safe to say that things like TypeScript and JavaScript would not be possible without the lower level "system" languages. In all fairness they were there first, by a matter of decades in most cases. Ultimately the V8 engine, Node and other similar stuff is largely built with C++ and C anyway. Fundamentally what you are asking about CAN be done, there is a larger, fairly academic discussion of "should" it be done or "why hasn't" it been done. "It's quite clear that TypeScript is going to be around forever" Really? Why? Type script is 9 years old, C is 50 this year. Sure C is still here but lots of things have come and gone in that time, small talk, lisp, fortran, cobal... (as long as you dont look TOO closely in some basement mainframes). Ive been at this for a while and the way I see it typescript is still in the late "fad" stage, it has yet to truly prove its staying power and there is nothing indicating with will "be around forever" just yet. Languages dont have real staying power until they last through the the subsequent fad, if people are still using it after the next cool thing comes out then its likely here to stay. "It's nice and simple." as others have noted, it's nice and "familiar" there are plenty of us out there who love C/C++ syntax and coding styles. I consider C to be one of the simplest languages out there. "A systems language essentially just adds access to pointers." Sure, but it also does LOTS of other things. If you want to make a vague comparison systems languages are closer to running "on the metal" than interpreted languages and for some use cases this this is critical. If your flying a jet at 35,000 feet you don't want your altitude tape to all of a sudden read NaN... In many cases, especially mission critical systems, programing close to the metal is the only way to achieve the sort of optimization you really need to run a system, abstraction is NOT always a good thing "Imagine the same syntax/tooling for embedded, kernel, system (browsers, interpreters), backend, and frontend." -> You could define a systems language that had similar syntax to JS but the main point of JS is the broad abstraction of some things that you very much want access to when you working on a system closer to the metal. Sure its nice when all numbers are of type "Number" but there are lots of cases where you need far stricter control over that. Another piece of historical context here is that the web era brought around the notion of a "full stack" developer, someone who could work on "front end" and "back end" code. In my experience the best dev's are good at one of the two and have a cursory understanding of the one they are not good at for the sake of knowing whats going on most of the time. Realistically these people are not tinkering with the "low level" aspects of the system since its all provided by other things. "I just don't know why there is not more interest in this." Perhaps because there is no real reason to sink the engineering effort into adding a new syntax to something that works and there are plenty of competent, educated engineers out there working on the stack already. There is lots of historical context here as well, JavaScript more or less became popular in the web era to manipulate front ends, Node made a viable server side platform so it was "one language up and down the stack" which made engineers easier to train (supposedly, I have yet to see this in practice). This was all great but thats a web centered view of the whole situation. In reality there are computers in EVERYTHING these days and many of those computers/microcontrollers/microprocessors simply can't run javascript (for what ever reason) and systems languages are quite relevant. To sum it all up I think your largely ignoring:
1) The huge historical contexts to why some languages are the way they are
2) Why some syntax/language designs lend to certain use cases
3) Why the "web" era made JS popular for better or worse
4) Why OOP is not a silver bullet for all computing use cases It took me the better part of the first decade of my career to understand that the purest developers/comp sci's fundamentally know that the language does not matter but instead understanding WHY a language/framework/library/system is good for the use case. Roller Coaster Tycoon was mostly written in assembly anyway... |
Haha that really is wild. It was just a blink of an eye ago that Ruby was the big thing and now when do you ever hear about it?
I see TypeScript being around for a while because it's doing to JS what C++ did to C, but WebAssembly is currently a huge unknown that could end up either being the death knell of the JS ecosystem long term, or have no real effect whatsoever on it.
So JS/TS could be just as popular as now, or totally obscure in 15 years, in my estimation, but it would be insane if C was gone. There's just not enough time or motivation to rewrite the vast amount of C/C++ code under the hood of literally everything everywhere.