18 blog posts and very limited mention of NUMA and HT?

https://adsharma.github.io/more-performance-hints/

Cypher tries to solve problems closer to storage.

GraphQL was designed to add types and remote data fetching abstractions to a large existing PHP server side code base. Cypher is designed to work closer to storage, although there are many implementations that run cypher on top of anything ("table functions" in ladybug).

Neo4j's implementation of cypher didn't emphasize types. You had a relatively schemaless design that made it easy to get started. But Kuzu/Ladybug implementation of cypher is closer to DuckDB SQL.

They both have their places in computing as long as we have terminology that's clear and unambiguous.

Look at the number of comments in this story that refer to GraphQL as GQL (which is a ISO standard).

Got it. I didn't realize. Checking out the docs, looks like GQL is based on Cypher. So in the thread people were talking about it, just calling it GQL as the common name, not Cypher as the original name and I missed it.

GQL-SQL - for queries.

GraphQL, more for REST??

GQL is related to Cypher, but not a common name for Cypher.

https://www.tigergraph.com/glossary/cypher-query-language/ https://www.tigergraph.com/blog/the-rise-of-gql-a-new-iso-st...

Has some history behind it.

Syntax and some queries:

https://github.com/opengql/grammar/tree/main/samples

Full specification costs you about $270

Opensource Embedded Columnar Graph Database: https://github.com/LadybugDB/ladybug

Store your graphs in Parquet files on object storage or DuckDB files and query them using strongly typed Cypher. Advanced factorized join algorithms (details in a VLDB 2023 paper when it was called Kuzu).

Looking to serve externalized knowledge with small language models using this infra. Watch Andrej Karpathy's Cognitive Core podcasts more details.

It's interesting to see people use the term "GQL" to refer to GraphQL.

https://www.gqlstandards.org/ is an ISO standard. The Graph Database people don't love search engine results when they're looking for something.

I maintain a graph database where support for GQL often comes up.

https://github.com/LadybugDB/ladybug/issues/6

For every person trying to move an old code base from COBOL to Java to remove tech debt, there are an equal number of people who want rewrite a working C++ code base in Rust/Go/Zig.

Leaders who know that it's a people problem and who have read the Jerry Weinberg book know both sides of the problem.

We need a new word for a universal transpiler. Something that can transpile to 7 or more languages.

Poly-transpiler? It will also trigger more people.

See my other comment in the thread. I would argue that anything that uses arcane dynamic stuff in python should be renamed to .dpy and the vast majority of the commonly used constructs retain .py

The issue in HN threads like this is that everyone is out to promote their own favorite language or their favorite python framework that uses dynamic stuff. The majoritarian and hacker-ethos of python don't always line up.

Like Chris Lattner was saying on a recent podcast, he wrote much of Swift at home on nights/weekends over 18 months. We need someone like that do this for spy.

++spy ethos and ideas

But why limit to an interpreter? Translate to other excellent compiled languages and benefit from the optimization work there.

Giving up on C-API and the dynamic parts of python that 1% of the people use is a good trade-off.

In the age of cursor and windsurf it's not hard to auto replace incompatible code with something that works in the static-py ecosystem.

Would love to participate in an effort to standardize such a subset.

I'd imagine a lot of packages that you may want to use make deep use of some of these obscure features. So much magical "it just works" of Django is surely various kinds of deep introspection.

Not sure an AI can fix it yet. It's not just adding type annotations.

The position I take is that such obscure code in the guts of a popular package could be slowing down large amounts of deployed code elsewhere. If such code must exist, it should be marked as special (like how Cython does it).

Beyond adding type annotations, there are other important problems to solve when translating python to rust (the most popular path in py2many so far).

  * Translating inheritance -> traits
  * Translating exceptions -> Result<T>
  * Handling incompatible pattern matching

This is why I've urged FastAPI and pydantic maintainers to give up on BaseModel and use fquery.pydantic/fquery.sqlmodel decorators. They translate much better.

There is a compiler detailed in the page on the link;

> 3. We have a compiler for deployment and performance. The interpreter and the compiler are guaranteed to produce the exact same results at runtime.

Where is it? Would love to compare the approach to py2many.

Py2many would fail to compile dynamic code whereas spy runs it through the interpreter.

Otherwise the internal structure looks similar. Py2many has been around for 10+ years under previous names and has significant test coverage.

One of the problems with Ceph is that it doesn't operate at the highest possible throughput or the lowest possible latency point.

DAOS seemed promising a couple of years ago. But in terms of popularity it seems to be stuck. No Ubuntu packages, no wide spread deployment, Optane got killed.

Yet the NVMe + metadata approach seemed promising.

Would love to see more databases fork it to do what you need from it.

Or if folks have looked at it and decided not to do it, an analysis of why would be super interesting.