Naming things 'zig' which are not Zig, the language

Furthermore, if you just want to use a project directly (not build / crack open the sources right away) most of the time, you do not really care which language it is using.

2 Likes

Yep, and if it’s an import, the zig is fully redundant, because you know what language you’re using.

We don’t have a central repo like cargo to make this kind of critique into policy, and I don’t think we should have, or it should be. But nor do I think it’s good to do it.

1 Like

My personal nuance here: Name it whatever the heck you want for your private experiment. But before you publish it, take the time to consider all the things @mnemnion cites here.

(Edit: I guess if you’re developing in public repo like on codeberg, that doesn’t work, does it? Well, in the spirit of “let people try things” maybe I’d say “zig-experiment-…” is a lot less likely to cause confusion down the road.)

2 Likes

Exercising a bit of executive privilege here, and leaving the admittedly also-off-topic PSA in the show thread, but side channeling the discussion around it.

I also support doing whatever one wishes in private, but even then it’s nice to get off on the right foot out of the gate. I often don’t start a project until I find the name for it, and with code as well: if I don’t know what to call things that means I don’t know what they do, so I wait until I figure it out. But that’s me.

2 Likes

For my own personal projects, it makes sense for me to often name Zig projects with the zig- prefix. In this case the relevant namespace to me is not “Zig packages”, but rather “projects written by myself”. So having a “zig-modal” or “zig-backtracking” name is the clearest description of what the project accomplishes.

Similar I imagine for language bindings such as “zig-sqlite” (to pick a random example). In which case full package URLs solve the namesquatting problem.

I have a directory called z where they all go, just in case I forget what language I wrote them in.

Sometimes you don’t need to be creative: zig-clap, zig-sqlite, zig-toml, …, all good names and I don’t want any of them to change (none of them mine for the record). They tell me exactly want I want when I look at a project’s zon file. I don’t have to remember and translate from “Preston” or whatever to “that Zig toml library”

For more novel kinds of Zig projects, I think people are actually pretty good at finding names.

I don’t think the graveyard argument in the orginal post holds, if it was a potential problem we’d already have it. Zig is getting old and there’s an awful lot of zig-… projects. And it’s fine - active projects end up high on search result, and people find projects through community interaction.

7 Likes

I would probably make an exception for bindings maybe. even rust does that to some extent, by prefixing those with rs-foo

3 Likes

zqlite is right there. C’mon!

Consider yours grandfathered in, if you have to. You get to be special.

But I remember you from last time: do not encourage bad behavior on the part of others just so you feel better about your own decisions.

No it really isn’t. The Internet is forever. This is why most language communities discourage this crap.

Yes, that’s my point. Stop adding to the pile already.

1 Like

What are you referring to?

Obscuring the name of the library like that just to avoid having a zig- prefix seems a bit dogmatic. zostgres, zabbitmq, zdl4 – what is gained from this? Compared to referring to the project by its author to provide clarity.

(Not to say that zqlite is “bad” – both vrischmann/zig-sqlite and GhostKellz/zqlite exist.)

4 Likes

Even if it’s a library written in Zig, if it exposes a C ABI then it’s reasonable to say that it supports pretty much all programming languages. No need for “zig” prefix in this case, right?

3 Likes

If that’s the case I would suppose so – but what if the project takes an existing library and improves to work more idiomatically in Zig, such as by providing Zig error types, working with std.Io, etc?

IMO if it’s zig bindings, that’s a good case for “zig” prefix.

11 Likes

I have a number of projects that I converted from Go that got a zig- prefix for clarity. I think we are well past the point of clever unique names. Now I just try to make them descriptive of what they are.

e.g. This week I’m working on go-zigbee-lora-bridge albeit using tinygo. Had I found a zig-bluetooth lib it would have been zig-zigbee-lora-bridge :slight_smile:

2 Likes

pip is full of py-foo, foo-py, foopy, pyfoo variants - they were all created by their authors to do the same foo. One of them is actively developed. Another one has been stale for five years, but still works great, and doesn’t need any touch-up paint. The others are abandoned trash or unabandoned trash. It will always require a little recon to figure out which is which. It’s not just a python problem. When I was young, I named my iguana… yup, iggy. Oh well… nobody thought it was a chameleon. Names can give life to things, and they might as well, when utility is hard to derive from 10 variants of purely informative names. But I confess respect for some that are grandfathered in, especially when they live long lives. They earned the honor, I guess.

(I confess, when I read the original post (in the other thread), it tempted my diabolical side to go create a project exactly called zig-thing, and populate it with lots of code that does nothing. :))

7 Likes