Tracking Issue: Priorities of Real World Zig Users

[andrewrk]

This issue is a reminder to go look at Third Party Tracking Issues (what is important to other people?) and browse through third party tracking issues to learn what things are affecting real world users of Zig. That link is on the Zig wiki and is freely editable. Please feel free to add your projects to the list there and share your troubles.

---

Additionally, I will list some actionable issues that are already in the Zig issue tracker:

• Get pacman.zig on the Package Manager #16711
• Get Ghostty on the Zig Package Manager #16672

[jcollie]

There needs to be more examples in the documentation, especially in the standard library reference. Sure, there's lots of Zig code out there to look at, but it's typically in larger Zig projects and those can be hard to digest, especially for someone new to the language.

[He-Pin]

Can we use it with Clion？

[xdBronch]

Can we use it with Clion？

you can with zigbrains but note that its still just using zls behind the scenes, theres not yet a fully custom plugin built for jetbrains.

[xdBronch]

There needs to be more examples in the documentation, especially in the standard library reference

there is quite a large number of stdlib examples in the form of tests but theyre hard to find and arent presented very well. i think this will be largely improved once doctests are utilized more, you can see what they look like a lot in parts of std.json at the bottom of the page.

[Jarred-Sumner]

Added one for Bun - oven-sh/bun#5611

[godalming123]

1. Please improve compilation speed
2. Add a guide in the docs for converting c code into zig code I wanted to convert a medium sized c project using meson to zig and found that:
   • I did not know how to convert c #ifdef statements into zig, I also needed to know how to define these in a zig build file (previously if a dependency was met the meson.build would define HAVE_XYZ which would enable an extra feature that requires the dependency in the code if this was the case)
   • The guide should include how to take your zig build file that you've created by hand and run a command to see what options you should pass to translate-c to get everything to work
3. Hot code reloading, this is a really cool feature, but only becomes valuable if number 1 is implemented. It would also have to work with c libraries that are being used

[xdBronch]

(1) is well on its way, the x86 backend is nearly ready for use and it alone can give a ~5x compilation speedup compared to the llvm backend. there is also work being done to add incremental compilation which i imagine will be an even bigger improvement along with some other things.
(2) is likely something that will just have to be done by the community at some point, not all ideas translate 1-1 and the core team is busy working on the compiler, not documentation.
(3) is also a WIP, there have even been a couple proof-of-concepts of it

[expikr]

https://github.com/gabdube/native-windows-gui/

A project like this for Zig would be great, the thinnest possible wrapper over winapi syscalls merely to make it idiomatic for Zig.

[jcollie]

https://github.com/gabdube/native-windows-gui/

A project like this for Zig would be great, the thinnest possible wrapper over winapi syscalls merely to make it idiomatic for Zig.

Check out zigwin32:

https://github.com/marlersoft/zigwin32
https://www.youtube.com/watch?v=HsnWZxrf5VE

[expikr]

Check out zigwin32:

https://github.com/marlersoft/zigwin32 https://www.youtube.com/watch?v=HsnWZxrf5VE

That's autogenerated though, not quite "adapting it to be idiomatic zig", and much larger in scope than making just the GUI subset zigernomic to use.

Whereas only focusing on the native Windows controls consists of just the following elements and their respective styles/messages/notifications:

const WC_ANIMATE = "SysAnimate32";
const WC_BUTTON = "Button";
const WC_COMBOBOX = "ComboBox";
const WC_COMBOBOXEX = "ComboBoxEx32";
const WC_DATETIMEPICK = "SysDateTimePick32";
const WC_EDIT = "Edit";
const WC_HEADER = "SysHeader32";
const WC_HOTKEY = "msctls_hotkey32";
const WC_IPADDRESS = "SysIPAddress32";       // obscure
const WC_LINK = "SysLink";
const WC_LISTBOX = "ListBox";
const WC_LISTVIEW = "SysListView32";
const WC_MONTHCAL = "SysMonthCal32";
const WC_NATIVEFONTCTL = "NativeFontCtl";
const WC_PAGESCROLLER = "SysPager";          // obscure
const WC_PROGRESS = "msctls_progress32";
const WC_REBAR = "ReBarWindow32";            // obscure
const WC_SCROLLBAR = "ScrollBar";
const WC_STATIC = "Static";
const WC_STATUSBAR = "msctls_statusbar32";
const WC_TABCONTROL = "SysTabControl32";
const WC_TOOLBAR = "ToolbarWindow32";
const WC_TOOLTIPS = "tooltips_class32";
const WC_TRACKBAR = "msctls_trackbar32";
const WC_TREEVIEW = "SysTreeView32";
const WC_UPDOWN = "msctls_updown32";

[nullptr-deref]

I agree with @jcollie and also wish there was much more detailed standard library documentation.
Also, the overall build process isn't that transparent and there're loads of functionality lacking any detailed description.

[sergeypdev]

Hey, sorry if this is the wrong place to ask about this, feel free to ignore if it's out of place.

It would be nice to have a feature in Zig PM to use a subfolder of a tarball/git repo as the dependency root.

Main use case: depend on a subproject inside of a monorepo. For example: https://github.com/zig-gamedev/zig-gamedev

Right now to depend on a project from a monorepo like this, the maintainer has to figure out how to publish each package separately. That can be done using github releases and some automation, but if were to be solved on the Zig side it would ease adoption of third party code that's not necessarily well structured to be consumed by the package manager.

