9 ms·
What is the use case for Zig?
by asimjalis 6y ago
What is the use case for Zig?
- jamii 6y agoSimilar to C but less footguns, less error-prone error handling, better meta-programming, really good C interop. If you're writing C (or maybe even C++) on a platform that llvm supports, it's worth checking out.
- AndyKelley 6y agoZig is a general purpose programming language, so it's actually easier to answer the question, what kinds of programming are not a use case for Zig!
- Santosh83 6y agoAnd what would those be, in your opinion?
- dnautics 6y agowriting code for gpus, writing "code" for FPGAs/ASICs, writing excel macros, writing MAX presentations... Probably most websites (not counting any WASM layers...)
- AndyKelley 6y agoThere are a few categories: * Things that would be in scope, but the Zig project is not yet capable of supporting. An example of this would be compiling stuff to GPUs, e.g. SPIR-V. Such things are planned but not implemented. https://github.com/ziglang/zig/issues/2683 https://github.com/ziglang/zig/issues/2683 * Things that will never be in scope. An example of this would be code obfuscation, which is a use case the Zig project does not recognize. * Object formats that are drastically incompatible with the von Neumann architecture. It would be infeasible for Zig code to be compiled to such things. For example, attempting to compile to CSS (Cascading Style Sheets). I think that's it. Anything else would be supported, provided there were enough people interested in providing maintenance for the respective parts of the codebase.
- rawoke083600 6y agoMaybe it's a stupid question and I should read the docs... but is there any "multi-core or concurrency paradigms" in Zig ?
- dnautics 6y agoYou have to spawn a thread using a method of your choice. Once you've done thar though zig gives you some very nice async primitives that let you reenter functions and do scheduling/event loops easily, and it's agnostic; the calls autoconvert to blocking if you don't have async. There was a recent demo of task sharing in zig and comparing to go and rust: (https://youtu.be/UaF6-5BmX2I&t=1h10m https://youtu.be/UaF6-5BmX2I&t=1h10m) I've even plugged zig into another highly concurrent vm and gotten it to be a "good citizen": https://youtu.be/l848TOmI6LI https://youtu.be/l848TOmI6LI (these constructs are running concurrently in test and CI so I know they are robust)
- anta40 6y ago"what kinds of programming are not a use case for Zig!" Mobile app dev? PS: My daily work involves writing Java/Kotlin for Android, and just started learning Flutter for cross platform mobile app dev. I mean, if one day Zig support those, that's definitely super awesome. Of course I'm aware that more menpower on that direction is needed :)
- AndyKelley 6y agohttps://github.com/MasterQ32/ziggy-on-android https://github.com/MasterQ32/ziggy-on-android https://forum.nim-lang.org/t/4840 https://forum.nim-lang.org/t/4840
- Oreb 6y agoHow about iOS? I'd love to give Zig a try, but I need to be able to build static libraries for both iOS and Android.
- qaq 6y agoWell given current state of things Web Dev is def not a use case for now.
- The_Colonel 6y agoI know that as a language author it's natural to assert "it can be used for (almost) everything", but it's not a good strategy for adoption - plenty of languages can claim the same after all. It's better to mention in which areas it really excels, where it beats the competition hands down.
- discreteevent 6y agoIf I like (for whatever reasons) to primarily program in a classical OOP style with objects that have encapsulated state and can be late-bound then at the moment it looks like that this would not be a great use case for Zig. Would this be true? (BTW I really like Zig's philosophy in general, just saying that this might not be a great use case for it)
- hansvm 6y agoIt's another "C but better" language. Contrasted with some of the other solutions in that space, it has an emphasis on stability (once 1.0 is released) and simplicity -- eliminating low hanging fruit in terms of undefined behavior and whatnot, but not significantly hampering expressiveness or requiring excessive syntactic contortions to go the last mile and make it completely safe.
- blackrock 6y agoSo.. never? I’m of the impression that C will never die.
- dnautics 6y agoYou should try zig. You'll never want to go back, and the c interop is so good, it's easy to kill the c code over time using embrace extend extinguish.
- jorangreef 6y agoAs someone who loves C, Zig has replaced C for me and I don't plan to go back. There are just too many benefits, not least developer velocity and readability. Zig is also very approachable to anyone who is familiar with TypeScript, in a way that C isn't. This means more of your team can get excited and get involved, at least in terms of reading the code. And with Zig, where you have to spend a little extra maintenance time paying for the language being pre 1.0, that's still nothing compared to the upfront and long-lived costs associated with C. You can develop so much faster in Zig compared to C, that you're ahead even pre 1.0.
- yellowapple 6y agoTo expand on this a bit: I feel like learning Zig has helped me better understand C, particularly when it comes to allocation and pointers. Zig has more facilities to specify the intent behind a lot of the common C programming concepts, which has helped make things "click" in both languages.
- blackrock 6y ago
- gameswithgo 6y agoa lot safer C. not as safe as rust but much simpler. c programmers would likely feel at home.
- pron 6y agoIt's a general-purpose programming language, but its primary use case is low-level programming. Anything you'd use C or C++ for today -- OS kernels, command-line applications, games, drivers, embedded software, signal processing, packet filtering, VMs, and applications that require precise control over resources. Zig brings a radical new approach to this niche that reconsiders how low-level programming should be done -- unlike, say, Rust which is an improved C++ -- and is one of the most interesting languages I've seen in a very long time.