adsharma · HackerTrans

adsharma

508 karmajoined 10 jaar geleden

ladybugdb.com

Submissions

LadybugDB Flying Solo

blog.ladybugdb.com

1 pointsby adsharma24 dagen geleden1 comments

Show HN: Vpg – Pglite for Native Code

github.com

1 pointsby adsharma3 maanden geleden0 comments

Show HN: Py2many – Transpile Python3 to 7 languages

github.com

9 pointsby adsharma5 jaar geleden13 comments

Show HN: Language Agnostic IDL for Rust, Swift and Kotlin

adsharma.github.io

7 pointsby adsharma6 jaar geleden0 comments

comments

11 dagen geledendiscuss

Many recent graph databases are built like this. If you compare ladybugdb vs duckdb, the internals are very similar.

The main innovation is the "REL table". You can think of it as a many-to-many relationship table on steroids with optimizations at the storage layer and join algorithms.

Definition of what makes something a graph database (apart from the query language) is contested. But we seem to be moving towards: build a reasonable relational database and then add a "REL table" to it with join optimizations.

11 dagen geledendiscuss

Just use postgres (or another SQL db) ignores the following innovations:

* Columnar storage * Compressed Sparse Row on disk * Factorized joins * ASP joins, WCO Joins

Details: https://vldb.org/cidrdb/2023/kuzu-graph-database-management-...

11 dagen geledendiscuss

Recent benchmarking: https://theconsensus.dev/p/2026/05/29/ladybug-duckdb-and-pos...

Response: https://blog.ladybugdb.com/post/better-graph-database-ball/

11 dagen geledendiscuss

There are several MIT/Apache licensed embedded graph databases available, including the one linked from my profile.

13 dagen geledendiscuss

Just in case you find the earlier message too cryptic. It's not performing well on web search.

https://pypi.org/project/tsc-py/

13 dagen geledendiscuss

Need something for backward compatible RPC? Use protobuf. But for storage and types?

This is where I feel there are better alternatives. If you go with protobuf, you're picking 2 out of 3: simplicity, fast, idiomatic.

Please consider "uvx tsc-py --help" for things that don't fit.

24 dagen geledendiscuss

LadybugDB was forked from KuzuDB 8 months ago. Find out what's new and how it differs from KuzuDB in performance, features and market positioning.

27 dagen geledendiscuss

A more appropriate mirror test for LLMs is to get them to state facts about their training data. Percentage of arts vs science for example.

Given the framing that they're similar to nukes and a national security issue, it's likely that the models are post trained to not answer such questions accurately.

Also the article could be trying to normalize thinking that these are more than matrix multiplication gadgets good at compression.

vorige maanddiscuss

It's interesting that the blog post places SQLite and Ladybird on the spectrum, but omits it's chief open source rival: DuckDB.

Agree that Level 3 is what inspires confidence. But we need to invent new business models to sustain in the era of vibe-coded databases.

2 maanden geledendiscuss

DuckDB and LadybugDB use the same terminology to describe internals.

2 maanden geledendiscuss

The future is to write Rust in a python interpreter compatible way leveraging large parts of the python ecosystem.

This will require minor tweaks to the language and perhaps a forked interpreter (a forked parser already exists).

Then you solve the two language problem with a combination of probabilistic and deterministic translation.

2 maanden geledendiscuss

7 years of python -> rust here.

https://github.com/py2many/static-python-skill/blob/main/ass...

2 maanden geledendiscuss

Installing thing like this should be an agent skill, not a distribution.

2 maanden geledendiscuss

+1 - I was making exactly this argument in other threads. But I have a slightly different take on how software should be written.

Translating zig -> rust is more complex than writing a JPEG parser in static python and then lowering it into zig and rust differently using idiomatic construct for each language.

Towards that end, I've created a parser for a dialect of python which is suitable for this purpose. It should maintain compatibility with the vast majority of python code out there, while picking up some rust/zig features that make translation easier. JPEG parser included in the assets of the skill for a flavor.

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

https://github.com/py2many/spy-ast

3 maanden geledendiscuss

A SMT solver may work better.

3 maanden geledendiscuss

Experimenting with the pglite way, this time using vlang here:

https://github.com/adsharma/vpg

  v run cmd/vpg_test.v

4 maanden geledendiscuss

The first one. It's forked from pgserver.

Yes, what you get is a multi-server postgres under the covers. But for many users, the convenience of "uv pip install...", auto clean up via context manager is the higher order bit that takes them to SQLite.

Of course the bundled extensions are the key differentiator.

With enough distribution and market opportunities we (yes, there is a for profit company behind it) can invest in making it truly embedded.

4 maanden geledendiscuss

Pgserver is not maintained. Had to fork it as pgembed, compile recent versions and bundle BM25 and vector extensions.

4 maanden geledendiscuss

Pgembed is pglite for native code.

4 maanden geledendiscuss

This is why transpilers exist.

py2many can compile static python to mojo, apart from rust and golang.

Is it comprehensive? No. But it's deterministic. In the age of LLMs, with sufficient GPU you can either:

  * Get the LLM to enhance the transpiler to cover more of the language/stdlib
  * Accept the non-determinism for the hard cases

The way mojo solves it is by stuffing two languages into one. There are two ways to write a function for example.

I don't think the cost imposed by a transpiler is worse. In fact, it gets better over time. As the transpiler improves, you stop thinking about the generated code.