Comment by jesse__ | Hacker News Reader

Comment by jesse__ | Hacker News Reader

Parent Full thread

1. Choosing a shitty architecture to absorb the downside of low quality tools seems like a bad decision, but I guess that's just where the industry's at right now.

2. AFAIK Go can both compile and load DLLs now. A language that doesn't have native compilation facilities (Java, JS, python, etc) would have to have extra tooling that loads the runtime and program from a DLL. A quick google search tells me Java has this tooling already. I'm sure other languages would too.

3 a,b. See point 1.

4. Yeah, that's fair, although I'd probably still rather have a single process.

6. Also a good point. Might be a useful paradigm for large codebases. Although at that point the usage pattern is so different that the calculus for choosing the architecture is different, and I stand by my choice. Google can afford to build fancy shit for themselves.

first of all I want to say that I have a lot fun talking to you! Honestly I would also prefer dll based approach, if you really want to see the limits of the architecture of Lsp I recommend you to read the discussion about adding syntax highlighting to the protocol, but I see why the people behind LSP did what they did.

One final point!

I think there is a difference between absorbing low quality tools and absorbing low quality code. I think that it makes a lot of sense for a plugin system to design for low quality plugins. I have two examples from my job, the first is a micro services based parsing infrastructure, where each team is responsible with parsing it's own formats, which are oftentimes layered apon formats parsed by different teams. I believe this takes about 10x-100x more resources than it should, but it has the benefit that a rouge parser can't takes everything down with it. The second example is internal scripting capability of a different system where a lot of work was done to make sure the script can't do anything stupid.

In both of those cases the system is designed for low quality code because it is more cost effective to make sure code can be low quality without affecting the overall system, than to make sure low quality code doesn't exists.

Reply on news.ycombinator.com