Gremlin-like API gives end to end type safety if you're querying the database from TypeScript. This was the original motivation for the library.
Zod/Valibot/ArkType/Standard Schema support because you need a way to define your schema and this allows for that at runtime and compile time.
Y.js as a backing store because I needed to support offline sync, branching/forking, and I use Y.js for collaborative editing in my product, so I needed to be able to store the various CRDT types as properties within the graph. e.g. you can have a `description` property on your vertices or edges that is backed by a Y.Text or Y.XmlElement
Cypher because until the arrival of codemode it wasn't feasible to have LLMs write queries using the Gremlin-like API and LLMs already know Cypher.
Most of all though, this was an experiment that ended up being useful.
unfortunately it's unavoidable if you want to preserve type safety. I did consider parsing Cypher in typescript types, but it's not worth the effort and it's not possible to do safely.
Why not with a pipe that returns a function, the type of which is determined by the args of the pipe? That is possible to make typesafe in TS. That way you can have both APIs where the chained version is just wrapping successive pipe calls.
I needed it to be possible to run the graph in the browser and cloudflare workers, so TS was a natural fit here. It was built as an experiment into end to end type safety - nothing to do with LLMs, but it ended up being useful in the product I'm building. It's not designed for large data sets.
How large is large, here? Tens of thousands of triples? Hundreds? Millions?
I'm working on a local-first browser extension for ActivityPub, and currently I am parsing the JSON-LD and storing the triples in specialized tables on pglite to be able to make fast queries on that data.
It would be amazing to ditch the whole thing and just deal with triples based on the expanded JSON-LD, but I wonder how the performance would be. While using the browser extension for a week, the store accumulated ~90k thousand JSON-lD documents, which would probably mean 5 times as many triples. Storage wise is okay (~300MB), but I think that a graph database would only be useful to manage "hot data", not a whole archive of user activity.
it depends on the backing store (which is pluggable). I would not want to exceed let's say 50Mb in a Y.js doc, but i've tested the in memory storage with graphs approaching 1Gb and it's been fine - like any graph it really depends on how you query it. Most of the docs I'm dealing with in production are less than 10Mb, so this is fine for my use cases, but... buyer beware!
> Have we really reached a point where marketers have polluted our lives with so many ads for garbage that we're incapable of discovering anything worthwhile unless it has a massive marketing agency behind it?
Yes, exactly this. It is extremely difficult to get attention these days, no matter how good your offering.
I'm pretty excited about agentic coding myself, but this does appear to be an extended ai-psychosis (i'm not super comfortable with this phrase, but it is becoming pretty recognisable).
I think he's boxed himself in by continually layering more complexity on his approach, rather than stepping back and questioning the fundamentals or the overall direction.
All of the steps Gas Town or Gas City etc are taking are towards reducing human oversight and control. This is profoundly misguided! In a world of infinite cheap software it is precisely this human decision making and control that matters.
> There will be nothing like it. You are going to want to use Gas City.
No. I do not want to talk to the mayor of my software factory, as its cartoonish minions build an infinite mountain of slop. Unreviewable, both in terms of code and the finished product.
Instead, I want to precisely capture human ideas, have those ideas questioned, challenged, improved, and then I want to bring those ideas to life, keeping the human in the loop whenever they want. Neither Beads, Gas Town, nor Gas City or anything like them are required for that.
Building harnesses does seem like a task that's particularly conductive to psychosis. I've wondered if it's because there is no push-back; almost anything you try will be "right" in that your changes appear to make things happen. "Oh look I added a carpenter and now it's walking around and making notes about the scaffolding" So you get to stay in your flow state without reassessing if the concepts you are forming are ultimately meaningful.
Although I think the post also self-diagnoses some factors that also help:
With the Gas Town Mayor, you feel like you’re operating at a special level, a VIP, above all the workers. You are talking to someone important: the mayor of a factory the size of a town. You have access to someone with resources, someone who gets you, someone who appreciates how busy you are.
Working with regular coding agents just doesn’t give you that special feeling.
I think at this point it’s all but confirmed that LLMs sycophantic tendencies coupled with yes-man attitudes produce AI psychosis and AI fanaticism. Especially if you’re already of high opinion of yourself (be it deserved or not).
> All of the steps Gas Town or Gas City etc are taking are towards reducing human oversight and control. This is profoundly misguided!
I mostly agree with you other than this one sentence.
Let's say you're building the literal antithesis of Gastown: an AI agent software specifically designed to be human reviewed and monitored. How to you make this as efficient as possible? Well, it's by ensuring high quality results from human oversight and control while spending the least amount of time. Which to be precise, is still reducing human oversight and control per unit of useful work done.
It's really about granularity - when I'm building something there are parts of the system where I want very fine-grained control and oversight over what is built and how, and there are others where... it just doesn't really matter. What matters to who is contextual - a software architect tends to care about different things from a product manager for example. This is the idea of gradual specification - I should be able to defer some decisions to the AI and exercise full control over other aspects, but it's the humans that should be able to choose what level they want to work at.
Zod/Valibot/ArkType/Standard Schema support because you need a way to define your schema and this allows for that at runtime and compile time.
Y.js as a backing store because I needed to support offline sync, branching/forking, and I use Y.js for collaborative editing in my product, so I needed to be able to store the various CRDT types as properties within the graph. e.g. you can have a `description` property on your vertices or edges that is backed by a Y.Text or Y.XmlElement
Cypher because until the arrival of codemode it wasn't feasible to have LLMs write queries using the Gremlin-like API and LLMs already know Cypher.
Most of all though, this was an experiment that ended up being useful.