That's what LLMs are best, actually. Go through all your stuff and painstakingly document, add tags, refer to other documents, etc

> Due to this, my Obsidian vault is pretty much a collection of a bunch of temporary to-do lists and then some folders with specific reference information

LLMs can also separate what information was only useful at a specific time vs more perennially useful notes.

can someone link to some of those paid resources?

This is huge, thanks. Unfortunately many Bevy resources became stale (the Bevy cookbook was even abandoned, there was little interest in keeping it up to date and so there were many sections for, say, Bevy 0.12)

When I talk about a higher level interface it may be something like this https://crates.io/crates/typed-generational-arena those sort of things are very common in Rust. In here the index is an usize, but you don't directly do math with it (also you have a generation number to guard against index reuse), so you never experience any `as usize` thing.

Of course that's not applicable to everything. Some domains will naturally require doing arithmetic with indices, which is annoying in Rust. Hopefully you enclose this into a library and try to forget the horrors (rather than using usize everywhere, which is objectively the wrong thing to do)

Then you have libraries like petgraph that does use u32 indices by default, to save memory https://docs.rs/petgraph/latest/petgraph/graph/type.DefaultI...

Both will either download or ship the postgres binary with your app, and run it in a separate process. Pglite is different, it's actually a library (they have stripped some parts of the postgres source code) and it could in principle be ported to be used as a native library (meaning, you link to it and run as a single program)

There's even a draft PR to do this, but it became stale

https://github.com/electric-sql/pglite/pull/842

Right now what exists is, grabbing the pglite wasm and running it on native code on wasi

https://github.com/f0rr0/pglite-oxide

but this still burns tokens needlessly in the subagent. if the agent could filter the mcp output using a cli (often jq, but sometimes something else), it could be more economical

maybe anthropic wants you to burn those tokens though

MCP has severe context bloat just by starting a thread. If harnesses were smart enough to, during install time, summarize the tools provided by a MCP server (rather than dumping the whole thing in context), it would be better. But a worse problem is that the output of MCP goes straight into the context of the agent, rather than being piped somewhere else

A solution is to have the agent run a cli tool to access mcp services. That way the agent can filter the output with jq, store it in a file for analysis later, etc

if someone sends you a malicious file that uses a rare codec and you open it, you will trigger this codepath that is not widely used and don't get a lot of scrutiny

Maybe we could say they went uphill instead for a while? Or something

Also: why not riscv?

Anyway, I think that most pain for being low level and portable is due to C and C++, and it's not as painful in Rust. In Rust it's not as common to use non-portable integers like C's int (there is isize/usize but they are used for indexing; logic is supposed to be done in i32/u32/i64/u64), and the Rust stdlib comes with excellent support for dealing with byte orders like https://doc.rust-lang.org/std/primitive.i32.html#method.to_b... (and for more support, usage of https://docs.rs/byteorder/latest/byteorder/ is widespread), among other things

I think it's more immediately clear when Rust code is non portable too. It's not uncommon for random C code to be plagued with undocumented portability issues (and as such, you can't assume that code is portable without some inspection), but unportable Rust code may fail to build on unsupported platforms, which is an excellent idea

Perhaps it's already necessary, or it will be in the following months. We are hearing only about the public developments, not whatever classified work the US is doing

I think the analogy with the Manhattan project is apt. The US has enormous interest in decrypting communication streams at scale (see Snowden and the Utah NSA datacenter), and it's known for storing encrypted comms for decrypting later. Well maybe later is now

The US government routinely deploys malware to users devices, for multiple reasons. Here is a 2017 link about this: https://www.aclu.org/news/privacy-technology/challenging-gov...