[flagged]
- Something like Java/C#, but that would have required users of the tool to manage a second toolchain / runtime just for developer tools - quite a hard sell for widespread adoption
- C/C++ which are quite hard to learn (and use correctly once learnt) for users of interpreted languages which ends up being a barrier to their use.
Now we have Go and Rust which are fast, compile to a single binary, and are much easier to learn than C/C++, which is leading to a whole new generation of tools.
Learning C++ legalese takes ages but the basic principles really aren't that hard. It feels more performative than most are prepared to admit.
Rust probably has less bullshit but is borrow checking and macros aren't exactly simple in vacuo either
The borrow checker wasn't trivial to learn, but I could at least bash my head against the compiler, and be pretty sure that once it compiled my code was correct. With C++ it is much harder to get that feedback while learning as it's very easy to compile something that segfaults, crashes, or has Undefined Behaviour.
After a few months of coding in Rust, I stopped having that problem altogether. I still ran into bugs, mind you, but solving them usually became painless.
It's not about memory safety, exactly. It's hard to convey the difference in how I experienced coding in Rust vs in C++/JS/Python/etc.
The big thing is that the absence of shared mutability means you can be very confident that when you "have" a reference to a thing, you "own" it, and it's not going to change value under you. When a bug came up in a C++ codebase I often felt like it could come from anywhere. In Rust the suspect list was much shorter, which made for a more tranquil debug experience.
(I'm told this is also the experience of people writing Haskell, but I've never managed to read any Haskell code, so Rust it is for me.)
I don’t know C++. Does it have tooling that makes figuring things out similarly easy?
Swift is 9 years old
Rust is 8 years old
Zig is 7 years old
If you compare like for like, Rust started development 17 years ago, as did Golang. Though Rust spent longer in the research project phase.
Also, Zig still isn't 1.0 so if we're measuring languages from when they first became public, I believe those others in your list are much older as well.
Later once you have figured out how the program should be written, that’s when you go back and rewrite it in a language that is _fast to run_, like Rust. Sure, if you had written it in Rust to start with it would have been fast to start with. The problem is that the exploration would have been far slower, taking years instead of months. And because you haven’t done the exploration, it is unlikely that you will start with the right architecture. That means a lot of factoring and refactoring once you figure out what the right architecture is.
In most cases you can gain far more by writing the program quickly than you can by writing a quick program.
Sure but rather than scold people perhaps we should examine why they used JS instead of a compiled language. And why that’s changed now.
We know why js devs chose js already.
We also know some of them learned rust and used their new hammer to bang out better solutions. See OP :)
But it was possible to write C/C++ modules for Node very early on. So there were always multiple hammers available.
It's also nice that people in the JS community can easily contribute to tools written in JS (including writing custom eslint rules).
The words you are looking for are "language runtime". And even if you used that, you'd still be wrong. Java is exactly that: "even if with a dynamic JIT", and it does perfectly fine and even sometimes is the fastest solution for a problem (I think Java beat everyone on fastest HTTP server with largest number of simultaneous connection, where second in class was an Erlang program iirc).
Because you don't understand the problem, you are trying to offer a wrong solution: compiling doesn't do anything to speed up programs, for example. What people who want better performance need is:
* Tools to analyze program performance.
* Tools to alter program runtime ahead of time and during the program execution.
* Access to runtime primitives as far down to the "metal" as possible with as little undue effort as possible.
---
The problems with current JavaScript runtimes are that they aren't designed for performance-minded developers. The developers are given highly engineered "primitives" to work with, which make them commit to certain solutions which in turn will make automatic or manual optimizations very hard, next to impossible.
But it doesn't have to be like that. For example, a variant of JavaScript, the version 4 a.k.a. ActionScript had an "escape hatch" -- if you wanted to optimize a program you had simple unchecked memory access with primitive memory operations, which would allow you to side-step all the "bloat" of object lifecycle management. This library was often used to implement various online tools for dealing with a lot of data-processing (eg. image or video compression) and they did just fine.
Current version of JavaScript doesn't have anything like that. But it could as the evidence of its previous version doing it successfully shows.
A competent in the subject person would've had something to say relevant to the subject.
The problem is that CS studies are, in general bad. Not just your specific case. In other fields something would've pinched your bubble by now and you'd start wondering what other things you might have possibly missed, but because CS studies are so universally bad, virtually everyone you interact with professionally will share your misconceptions.
Ironically, the "hard sciences" as well as math like to pet themselves on the back about how these disciplines open students to critical thinking, requiring proofs and soundness of definitions, and yet your whole taxonomy of the thing you interact with professionally is ridiculously wrong, contorted and full of magical thinking.
During your studies, I'm sure, you were given a straight up definition of what a programming language is. You must've taken at least one semester of automata theory -- it's hard to imagine a CS degree w/o it. The premise of this discipline is that there are languages, and throughout the course you discuss their properties, various ways to define them, operate on them etc.
And then one day you take an "intro to CS with language X 101" course. And that b/s course tells you with a straight face that language X is "object oriented" or "functional" or "compiled" or "dynamically typed". And you just eat it up. You never connect the dots between what you've studied in automata course and this intro b/s course. You never ask the question like "so how do I get from states, transitions, initial and final state to... objects?.. or w/e other b/s property the course ascribes to that language.
And now you are waving your diploma in my face and making a fool of yourself... you should probably ask the academic institution who handed you this diploma to reimburse you for the time you wasted there instead. Alas, they won't do it. They won't so much as understand the reason why what they did was a disservice to you. Well... life's unfair.