I've been working on some parts of this problem, specifically capturing and retaining other semantically useful layers of the systems we build as we build and maintain them.
By introducing progressive semantically enriching layers (starting with prose, reasoning and terminology and going all the way into specifying interaction surfaces), we can reduce the dark matter between spec and code, make code more disposable – if your semantics live in the spec layer rather than the implementation, you can throw away and regenerate the implementation without losing understanding – and, critically, give LLMs a way to navigate a graph of knowledge instead of gobbling up walls of text.
This document describes the conceptual architecture of our company workspace - a text-based, version-controlled knowledge and operations hub designed to replace tools like Notion and Webflow while being natively accessible to AI assistants.
As an international founder, I'd like the section 174 to be fully restored as it was before – not just for domestic R&D but offshore one as well, so we're not hit with 15 years deprecitation (it is as good as "infinity")
Current image builds are to be phased out soon(ish). They were a way to get something into people's hands. And yes, plrust/rust are definitely space hogs :)
I've been a user since the early days and loved the immediacy of responses to all our issues. Issues were fixed nearly instantaneously. It's very impressive.
Omnigres | Founding Engineer | SF Bay Area HQ | REMOTE
At Omnigres, our north star is to enable developers to laser-focus on business needs instead of fighting technological challenges.
We're fighting the complexity and inefficiencies of contemporary stacks by removing them instead of hiding them.
At the core, we are turning Postgres into an Application Runtime. Why? Because we believe that code and data are inseparable in pretty much all of the line-of-business application systems. Turns out, when done this way, applications work a lot faster, require a lot less maintenance and are simply easier to write.
We're backed by some great early-stage VCs and looking to onboard people who can move quickly, learn on the go and maintain the focus on the goals. Another way to look at it: we want to meet other pragmatic idealists.
It does not have any UI yet. Something we haven't thought much about yet. Technically, feasible, just need to have a good story to drive a good experience there.
Currently, we have an early version of `omni_schema` [1] that allows traditional incremental migrations and in-place migration of certain objects.
However, we're not quite satisfied with this and working on a more sophisticated system that would allow us to derive incremental changes where possible, lint schema, load application code with the right dependencies on types and other functions where necessary.
We are working on first-class support for Python indeed (and other languages like JavaScript)
An important thing here is that we see Omnigres as a polyglot runtime with a database inside (Postgres) and we want people to use languages they prefer.
By introducing progressive semantically enriching layers (starting with prose, reasoning and terminology and going all the way into specifying interaction surfaces), we can reduce the dark matter between spec and code, make code more disposable – if your semantics live in the spec layer rather than the implementation, you can throw away and regenerate the implementation without losing understanding – and, critically, give LLMs a way to navigate a graph of knowledge instead of gobbling up walls of text.
https://clayers.com -- https://github.com/CognitiveLayers/clayers