this post was submitted on 30 Aug 2023
100 points (93.9% liked)
Programming
17398 readers
106 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I've heard of it, and don't know what the point is.
In zigs defence, I felt the same way about rust a few years back as well.
I wonder what the killer feature for zig is. At least rust promises safer code, what does zig promise?
I think the main advantages over C are:
There are probably more, but those are the ones I remember.
The killer feature (IMO) is automatic conversion of C code to Zig code (transpiling). E.g. take a C project, convert it all to Zig, and even if you don't transpile, you still get really nice compat (include C headers just like a normal input without converting). Getting a medium sized C project converted to Zig in 1 day or 1 week, then incrementally improving from there, is really enticing IMO especially considering the alternative of rewriting in Rust could be months of very hard conversion work. Transpiling isn't perfect but it seems to be a 97% soltuion.
The second advantage seems to be easy unsafe work.
BTW I don't really use Zig, and I still prefer Rust, but those are the reasons I think it has a niche of its own.
I wonder if owners of large C projects are that keen to move off C to zip though? I guess time will tell. I do a fair bit of C, and I can't see us risking switching to Zig, unless there was something else that made it really worth it. I should probably have a look at Zig if I have spare time, maybe there is a killer feature we aren't seeing yet.
Easy interop with legacy code is how kotlin took off, so maybe it will work out?
My understanding is that this is possible: you should be able to take a C project, add a build.zig file and under the hood the system is calling clang to compile the C project. HOWEVER, you can now add a .zig source file, compile that in zig and link together with the output of the C compiler into an executable. If this is actually true, I can definitely see the attractiveness of the language.
Definitely sounds like a well thought out upgrade path. But I don't feel like an upgrade path is a killer feature in of itself. I think I'd have to have a play with it to see if there is something to make transitioning worthwhile.
Good interop was a requirement for widespread adoption, but not the reason why programmers want to use it. There's also null safety, a much nicer syntax, custom DSLs, sealed classes, type inference, data classes, named and optional arguments, template strings, multi-line strings, computed properties, arbitrary-arity function types, delegation, custom operators, operator overloading, structural equality, destructuring, extension methods, inline functions and non-local control flow, reified types, ...
Some of these features have since been added to Java.
I wasn't trying to diminish the value of Kotlin, my point was that interop makes it so easy to stealth insert it into legacy java codebase, and that probably contributed heavily to it's success?
Language adoption is a multi-part problem, you ideally need good interop (or upgrade path) and your language needs to also be compelling enough to upgrade to. Zig certain seems to have the former, I'm not personally sold on the latter, but it certainly sounds like it might have some compelling features.
It competes with C, so in 2023 this basically means embedded systems. It offers executable size of few KB and out-of-the-box cross-platform compilation. It's a modern C, basically, and it claims to be even faster than C as some language rules allow more optimizations
This talk is technically not about Zig, but he still shows many of Zig's strengts: https://youtu.be/aPWFLkHRIAQ?si=b-rf_oMremovedIvAdq
To me, Zig is a language that tries to be like C, but with all the decades of mistakes removed, or rather with modern knowledge of good language design in mind, while keeping as much compatibility as possible, as to not require a lot of work for the transition as Rust did. Thus, if you're working in a C codebase, you'll be good to go to integrate Zig in as little as an hour. They also have by far the cleanest solution to macros and generics that I have seen yet (although I miss my type classes).
It promises more correct code. As an example, most rust code and in fact most crates you will find will treat a memory allocation failure as an irrecoverable error, ie. your program will just crash.
In Zig, such error classes are not supposed to exist by definition, making the resulting programs more robust.
How does zig solve the memory allocation failure issue? RAM isn't unlimited, it has to fail eventually?
It does not "solve" memory allocation failures, as its not a thing that can be solved. It exposes memory allocation in a way that forces you as a programmer to handle the possible error situation. You cannot just call
mallocornewor what have you and the just move on as if nothing happens.Oh right, okay. I thought you meant that allocations just couldn't fail.
Instead you are just forced to handle it properly if it does fail. Would be very interested to test that in practice. C memory allocations are notoriously tolerant, and will happily let you allocate terabytes of memory that doesn't really exist until you try write to it.
I'll definitely have to give that a play at some point.
Ah, that is another thing that Zig does well (in my opinion). Instead of having a global allocation call, Zig uses an
allocatorinterface interface, meaning you as the programmer can plug in different allocation strategies as you require. So depending on if you do or don't like that behavior, just pick the allocator accordingly, either for your whole program or just for parts of it.zig's biggest feature is comptime. completely removes need for generics as types exist as first class at compile time. also all functions can run at comlile time. no exceptions.
for example the
Vecfunction accepts a type as and returns a struct that can hold arbitrary amounts of said type on the heap.