50 extra packages are cursed
There is a user in the JavaScript community who goes around adding "backwards compatibility" to projects. They do this by adding 50 extra package dependencies to your project, which are maintained by them.
which bring to this user: Jordan Harband https://github.com/sponsors/ljharb
Does anyone know what they actually mean with that cursed knowledge point? And what's the "backwards compatibility" that Jordan also boasts in his GH profile?
To not just link to another thread: The specialty of ljharbs issues sits somewhere between "JavaScript is a very dynamic programming language that grew a lot and quite fast" and "we cannot trust developers to do the right thing".
His libraries tend to build up on older runtime implementations and freeze every used functionality during runtime, so they provide "second-run safety" and "backwards compatibility". Developers disagree with some of its effects, such as a grown dependency tree and impacts in performance of multiple magnitudes (as measured in micro-benchmarks). ljharb seems to follow a rather strong ideology, but is a member of the TC39 group and a highly trusted person.
I still think the conclusion on "setTimeout is cursed"[0] is faulty:
> The setTimeout method in JavaScript is cursed when used with small values because the implementation may or may not actually wait the specified time.
The issue to me seems that performance.now()[1] returns the timestamp in milliseconds and will therefor round up/down. So 1ms errors are just within its tolerance.
setTimeout() does not actually guarantee to run after the elapsed time. It merely gets queued for the next async execution window after that timer elapsed. Hence it can also be off by infinity and never get called - because JS is single threaded (unless you use a worker - which comes with its own challenges) and async windows only open if the main thread is "idle".
Usually, this is very close to the time you set via setTimeout, but it's very frequently slightly off, too.
They think Postgres is cursed with a 2^16 limit; SQL Server has a parameter limit of ~2,000. I guess at least it's low enough that you're going to fail early.
Sure, but SQL Server DB protocol (TD) has a dedicated Bulk Insert specific for that functionality. TDS isn't perfect, but it is much better then the postgresql wire protocol v3.
Sometime I want to build a DB front-end that you send up some type of iceberg/parquet or similar, and return a similar file format over a quic protocol. Like quic, persistent connections could be virtualized, and bulk insert could be sane and normalized: eg insert these rows into a table or temp table, then execute this script referencing it. While I'm at it, I'll normalize PL/SQL so even brain-dead back-ends (sqlite) could use procedural statements and in-database logic.
darkwater|5 months ago
whilenot-dev|5 months ago
His libraries tend to build up on older runtime implementations and freeze every used functionality during runtime, so they provide "second-run safety" and "backwards compatibility". Developers disagree with some of its effects, such as a grown dependency tree and impacts in performance of multiple magnitudes (as measured in micro-benchmarks). ljharb seems to follow a rather strong ideology, but is a member of the TC39 group and a highly trusted person.
slaterbug|5 months ago
pcthrowaway|5 months ago
whilenot-dev|5 months ago
I still think the conclusion on "setTimeout is cursed"[0] is faulty:
> The setTimeout method in JavaScript is cursed when used with small values because the implementation may or may not actually wait the specified time.
The issue to me seems that performance.now()[1] returns the timestamp in milliseconds and will therefor round up/down. So 1ms errors are just within its tolerance.
[0]: https://github.com/immich-app/immich/pull/20655
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Performance...
ffsm8|5 months ago
setTimeout() does not actually guarantee to run after the elapsed time. It merely gets queued for the next async execution window after that timer elapsed. Hence it can also be off by infinity and never get called - because JS is single threaded (unless you use a worker - which comes with its own challenges) and async windows only open if the main thread is "idle".
Usually, this is very close to the time you set via setTimeout, but it's very frequently slightly off, too.
daemonologist|5 months ago
kardianos|5 months ago
Sometime I want to build a DB front-end that you send up some type of iceberg/parquet or similar, and return a similar file format over a quic protocol. Like quic, persistent connections could be virtualized, and bulk insert could be sane and normalized: eg insert these rows into a table or temp table, then execute this script referencing it. While I'm at it, I'll normalize PL/SQL so even brain-dead back-ends (sqlite) could use procedural statements and in-database logic.
thewisenerd|5 months ago
i wish there was an unused lambda parameter warning..
kmarc|5 months ago
senectus1|5 months ago
perching_aix|5 months ago