Is it time to kill the database and replace it with a LLM optimized compiled version that simply implements the required API directly in (Rust) code, without any dynamic overhead? It probably will still be based of off a base design or a base file format.
Ultimately this system will encompass the whole OS, of course, but the DB might be the best place to start.
Instead of a database, the LLM will expose an api endpoint and build a database on demand?
That's interesting. Maybe to decrease latency the LLM could "cache" it's build of it's database and reuse in between instances. It could host this artifact on a "hub" of git trees and then any new use cases that come up, can be added to this git tree. Then it can possibly be reused in different use cases.
Yes you got it. Get rid of all the abstractions we've gotten so used to and effectively approach this as an embedded project, where every line of code has to be justified.
It tends to make sure you understand the system fully, as no foreign concepts need to be imported and deferred to. That should make your organization run better.
childintime · · focus · HN ↗
Ultimately this system will encompass the whole OS, of course, but the DB might be the best place to start.
nemothekid · · focus · HN ↗
That's interesting. Maybe to decrease latency the LLM could "cache" it's build of it's database and reuse in between instances. It could host this artifact on a "hub" of git trees and then any new use cases that come up, can be added to this git tree. Then it can possibly be reused in different use cases.
childintime · · focus · HN ↗
It tends to make sure you understand the system fully, as no foreign concepts need to be imported and deferred to. That should make your organization run better.
Just like Rust does, btw.
Thx.