I had an HP Mini 5102 and I absolutely loved it! I actually revived it a few years ago and used it for some modern programming tasks. I think I tried to compile rustc on it once and had to leave it on for the night, coming back to it in the morning and finding that it had just frozen fully.
Unfortunately its CMOS battery ran out and when I went in to replace it I had to unplug a few ribbon cables which of course promptly snapped the now-brittle plastic connectors. Its been sitting on a shelf waiting to be revived once again ever since... I miss that little thing.
Ooh, cooll to hear you got some uptake on the call for formal methods help! Or did you end up figuring it out on your own? Either way, looking forward to the followup!
Beyond just quite possibly being slop, this is also sloppy and confused: complaining that C++ cannot remove features because they live in the stdlib forever while listing out a bevy of features that got deprecated and then removed is just oof.
Also, fun fact: Rust cannot remove anything from std once stabilised, presumably forever. Take this with a slight grain of salt, I haven't vetted this thought myself, but it's what I hear from Rust project people and I've just been in the project all-hands for three days.
Rust does partially have an easier time since it eg. does not guarantee the ABI of various std types like Vec (although the size and alignment are probably guaranteed at this point), and with 1&mut XOR N& providing local reasoning and isolation you get to change internal details easier.
Rust promises not to remove things from the stdlib unless they're unsound. It does commonly deprecate things - the deprecation warnings won't bother people merely using your library or whatever but will still show for you if you're maintaining it.
They have a PR (~~closed by GitHub bot as AI slop, ironically~~ this was wrong info, it was apparently closed by Jarred himself as it missed a conversion or some 20 Zig files to Rust) to remove the Zig code.
Regarding the architecture documentation you have up on tsz.dev, one thing that jumped out to me was the use of the per node typed side pools. A semi-recent talk[0] had benchmarked this and found it to be a deoptimisation: he couldn't explain it, but an audience member suggested it is likely because an AST is not generally very type-homogenous in its visit order. After a CallExpr node the next node to visit is probably not a CallExpr but more probably an Identifier etc, so storing the node "extra data" in separate pools makes them more likely to be cold in cache rather than hot.
In Nova JavaScript engine[1] I've done exactly as you've done and split objects into typed side pools (I call them "(typed) heap vectors") but in a JavaScript engine my _hypothesis_ is that the visitation patterns are much more amenable to this: an Array, Set, or Map is more likely to be homogeneous than heterogeneous, and therefore a loop over the contents is likely going to hit the same side pool for each entry.
That talk is very interesting. Thanks for sharing. I'll watch it later.
Now that most of the implementation is nearly completed, I'm building a lot of instrumentations to have better visibility into those things to have concrete answers to that sort of question. I'm experiencing huge RSS right now that could be exactly what you're pointing to.
reply