Agree with the analysis here! The way I see it, there are possible two grand architectures: * you either have a single, multi-language combine supporting any

Agree with the analysis here! The way I see it, there are possible two grand architectures: * you either have a single, multi-language combine supporting any language. In a sense, LLVM/GCC but for front-ends * or you have a bunch of independent servers The first is clearly less code — there’s a lot to share. The second is embarrassingly parallel though. So, if you are a (single-threaded company), you should go for the first approach. If you are a (multi-threaded) OSS community, the second approach has shorter critical path. Some second order effects: 1. While backands are more or less the same between languages and LLVM is a clear win, frontends tend to differ a lot. That’s the point of having different programming languages. So in practice sharing the code in IDE is harder. 2. An interesting benefit of separate process architecture is that it forces you to have async interface, which is important for responsive IDEs. But that’s an argument for separating back and front, not necessary for sharding back.