billywhizz
billywhizz on Hacker News
i haven't looked at the code yet but i love the website. just how open source project websites should be! ♥
i guess you didn't bother reading it then.
the fact fortune magazine is the one ringing the alarm bell here is arguably more useful information than any attempt at a "mathematical proof".
also notable that deno has a very low overhead bindings layer for doing JS->C/C++/Rust/Native interop using v8 fastapi calls where possible.
this is social media induced psychosis my friend
> It will completely kill the market.
it will kill all the people in that hospital too
i did a quick benchmark on this with a single db connection updating user_version in a tight loop with the wal_hook callback enabled.
on my crappy old i5 with the db file on /dev/shm it can do ~150k writes a second with the wal_hook callback called on every write. and this is using JS bindings to C++ so has some unnecessary overhead.
good point. but ime and as seems to be widely understood writing from multiple connections is a bit of a minefield in SQLite. and afaik it still would be possible to have a hook on all connections you expect to be writing?
"some value" is not the same as "a surprisingly good measure of the quality of the model for other tasks".
doublethink does not mean holding two conflicting ideas in your head at once. it means holding two logically inconsistent positions/beliefs at the same time.
how can you say "it ended up being a surprisingly good measure of the quality of the model for other tasks" and also "It should not be treated as a serious benchmark" in the same comment?
if it is indeed a good measure of the quality of the model (hint: it's not) then, logically, it should be taken seriously.
this is, sadly, a great example of the kind of doublethink the "AI" hypesters (yes - whether you like it or not simon - that is what you are now) are all too capable of.
you probably could have written the low stakes productivity app in a fraction of the time you wasted on this.
what's even more amazing is it took them two weeks to fix what must have been a pretty obvious bug, especially given who they are and what they are selling.
why do you find it surprising? these models have no actual understanding of anything, never mind the physical properties and capabilities of a bicycle.
SQL Server was very good and used in a lot of enterprises. ime the decision between Oracle and SQL Server tended to be down to whether the IT department or company was a "Microsoft Shop" or not. There were a lot of things that came free with SQL Server licenses and it had really nice integrations with other Microsoft enterprise systems software and desktop software.
Oracle was definitely seen as the more mature and resilient (and expensive!) RDBMS in all the years I worked in that space. It also ran on Unix/Linux whereas SQL Server was windows only. Many enterprises didn't like running Microsoft servers, for lots of (usually good) reasons.
that sounds way off. there is a big perf hit to async, but it appears to be roughly 100 nanoseconds overhead per call. when benchmarking you have to ensure your function is not going to be optimized away if it doesn't do anything or inputs/outputs never change.
you can run this to see the overhead for node.js Bun and Deno:
https://gist.github.com/billywhizz/e8275a3a90504b0549de3c075...
> We are just dumber than them.
you are, for sure.
is it not obvious?
> These issues are present in the patches published last week.
> The patches published last week are vulnerable.
> If you already updated for the Critical Security Vulnerability, you will need to update again.
the OP was specifically about jetstream so i guess you just didn't read it?
is this really the best use case you could come up with? says it all really if so.
> When a package in the npm registry has established provenance, it does not guarantee the package has no malicious code. Instead, npm provenance provides a verifiable link to the package's source code and build instructions, which developers can then audit and determine whether to trust it or not
yes. most folks don't seem to understand this. but, you can get something approaching such guarantees if you are able to limit yourself to something as (seemingly) simple as updating a ledger. this approach is used in a lot of places where high performance and strong consistency is needed (see e.g. LMAX disruptor for similar).
https://tigerbeetle.com/
i can't see how these numbers can be anywhere near correct (nor the ones above). in JavaScript on an old Core i5 the overhead of a simple ffi call is on the order of 5 nanoseconds. on a recent x64/arm64 cpu it's more like 2 nanoseconds.
you can verify this easily with Deno ffi which is pretty much optimal for JS runtimes. also, from everything i have seen and read, luajit should be even lower overhead than this.
you really shouldn't be asking chatgpt questions like this imo. these are facts, that need to be proven, not just vibes.