It's just not what the word axiom means nor how anyone uses it. An axiom is unprovable by definition - is it a thing we accept to be true because it is useful to do so (e.g. there exists an empty set)
"Provably Correct Axiom" is nonsense. An axiom is unprovable.
Just "provably correct" would've been fine. This chess stuff is hilariously pretentious.
I just don't understand how this can be this slow. What on earth is it doing to get 193 requests per second on static, cached content?
The article doesn't dig too deep into this sadly, rather just accepts that it's slow and uses a different tool.
But seriously, this is responding to a request with the content of a file. How can it be 100,000x slower than the naive solution. What can it possibly be doing, and why is it maxxing out the CPU?
If no-one else looks into this, I might get around to it.
But this isn't even true, and NextJS is well into egregiously complexity. Remix was an alternative option in the space that is now deprecated in all-but-name for React Router v7, which (for those just tuning back in), react router is now a framework.
If you wrote your app in NextJS 2 years ago, you would already have to rewrite chunks of it to get it to compile today. These tools are NOT solidified, they are releasing breaking changes at least once a year.
The blog post you've linked doesn't justify what you've said about it at all.
In the netflix blog post they're complaining about increasing latency over time because they have a function that *reloads all express routes in-memory* that didn't properly remove all the previous routes, so the routes array got bigger and bigger. That's not a fundamental problem with express[1], that's an obscure (ab)use case implemented wrong. Hardly a damning indictment of express.
> This turned out be caused by a periodic (10/hour) function in our code. The main purpose of this was to refresh our route handlers from an external source. This was implemented by deleting old handlers and adding new ones to the array. Unfortunately, it was also inadvertently adding a static route handler with the same path each time it ran.
[1]: Admittedly an array is not the "best" data structure for routing, but that absolutely wasn't the performance issue they were having. Below a couple thousand routes it barely matters.
Where there is smoke, there is fire. And Trump has been boasting about hacking the election, if some Twitter screenshots are to be believed..
This looks a bit thin and a bit far-fetched, but, then again, it might be the beginning of some proof.
If there was fraud, it's hard to believe they managed to cover all their tracks. So let's archive and save the possible clues we can find, and maybe, one day, we will have an answer.
All these replies trying to justify the title... absolutely bonkers. Should be ashamed.
Literally has nothing to do with faking data, hacking data, changing data or trying to influence any outcome whatsoever. The title is 100% not what his code is about.
But yall keep on trying to fit a square peg into a round hole and wonder why no one cares about your outrage.
Use it on something legitimate, not something 100% made up.
cargo is a bad example as it's universally `cargo build`.
Make on its own is great but most of the time I've worked with C projects it's been cmake/autotools + global pkg installs, which you Do have to frequently look up.
Parent states that it's always "cargo build" which in 90% of the cases, is true.
Except for the projects that would require something like "cargo build --feature=wayland" for example, in order to run.
So "cargo build" ends up not being universal, and adding make will make it just "make build" regardless of what flags people use with cargo, meaning it's more universal than "cargo build".
There's quite a lot of mathematical mistakes (obvious ones, even) in DFWs work. I'm not sure whether it's intentional or not, but given that he also makes mistakes in his nonfiction it might just be that he's not a great mathematician.
Like in TPK, 0/0 is Infinity and
in IJ, Pemulis explains differentiation completely incorrectly, also that stuff about the mean value theorem is irrelevant?!?
Still one of the greatest authors; deep technical correctness is more of a Pynchon thing.
That makes sense to be honest, I thought it was intentional but then seeing so many other maths errors in other DFW works led me to believe it might very well not be.
"Provably Correct Axiom" is nonsense. An axiom is unprovable.
Just "provably correct" would've been fine. This chess stuff is hilariously pretentious.