Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming

Meet Zig: the Modern Alternative to the C Programming Language (infoworld.com) 117

Posted by EditorDavid from the for-great-justice dept.
Systems-oriented developers already have programming languages like C, C++, Rust, and Go, notes InfoWorld.

But now, "we also have Zig, a newer language that seeks to absorb what's best about these languages and offer comparable performance with a better, more reliable developer experience." Zig is a very active project. It was started by Andrew Kelley in 2015 and now seems to be reaching critical mass. Zig's ambition is rather momentous in software history: to become the heir to C's longstanding reign as both the go-to portable low-level language and as a standard to which other languages are compared....

Currently, Zig is being used to implement the Bun.js JavaScript runtime as an alternative to Node.js. Bun's creator Jarred Sumner told me "Zig is sort of similar to writing C, but with better memory safety features in debug mode and modern features like defer (sort of similar to Go's) and arbitrary code can be executed at compile-time via comptime. It has very few keywords so it's a lot easier to learn than C++ or Rust."

Zig differs from most other languages in its small feature footprint, which is the outcome of an explicit design goal: Only one obvious way to do things. Zig's developers take this goal so much to heart that for a time, Zig had no for loop, which was deemed an unnecessary syntactic elaboration upon the already adequate while loop. Kevin Lynagh, coming from a Rust background, wrote, "The language is so small and consistent that after a few hours of study I was able to load enough of it into my head to just do my work." Nathan Craddock, a C developer, echoed the sentiment. Programmers seem to really like the focused quality of Zig's syntax.
While Zig is "approaching" production-ready status, the article notes its high degree of interoperability with C and C++, its unique error-handling system, and its elimination of a malloc keyword (leaving memory allocation to the standard library).

"For now, the Zig team appears to be taking its time with the 1.0 release, which may drop in 2025 or later — but none of that stops us from building all sorts of things with the language today."
This discussion has been archived. No new comments can be posted.

Meet Zig: the Modern Alternative to the C Programming Language More

Meet Zig: the Modern Alternative to the C Programming Language

Comments Filter:

  • But... why? (Score:5, Insightful)

    by CAIMLAS ( 41445 ) on Saturday March 11, 2023 @07:37PM (#63362539)

    What does Zig actually provide that is not already available elsewhere? I don't see the demand, or even the reason to look elsewhere. "Only one obvious way to do things" is not that different than the design criteria for Go. "It's just like C!" fits a very large number of languages at this point - a claim I think we can safely dismiss as universally untrue.

    Was C really that complex that you needed to eliminate common conditionals to make it easier to use? I mean... I can't really say that having multiple conditional loop grammars was ever a reason for C being difficult.

    • "Only one obvious way to do things" is not that different than ...

      More to the point, even if there are multiple ways to do something, you can always choose to use only one. So Zig is forcing something on you that you could choose yourself -- and who says Zig has chosen the best? Every problem / project is a little different and people have different styles. Personally, I *generally* don't care how someone does things as long as they're consistent and document weird/different things appropriately.

      • Re: (Score:2)

        by dfghjk ( 711126 )

        "...you can always choose to use only one. "

        that's not the same. Different programmers will choose different ones, causing the goal to be unrealized.

        "...and who says Zig has chosen the best?"

        This is the real problem, and judging from the few comments on loop syntax my reaction is that they won't. My reaction was that I wondered if they really were even programmers given the nonsense assertions they were making.

        One way to do things is a noble goal, not an end-all-be-all, and if you are going to have morons

        • My reaction was that I wondered if they really were even programmers
          Compilers are not programmed, erm written, by "non programmers"

          • Re: (Score:2)

            by dfghjk ( 711126 )

            Who says any of them work on compilers? The comment regarded the people discussing the topics, not literally everyone.

      • Re:But... why? (Score:4, Interesting)

        by ArmoredDragon ( 3450605 ) on Saturday March 11, 2023 @09:40PM (#63362721)

        That's one of the things I don't like about go -- it's not very expressive. The thing I find myself sorely wanting to have in many projects that just don't exist in go are enums and unions. Sure they have the var / iota syntax, but it's a tad error prone in the sense that the compiler doesn't assist you in ensuring that your pattern matching is exhaustive. (And if you need unions, well guess what? Not happening in go, period.)

        And that's exactly why I find myself reaching for rust, even if I'm trying to solve a problem that might be better expressed with garbage collection: Every time I refactor one thing, I don't have to worry so much about inadvertently breaking something else. All of those little bugs get found before you even compile, which saves an incredible amount of time. Not to mention the very strong implicit typing (and the occasional type aliasing) allows your code to be extremely flexible to refactoring to begin with.

        Although there being one way to do any given thing can be nice for people new to the language, it often leaves you shackled later on to some pretty crappy way of solving certain problems.

      • No software language that cares about any sort of idealistic purity will ever replace C. That goes for Rust too with its whole lend/borrow access control framework.

        • Replace is not a good word.

          No one is going to rewrite everything written in C in "pick your language".

          However in 100 years, C will have incorporated the good things of Go, Rust, Zig and other languages. Or will be gone. Probably one of Go or Rust or Zig will be gone, too.

          If C is gone: the term "replace" is still a matter of semantics. Forensic software analysis keeps many things running that one mere person would consider "gone".

          I did Y2K analysis on software that was 30+ year old at that time. Now we are 2

          • Re: (Score:2)

            by dfghjk ( 711126 )

            "No one is going to rewrite everything written in C in "pick your language"."

            Nor has anyone suggested otherwise, nor is that required for a language to be replaced.

            That was once an alleged requirements when languages couldn't be mixed. I'll assume you don't know that.

          • There are lots of good things in Go, Rust and Zig which are simply not appropriate in the tasks where C excels. For example, C should not have a built-in hash type, even though those are commonplace and exceedingly useful in other languages. Content addressed memory is a complex computing operation. C puts complex operations in libraries, not the base language.

            In fact, there are really only a handful of additions that would fit well in C. The main one that comes to mind is that C would benefit from an offic

            • No one forces you to use additions in a language.

              Boils down to the question if one should/could switch to a different language easily, or not.

              After all your examples of Go/Rust/Zig do not exist on each processor, C mostly does.

              • No one forces you to use additions in a language.

                Unless you code alone, of course they do.

                Further, C is intentionally structured so that the programmer can tell at a glance how close to the underlying machine code a particular section of C code is likely to be. By adding something which breaks that paradigm (like a hash data type), it'd no longer be C.

      • No language will stop you doing that.

        The point is, and by the way this is a design principle in Python too (although one I feels been left a little behind in the most modern iterations) to avoid the kind of abundance of riches you get in languages like C++ and Perl that let you easily write things a bazillion ways, but leave behind code that you need to know all one bazillion ways if you hope to understand.

        Its about setting standards. And yes sometimes standards are impediments, particularly to one man band

        • See also, Google's C++ guide - it is massive. https://google.github.io/style... [github.io]

          Multi-paradigm, aka let's write a hundred page style guide on correctness and which features not to use because it's a kitchen sink of languages!

          But, but... 'one obvious way' is some sort of Sapir-Whorf straitjacket, go figure. :)

          • Re: (Score:2)

            by dfghjk ( 711126 )

            Don't confuse C and C++, and when the problem is as large as it is with C++ a "hundred page style guide" isn't offered out of incompetence, criticizing it is.

            "But, but... 'one obvious way' is some sort of Sapir-Whorf straitjacket, go figure. :)"

            Who has said this? Trying to impress us with your education while simultaneously telling us how shallow your thinking is?

        • The point is, and by the way this is a design principle in Python too (although one I feels been left a little behind in the most modern iterations) to avoid the kind of abundance of riches you get in languages like C++ and Perl that let you easily write things a bazillion ways, but leave behind code that you need to know all one bazillion ways if you hope to understand.

          If that was the design goal, Python fails miserably at it.

          I have to use it now for some machine learning stuff and any time I need to google "python how to do [basic thing]" there's a huge article listing 12 ways to do [basic thing]. It's far worse than C, frankly.

    • Re: (Score:2)

      by bjoast ( 1310293 )
      The question isn't what it provides that isn't already available elsewhere, but which subsets of features, combined with philosophical views and target use-cases, that the language brings to the table.

    • Re:But... why? (Score:5, Funny)

      by 93 Escort Wagon ( 326346 ) on Saturday March 11, 2023 @08:08PM (#63362607)

      What does Zig actually provide that is not already available elsewhere?

      A second chance at smugness for people who were too slow to hop on the Rust train?

      I kid, I kid...

    • There's never I've obvious way to do something, only I've obvious idiomatic way, but you need to know the idioms.

      As for small package footprint and consistency, I think that's overrated. Trivially, brainfuck is an exceptionally simple language and very consistent. You can load it into your mind in its entirety in probably a minute. That doesn't make it a good language.

      Even backing off from the reductio ad absurdum, lisp has the same problem. Small language and you build everything, the problem is that you d

      • Bingo. If you want to see small and consistent try the pure Lambda Calculus and its even smaller kid brother, Combinatory Logic. Try writing your OS in that.

      • You can load it into your mind in its entirety in probably a minute.
        Says the guy who never tried to use it.

        No: without a cheat-sheet besides your computer you can not do anything in it.

        As the name of the language indicates: you can no load it into your brain.

        Certainly not in a minute. Or an hour, or a week if that is what you are aiming at.

        However you can learn most assembly languages in about an hour ...

        • What are you talking about?

          BF has only 8 single-character keywords, and no other syntax. You can easily understand what they all do in less than one minute. Why would you need a cheat sheet?

          The OP's whole point was that even though you it may be possible to understand a language in and of itself, that doesn't imply that it's even possible for a person to write real-world programs with it.

        • Says the guy who never tried to use it.

          Sure I have. I was into esoteric programming languages a few years ago. And by years, I mean in about 2007 ish. I remember because I happen to remember which airport I was sitting in when I figured out how to get something working, which limits it to a range of 3 years. Anyhow, I think I can still remember it. I'm going to try, so this might be slightly wrong. [ mark. ] jump to matching [ if 0. > move right < move left, -/+ dec/increment the value (mod 255). Then

        • Re: (Score:2)

          by dfghjk ( 711126 )

          Continuing to impress...negatively.

          "Says the guy who never tried to use it."

          It is not intended to be used, it is intended to be a challenge.

          "No: without a cheat-sheet besides your computer you can not do anything in it."

          Or with a cheat-sheet. Lack of cheat-sheet is not the problem.

          "As the name of the language indicates: you can no load it into your brain.Certainly not in a minute. Or an hour, or a week if that is what you are aiming at."

          "Notable for its extreme minimalism, the language consists of only eig

    • Comment removed based on user account deletion

      • Some of that is solved by standardization of the compiler used for a given project.

        Yeah it's cheating if you live in abstraction land, but it's a reasonable effort at process control in the real world.

    • Re: (Score:2)

      by Dwedit ( 232252 )

      Zig can apply types at compile time for a much simpler means of implementing templates.

      It also does not allow hidden function calls (no operator overloading, no destruction on things going out of scope, etc...)

    • You could read up at https://ziglang.org/ [ziglang.org]
      Or you could visit the wikipedia page https://en.wikipedia.org/wiki/... [wikipedia.org]

      Or you can stay dumb and pretend asking stupid questions on /. ... or facebook ... makes yo look smart.

      Hint: it does not make you look smart.

    • The Zig team's attitude is one of progress.

      Last I heard Rust people were bickering about their wokeness.

      SVB was watching their ESG more than Treasure Rates too.

      Outcomes are guaranteed.

  • Meet Zig (Score:4, Insightful)

    by LondoMollari ( 172563 ) on Saturday March 11, 2023 @07:41PM (#63362551) Homepage

    Hi Zig.

    Goodbye Zig.

  • Maybe, in a few years (Score:5, Funny)

    by sonamchauhan ( 587356 ) <sonamc@PARISgmail.com minus city> on Saturday March 11, 2023 @07:50PM (#63362569) Journal

    "Meet Zag, the modern equivalent to C++"

  • I couldn't even tell whether they had a string type, or whether they just had arrays of bytes that could be interpreted as characters. I didn't encounter anything about I/O, though it could well be there. They don't have an accessible index. Etc.

    OTOH, I notice the version number was 0.10.?, so rough edges aren't unreasonable, but it's a bit early to start promoting it. They've got built in hash maps of various kinds, so that's probably a good sign, but they'll need to have a decent way of handling unicode strings (rather than chars) before I'll consider it worth paying attention to. (FWIW, there are signs that they DO have some ideas along that line, but the documentation didn't exactly make it clear that they did or if so what they were.)

    As it is now I'd need to do almost everything in C anyway, so why not just use C++, which is largely compatible and which also includes hash tables...and various other useful feature. And has defined, if pretty garbage, ways of handling unicode.

    • Documentation is hard, and boring. That's why it's so hard to get people to do it. But IMO it's also critical to the long-term success of a project.

      Disclaimer: The need for documentation is something I keep trying to hammer into my coworkers' heads. But their heads are really hard - so maybe I need a bigger hammer?

      • You need a tech writer or two. Devs shouldn't be wasting their time writing documentation, they should rough it out and then pass it to the tech writers, who will make it gooder (and readable by normal people).

    • Re: (Score:2)

      by caseih ( 160668 )

      According to the docs, strings are null-terminated arrays of bytes, and normally the strings are expected to be encoded in UTF-8. https://ziglang.org/documentat... [ziglang.org]

      • Re: (Score:2)

        by HiThere ( 15173 )

        That's great is that's what you've got. And it encompasses all ASCII-7 strings. But it's not anything like a general way to handle unicode. Vala had that before they had enums documented. D had that in the version 1 time.

        Basically the capability you describe is already built into C, so that's no reason to prefer a new language. But how do handle 16 or 32 bit unicode representations, and how do you do conversions? It's a real pain in C or C++, so that's one place they could have an advantage. This is

        • Null terminated strings are the wrong way to go. The right answer is that you have a set of functions to operate on strings, and the internal representation of a string is a black box.

          If you need to deal with unicode, you can't have characters, either. A character is just a string with a length of one (otherwise toupper() and similar functions break).

        • C is not optimized for anything.

          No idea where you got that misinformation from.

          It's quite possible that the features I'm most interested in require code that takes up more RAM, or executes less quickly. For me it's a tradeoff I'm willing to pay.
          That is a trait of your own code, and not the language you chose. Facepalm.

          • Re: (Score:2)

            by dfghjk ( 711126 )

            "C is not optimized for anything. No idea where you got that misinformation from."

            You have one true skill...informing everyone how unimportant your opinions are.

            "Facepalm."

            Indeed.

            • C is an portable assembler.

              Everything optimized in C is done by the compiler vendor ^H^H^H^H^H^H^H^H^H^H^H CPU vendor who is shipping a compiler for his CPU,

              No idea why you want to insult us with your stupid ideas about C.

              C is basically the lowest level procedural language in existing: there is absolutely nothing "optimized" in it. Except: portability to other platforms.

              Oh, another hint: go to a library and read a book about C. The recommend starter book is: the K&R bible. Up to you to google what that

      • Re:The documentation, at least, needs a LOT of wor (Score:4, Informative)

        by willy_me ( 212994 ) on Saturday March 11, 2023 @11:24PM (#63362867)

        Zig has null-terminated arrays of bytes for backwards compatibility with C. Native strings are structures with an array and a length. So in some ways it is more like Pascal.

        The idea is to make it easy to write functions that do not overflow the array. When you do not have to scan for the string length it becomes a lot easier to write these functions in a safe manner.

        I tried working with Zig for a while and found it to be initially quite bothersome. The documentation is actually there in one place or another - but it is not well organized and easy to find. That being said, after a while it started to grow on me and I can see it being safer and more productive then C. Sadly, support for ARM32 kind of sucks at the moment due to requiring the latest LLVM so I never ended up using it. But it is worth trying out.

        • I will never understand why it is so difficult to check every character for null as you loop through a string.

    • Re: (Score:2)

      by Tailhook ( 98486 )

      I didn't encounter anything about I/O, though it could well be there.

      The first code example at the start of the Zig Language Reference [ziglang.org] illustrates I/O to stdout.

      const std = @import("std");

      pub fn main() !void {
      const stdout = std.io.getStdOut().writer();
      try stdout.print("Hello, {s}!\n", .{"world"});
      }

      Documentation for the File object returned from std.io.getStdOut() is found here [ziglang.org]. Yes, it's all a bit thin, but it's not hard to find what's there.

  • Are modern alternatives to C. :)

    • I've only had a look at various program languages out of technical interest and the only "serious" programming I do in between is on my modification of OpenTTD, but I've never seen a real alternative to C because it's already so basic, at most one can make small changes to address the pitfalls like string length and index and the /0 for instance (without a need for a library).

      I like C best because I see it as basic building blocks like LEGO, from which everything else can be built, including the other progr

  • This story is so overenthusiastic and uncritical that normal readers are put off by it and will look no further at Zig.

    Do the author and 'Editors" not realise that ?

    Or do they realise that and not care?

    Shame on them, either way.

  • You have no chance to survive make your time. (Score:5, Funny)

    by backslashdot ( 95548 ) on Saturday March 11, 2023 @08:07PM (#63362605)

    Take off every Zig. Move Zig. Move Zig. For great justice.

  • They love them their babies (Score:3)

    by AlanObject ( 3603453 ) on Saturday March 11, 2023 @09:38PM (#63362719)

    Does anyone besides me find this infinitely tiresome?

    I glanced at their language samples and I didn't see one single thing that is not already provided by the more established languages with the more established ecosystems. Nothing.

    What problem are they trying to solve?

    The only thing I can think of is they want to be the fathers of the next programming language superbaby.

    • Does anyone besides me find this infinitely tiresome?

      No, I like watching people invent languages and seeing what they come up with.

      When someone hacks something out that they care about, the result is usually interesting in some way or another, even if it's not ready for prime time.

      • But they don't seem to have come up with anything. All they did is rehash well known concepts from other languages and rename some keywords.

        Can anyone point out what is valuable or even new about this new language?

    • "oUr lAnGuAgE wIlL sOlVE aLl oF tEh sHoRtCoMmInGz oF eXiStInG lAnGuAgEs!"

      If I had a nickel for each time I heard this in the past 20 years...

    • No, I like watching people invent languages and seeing what they come up with.

      Perhaps you should invent your own language once, too. Then you see.

      What problem are they trying to solve?
      Probably none. They simply want a better C.

  • "Only one obvious way to do things"

    That's not a feature.

  • Who would want to trust putting time into a language where silly grammar fights about basic syntax happen, especially about basic things like how to design a loop. What will be crucial how fast it is. Can it be used to produce something as complex as video editing software with decent performance?

    • Re:Silly grammar discussions (Score:4, Insightful)

      by Jeremi ( 14640 ) on Sunday March 12, 2023 @01:02AM (#63362993) Homepage

      Who would want to trust putting time into a language where silly grammar fights about basic syntax happen, especially about basic things like how to design a loop.

      You haven't spend much time around language designers, have you?

      Because you just ruled out every computer language. None of them fell from the sky in their current form; all of them are the way they are as a result of all the silly grammar fights that were won (or lost) during their development.

      What will be crucial how fast it is.

      Seems like every modern language is implemented as a front end to LLVM, which will optimize the hell out of anything you give it. Since Zig is intended to handle C's use-cases, there's no reason to think its performance won't be comparable to C, and several reasons to think it will be faster than C (for example, Zig declares overflow of signed integers to be undefined behavior, which I personally don't approve of, but they did that to enable a class of optimizations that C will never be able to employ)

      • Re: (Score:2)

        by Jeremi ( 14640 )

        for example, Zig declares overflow of signed integers to be undefined behavior

        Dammit, autocorrect -- that should be "overflow of unsigned integers", of course.

    • Can it be used to produce something as complex as video editing software with decent performance?
      Obviously not.

      Perhaps it is time you throw away your 80286 and get a computer with a slightly better processor and a little bit more of ram?

      It would also help if you had an HD which is big enough to hold all the video files you want to edit, so you do not need to disk jokey with CDs.

      • Re: (Score:2)

        by dfghjk ( 711126 )

        Projection?

        Maybe he should get rid of all the assembly language software by "programmers" like you who think an hour is sufficient to learn the tools.

    • Re: (Score:2)

      by dfghjk ( 711126 )

      "...especially about basic things like how to design a loop."

      And I'd be fine with that if the arguments were intelligent. They are not, though, they are the kind of arguments you'd expect from undergraduates.

      The key to creating a "replacement" for C is not reinventing loop syntax, and I do not trust "designers" who argue that loop variables constained to loop scope creates "readability" or "searchability" problems. The consistent wrongness of the comments I saw was most notable.

  • ..."must have at least 5 years experience in Zig"

    Another item for employers to fake say they are trying to hire Americans while outsourcing the job overseas. "We just can't find any American that can fill the position in 2023".

    The terminally klewless regulators that are supposed to stop this kind of fraud do nothing.

  • malloc is a library routine like any other in C (Score:3)

    by EMB Numbers ( 934125 ) on Saturday March 11, 2023 @11:48PM (#63362909)

    >its unique error-handling system, and its elimination of a **malloc keyword** (leaving memory allocation to the standard library).

    Sigh! malloc is not a keyword in any language I know. malloc is a library routine like any other in C. malloc ends up calling mmap() or the system call, brk.

    • Re:malloc is a library routine like any other in C (Score:4, Insightful)

      by Dwedit ( 232252 ) on Sunday March 12, 2023 @12:58AM (#63362989) Homepage

      On Win32, malloc is usually a wrapper for Kernel32.dll's HeapAlloc function. But not always. When you load another DLL, it might use a completely different and incompatible malloc. So you can't free memory allocated by one module in a different module.

      • Re: (Score:2)

        by vbdasc ( 146051 )

        So you can't free memory allocated by one module in a different module.

        I don't see how this is different in Windows than in Un*x. You should avoid mixing modules using different run-time libraries in any OS, if you aren't addicted to trouble.

    • malloc() does not call mmap().

      Why would it?

      https://man7.org/linux/man-pag... [man7.org]

      It might call brk, but that is not really relevant for the discussion.

      However you are right: malloc is not a keyword.

  • Carbon is going to run...zigzagz around this, and probably Nim too. Granted, it is aimed at C++ while Zig aims at C. Cant' wait for Carbon though.

    Zig could be cool for MCUs/small embedded...but currently the backend is llvm afair which limits the targets.

  • Multiple standards? (Score:4, Insightful)

    by chthon ( 580889 ) on Sunday March 12, 2023 @05:58AM (#63363249) Journal

    What, no XKCD reference?

    Standards [xkcd.com]

  • Heil, zig!

  • Tough audience :-). If you consider Rust as a modern C++ replacement, Zig is your modern C replacement. I think that 's its unique selling point in the sea of programming languages seemingly invented ever day. I've been learning Rust for the last year or so and to be honest I'm drowning in the complexity, maybe that's a reflection on my competence but Zig is a much simpler language and I could consider myself fairly proficient within weeks.

    It's still very early, the language is still evolving, the documenta

Slashdot Top Deals

To the systems programmer, users and applications serve only to provide a test load.

Close