I have been reading about this new language for a while. It’s a C competitor, very slim language with very interesting choices, like supporting cross platform compilation out of the box, supports compiling C/C++ code (and can be used as a drop in replacement for C) to the point in can be used as replacement of ©make and executables are very small.

But, like all languages, adoption is what makes the difference. And we don’t know how it goes.

Is anyone actually using Zig right now? Any thoughts?

  • CameronDev@programming.dev
    link
    fedilink
    arrow-up
    19
    arrow-down
    1
    ·
    1 year ago

    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?

    • Chrobin@discuss.tchncs.de
      link
      fedilink
      arrow-up
      11
      ·
      1 year ago

      I think the main advantages over C are:

      • better tooling
      • modern syntax
      • by default, pointers must be non-null. You have to specify if you want to use null pointers
      • better exception handling using the functional style of exceptions-as-values

      There are probably more, but those are the ones I remember.

    • jeffhykin@lemm.ee
      link
      fedilink
      arrow-up
      7
      ·
      edit-2
      1 year ago

      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.

      • CameronDev@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        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?

        • Blackthorn@programming.devOP
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          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.

        • Aloso@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          1 year ago

          Easy interop with legacy code is how kotlin took off, so maybe it will work out?

          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.

          • CameronDev@programming.dev
            link
            fedilink
            arrow-up
            3
            ·
            1 year ago

            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.

    • Blackthorn@programming.devOP
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      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

    • Treeniks@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      This talk is technically not about Zig, but he still shows many of Zig’s strengts: https://youtu.be/aPWFLkHRIAQ?si=b-rf_oM*removed*IvAdq

      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).

    • ck_@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      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.

        • ck_@discuss.tchncs.de
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          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 malloc or new or what have you and the just move on as if nothing happens.

          • CameronDev@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            1 year ago

            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.

            • ck_@discuss.tchncs.de
              link
              fedilink
              arrow-up
              4
              ·
              1 year ago

              Ah, that is another thing that Zig does well (in my opinion). Instead of having a global allocation call, Zig uses an allocator interface 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.

    • voxel@sopuli.xyz
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      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 Vec function accepts a type as and returns a struct that can hold arbitrary amounts of said type on the heap.

  • Vorpal@programming.dev
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    1
    ·
    1 year ago

    I really don’t see what niche it is trying to fill that isn’t already occupied.

    Rust is as successful as it is because it found a previously unoccupied niche: safe systems programming without garbage collector and with high level abstractions that (mostly) optimise away.

    I don’t think “better C” is a big enough niche to be of interest to enough people for it to gain a critical mass. I certainly have very little interest in it myself.

    • jeffhykin@lemm.ee
      link
      fedilink
      arrow-up
      8
      ·
      1 year ago

      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. Does rust already fill this space? Yeah kinda, but that’s why I’d call in a niche

    • voxel@sopuli.xyz
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      comptime is a huge killer feature for me. I used it to generate ARM lookup tables at compile time and it’s amazing, it also removes the need for generics as types are just arguments
      for example the Vec function accepts a type as and returns a struct that can hold arbitrary amounts of said type on the heap.
      I eventually switched to rust + proc macros tho (zig solution was MUCH cleaner!) because both ZLS and the Zig compiler are terrible and still needs a lot of work.

    • philm@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Yeah my thinking as well.

      Addtionally, why I think other system language competitors like Zig or Nim aren’t succeeding long-term, is because of fast growth and already big ecosystem of Rust. Zig may be better though for some use-cases (when you want to avoid all the mental overhead, and the application stays simple).

  • NotPengi@feddit.nl
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    2
    ·
    1 year ago

    I’ve heard of it for sure, and have seen some examples. I’ve never seen a real good use case for my personal or professional projects that I couldn’t fulfill with Rust or Dart in the same capacity or better. Then again, I don’t work with C projects basically at all, so other people’s mileage may vary.

  • jeffhykin@lemm.ee
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    Yes some people are using it! I think this video gives a good idea of adoption since its about a company’s experience using zig: https://www.youtube.com/watch?v=wxx5_Xaw7zU

    I considered Zig and Nim as kind of irrelevant given Rust is being adopted, but this video, specifically the C compat, changed my mind, at least for Zig.

  • huntrss@feddit.de
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    I started hearing of it in 2021. Read through the documentation in February of 2022 and started to learn it in Fall of 2022. Ever since then I use both, Rust and Zig depending on the small project or concept I currently want to explore.

    I wrote a blog post that describes the 3 things I like about both languages each: https://zigurust.gitlab.io/blog/posts/three-things/

    Might be interesting.

  • owsei@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Well, there’s the focus text editor

    but, at least when I tried it, you had do change the code just to compile it in Linux. Even tho it has a Linux “compatible” version.

  • Paradox@lemdro.id
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    Its a neat language, very simple. Has a somewhat simple approach to codegen at compile time, which is both a boon and a curse; you can do a lot with it, and not get too deep into footgun territory, but once you hit the limits of what you can do, you’re pretty much stuck there.

    The syntax and other features are very nice, and it makes rather small binaries. I’d say its comparable to Nim in this area.

    Sadly, it also suffers the same problems Nim suffers: dearth of libraries.

    • TechNom (nobody)@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      Sadly, it also suffers the same problems Nim suffers: dearth of libraries.

      That might change once the language stabilizes. Imagine creating a library now and the language changes breaking it.

      • Paradox@lemdro.id
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        In theory yes, but it becomes a problem of ergonomics. The transpiled library feels like a transpiled library, it doesn’t match the conventions of Nim/Zig. The best ports/wrappers/whatever typically use the C lib for all the heavy lifting and unique things, and build their own interface, that matches conventions of the calling language

  • choroalp@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    Syntax is too confusing. Instead of looking like code it looks like a wall of pure text instead. Also too strict to do basic stuff

  • theherk@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    I’m not super interested in the language at the moment, simply because the two I currently use most (Go and Rust) cover all of my use cases. It does sound quite promising though and I like the governance model.