Astro is a meta-framework that allows you to plug in other web frameworks where you need it (React, Solid, etc). Although it would also be fair to consider Astro a sort of build tool / bundler.
Node is a runtime, not a framework.
So there's really only one framework here (Astro). Using other web frameworks within it is completely optional.
I've been presented with this thought experiment before and I always feel like I'm missing something when other people talk about it. Why would you ever take both boxes?
The premise is that the predictor is always right. So whether you take one or both boxes, the predictor would have predicted that choice. We know from the setup that if the predictor said you would take the one box, it will have a million dollars. Therefore, if you take the one box it will have a million dollars in it (because whatever you choose is what the predictor predicted).
As an aside, I think whatever this says about free will or if you're actually making a "choice" is irrelevant in regards to if the million dollars is in the box. The way I see both choices is this:
You "decide" to take both boxes -> the perfect predictor predicted this -> the opaque box has zero dollars -> you get a thousand dollars
You "decide" to take the opaque (one) box -> the perfect predictor predicted this -> the opaque box has a million dollars -> you get a million dollars
If you want to consider the version of this where the predictor is almost perfect instead of truly perfect, I don't think that changes anything. Say it's 99% accurate or even 90% accurate.
You take the opaque box -> the predictor has a 90% chance of predicting this -> it follows that there's a 90% chance that the box has a million dollars -> you have a 90% chance of getting a million dollars
Had you picked both boxes, you have a 90% chance of not getting the million.
I know that one thing you guys are working on or are at least aware of is the size of single-file executables. From a technical perspective, is there a path forward on this?
I'm not familiar with Bun's internals, but in order to get the size down, it seems like you'd have to somehow split up/modularize Bun itself and potentially JavaScriptCore as well (not sure how big the latter is). That way only the things that are actually being used by the bundled code are included in the executable.
Is this even possible? Is the difficulty on the Bun/Zig side of things, or JSC, or something else? Seems like a very interesting (and very difficult) technical problem.
I used Proxmox for years to run a fairly comprehensive homelab, and a few months ago replaced the entire thing with Incus (on a debian host, haven't tried IncusOS yet). Incus is amazing and it makes so many things so much easier compared to Proxmox.
One thing in particular is permissions in unprivileged containers. In Proxmox, you have to do a bunch of somewhat confusing ID mapping. In Incus, it's as simple as setting "shift=true".
Also the profile system in Incus is really powerful and allowed me to deduplicate a ton of config.
I'm personally looking forward to this change because I currently pay $20/month just to get edit prediction. I use Claude Code in my terminal for everything else. I do wish I could just pay for edit prediction at an even lower price, but I can understand why that's not an option.
I'm curious if they have plans to improve edit prediction though. It's honestly kind of garbage compared to Cursor, and I don't think I'm being hyperbolic by calling it garbage. Most of the time it's suggestions aren't helpful, but the 10-20% of the time it is helpful is worth the cost of the subscription for me.
There are plenty of larger ones and plenty of ones that used the date as the version, but I was mainly curious about packages that followed semver.
Any package version that didn't follow the x.y.z format was excluded, and any package that had less published versions than their largest version number was excluded (e.g. a package at version 1.123.0 should have at least 123 published versions)
I made a fairly significant (dumb) mistake in the logic for extracting valid semver versions. I was doing a falsy check, so if any of major/minor/patch in the version was a 0, the whole package was ignored.
Hmm yeah, I decided that one counts because the new packages have (slightly) different content, although it might be the case that the changes are junk/pointless anyway.
Hmm, maybe I need to think about this more, but since operations are a language feature (and could have any name, see custom operations), I don't think they could be attached to the filterql class like that.
You're right though, the naming of the `filter` method is confusing. I need to split off the filtering and applying of operations into two separate methods. And probably provide an additional `query` method like you said which would do what `filter` is doing now. Appreciate the feedback!
I've been using it in a CLI tool [1] to query media in my *arr services.
If you're talking about a query where you want "foo" to not be "evil" OR "silly", you could write 'foo != evil || foo != silly'.
There's a separate case where the value itself is an array/collection/set, in which case doing anything with that is currently unsupported. Values can only be strings, numbers, or booleans.
I thought about doing exactly what you suggested, where a query could access deeper properties with a syntax like "model.cost", but ultimately decided against it because I didn't like the complexity that would necessitate.
As for arrays, I usually opt for joining the string and then doing an "includes" query. e.g. ["sm", "md", "lg"] -> "sm,md,lg" and then you could write a query like "size *= md". Obviously this approach has its disadvantages though.
I'm definitely open to rethinking both of these if that's a common enough want/need.
Node is a runtime, not a framework.
So there's really only one framework here (Astro). Using other web frameworks within it is completely optional.