Why does Typst implements its own incremental computation (comemo) instead of using salsa?

[marcelroed]

Hi! I’ve been using Typst a bit and am enjoying it a lot! I’m also closely following some Rust packages being developed for the Python ecosystem, and noticed some traction around a new framework for incremental computation in Rust through the Salsa crate, which is the incremental computation backend for the insanely fast upcoming ty type checker for Python.

I’m wondering: might this simplify some of the incremental compilation implementation in the Typst backend? I’m not familiar with the source for Typst, but it seems to me like this would be a good fit and potentially further speed up compilation.

Thanks for the solid work!

[quachpas]

Typst uses its own implementation comemo, which actually implements the same concept more or less.

As for why re-implementing, and not using salsa, I can only quote the Typst developers

@larmaedje

I had looked at salsa before building comemo, but ultimately didn’t feel like it would work well for Typst. But they are ultimately at the same level of abstraction, so we are already more or less doing what they do.
[…]
The closest alternative is salsa, but it dictates the program’s structure a lot more.
[…]
It’s just a different design. It is more advanced in some aspects, but also more rigid in others.

The topic is recurring on Discord, because salsa does implement things that comemo doesn’t, or in different ways.

Ultimately, I think it would make the incremental compilation implementation more complicated than it is currently. Notably, you would need to spend a lot of time refactoring.