[HTGAzureX1212]

theres not yet a fully custom plugin built for jetbrains

@xdBronch Me and another developer are currently working on a full-blown IntelliJ-based IDE for Zig: https://github.com/ZigIDE/ZigZen.
While we do have some completion, documentation, project creation and syntax highlighting implemented, it is still at a development stage.

[JensvandeWiel]

theres not yet a fully custom plugin built for jetbrains

@xdBronch Me and another developer are currently working on a full-blown IntelliJ-based IDE for Zig: https://github.com/ZigIDE/ZigZen. While we do have some completion, documentation, project creation and syntax highlighting implemented, it is still at a development stage.

This is cool though i must say zigbrains has come far since then and is quite useable

[justin330]

To add to @jcollie has suggested, docs should include the command line equivalent of steps in the build file.
Creating modules for example:

	const module = b.createModule(.{
		.source_file = .{ .path = "src/core.zig"},
		.dependencies = &.{},
	});
	...
	exe.addModule("core", module);

Is equivalent to:

	zig run --deps "core" --mod core::"src/core.zig" ...

[ben-laird]

I have two main improvements I'd like to see when working with Zig:

1. More precise standard library panics. Something like error: Unexpected when building can be very confusing, especially for a low-level language still in development that uses a cache for compilation: is the problem in the language, in my code, or in the cache? What even is the problem?
2. More emphasis on C/C++ interop. I've primarily used Zig as a C/C++ compiler for my undergrad C++ course, and I had to look up many guides to do so.

Zig as a language has been very beginner-friendly; Zig has given me arguably the smoothest introduction to low-level development out of all the languages I've tried. That said, I agree with others in this issue who would like a cookbook of sorts for common patterns or didactic examples in Zig. Very happy v0.12 is released, and very excited for the compiler work in v0.13!

[rektide]

WASI Preview 2 support and Component Model support would be huge for me, allowing me to introduce Zig into existing projects & environments. Being able to interoperate with other webassembly works would in general open a lot of doors.

Going to cite #19581 as a recent issue that helped clarify that Zig right now targets WASI Preview 1, and which briefly discusses Preview 2. Also work on updating wasi-libc!

[jedisct1]

WASI Preview 2 support and Component Model support would be huge for me, allowing me to introduce Zig into existing projects & environments. Being able to interoperate with other webassembly works would in general open a lot of doors.

Going to cite #19581 as a recent issue that helped clarify that Zig right now targets WASI Preview 1, and which briefly discusses Preview 2. Also work on updating wasi-libc!

Zig can already interoperate with other languages targeting WebAssembly. Libraries created by Zig can be linked by anything using LLVM. For example rust-aes-wasm is a Rust library for WebAssembly, but actual implementations are written in Zig.
The wasm-merge tool included in binaryen also works very well to merge multiple wasm modules into one, regardless of the language they have been written in.

[Torphedo]

My main problems with Zig have been C interop and the build system. Writing build scripts in Zig seems kind of insane, and there's not much information provided or a template build script to start with. Writing a Zig build script for my C project took 4+ hours of looking through documentation, which was especially confusing as someone new to the language & struct syntax. I would really prefer a simple method to add source files to a target with strings like "src/*.c", instead of having to figure out how to walk a directory in a low-level language just to compile my code. I think there's a better middle ground between a config-based build system and having the entire thing driven by Zig code. Also, it's very confusing having 2 nested structs just to add a filepath to the list of sources:

const lazy_path = std.build.LazyPath.relative(path);
target.*.addCSourceFile(.{ .file = lazy_path, .flags = &.{} });

// Why couldn't we just use a []const u8? Then maybe another flag to indicate relative/absolute?
target.*.addCSourceFile(path, build.PathType.Relative);

The equivalent CMake file is half the length (mostly just listing files) and would take an hour at most without knowing anything about CMake.

As for C interop, it's been a while but I found it really difficult to call Zig from C code. Calling C from Zig was fine, but when I tried to rewrite a few C utility files in Zig, it was a nightmare. Maybe this has been fixed since last year, but as far as I could tell the export keyword just didn't work (my C objects couldn't link to it).

[andrewrk]

@Torphedo I see that you're quite young, so I'll give you some pointers: this kind of feedback is neither interesting nor valuable because it contains generalized opinions that are not actionable. For example,

Writing build scripts in Zig seems kind of insane

This sentence has no substance. It does not actually point out any problems, and is in poor taste since most people who have tried it have reached a different conclusion than you.

there's not much information provided or a template build script to start with.

Factually incorrect, please see zig init.

I would really prefer a simple method to add source files to a target with strings like "src/*.c", instead of having to figure out how to walk a directory in a low-level language just to compile my code.

This is an example of actionable feedback. More of your comment should be like this.

As for C interop, it's been a while but I found it really difficult to call Zig from C code. Calling C from Zig was fine, but when I tried to rewrite a few C utility files in Zig, it was a nightmare.

This statement does not belong on a bug tracker. It needs to show a code example, and explain what makes it difficult.

the export keyword just didn't work (my C objects couldn't link to it).

Please follow the bug report template for filing bugs. No assistance can be provided without steps to reproduce, expected behavior, and observed behavior. As a maintainer, it is frustrating when users say "doesn't work" without further details.

---

Overall, this is not really an issue intended for anyone to comment on. It's just for Zig contributors to follow the link at the top to the wiki. I'm not interested to read anything beyond my original post at the top.