This is very cool!

Hi Charles!

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.

For example:

  • 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.
    • etc
  • 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.

  • (and more)

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!

1 Like

Hello! Thank you so much for your thoughts and for trying out Birch!

There’s a lot here so I can give some responses / ideas inline below. I am just a single person working on this right now so a lot of this will have to be long-term dreams, but it’s always fun to think about what it could turn into!

Groups of units are grouped into modules/packages for organization.

This is also something I’ve been thinking about! I don’t think it’ll be prioritized anytime in the near future but it would be sweet. I think it would kind of be spaces having sub-spaces that work similar to folders in a file system.

Aided with static program information

Totally! This one is tough to implement but I 100% would like to have static types in Birch (very far) down the line.

showing the complete flow of a request

This is very similar to https://darklang.com/! I can see it being quite useful but I will try to expand on the infrastructure side of things before tackling something like that. In general, a debugger would be quite nice though.

Birch instruments Units with metrics/tracing/profiling and is capable of showing results live from the production environment.

Yeah I’ve been thinking about how visualizations and stuff would work. I think I’m likely to have an imperative-style reference to a value that can then be inserted into a space as a visual element. An image, say, or a graph. I don’t think I will add any incrementality to Birch at least for the time being: it’s easy enough to use timers to run something every second if people want to approximate that, and at least that keeps the pricing and the compute being used much more transparent.

Units can be hot-swapped

Why unit at a time? :wink: The current model is that any function is hot swapped the second you finish editing it. I would like to introduce some sort of version control so you can edit in a staging/testing environment sort of thing and then merge into production all-at-once when you’re done.

Far-fetched: support for polyglot development

Yeah I think I probably won’t do this anytime soon. I am myself very partial to using obscure languages but from a product point of view, it’s hard to justify the cost at the moment. If there was a good sandboxing environment for python I could imagine using that, but right now Deno has me covered quite well for Javascript.

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

I think a lot of what you’re thinking about is how visual programming intersects with a production environment: as far as I know there hasn’t been a whole lot of work there (maybe Dark again is the best example so far.) So yes exciting stuff!

Thanks again for sharing your ideas! I’m glad Birch can be such a source of inspiration :smiley: