|
|
|
|
|
|
by binary132
708 days ago
|
|
|
I’m not sure there is really more to say here. A lot of people don’t seem to like strong type systems very much either, but that doesn’t mean they’re not wrong. ;) That said, it clearly has some interesting ideas! I’m just not sure I understand why the database needs to be the compiler. It seems like an awful lot of design decisions baked into the stack instead of offered as APIs or protocols. And it’s obvious that we can consider the filesystem itself to be a sort of database — Git famously is implemented entirely in filesystem semantics, for example, so it’s also not clear to me why this content addressing can’t simply be done in a cache dir, or some such, the way many build systems do for their compilation units. |
|
|
I'm sure that there can be some very interesting discussions about code-in-database and interop with tooling!
> I’m just not sure I understand why the database needs to be the compiler.
I'm not entirely sure if these two are tightly bound. For example `ucm` uses a SQLite database, but Share(their Github equivalent) uses PostgreSQL afaik.
I believe a previous iteration used Git as the backing store but they didn't go through with it. I'm not sure about this tho.