Static python can transpile to mojo. I haven't seen an argument on what concepts can only be expressed in mojo and not static python?

Borrow checker? For sure. But I'm not convinced most people need it.

Mojo therefore is a great intermediate programming language to transpile to. Same level of abstraction as golang and rust.

"Python to rust transpiler" -> pyrs (py2many is a successor) "Python to go transpiler" -> pytago

Grumpy was written around a time when people thought golang would replace python. Google stopped supporting it a decade ago.

Even the 2022 project by a high school student got more SEO

https://github.com/py2many/py2many/issues/518

https://github.com/py2many/static-python-skill

- Ladybug by default allocates 80% of the physical memory to the buffer pool. You can limit it. This wasn't the main reason.

- Much of the RSS is in ladybug native memory connected to the python connection object. I noticed that you keep the connection open between benchmark runs. For whatever reason, python is not able to garbage collect the memory.

We ran into similar lifetime issues with golang and nodejs bindings as well. Many race conditions where the garbage collector releases memory while another thread still has a reference to native memory. We now require that the connection be closed for the memory to be released.

  https://github.com/LadybugDB/ladybug/issues/320
  https://github.com/LadybugDB/go-ladybug/issues/7
  https://github.com/LadybugDB/ladybug-nodejs/pull/1

Perhaps people can invent LSM like structures on top of them.

But at least establish that CSR on disk is a basic requirement before you claim that you're a legit graph database.

But rewriting a complex working piece of software in Rust is not trivial. Having an incremental path (where only parts are rewritten in Rust and compatible with C++ code) would be a good path to get there.

Also open to new code and extensions getting written in Rust.

There are second order optimizations that LLMs logically implement that CSR implementing DBs don't. With sufficient funding, we'll be able to pursue those as well.

https://github.com/LadybugDB/ladybug/discussions/204#discuss...

AlexNet -> Tansformers -> ChatGPT -> Claude Code -> Small LMs serving KBs

Large LLMs could have a role in efficiently producing such KBs.

In the meanwhile, wikipedia ships wikidata, which uses RDF dumps (and probably 8x less compressed than it should be).

https://www.wikidata.org/wiki/Wikidata:Database_download

There is room for a third option leveraging commercial columnar database research.

https://adsharma.github.io/duckdb-wikidata-compression/

I wonder how you reconcile the demand for LLMs with multihop reasoning with the statement above.

I think a lot what is stated here is how things work today and where established companies operate.

The contradictions in their positions are plain and simple.

Just in case folks here were wondering if I'm some type of a graphdb bigot.

My other favorite quote: transformers are GNNs which won the hardware lottery.

Longer form at blog.ladybugmem.ai

You want to believe that everything probabilistic has more value and determinism doesn't? Or that the world is made up of tabular data? You have a lot of company.

The other side of the argument I believe has a lot of money.

https://www.anthropic.com/research/mapping-mind-language-mod...

https://research.google/blog/patchscopes-a-unifying-framewor...

Some apps want it to be deterministic.

I'm surprised this question comes up so often.

It's mainly from the vector embedding camp, who rightfully observe that vector + keyword search gets you to 70-80% on evals. What is all this hype about graphs for the last 20-30%?

I wonder why no one has claimed it. It's possible to compress large graphs to 1 byte per edge via Graph reordering techniques. So a trillion scale graph becomes 1TB, which can fit into high end machines.

Obviously it won't handle high write rates and mutations well. But with Apache Arrow based compression, it's certainly possible to handle read-only and read-mostly graphs.

Also the single machine constraint feels artificial. For any columnar database written in the last 5 years, implementing object store support is tablestakes.

It's possible to run cypher against duckdb (soon postgres as well via duckdb's postgres extension) without having to import anything. That's a game changer when everything is in the same process.

Author of ArcadeDB critiques many nominally open source licenses here:

https://www.linkedin.com/posts/garulli_why-arcadedb-will-nev...

What is a graph database is also relevant:

  - Does it need index free adjacency?
  - Does it need to implement compressed sparse rows?
  - Does it need to implement ACID?
  - Does translating Cypher to SQL count as a graph database?

Full history here: https://www.linkedin.com/pulse/brief-history-graphs-facebook...