I recently tried mojo and was surprised that it’s lsp and formatting is already way better than zig lsp. Don’t know if they just extended an existing python lsp with mojo syntax, but that’s not important. Im curious why is zig lsp so bad, is it the problem with the language so it just can’t make good suggestions because of zigs comptime and type system. But then why is rust analyzer so good at rust macros? Is it just the lack of development funding and interest? I don’t want to sound rude but I’m just curious what are the problems with zigs lsp.
1 Like
If you’re looking for something official, the issue to track a compiler server is here:
Why is it not done yet? Because I’ve been prioritizing other things, and so have the other core team members.
I can’t speak for the zigtools/zls project, assuming that’s what you’re referring to.
4 Likes
For ZLS, check out this response from last year (and the whole thread).
2 Likes
I don’t want to deny your opinion, but I’m curious about what you think is so bad about zls ? Because from my experience, it’s been working quite well for me, It take some getting used to for sure, because for example it can fail to provide autocomplete when you reference something that doesn’t compile or exist. but when you learn to recognize the patterns I think it’s ok. It does provide the most useful features really well, like goto definition, rename, and stuff. Maybe there are some part that I don’t see, but so far it’s been pretty helpful so I wonder what are the things that you think are lacking ?
9 Likes
(I am the original author of rust-analyzer)
The economic answer here is that mojo has approximately infinity-$, relative to your average upstart programming language. For Rust, first JetBrains paid for couple man-years worth of work to make IntelliJ Rust (out of income generated by previous successes in the IDE market), which proved that there’s enough demand here, then I’ve spent a year burning those savings to start rust-analyzer, to prove that you can do a similar kind of thing without IntelliJ, than Ferrous Systems funded couple of more years of development (out of concurrent work-for-hire to do various embedded things), and after that the thing finally became able to generate enough support through donations and what not.
Building a good LSP is just costly, in terms of work. It actually isn’t prohibitive, in the grand scheme of things, but is certainly much larger than a weekend hack!
Another economic angle here is for someone else to invest paid hours into Zig dev tooling, they need to predict that Zig will have a lot of users of such tooling in the future. And I think a reasonable person looking at the landscape of programming languages today would not predict Zig capturing a large fraction of all the programmers (I explicitly not giving my own prediction here 
).
On the other hand, Zig toolchain is very smartly engineered, and it is the exceptional case where I actually do believe (at 0.7-ish) that it would be possible to incrementally evolve from the existing compiler to robust&snappy&featureful LSP. Zig might not actually need that large amount of work on top of what’s already happening with the compiler.
All that being said, ZLS works surprisingly well. I would have predicted it to be much worse, it definitely exceeds my expectations, major kudos to the team.
And, uhm, I don’t usually like to obnoxiously plug my stuff, but there’s a coincidence here! On Thursdays, at 17:00 UTC I stream TigerBeetle stuff on Twitch, but today is a Christmas Special episode — dev tooling. So, if anyone curious to hear more anecdotes about LSP-development, feel free to pop in the chat in about five hours!
EDIT: sorry, too many coincidences today, had to skip this one 
Will do in a week for sure!
And let me re-iterate on kudos to the ZLS team — I used the tool daily, and it is excellent at what it does, at least in my usage pattern <3
23 Likes
I think zls is pretty darn good for what it is considering it’s a third-party tool for a language with a fairly small community. It’s not as good as clangd, but that’s an lsp for a massive community that also requires some setup if you want it to work correctly. I’m fairly confident that if zig had a community the size of C and C++ the zls would be as good as clangd.
1 Like
I don’t want to deny your opinion, but I’m curious about what you think is so bad about zls ?
At least when used with VSCode, the default settings do not discover almost any build errors while typing code in the editor. (I recently asked about this here: How to get more out of Zig ZLS with VSCode? and the fix is to use “zig build check” and configure the ZLS plugin to use that. Why this is not the default or otherwise emphasized in docs, I don’t know.)
I’ve recently also found that “autofixing” unused variables messes up and breaks my code quite often. (Although I’m in the camp that’d prefer not having to do this “fixing” to get my build to pass while editing code - esp. when debugging something.)
I find that things like go to symbol work pretty well. Some other things, like a lot of things involving comptime, tend to fall off the working path.
Symbol rename works reasonably well, although it seems to have issues when renaming struct fields. It’s not always able to rename all uses of that symbol in a single zig file.
Even with its faults, ZLS improves the Zig experience for me a lot, and I probably wouldn’t even code Zig if I didn’t have it.
4 Likes
I use LSP, it is excellent, but maybe not with all IDEs. I’ve noticed that some IDEs aren’t very smart. Personally, I use HELIX, and it is very efficient. I tried FLOW IDE with a lambda terminal, which is also very efficient, but it’s a shame that it requires KITTY and cannot be used with a VTE GTK emulator. Now, I admit that I work with nightly versions; I keep the previous stable version in case, but sometimes there are significant advancements in LSP. I maintain that it all depends on the IDE…
1 Like
I think you’re confusing IDEs, like Visual Studio and CLion, with text editors like vim, Helix, and vscode. The former are much more powerful software with many more features than a text editor, even if LSPs and other tools have blurred the lines in recent years.
I don’t confuse a studio with an IDE. For me, an IDE should strictly conform to text code work and provide good assistance. I don’t ask for anything else. I like it to be specialized in writing so that I can rely on it. Visual Studio, also known as Codium, is not always stable, yet I use it for markdown. Then there’s Eclipse, but again, that’s the heavy artillery…
There are others, like JetBrains, which are paid… It’s not the cost that bothers me, it’s that they try to do too many things and end up not fulfilling the main purpose for which I need to use them.
I don’t hesitate to make a donation when I find the work done is correct. I would like to do more, but… my condition doesn’t allow me to.
Bit of a loaded question you’re asking, and I am not trying to be rude. Really want to understand, what exactly is bad about ZLS? I like the ZLS more than the confusing zig compiler tracebacks ( can’t really complain about it, yet, pre - 1.0).
For example, I dislike all the pyton LSPs, because they’re almost useless at some point, in a larger project. You have dynamic typing, so good luck with that. If I get a warning from a python LSP, I’m gonna ignore it most of the time, but if I get one from ZLS, I probably, if not 100% of the time, will get a compile error as well.
( I should mention that I use nvim, but the LSP should be the same, although I’ve seen some weird stuff with vscode on yt heretics that use vscode ).
3 Likes