Hacker News new | past | comments | ask | show | jobs | submit login

I’m trying to map relational algebra onto Rust’s type system. If I’m successful, I’ll have a bunch of collection types with different performance characteristics that are all drop-in replacements for each other.




I'm in the same boat: https://github.com/Tablam/TablaM, only that also building a lang (wish to revive the spirit of the dbase/fox family langs).

I have experimented with varied stuff, including columnar, so I think we can help each other!


Our two projects actually look like they have very different goals and approaches: I’m aiming for a rigorous solution for small design problems, like needing to add an index to a datastructure that wasn’t designed for one— nothing really to do with databases proper. I need the overhead for these simple cases to be low, so I’m trying to do as much as I can at compile-time inside the type system.

You’re doing everything at runtime (at least in Rust), which is a more flexible approach but can’t do things like trigger a compile error when attempting to access a field that isn’t present in a record.


> Our two projects actually look like they have very different goals and approaches

Surely! but learning that is pretty interesting and could help, also, I think that combining ideas/crates is what give more power to the rust ecosystem...

More to the point, I'm still thinking how/which data-structures to use, and how deal with the ability to provide SELECT/WHERE/etc across them (like a file)

> nothing really to do with databases proper

This is a big misunderstanding with the relational model: That is only for (r)dbms and storage.

I'm looking to apply it to regular programming. Is similar to apply OO or Array or Functional paradigm as your base for a lang.


Got a link?


Not right now; I haven’t set up a repository for it yet; I’ll certainly post it here when it’s ready to show.

I’m working from the bottom up and am almost ready to start working on collections— I started with newtypes to represent columns and then tried to get them to combine together properly.

As of today, I’ve got what looks like a good scheme to treat arbitrary objects as records, and can do joins, projections, and column renames with the type system keeping track of which objects have which columns.

The plan for tables/collections is to implement a sequential-scan interface backed by something simple, and then add wrapper write-through index objects to speed up particular query types.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: