The distance from Earth to Mars is about 3 to 22 light minutes, not 20 to 90. That doesn't change anything about your point, except the capacity is lower.
Twice as fast at executing JavaScript? There's absolutely zero chance this is true. A JavaScript engine that's twice as fast as V8 in general doesn't exist. There may be 5 or 10 percent difference, but nothing really meaningful.
You might want to revise what you consider to be "absolutely zero chance". Bun has an insanely fast startup time, so it definitely can be true for small workloads. A classic example of this was on Bun's website for a while[1] - it was "Running 266 React SSR tests faster than Jest can print its version number".
I only claimed there is absolutely zero chance that Bun is twice as fast at executing general JavaScript as Deno. The example doesn't give any insight into the relative speeds of Bun and Deno, as fast as I can tell.
johnfn@mac ~ % time deno eval 'console.log("hello world")'
hello world
deno eval 'console.log("hello world")' 0.04s user 0.02s system 87% cpu 0.074 total
johnfn@mac ~ % time bun -e 'console.log("hello world")'
hello world
bun -e 'console.log("hello world")' 0.01s user 0.00s system 84% cpu 0.013 total
That's about 560% faster. Yes, it's a microbenchmark. But you said "absolutely zero chance", not "a very small chance".
Keep in mind that it's not just a matter of comparing the JS engine. The runtime that is built around the engine can have a far greater impact on performance than the choice of v8 vs. JSC vs. anything else. In many microbenchmarks, Bun routinely outperforms Node.js and Deno in most tasks by a wide margin.
The claim I responded to is that Bun is "at least twice as fast" as Deno. This sounds a lot more general than Bun being twice as fast in cherry-picked microbenchmarks. I wasn't able to find any benchmark that found meaningful differences between the two runtimes for real-world workloads. (Example: https://hackernoon.com/myth-vs-reality-real-world-runtime-pe...)
We are in the "system engineering territory" and as such it might have more to do with the way the runtime is designed and how the javascript native runtime does things than the compiler optimizations.
You have to measure syscalls, memory access, cpu cache locality and a bunch of design decisions that in the end contribute a lot to the running time. So depending on the decisions taken, it can easily happen.
Are you using the Ubuntu Snap to train Firefox? If so, you can switch to the native Debian packages released directly by Mozilla. They don't do that sandboxing stuff, and they are a lot faster. I don't notice any speed difference between Chromium und Firefox even on a Raspberry Pi.
He also links a Wikipedia article stating that more than 60 percent of Londoners were born in Britain to prove his point that only a third of Londoners are "native Brits". That doesn't leave much room for interpretation.
Not even that. There's no rule in the GDPR to disclose the use of cookies. The regulation doesn't actually mention cookies at all, except maybe in an example. Instead, any data collection that's obviously required to do what the user requests (including session and shopping cart cookies) doesn't require any explicit consent. Only additional data collection, whether performed by cookies or any other means, requires consent.
That's why there are websites without cookie banners, like GitHub. It's not even hard to do that; it's just that most companies don't bother, because they know the EU will be blamed anyway.
A guerilla marketing plan for a new language is to call it a common one word syllable, so that it appears much more prominent than it really is on badly-done popularity contests.
Call it "Go", for example.
(Necessary disclaimer for the irony-impaired: this is a joke and an attempt at being witty.)
Amusingly, the chart shows Rust's popularity starting from before its release. The rust hype crowd is so exuberant, they began before the language even existed!
They are not complaining. You configured Google Search Console to notify you about problems that affect the search ranking of your site, and that's what they do. if you don't want to receive these messages, turn them off in Google Search Console.
Worth noting that the comment closing the issue mentions:
> You can disable Google Analytics in about:addons by setting your Do Not Track status to on.
> Again: this only affects users who visit the page with Tracking Protection on (which automatically enables DNT) or who manually set their DNT status to on.
but Firefox removed the DNT control last month (https://bugzilla.mozilla.org/show_bug.cgi?id=1928087), though it kept the Tracking Protection control and privacy.donottrackheader.enabled is still available in about:config.
Maybe at one point really early on the external tank was planned to be reused, but it was expended in every launch of the shuttle with no provisions for re-usability. They even stopped painting it within a few launches.
Look up any popular game, although a lot of the bigger ones are good about reporting their clones and getting them removed. An immediate example I can think of is 2048, the original by Gabriele Cirulli, is published by Solebon LLC on the Play store, when you look for 2048 using the search, it's not even the first result that comes up. Although to be fair to them, it's not the first that comes up on the apple store either.
Do you think 4096 is different from 2048? It is not developer friendly if they stop something similar publishing. And it already leck of creative, like just only can use gpt4o on iPhone.
reply