1
If such a thing exists or is possible, how would the performance be? I imagine the performance would be significantly degraded? Or could caching help mitigate this? If such a thing exists or could exist, how would the distinction be made between in-memory and persistent structures? For example:
A let a_xpto: i32 = 10; would place the value "10" in the memory region called "a_xpto". If it were persisted, it could be something like: ^let a_xpto: i32 = 10; which would place the binary value "10" in a key-value position with the key "a_xpto" where the "^" directive would indicate that the writing would be done in the database and not in memory.
Wouldn't such a language solve all the age-old problems we face at the interface between code and databases? I see that today we have numerous databases, each with a different purpose, a different interface, and communication between code/data structures in memory vs databases is always very painful. We're always left wondering: should we create this function in the database or in the code? How would the performance be? And if I have more than one type of database? How do I integrate them? Should I load everything into memory to filter? Or should I filter something in the database before processing further?
Additionally, we end up with that odd-looking code that passes strings to databases. Even when using an interface that "maps" the database to objects, it's still not great. It's always a pain to modify the database, for instance. If something like what I'm describing existed, it wouldn't matter which database was behind it. I know that Datomic does something in this direction: it abstracts a database, allowing you to easily swap out the underlying database type. However, it's still not quite what I'm talking about. What I'm describing goes beyond that: you would use the same data structures, objects, etc., that you're used to working with in your code, but in a persistent manner.
Can anyone shed some light on this?