Yeah, that's roughly my take as well. The AI bit is especially jarring, given the supposed goal of being "resonant", when in fact AI is the most powerful force right now towards making things that are functional without being resonant. As in, things that work superficially but just feel... off. (And upon closer inspection, they don't quite work as fully as you'd thought.)
Like, AI is certainly powerful and can do a lot, but this "resonance" is its weakness, not its strength.
Huh. I expected two main advantages on Rust's side: usable multithreading (as mentioned) and stack allocation. For the latter, the ownership model makes it possible to stack-allocate things that you wouldn't dare put on the stack in either C or C++, thus saving malloc and free time as well as second-order effects from avoiding fragmentation.
Does Rust not do this for subtle reasons that I'm missing, or does it just not matter as much as I'd expect it to?
Both of those things are important, sure. I wanted this post to be talking about the higher level conceptual question, and then using interesting examples to tease out various aspects of that discussion, more than "here's what I think are the biggest differences between the two."
I think these two things are also things people would argue about a lot. It's hard to talk about them in a concrete sense of things, rather than just "I feel like code usually does X".
Right, sorry, I didn't mean to imply that you should have covered stack allocation in your post. I think your post covers the right material to make its point.
This is more of a side comment about a different question, perhaps "ok fine, but then what are the language differences that could be performance-relevant for one language or the other, even if (as you say) they don't lead to a yes/no answer for your original question?"
It's a good reason to choose Rust over C++ for that application, and others that share its characteristics. (Or, more to the point of the article, it's a good reason to declare that Rust is faster than C++ for that application.)
It doesn't provide a lot of evidence in either direction for the rest of the vast space of potential programs.
(Knowing C++ fairly well and Rust not very well, I have Opinions, but they are not very well-informed opinions. They roughly boil down to: Rust is generally better for most programs, largely due to cargo not Rust, but C++ is better for more exploratory programming where you're going to be frequently reworking things as you go. Small changes ripple out across the codebase much more with Rust than C++ in my [limited] experience, and as a result the percentage of programming time spent fixing things up is substantially higher with Rust.)
It did not contribute to a yes/no answer, which is good, because it is not answerable with "yes" or "no", and the article points that out and explains why. So I would disagree; it does contribute to answering the question, in the form of spelling out why it is unanswerable.
Compare:
"Have you stopped beating your wife yet?"
"I do not beat my wife."
The response contributes to the answer, even if it brings you no closer to "yes" or "no".
Yes. "Is language X faster than language Y?" means "Is language X better than language Y?", which means "Do you like language X more than you like language Y?", which means "Do you have more experience with language X than language Y?" (well, good experiences, I guess).
So "Is language X faster than language Y?" is totally answerable, but the answer depends on the answerer.
It's complicated, though mostly that complication doesn't change the overall conclusion.
Much of the language's semantics can be boiled away before JIT compilation, because that flexibility isn't in use at that time, which can be proven by a quick check before entering the hot code. (Or in the extreme, the JIT code doesn't check it at all, and the runtime invalidates that code lazily when an operation is performed that violates those preconditions.) Which thwarts people who do simple-minded comparisons of "what language is fastest at `for (i = 0; i < 10000000; i++) x += 7`?", because the runtime is entirely dominated by the hot loop, and the machine code for the hot loop is identical across all languages tested.
Still: you have to spend time JIT compiling. You have to do some dynamic checks in all but the innermost hot code. You have to materialize data in memory, even if just as a fallback, and you have to garbage collect periodically.
So I agree with your conclusion, except for perhaps un-nuanced use of the term "performance floor" -- there's really no elevated JS floor, at least not a global one; simple JS can generate the same or nearly the same machine code as equivalent C/C++/Rust, will use no more memory, and will never GC. But that floor only applies to a small subset of code (which can be the bulk of the runtime!), and the higher floor does kick in for everything else. So generally speaking, JS can only "be as fast" as non-managed languages for simple programs.
(I'll ignore the situations where the JIT can depend on stricter constraints at runtime than AOT-compiled languages, because I've never seen a real-world situation where it helps enough to counterbalance everything else.)
My initial guess would be "because of the zero-cost abstractions", since I read "zero-cost" as "zero runtime cost" which implies shifting cost from runtime to compile time—as would happen with eg generics or any sort of global properties.
(Uh oh, there's an em-dash, I must be an AI. I don't think I am, but that's what an AI would think.)
Yes, it's the stock configuration to be not broken. If you are ok with breakage in exchange for less fingerprinting, the config setting privacy.resistFingerprinting is right there: https://support.mozilla.org/en-US/kb/resist-fingerprinting
It is an uplift from Tor, and I believe Tor just enables it in their build, though it doesn't end up being quite the same. Tor is always going to be better for this.
But turning it on in the stock Firefox configuration would be suicide in terms of market share. When "I want maximal privacy" fights "I want this site to work", guess which one wins?
Pedantically, Temporal also deviates from the fundamental nature of time itself. Temporal.Instant? In which accelerating frame of reference? It supports equality, which is a nonsense concept.
Like, AI is certainly powerful and can do a lot, but this "resonance" is its weakness, not its strength.
reply