What IDE are you using for Zig development?

Help
1

My JetBrains OSS development license was not renewed :joy:

This gave me the oppotrunity to ask what IDE are you using for Zig development.

As far as I understand, main candidates are

  • VS Code
  • Zed

What do you recommend?

2

nano and grep
zig is that simple

3 Likes
3

I use Helix because itā€™s reliable to build from source, very very fast, and everything just works. The config uses TOML which is my preferred scheme. The doc is really well made. Also the Helix Nucleo crate is ridiculously fast for fuzzy finding things in a project. It also has the best implementation of multi-cursor that exist. Itā€™s the perfect middle ground between the ease of use of VScode and the power of a fully tailored Vim config without the slowness of the former and the headache of the latter, and I try to learn Zed on the side, because it seem like the only fast IDE.

8 Likes
4

Neovim works great too

10 Likes
5

Just bash and vim, but Iā€™d like to explore ZLS for autocompletions.
As here:

3 Likes
6

I would use the following criteria for selecting the editor:

  • Can the editor select enclosing syntax node (syntax-aware selection). Zedā€™s quite good here, ZLS is a hit and miss.
  • Can it find a specific function/type in a currently opened file by fuzzy name (typing TI to look for const TableImmutable = struct)? Zed and anything with ZLS should do the trick here
  • Can it find a type/function by fuzzy name project wide? Neither Zed, nor ZLS do this, and this is really bad. This is a relatively simple feature, but a very useful one!
  • If the editor canā€™t do that, than it should be able to do project-wide searches presenting navigable results in a single buffer. Zed does this with multi buffer, VS Code with search editors.
  • Can the editor do goto definition (zls is surprisingly good here)?
  • (if I am collaborating with other) does the editor have magit? This honestly narrows the scope down to Emacs & VS Code :stuck_out_tongue:
4 Likes
7

Emacs with eglot for ZLS and zig-mode.
(and yeah magit is really good)

6 Likes
8

Iā€™ve been playing around with Helix and itā€™s a good option if you want something that ā€œjust worksā€ and you like modal editing.

With that said Iā€™m a happy emacser.

4 Likes
9

Yep thatā€™s my experience with it, I was never able to figure how to configure VScode properly to work with C/C++. Too many json files, and weird hoops you have to go through. Iā€™ve tried many times to learn it because everyone use it, but I just canā€™t figure it out. So iā€™m stuck in Helix and it just works

10

Zed. Works great with the Zig extension.

1 Like
11

Sine LSP became a widespread standard, I donā€™t think editor choice matters much anymore.

So just choose (n)vim

12

and compared to vscode?

13

Sublime Text 4 + ZLS here. Works like a charm.

3 Likes
14

Faster than VSCode. Much faster. There is no Electron in sight.

It also has vim bindings built in, and I am yet to find a motion that I regularly use that doesnā€™t work.

EDIT: The barrier to entry is very low. Give it a go and Iā€™ll be surprised if youā€™re not impressed with it.

1 Like
15

I use Flow Control of course. It works out of the box with Zig (and 56 other languages) and requires zero config to get running (besides installing your LSP of choice and a good terminal).

As a bonus, itā€™s written entirely in Zig, so if it doesnā€™t do something I need I get to write more Zig to add it.

(Yes, I wrote flow and this is a shameless plug! But it is literally my only IDE for writting Zig.)

14 Likes
16

You inspired me to add expand/shrink selection commands based on the tree-sitter AST to flow. Very useful! Thanks!

I also added select next/previous sibling node commands.

6 Likes
17

My choice of ā€œIDEā€: neovim

1 Like
18

:thinking: can I nerd-snipe you to do

Can it find a type/function by fuzzy name project wide?

This shouldnā€™t be too hard, and is quite cute! Thatā€™s what you need to do:

  • A function that takes a file, parses it into tree sitter tree, and extracts set of symbols and meta information about the symbol (so, string, line/column, flag for pub, enum(u8) for kind (function, constant, struct, etc))

  • Some infra to discover all .zig files in project and run the above processing for all of them, in parallel

  • A function that, for each file, converts the set of strings to an FSM (an optionally compressed trie)

  • A lookup function that takes two state machines and builds their ā€œintersection state machineā€, an FSM containing strings which belong to both input state machines. This is how you do fuzzy search ā€” the trie from the previous step holds all the strings you have, a fuzzy query can be thought of as a subsequence state machine, and the intersection of the two is the query result.

  • Secret Sauce: an incremental update procedure which, when a single file changes, doesnā€™t re-build the entire index, and only re-builds the state machine for this specific file.

    In general, because this stuff is trivial to make both parallel & incremental, it can feel very, very fast. It kills me that VS Code has an artificial debouncing delay between when you type the first letter of the query, and when the results are returned. It would be stupid to not get first dozen results in under 8 milliseconds!

  • File watcher to kick the above when appropriate

  • Some glue code to take userā€™s input and thread it through all FSMs, appropriately waiting for FSMs to get built!

The implementation original implementation in rust-analyzer, which took advantage of the existing fsm crate, was about 200 lines of code!

EDIT: opened an issue: Global, incremental, syntax based, fuzzy index of all types/function in the project Ā· Issue #73 Ā· neurocyte/flow Ā· GitHub!

2 Likes
19

I use vim because it doesnā€™t break my workflow when I change the language. Itā€™s also handy when making large patches such as branches with 10,000+ lines modified.

I think all that stuff can be done based on AST alone. I mean, thatā€™s pretty similar to what autodocs search already does. I use that often while editing.

3 Likes
20

Precisely! Project wide fuzzy symbol search is one of the more valuable IDE features because it is incredibly robust ā€” you build might be completely borked, you might not have your compiler available, half of the files might have missing braces and semicolons, but the search would just work, because it only needs syntax, and parsing can be made robust.

Though, at this point, Iā€™d probably reach out for tree sitter, rather than std.zig.Ast. I havenā€™t looked at it too closely, but it seems that the parser in std is only somewhat robust, and thereā€™s still a lot of cases where it fails to produce a reasonable tree. Tree sitter feels like it is more robust. To be clear, low confidence here ā€” this is based mostly off ā€œextend selectionā€ functionality breaking often in VS Code and being robust in Zed.

For the curious, Iā€™ve wrote a tutorial on resilient parsing here: Resilient LL Parsing Tutorial

5 Likes