Fellow Uber engineer here (though we missed each other by a few years). I just came across your project on Twitter
I found your visual programming environment super interesting and inspiring
In a moment, I had already dreamed up the possibility of using something like Birch to develop whole ecosystems of microservices
In particular, I would be interested in leveraging this sort of visual environment so that the entire programming experience is ‘elevated’ beyond and away from traditional source files, directories, local environments, dependencies, CI/CD, metrics, debugging, profiling, etc.
Birch is an IDE – a next-gen one. It integrates with Git. It is collaborative. It is not file-based; rather, it is more like a code database. It is connected to the production environment and leverages it for live information.
Programmers implement business logic by writing small, single-responsibility units of code. These Units depend on other units, forming a tree (not graph). Groups of units are grouped into modules/packages for organization. Birch then helps the programmer visualize and understand the dependency tree. E.g. it will be visually clear when the tree has accidentally turned into a graph, or when an undesired dependency across modules is introduced (e.g. layered architectures).
Aided with static program information, Birch can visualize all sorts of relations from the code:
- Only types, which helps the programmer understand the ‘model’ they are programming with.
- Per-endpoint, showing the complete flow of a request.
Birch instruments Units with metrics/tracing/profiling and is capable of showing results live from the production environment.
Units can be hot-swapped. Birch implements canary+gradual deployment strategies for per-Unit/Module deployment. Together with the above instrumentation, a programmer is able to e.g. derive empirical data about a particular optimization directly from the production environment.
Far-fetched: support for polyglot development. A Service is composed of multiple Modules, each of which may be programmed in a different language. Depending on each language pair’s interop boundaries, cross-Module communication happens over a regular ABI call convention, or over shared memory, or sockets, or anything else. Regardless, Birch provides auto-codegen’d, idiomatic APIs for each Module-Language pair. OR: something like GraalVM could be used.
I don’t know, perhaps my ignorance on the visual programming space is showing – it’s certainly possible that most things I’m thinking of have already been tried somewhere
Now that I think about, this is somewhat related to the Unison language.
Anyway, of course all of this requires an insane amount of work. Still, it’s been fun to dream it up!