Hi 0/, ZLS BDFL here. I imagine you’ve watched the talk Ryan linked above but here are my answers to some of the questions posed in this thread at this moment in time. :))
In short, our biggest enemy is time. We’re a team of 5 people who can only dedicate a small amount of time to ZLS per week as we have full-time jobs/university classes. It’s my hope that we can one day find a sustainable funding model to work more on ZLS (perhaps full-time!), and we’ve already begun paying one of our maintainers for his work (see zigtools - Open Collective), albeit significantly less than ideal.
Individual donators have been a huge help here, but it’s clear that companies will be our lifeline in this regard. My personal gameplan here is to wait for more companies using our Zig tooling to appear and hope they’ll fund us - this is already the case with Bun, TigerBeetle (hi matklad :P), and my employer Sourcegraph.
We’d be beyond excited if anyone would be interested in helping with development / donating (our GH Sponsors is most likely the best place for individuals) / finding sustainable, long-term sources of funding. Please feel free to reach out in the ZLS Discord Server found in our README. :))
Now to answer/respond to some questions/comments:
What is the current focus/direction of ZLS development?
There are a whole bunch of directions, which can be resumed as:
- Performance
- Stability
- Accuracy
These are incredibly broad goals that will take a long time to address. I’ve tried to do some PM-esque stuff at the request of other ZLS maintainers so we can get a timeline/project board of some sort going for a finer view of short-term/long-tern goals but that hasn’t gone well so far. 
Zig is advertised as a simple language. Shouldn’t it lead to a simple language server as well?
This is 100% true - most things in ZLS are rather simple and consistent because Zig is. Unfortunately, comptime and the build system exist, and though these are (relatively) simple and intuitive for a user, they’re an uphill battle for tooling.
Can I have a really slow ZLS that does thing in some unga bunga way, but will give me the correct type inferences, autocompletions and stuff?
I wish! ZLS is not designed to perform comptime resolution - it’s 100% AST based and performs no real type or semantic analysis (because of the aforementioned ease of the language). Everything we do is a guesstimate; if comptime didn’t exist, this guesstimation would make ZLS nearly perfectly accurate. I wrote ZLS this way in the first place because it was easier and I wanted a quick and easy way to help me navigate/complete Zig code for my own learning of the language.
Thankfully, we’re no longer at the “adding 100% correct comptime interpretation would require a massive amount of monthslong work” phase but rather at the “adding 100% correct comptime interpretation is actively requiring a massive amount of monthslong work” thanks to Techatrix’s excellent techatrix/stage2-sema (this isn’t really talked about publicly much as it’s far from ready and Techatrix can only allocate a few hours here and there per week into this branch). Note that this is 100% independent of the compiler, which has its own (pretty length) pros and cons list.
Given that Zig is not itself stable, I think it’s reasonable to wait here. The bricks underlying great IDE support are being laid — compiler now has server mode, there’s work underway to parallelize semantic analysis
Indeed; we’re exploring this along with our own avenues to land comptime support in a way that works for us. See Move Zir, InternPool, AstGen to `std.zig` by SuperAuguste · Pull Request #18127 · ziglang/zig · GitHub for the next steps on the compiler side of things.
I’m also working on mocking/implementing some changes to the build system for compiler server multiplexing which would incidentally resolve all our current problems with the build system. :))
Happy to discuss/answer anything else!