r/programming • u/BrewedDoritos • 8d ago
What Zig felt like, coming from Rust
https://besok.github.io/posts/what-zig-felt-like-coming-from-rust/51
u/Blashtik 8d ago
The language isn't young at all. It's gotten plenty of breaking changes over the years, but the general design of the language isn't changing.
Also, why did this person entirely skip over error handling beyond the issue with not calling free? Results are a very clean way to deal with errors. The Zig system is basically just a slight improvement over error codes in C. I didn't think this was the biggest deal until I was working with JSON parsing and realized that since the error can't carry any extra info, getting the position of a parse failure requires either storing the error state in the parser and having the caller read it out on an error, or by using an output parameter to hold that info.
After that case I noticed that I was over-simplifying my errors to fit Zig. I was missing useful information that would help understand the reason for errors. If any did arise, it would be as annoying as calling a Windows API and getting ERROR_INVALID_PARAMETER (which parameter is invalid?!)
3
u/hxtk3 8d ago edited 8d ago
I kind of like the Zig error handling. For me the coolest thing about Zig is how easy it is to control allocations. If I don't care about error details and just want to know that something failed, I pass
nilto an output parameter and only get a status code back and I'm guaranteed non-allocating error path. I can also pre-allocate space for the errors I care about.I do think that I would hate to write a large program in Zig, though. I really only like it for small things that are performance-sensitive enough that I want to be able to avoid any post-startup allocations.
I made a utility for relaying a UDP multicast stream into a TCP server that forwards the UDP datagrams as TCP packets to all connected clients with
io_uringand zero runtime allocations. It's extremely performant in terms of the memory and CPU utilization per concurrent client and it's relatively easy to beat a Rust Tokio/async version of the same utility in performance because it's easier to look at the code and know when you're writing a performance hotspot. I'd call Zig a good fit for about that size and complexity of program, at least for my personal usage.(Of course, Rust is fully capable of hitting the exact same performance, but the program would look radically different and you'd end up abandoning async entirely to write roughly the same code as the zig version. If you tried to write idiomatic IO-bound rust, you'd run into a local minimum while optimizing where you had to dramatically restructure the program to optimize more, but it would certainly be doable.)
1
u/skyfex 1d ago
I didn't think this was the biggest deal until I was working with JSON parsing and realized that since the error can't carry any extra info, getting the position of a parse failure requires either storing the error state in the parser and having the caller read it out on an error, or by using an output parameter to hold that info.
The idiomatic way to pass error information like that is through an optional pointer to a struct where you want that information stored. There are many legitimate use-cases where you don't want all that information, in which case you can pass null and all the code related to tracking that should get optimized away.
It's really not a great idea to try to shoe-horn all kinds of error meta-data into a result type or exceptions. Zig errors do one job, and they do it well: force you to consider error conditions for functions that can error. What you do from there is up to you and completely explicit.
I understand the feeling that Zig is too explicit and leave too many things to be done manually. But that's the whole point of the language: to be a fully explicit systems programming language.
157
u/esiy0676 8d ago
Rust has been designed to be error-resistant (junior developers welcome), which a hiring manager likes as they could form quite an unbalanced (cost effective) team and have their team lead do all the hard work without (as many catastrophic) bugs slipping though.
This can't be said as much about other languages. As a side effect, we are seeing Rust becoming a good combination with what AI spews out for the same reason. And junior developers might as well go extinct as a result, we will find out some generation later.
42
u/DigThatData 8d ago
I think we're ultimately going to see an evolution towards something like an apprenticeship system. We were already sort of headed in that direction with the seeming expectation that part of the CS undergrad experience is landing internships.
18
u/pjmlp 8d ago
We have had apprenticeship system in Europe for decades in computing, I did professional IT on the high school back in Portugal, with on the job learning in the early 1990's, just in case I would not manage getting into a Software Engineering degree at first attempt.
Same to several team members on my German agency.
8
u/TheBananaKart 8d ago
Yeah both Germany and the Uk have always been big on apprenticeships for engineering, they nearly died off in the UK at one point due to a push for university by previous governments.
6
8
u/gimpwiz 8d ago
I distinctly hope that adequate numbers of employers stay committed to hiring interns to continue making this possible. We try to have an intern every year. Part of that though is making sure we have a req to hire an intern to fulltime after graduation of course.
5
u/veverkap 8d ago
As long as they pay the interns I agree
11
u/gimpwiz 8d ago
Had to check the sub to make sure I was commenting in the right place. I do firmware these days so we mostly hire EE/CE kids. Regardless of EE, CE, or CS, there is absolutely no such thing as un unpaid internship in any of these fields anywhere in the US that I know of, except for random individual yahoos trying to get kids to make their facebook killer for them or something. No legitimate company even thinks they can get away with not paying.
I don't remember exactly what we pay our interns but I think it's in the 40s or 50s per hour. I know it was high 30s and low 40s like a decade ago. For undegrad interns, not grad.
We expect usable results (even if very modest) from an intern. You do work, you get paid... simple stuff
3
u/veverkap 8d ago
That's great but too simple for most shops I know of.
4
u/gimpwiz 8d ago
Yeah you're right, everyone seems to be trying to game that. Wage theft is rampant. I am lucky enough to work somewhere that time cards are taken seriously enough and nobody tries to get clever. Hell, I've multiple times had to remind interns that all intern events and all team events are paid time, so if they're going to get beers and listen to music at 2pm at an official company event, do not even think of not putting those hours down as worked hours; you absolutely get paid for that too. Not only is that federal and state law, but it's also explicitly something we remind them of - it's a work event at work hours, it's time on the timecard. If any of them get a little shy about it I remind them that part of their job as an intern is to network, and talk to people, and learn things, and if you happen to do it over a beer that the company is paying you for, so much the better.
I always say... you do work, you get paid. You don't get paid, you don't do work. Basis of our economic system, really. Anyone cheating that deserves trouble coming their way.
2
2
18
u/CherryLongjump1989 8d ago edited 8d ago
This can't be said as much about other languages
You mean like Go, which is the canonical example of a language designed to make hiring managers happy above all else? Or Java, which as far as anyone can tell, has avoided the fate of COBOL solely because of armies of offshored contractors willing to do the needful?
1
u/germandiago 5d ago
It has also been developed to be productivity-resistant from the point of view of prototyping and initial learning curve.
It is a double edged sword: what is great for rock solid security and/or safety (as long as you do not spam unsafe around) is the same thing that makes other kind of software more difficult to write.
18
u/CherryLongjump1989 8d ago
It turns out I’d simply forgotten how straightforward it can be to rely on bare CLI tooling.
I had this same exact experience with Zig. Switching back to the CLI for Zig, ended up switching back to the CLI for most languages I use. Zig debugger still works fine for stepping through code and I don't feel like I am missing anything else.
18
u/pm_plz_im_lonely 8d ago
Coming from Java: The linter bugged out and the compiler errored on unused variables. See ya.
3
u/neutronbob 7d ago
You won't like golang either. It would be nice to have this be a compiler switch, so that you could make it a warning, rather than always be a stop-the-compile error.
5
u/ManufacturedCakeDay 7d ago
as a rust enjoyer, OP should just use Odin. many of the points just straight up disappear.
i really don’t get why people prefer Zig to Odin. truly.
11
u/otherwiseguy 8d ago
As someone who was a C developer and has written primarily Python for the last 14 years or so, any language that is duck-typed is just inherently not something I am interested in. Never again.
7
u/unski_ukuli 8d ago
Confusing comment. Never again Python while you are a python developer?
11
u/somebodddy 8d ago
One can swear to never again buy another phone from <brand> while still using his <brand> phone. Switching away from an option is not a free action - it's much more costly than picking a different option to begin with.
7
5
u/otherwiseguy 8d ago
You can be good at using tools that have features you don't like. I'd argue that increased familiarity really highlights the features you don't like.And duck typing is my least favorite part of Python, especially when working on very large projects.
2
u/unski_ukuli 8d ago
Right. I actually agree but somehow I didn’t get that from the original comment.
1
u/renatoathaydes 6d ago
Zig duck typing is different than Python’s. Zig will check the function types when the compiler finds a function is actually calling it with a concrete type. It just can’t check that until then because the function is more of a template. Python only checks types at runtime unless, though they do have a type system now.
0
13
u/Awesan 8d ago
It's kind of subtle but I really felt that zig encourages you to fix your shit, so to speak. While rust seems designed to say "don't worry about it, i got you", zig is like "yeah that's your problem to solve, so solve it".
Basically you need to design your stuff correctly so that memory management is easy and you can lean into zig's features. If you try to go against the happy path in the language, you end up with a lot of crap code that is very hard to read and probably full of bugs. Whenever I see people hating on zig this is often what I think they ran into. It's very opinionated, in a subtle way that allows you to do what you want, but it just kind of sucks if you try to do lots of small allocations.
In any case I feel like I learned a lot from trying zig and probably will be able to write better C and even rust now that I've used it.
56
u/Antroz22 8d ago
"don't worry about it, i got you"
You mean the "I won't compile this"?
18
u/-Redstoneboi- 8d ago
yeah, basically.
it won't compile anything that has even the slightest hint of being unintentionally* unsafe. well, besides cve-rs. but we're also getting a new borrow checker now, so i wonder how that one's doing.
it's very restrictive, but we also regularly have people in rust subreddits asking why a certain operation is forbidden in rust before someone in the comments explains exactly why it's forbidden.
you can afford to be less careful/anxious about the code because there are practically no false negatives. false positives be damned.
-11
u/Awesan 8d ago
No, sorry it was unclear. I mean, provided your code compiles, you do not need to worry about where the memory comes from or when it is freed. Same for concurrency: provided your code compiles, you will not have memory related race conditions. If you're really into rust you can understand what the compiler does exactly, but you don't have to in order to be an effective programmer with rust.
7
u/gmes78 8d ago
If you're really into rust you can understand what the compiler does exactly
Local variables are always on the stack, some types allocate on the heap.
Does reading documentation for the types you use make you "really into Rust"? None of that stuff is hidden.
Box,Rc,Arc,Vec,String,PathBuf, etc. all allocate.Memory gets freed on
Drop, which happens at the end of the scope. It's true that you don't have to worry about that (except for reference count loops), but why is that a bad thing?1
u/Awesan 8d ago edited 8d ago
- I didn't say it was a bad thing, just a different philosophy
- I didn't say you cannot know how it works, just that for the most part you don't need to in order to be productive/get started (as opposed to zig, where you absolutely do)
I don't know why you're so combative with your reply when I was just trying to clarify what I meant, not trying to judge anything.
edit: I just read the comment again, this whole idea of having 2 places for allocations, "stack" and "heap", is an invented concept that does not accurately map to the underlying mechanics. There are also fundamental differences between how zig and rust handle this concept.
8
u/read_volatile 8d ago
I just read the comment again, this whole idea of having 2 places for allocations, “stack” and “heap”, is an invented concept that does not accurately map to the underlying mechanics.
This whole idea of having 2 ways to organize storage, “files” and “directories”, is an invented concept that does not accurately map to the underlying mechanics of blocks on a drive.
Hell, you could say the same thing about actual blocks themselves thanks to wear leveling. Or virtual memory, or processes and threads, or even the notion of a “register” given the existence of ROBs, etc etc.
I would recommend getting familiar with the concept of “abstraction”; it’s something that comes up a lot in this field.
0
u/Awesan 8d ago
Of course most of the time the differences between these things are minor and only relevant in certain edge cases (also for all the examples you provided). But when we're specifically comparing two things and the difference cannot be properly explained while maintaining that level of abstraction you cannot just pretend anymore.
Zig specifically is designed to ensure the compiler always knows how much stack space your program will ever need. This means you cannot run out of stack space in a Zig program unless you do recursion (which I understood will be disallowed directly at some point, forcing you to allocate your own stack space for that call stack, either on your own stack or somewhere else). Rust does not have this assurance and cannot due to its compilation model.
6
u/gmes78 8d ago
Your comments imply that Rust doesn't force you to get memory management correctly, while that couldn't be further from the truth. You need to design your data structures in a way that'll work with the borrow checker. Saying "provided your code compiles" dismisses all the work and knowledge required to write a program that does compile.
It's a bit confusing to see someone describe Rust as letting you not care about the details, when, to me, "doing things correctly" is the central theme of Rust.
edit: I just read the comment again, this whole idea of having 2 places for allocations, "stack" and "heap", is an invented concept that does not accurately map to the underlying mechanics.
Not really. The stack is part of both CPU architecture and ABI.
2
u/EntroperZero 8d ago
this whole idea of having 2 places for allocations, "stack" and "heap", is an invented concept that does not accurately map to the underlying mechanics. There are also fundamental differences between how zig and rust handle this concept.
Can you elaborate on this? I don't know that much about Zig.
1
u/Awesan 8d ago
The hardware does not have the concept of a stack or a heap. I also am not an expert but my understanding is that CPUs can only really operate on registers, so to use anything from memory they have to do load instructions first. Because loads from actual RAM sticks are slow, they have layered caches (L1, L2, maybe more depending on the model). The idea of "stack memory" vs "heap memory" is a language construct/abstraction that is very common but not a hardware-level thing.
What happens when your program starts is that the OS allocates some block of memory to be used by your functions known as "the stack". Each function can just use what it needs, and the memory is again available when the function ends (hence the name).
If your program then needs any compile time known size memory, it can allocate this on the stack. This is very cheap as it's just a bump allocator (pointer is moved back when the function returns). It's also nice because this memory is basically always going to be in L1 and compilers can often trivially assign it to a register, bypassing loads altogether in some cases. If you do not know the size of what you want to allocate at compile time you need to heap allocate it, basically ask the OS for more memory and storing a pointer to that (usually 8 bytes nowadays) on the stack instead.
Your program says how much it will need (deduced by the compiler). This is where Zig meaningfully differs from Rust -- Zig has gone to great lengths in its language and compiler design to ensure it actually knows how much stack space your program will ever need. Recursion is still allowed for now (so that's a current caveat) but this will be changed in future versions (see below). Rust does not do this and therefore stack overflows can occur (if you try to allocate more on the stack than was reserved).
I believe there's a language proposal for Zig to only allow recursion if the caller provides the stack memory, so basically you would not use the OS-provided stack memory for recursion but instead you have to make your own best guess of how much you need. Of course you can still allocate this guess on the OS-provided stack memory if it's compile-time known (this kind of thing is really easy in Zig).
6
u/EntroperZero 8d ago
Mmm, the heap isn't a hardware thing, but the stack definitely is. The CPU does use registers, one of which is called the stack pointer, and it has push and pop instructions that write to and read from the address pointed to, and increment or decrement the pointer. The OS does manage virtual memory, but the CPU "knows" where the stack is in its current virtual memory space. And referencing stack-allocated variables and blocks is done using stack-relative addressing modes supported by the CPU instruction set.
But anyway, that's interesting that Zig is doing static analysis to determine how big the stack can possibly get. I would have thought that impossible in all kinds of programs, but I guess it's kinda similar to declaring an "unsafe" block where you opt out of compiler protections.
2
u/ConspicuousPineapple 8d ago
I mean, if you disallow recursion it's kind of trivial to compute, isn't it?
1
u/EntroperZero 7d ago
Well that's what I mean, they give you the escape hatch, so they can do the analysis even if you want to use recursion.
53
u/dan00 8d ago
It's kind of subtle but I really felt that zig encourages you to fix your shit, so to speak. While rust seems designed to say "don't worry about it, i got you", zig is like "yeah that's your problem to solve, so solve it".
Actually Rust does the same to you regarding program architecture. If you've a messy, intertwined architecture, than you're gonna fight the borrow checker a lot.
But you're right about Zig and memory management. If you organize your code, that certain blocks of code share the same memory arena - perhaps even use a bump allocator - than memory managment gets a lot easier and it's as performant as it can get.
57
u/max123246 8d ago
Yeah idk, rust simply won't let you compile. I prefer that over zig's potentially buggy code
Plus personally after seeing how the zig creator dealt with the bun guy, I doubt I'd ever use zig as a result. And I agree with their anti ai stance too
4
u/0x564A00 7d ago
Well, Zig might not stop you from writing a use after free, but it successfully save you from trying to run your code that has an unused variable because you haven't finished writing it yet.
3
u/OSS-Corpo-Shit 7d ago
Bro, what do you mean?
The bun guy tried to get zig team to implement pull requests that causes non-determinant outputs from the zig compiler. IE: you would have to keep compiling your exact same correct zig code multiple times till tests passed and then keep that executable, then bun guys threw a massive hissy fit over zig rejecting said pull requests.
If anyone was the absolute child in this situation, I was absolutely bun.
2
u/max123246 7d ago
The zig creator then put out a hit piece on the bun creator. They're both children.
Edit: Well the zig creator has edited the blog post and it's far more civil. But y'know, damage already done and all.
2
u/OSS-Corpo-Shit 6d ago edited 6d ago
The hit piece following the multiple hit pieces that the bun team threw up all over GitHub, twitter, and other spots?
If anything, Andrew’s blog on it was overtly civil considering the bullshit bun was authoring.
Bun team deserved a mid-2000s Linus post and got a late-2010s Linus post.
Spinning this as AK being the jerk is utter fanboy nonsense.
2
u/max123246 6d ago
Did you read the first draft of that blog post? It was not civil. Yes, bun's attacks were slathered in corpo PR speak so it wasn't as inflammatory but still just as damaging. But none of it was civil.
I don't get why you feel the need to defend this. Even the zig creator has apologized and edited his initial blog post to be far more civil.
1
u/OSS-Corpo-Shit 6d ago
I have only read the original post. I did not know it was revised. Good on Andrew.
You know who hasn’t come out and admitted they were incendiary and wrong and that their pull requests were justifiably rejected? Bun team. That’s who.
It is funny that you are mad at myself for pointing out that you’re blatantly lying about what actually happened because writing what actually happened doesn’t align with your hit piece commentary.
2
u/max123246 6d ago
I edited my original comment once I found out he revised the blog post. I don't have an agenda i read the zig blog post but have not actually read any of the bun correspondence other than them crying about not getting to submit vibe coded slop
Sorry if it seemed otherwise. Have a good one
1
1
u/skyfex 1d ago
Yeah idk, rust simply won't let you compile. I prefer that over zig's potentially buggy code
FYI, there is a project to add on static analysis to Zig: https://github.com/ityonemo/clr
From discussions I've read this seems to be a path Andrew is very interested in: add a system to plug in any kind of static checking tools into the compiler. The current version of clr relies on a fork of Zig with this plug-in feature added. This is a path to check for a lot more issues than just memory bugs.
I think it's wise to have some patience with Zig. It's a language that seems very focused on not locking into a bad solution prematurely. See the async I/O development for instance.
Zig is not going to make its syntax unwieldy or compromise its crazy fast compilation speed to force expensive static memory analysis onto everyone in all compilation modes. I have a suspicion that Rust's borrow checker approach will be seen as the same kind of "mistake" as its choice to go for colored async functions. Sure, it was the best approach at the time. And Rust is great in its own right for it. But Zig is playing a longer game, for better or worse.
29
u/flying-sheep 8d ago
That's just stepping out of your comfort zone in general.
I learned Java, then Python, then SML (a functional language similar to Haskell), JavaScript, R, Typescript, and finally Rust, and each step made me better in general.
I think apart from learning to code in the first place, SML was the biggest step up.
17
u/-Redstoneboi- 8d ago
"if a language doesn't change the way you think, is it even worth learning?" or however that quote went
11
u/jl2352 8d ago
If you try to go against the happy path in the language, you end up with a lot of crap code that is very hard to read and probably full of bugs. Whenever I see people hating on zig this is often what I think they ran into.
Honestly I've seen the same with Rust. Everyone I've known who hated Rust basically had the same experience, where they didn't know the Rust patterns and found the language painful.
They will have millions of match blocks everywhere because they don't know the patterns to remove them, or their iteration logic is painful because they know only the basics of iterators. One time I had a team member write about 500 lines implementing logic that was simply `std::iter::Iterator::map` + `std::iter::Iterator::fold`. As a result their code is bloated, brittle, and everything takes 10 times longer, because there is a lot of stuff to learn on the happy path.
When you have `Into` vs `From` and `AsRef` vs `Borrow`, but strings also have `FromStr`, `ToString`, and `Display` (which when you implement you get `ToString` for free so why are there both). Then you have `Iterator` vs `Iter` vs `IntoIterator`, and `to_iter()` vs `into_iter()` ... and then `Send`, `Sync`, and `'static` all come up too (and `'static' is usually `&'static` but sometimes you need `+ 'static` so what's that about). ... all of this actually makes sense once you learn it. They've done a really good job of organising it well. But it's a lot of stuff. This is core stuff too. We ain't even onto common libraries yet, where you get questions like why do I need `serde` and `serde_json`? That's not how it goes in most langauges.
You can see why people find this agonising when they start out.
11
u/xFallow 8d ago
Is it wrong that I'd rather focus on the problem I'm solving than how to best write in the programming language?
13
11
u/EntroperZero 8d ago
It depends how much of the problem you're solving is making your program highly performant and memory safe.
7
u/flying-sheep 8d ago
Not if you're writing a one-off script that you delete immediately after running it successfully.
Yes if you write code that ever has to be read.
1
u/xFallow 8d ago
I’m using Golang at the moment it’s a breath of fresh air being able to look at stuff I wrote 5 years ago and still perfectly understand it
Can’t say the same for the RXJS stuff I wrote
1
u/flying-sheep 4d ago
There's a balance and for me, Go ain't hitting it.
It's a language designed to keep junior devs humble. I'm senior enough to know when to use e.g. operator overloading and when not to, and my code is more readable as a result.
1
u/xFallow 4d ago
Fair enough I personally never find I needed operator overloading although it was fun to play around with in Clojure.
I've been working with nats a fair bit recently and I really enjoy reading their code when I have to https://github.com/nats-io/nats-server/blob/main/server/server.go
-15
u/coolmintchocolate 8d ago
"One caveat worth stating up front..." is such an obvious AI-ism
29
u/elperroborrachotoo 8d ago
People read more AI texts, AI-isms will enter human language.
Especially if it's a sub group where the median of creative writing is
fixes some minor bugs.12
u/atrocia6 8d ago
People read more AI texts, AI-isms will enter human language.
AI models train on human writing, human brains train on AI writing?
8
u/CherryLongjump1989 8d ago
Welcome to life in the Marine Corps. Where people are still pretending to be John Wayne, who was pretending to be a Marine.
1
u/disperso 8d ago
I'm not a native speaker. I've learnt what "load bearing" is very recently. Guess why... Also, lots of people are learning what em dashes are at a very fast pace.
I was saying "delve" quite lot, though. Thankfully people don't know about this that much.
1
15
u/xFallow 8d ago
Yeah the word choice is very AI like, nothing against people who use it to write but I find it grating after reading claude outputs all day at work
5
u/Blashtik 8d ago
The more I use LLMs the more I hate reading their output. It always felt off to me but now it's getting so tiring to see. I want to see their writing as little as possible.
3
u/max123246 8d ago
Yeah I agree. Way too many people putting a filter over their voice by "editing with an LLM".
1
u/AlSweigart 8d ago edited 8d ago
So, many "AI-detectors" are junk products that are just a front-end to ChatGPT, but I've found Pangram has held up pretty well to my own testing. If anything, it tends to have false negatives (it thinks AI-generated text is written by humans).
I fed the first 700 words into Pangram, and it gave me a 50ish% score for being AI. Don't think that it can zoom in on any given sentence as AI or not, but this is the kind of score I see from Pangram on stuff that has been edited by AI, though not written. So it's not like the author told ChatGPT, "Write a blog post about..."
The Pangram team developed their own ML classifier model for AI text. They don't just copy-paste it to ChatGPT and ask it for an answer.
Sorry that this sounds like an ad, but the "I saw Goody Proctor generating with the AI" accusations started to miff me a bit. People point to an em-dash and declare it as definitive proof of AI writing.
-27
u/BrewedDoritos 8d ago
AI bitching is getting really tiresome
18
u/cairnival 8d ago
“The first thing that caught me off guard — and honestly, who would’ve expected this to be the memorable part — was IDE support” reading stuff like this is tiresome
12
8
u/TankorSmash 8d ago
Did your use LLMs to help write this article at all?
10
u/disperso 8d ago
The bottom of the post says:
Disclaimer: styling and error handling throughout this article were cleaned up with the help of AI.
-3
1
u/QuarkCreator2610 8d ago
I think zig could really use a dependency manager and the little tooling that they do have feels clunky/hacky to use since its a bit too connected to your own source. If zig gets a good dependency system I think i would definitely seriously consider phasing out C for it(Im a C guy and i like what zig is doing, but i think Rust takes it to a level thats a bit too extreme for my liking where the features and standard library are starting to look like C++)
1
u/unski_ukuli 8d ago
I think the std is pretty far from C++, though I think thats sort of a problem. Rust doesn’t even have a bundled date library. A simple project can easily have hundreds of dependencies because 1) too small std together with 2) very easy to add dependency with cargo.
1
u/OSS-Corpo-Shit 7d ago
What is missing out of zig build and zig fetch that you need for dependencies?
2
u/QuarkCreator2610 6d ago
I’m not saying
zig buildandzig fetchare incapable of handling dependencies. They provide the basic mechanism, but to me the experience still feels more like “fetch this source and wire it intobuild.zig” than a complete dependency-management workflow. Its way too integrated into your source.What I’d like to see is a more standardized, ergonomic system for declaring dependencies, resolving compatible versions and transitive dependencies, updating them, inspecting the dependency graph, and applying overrides or patches - ideally with reproducible lockfiles and clearer conventions across projects. I also think the tooling is fairly coupled to the project’s
build.zig, which makes simple dependency management feel more manual than it needs to be.So the gap is less “Zig cannot use dependencies” and more “the workflow and ecosystem don’t yet feel as polished and predictable as I’d want before replacing C in larger projects.”
-1
u/MrFranzose 7d ago
May I ask an unconventional side question: how did someone come up with a programming language name which sounds quite similar to a motto of an Austrian painter?
186
u/ParadiZe 8d ago
Im a Rust guy and i really enjoy zig, but the subpar tooling and lack of documentation ultimately prevented it from being my "main" language. But im rooting for it and im excited to see where its going!