Not a single mention of diet or food...

https://twitter.com/travelingenes/status/1773126285633507786

yes, I have plans to try adding some query helpers eventually.

One could imagine representing queries as compound terms, like: q(user(id=Id, name=like("Bob%"), email=Email))

which would query, from user table and bind Id and Email for all matches. I plan to experiment with something like that.

that is coming, once I get it a bit more developed... this isn't anywhere near usable for real yet

This is backwards. Rich did not advocate for changes that break promises.

The point in the talk is that "strengthening a promise" should not be a breaking change. Changing return type from "T or NULL" to always returning T. The case where you previously couldn't guarantee a result, but now you can.

The other case "relaxing a requirement" also should not be a problem. The case where you previously had to give me a value, but now I don't need it and can do my calculation without it.

TBH, I'm happy with that being a breaking change, too. Just keep returning a T? that happens to always have a value until the next major version # increment (or whatever), and then make the breaking change, and then I get a clear signal that I can delete some lines of code.

The alternative seems like a path that, in any decently complex software project, ultimately leads to an accumulation of useless cruft that'll probably continue to grow over time as people keep copy/pasting code that contained the now-useless null-handling logic.