←back to thread

Zig is hard but worth it

(ratfactor.com)
401 points signa11 | 3 comments | | HN request time: 0.425s | source
Show context
latch ◴[] No.36150665[source]
I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category.

Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack of package manager, etc. For an insider living and breathing Zig, not only aren't these huge challenges, they aren't really "Zig" - they are just transient growing pains. For someone getting started though, the current state of Zig is Zig.

I wish Zig had a polished package manager (there's one in the current development branch, but you don't as much use it as fight it). They could then move some of the less polished code into official experimental packages, helping to set expectations and maybe focus the development efforts.

replies(7): >>36151206 #>>36152145 #>>36153037 #>>36153777 #>>36159350 #>>36159799 #>>36178599 #
zoogeny ◴[] No.36151206[source]
I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list.

It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0

replies(8): >>36151679 #>>36152038 #>>36152323 #>>36152773 #>>36153966 #>>36154058 #>>36155307 #>>36159420 #
1. savolai ◴[] No.36153966[source]
Would love to understand better what exactly is language specific about package managers? You would think a winner would emerge in this space like one has in version control to be used with all languages, just separate repos for different ecosystems?
replies(2): >>36154490 #>>36154491 #
2. anon84873628 ◴[] No.36154490[source]
I was also wondering this. Why does every language need to reinvent the wheel?
3. vineyardmike ◴[] No.36154491[source]
Different languages do imports differently. There are different constructs for “exports” and modules and namespaces that prevent a common single directory structure.

Pip used to store packages in a global location, now most of python used a Virtual Environment per project.

Node uses a “vendor” directory within the project structure. This is probably the easiest case.

Go used to store everything globally in the “go path” but now with go modules it does something else.

Java doesn’t need source code, just single JAR files, but it needs it within the classpath.

C/++ is very flexible, but varied depending on how you build and set up your project.

Swift/ObjC requires doing whatever apple wants and dealing with their tooling.

Everything is different. If you want “one winner” the closest you get it is the system package manager (of which multiple exist) and pointing your project to its package cache. But not all system package managers handle multiple concurrent versions of the same package.

Maybe one day people will standardize against Nix which seems to be the closest?