most of what I work on is internal, so the line between production and such is shady.
8 Likes
I am actually using Zig in a pre-production system at work. But I think we’re going to port it all to C++ in the near future. Mostly because of things outside of zig. For example, it’s polygot project, and zig’s bazel integration is “meh”. Code coverage tools are flaky. There are no standard code generation tools that fit into the build in a standard way, for custom serializations. etc. The list is long. Zero of it has to do w/ the language itself.
5 Likes
Not to contradict your broader point, but I’ve found kcov works quite well with Zig.
But sure, more generally Zig hasn’t conquered the long tail of ‘works with everything’ yet. A business might be willing to take care of one or two of those things, but it’s easy to see a threshold past which that wouldn’t be practical.
This is a Zig community, so I came here because I use Zig, not because I don’t use it. If you go to some other communities, you will see more funny answers, such as the famous one: “In no way Zig will be used in kernel and driver development, because Zig is not a native ahead-of-time compilation programming language.”
4 Likes
As @mnemnion said:
But sure, more generally Zig hasn’t conquered the long tail of ‘works with everything’ yet.
There exist code analysis and coverage tools for C and C++ which Zig’s tooling can’t yet match and which are a requirement for us to switch critical software. We do currently use it for greenfielding low-importance stuff, to get experience using it.
3 Likes
Zig is the best invention since the wheel. Not ready yet but it will rock.
1 Like
wheels typically dont like rocks, lets hope zig rolls instead
7 Likes
what if zig could both rock and roll? we’d really be on to something then
3 Likes
That’s wild, do you have a link where I can find this legendary thread?
I’m not sure if this is what @IceGuye was referencing, but there’s this gem on the FreeBSD forums: ZIG programming language. | The FreeBSD Forums
5 Likes
This is my experience from a hobby gamedev standpoint.
I don’t like zig purely from the syntactical noise it permeates.
It’s not on the level of Rust or C++ but there is syntactical noise. Especially in the gamedev related space where there is a bunch of multiplication, division the syntax for it can get incomprehensible.
I haven’t tried zig lately but it felt that way when I tried it using zig 0.13.
6 Likes
I have accepted that zig is not swift and doesn’t aspire to be. I propose below a vision, not so negative about why it CAN’t be used, but more about how it COULD be used, in a novel and fresh way.
First, the strength of zig is the people writing it. 100%, full stop. No notes, keep on trucking.
If anyone feels bad about this thread, stop reading. We all love and cherish the good work in zig.
What Zig Appears Not To Be
- For large enterprise use-cases, time is money; labor is time; and many roads to Rome are expensive.
zigis, by defn, a ‘pave your own way’ platform- result -
zigdoes not appear to be designed for mass enterprise adoption (see - go, swift, c#). Less is more in this space. - For enterprise use cases, a CLEAR singular path is essential: clear upgrades; clear backward compatibility; clear philosophy.
zighas focused on VISIBILITY - choosing to show vs hide, even if that does cost some clarity, for good reasons.
Knowing limits is important.
To be all things to all people - is messy.
The above is not a criticism - now that I understand the focus, I 100% encourage deepening that focus. zig is not for the app layer – so what? keep on rocking AND rolling 
The strength of zig is it’s compiler team.
What zig could be
- I could see
zigemerging as an AI native compiler–suppose it is a first class citizen to theclinesof the world; why should people have to learn zig? Why should zig have to be a skill, for person or Ai model? Why can’t AI deepen its integration with a compiler…does the veil have to be SO separate? - Cross-platform C ecosystems are in tatters.
- Imagine zig replacing C as a bytecode sidecar standard.
- When compiling bytecode for distribution to the masses (or AI models), zig could cross-compile all the popular target platforms and embed those results inside the distributed package
- No longer would it be required to build native C locally, by human, script or AI model alike.
Next Generation
Now fit all the pieces together
- Generative AI writes bytecode “syntactically sweet” code, because it is more clear for more people (until AI is just writing bytecode, unseen by human eyes geepers but remember the enterprise case)
- In doing so, AI determines a block of code is ineffcient, and so re-writes slow bits as cross platform zig.
- Cross platform Zig is compiled and delivered alongside the bytecode dsitribution
Bright and sunny future! just my two cents.
1 Like
Don’t understand this. I take “choosing to show vs hide” meaning having an explicit syntax, in which case how could that cost any “clarity”? This sounds like a contradiction.
1 Like
I agree it’s a little confusing, but I’ll add that Zig’s verbosity can also be seen as “noise” in certain instances.
For example, requiring repeated casts (and/or new variables) when doing certain kinds of math. It’s more explicit, so you have all of the information required to understand what’s going on. However, many may find that explicitness to be less “clean” than a simple math expression like you’d expect in many other languages.
This is obviously subjective, but I think it’s affected enough users to be worth mentioning.
2 Likes
Yes that explicit math is different than in other languages.
But I got used to it. And like it better. In C# it is really a mess. What you see is not what you get
In Zig it is, altough verbose.
Zig has been a breath of fresh air, edging out C99 for me.
“Regulations/government” :: not yet included Zig in anything subject to regulatory standards approvals.
“Miss-compilation” :: me committing more time cross checking godbolt would help close this gap.
Here are my main reasons why I don’t use zig (yet). Actually I am using zig, but only for doing advent of code for past years. So basically toy problems only.
I come from the world of High Performance Computing. My main reason not to use zig is that I could not get to build it with openMPI easily, which is THE communication framework for multi-node calculations in HPC. It seems like the header of openmpi is abusing the C-preprocessor in a way that is too complicated for zig.
5 Likes
I work in scientific computing as well and we’re about to potentially embark on rewriting fortran codebase into c++. I’ve highlighted potentially using Zig to build the code, and I’ll try using zig for projects that are completely my own for experience. The off-putting aspect of “maintain it with Zig” for work is that the build api has changed a lot and most examples online simply don’t work. I’m still personally interested in pursuing that, though i am limited by my free time. And MPI incompatibility could be a deal breaker.
6 Likes
how could ‘show vs hide’ cost ‘clarity’?
Verbose is unclear but visible. Terse is opaque but clear. Clarity has tension with visibility.
When there is complexity, and understanding is needed, clarity becomes a priority.
When there is high impact / high stakes, and safety is needed, visibility becomes a priority.
2 Likes
I wrote my last FORTRAN IV program in 1986
And I wonder why not plain old C?
BTW AFAIK there are several fortrant2c transpilers