6 ms·

Is Zig the Long Awaited C Replacement

71 points by kristoff_it 6y ago

zepto 6y ago
“Swift Syntax is Poorly Suited for Functional Programming“ - sad but very true. On the other hand it’s a weird statement to make in an article about Zig, because Zig is much worse.
- jdmoreira 6y ago
  I was surprised by the statement since I use Swift mostly as a functional programming language. Sure you need to avoid classes and restrict yourself to value types but I enjoy the syntax. Immutability is guaranteed, closure syntax is not that clunky, the type system is great, extensions are amazing for namespacing and protocols / generics solve all my polymorphism needs. The language is huge though and getting bigger (which I don’t enjoy).
  - zepto 6y ago
    I like Swift more than any other curly brace language, and I use it for functional programming. I have pure Swift apps in the App Store and continue to work on Swift projects. But compared to something like OCaml or Haskell, the syntax is just plain nasty for real fp. It feels clumsy and verbose - like wearing a pair of hob-nail boots for ballet dancing. However, I think they made a good trade off in terms of balancing readability, power and progressive disclosure.
    - johnnycerberus 6y ago
      I wouldn't call OCaml or Haskell languages with nice syntax either. Are they powerful? Yes, but the syntax is not very appealing.
- dnautics 6y ago
  Being a avid user of functional programming and Zig, I don't find zig's syntax to be particularly bad for FP, though I don't typically program zig in an FP style. Could you be a bit more specific about what you mean?... (I have done this: https://www.youtube.com/watch?v=fIxNEILcNGM https://www.youtube.com/watch?v=fIxNEILcNGM) And I have coded Zig in a style that resembles Elixir code, which is basically: "use a different style for casing, never use the self syntactic sugar".
nurettin 6y ago
Ironically, this article got me interested in V.
- setr 6y ago
  If I remember correctly, V had a lot of controversy because the author failed to clearly communicate between what was planned, and what was already done, and wrote as if it were feature-complete with blisteringly fast compile times when it was in fact fairly simple in its general capabilities. So.. perhaps be interested in it with a grain of salt.
  - renox 6y ago
    Also for non-optimised compilations, Zig devs are working on their own backend which should be much faster. That said, I don't know if I'm interested in Zig: I like comptime but passing around allocators doesn't seem pleasant I think I prefer Odin's 'context' concept.
    - dnautics 6y ago
      honestly passing around allocators is only a thing to worry about if you're a library writer, if you're a library consumer, just make a global GP allocator for your program, and pass that in when you need it.
- deleted 6y ago
  [deleted]
- forgotpwd16 6y ago
  Supposing you got interested because of the speed it claims, comparisons on the site shouldn't be taken at face value. Fixing any errors* and for N=2 (2K prints), the times for some of the languages (running ten times and taking the average) are: C 0.24s (gcc 9.3.0, gcc $file) C++ 0.96s (gcc 9.3.0, g++ $file) Go 0.12s (go 1.15.2, go build $file) Nim 0.44s (nim 1.2.6, nim c $file) V 1.37s (v 0.1.29, v $file) Zig 16.9s (zig 0.6.0, zig build-exe $file) I guess Zig does some optimizations but not sure how to turn them off. Someone should do an analytical comparison for all of them and different values of N. *The generated V test doesn't work with the latest version as `;` between expressions throws a bad token error and zig requires `a` to be `.{a}`.
jedisct1 6y ago
Zig is a boring language. As in, if you already know another programming language, picking up Zig is going to be very fast and simple. Sure, it introduces some new concepts, comptime being the main one, but these are very easy to grasp, and you will immediately use them and understand their value. It’s a replacement for C as the compiler doesn’t get in the way, but still brings you safety features that C never had: checked arithmetic, slices, checked pointer casts, tagged unions, nice error handling, better memory management, defer, etc. It also has excellent support for WebAssembly. I must confess that Zig is the first language that I’ve been so excited about since Rust.
- contravariant 6y ago
  Out of interest could you explain exactly what you look for in a language that makes Zig a good replacement?
  - 10000truths 6y ago
    For me, the best parts of it are: Very versatile metaprogramming (C’s macros make me puke), slices (if I had a nickel for every time I wrote a struct { thing_t* data; size_t len; }...), namespaces, and coupling of initialization and cleanup with defer/errdefer (gcc’s __attribute__((cleanup)) sucks to use).
FandangoRanger 6y ago
>medium nagsite C will never ever be replaced. It's just not happening.
AussieWog93 6y ago
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline... "Any headline that ends in a question mark can be answered by the word no."
- casion 6y ago
  Then you read the wiki article and see that "yes" is the most common answer when actually studied. So, good point. Zig must be a great C replacement.
johnisgood 6y ago
I just use Forth. ;P
throw_m239339 6y ago
C will go away when operating systems stop begin written in C but language X or Z, no more, no less. If Linux was written in ADA or Turbo Pascal then people would be using ADA or Turbo Pascal instead of C. It's a chicken and egg problem. A lot of C programmers complain about the wildness of C++, but frankly, often complex C programs are that close to be their "own languages" with custom object systems, Macros and what not.
- wishinghand 6y ago
  Sounds like that'd be Redox (Rust) if it ever gets more funding.
- pjmlp 6y ago
  Thankfully there are already quite a few written in something else, but yeah C will survive as long as UNIX clones are kept around.
xedrac 6y ago
I think Zig might be better suited for Linux kernel development than Rust, even though I really love Rust. My biggest issue with Zig is that heap allocated memory must be manually freed. There is no RAII, smart pointers etc...
pjmlp 6y ago
Not really, unless it manages to cater the interest of a platform vendor. As much as I dislike it, fact is that C will stay around as long as UNIX clones, or POSIX implementations exit. So here efforts like Frama-C and Checked C are much more tailored for success. Then if we look at the OS landscape, we already have a mix of languages replacing C to certain extent. On mainframes, C was never relevant to start with, so the surviving ones from IBM and Unisys make a mixed use of their original systems programming languages, PL/S and NEWP, mixed mostly with C++. Whatever C like code is used, it is in the context of "compiles as valid C++" still. On embedded, besides C + language extensions (stuck at C89 in some domains), there are C++ based platforms like Arduino and ARM mbed, microEJ (Java + C), Pascal and Basic (a couple of surviving OEMs are still around), Oberon (Astrobe), Ada, Java and .NET bare metal, TinyGo and Rust are now doing their baby steps. The relevancy of C on embedded can be shown by Microsoft adopting it as the only language for Azure Sphere applications, despite the whole sales pitch about IoT security. Apparently despite all that talk, the market they are targeting is only interesting in buying, if the platform only speaks C. Currently developer requests for C++, C# and Rust support keep being nicely rejected. On research OSes we have GenodeOS now going with a mix of Ada/SPARK and C++. Windows is a mix of C, C++ and .NET, and the market pressure for C has won, as Microsoft gave in to their "you will only need C++ and .NET", and the more recent version of MSVC introduced support for C11 and C17. Most likely also caused by the need to support Azure Sphere and WSL development workflows. On ChromeOS, only the Linux kernel is C based, everything else is a mix of JavaScript, C++ and Rust. On Android, similarly, we have C for the Linux kernel and "legacy drivers", everything else is a mix of Java and C++. Project Treble also supports writing drivers in Java if one wishes to do so, and the reason why Google is having meetings about using Rust in Linux kernel is related to possible adoption of Rust in the Android world. Fuschia uses a mix of C++, Rust and Dart. I think none of the original C code still survives as pure C. Apple platforms use a mix of C, Objective-C, C++ and Swift. Then we had experimental OSes like Redox (Rust), Powernext (D), in production hypervisors like gVisor (Go), secure firmware like TamaGo from F-Secure, low level file system drivers like Weka.io (D),... C++ has gained a new wind on its sails as the main language for GPGPU programming, regardless of used directly or via language bindings. The only thing that might cut it, are better support for GPGPU programming from other languages, or some kind of GPGPU DSLs, then again NVidia is pretty much focused on first class support for C++ on CUDA, so. Game console SDK are all about C, C++ and now C# (thanks Unity). So, C replacements already exist, one just needs to step away from C cargo culture that there is no other systems language. On the other hand, there are domains where no matter what, C will remain the sole king. So we need to fix its warts without throwing away everything. However, Zig is a welcomed arrival to the party of compiled languages, maybe it will find its niche and make a couple of happier users anyway, even if it never makes a dent replacing C. That I what I consider a success for programming languages, having their own customer base that keeps the language alive.
ncmncm 6y ago
C already has a replacement, and that replacement is, manifestly, C++. Essentially all of the most demanding, highest paid system development is done in C++. The number of C++ programmers, judging from attendance at rapidly proliferating C++ conferences and seminars, including even ISO 14882 SC22/WG21 C++ Language, is growing faster than ever. Attendance at each WG21 meeting in the last several years has exceeded that of all previous meetings. By all means, learn niche languages. They bend your brain and make you a better programmer. Just don't imagine there will be a job waiting for you, using it. And, any code you write in it at work will probably be abandoned when you leave, as it will be too hard to hire a competent replacement who can maintain it. This means that the niche languages to learn are the ones that really do bend your brain. Rust, OCaml, F# are probably worth exploring. Zig, by that measure, probably isn't. The natural fate of almost any language is to die. Only a few get the miracle it takes to survive, as did (only) COBOL, Fortran, C, C++, Python, Java, and Javascript. There was a time when Pascal and Ada looked like they would survive, but the needed miracles did not arrive. There is no excuse for writing a new program in C, or, for a program that should be maintained over years, any niche language. There is no reasonable expectation that a language will still be known, over the life of the program.. It is just barely possible Rust and/or Go will survive. If they do, over the years they will get radically more complex.
- tutfbhuf 6y ago
  Basically everything related to cloud computing is written in Go nowadays. As long as there is kubernetes, containers and cloud there will be Go. I would say Go is at least here to stay for the next decade or two. For rust I would like to see (wide) linux kernel adoption, if that is going to happen, then rust will also be major for decades.
  - ncmncm 6y ago
    It would be good if Rust doesn't die. In order not to die, it would need to get its adoption rate up by two or more orders of magnitude. That would require some big changes in how Rust conducts business, that I don't see any indications of beginning. Most important would be to cut the number who try it, and give up before they have got their legs under them. Changes in how borrow checker enforcement is applied could go a long way. But, even mentioning the topic, people come out of the woodwork shrieking that you want to turn off the borrow checker. It is a real embarrassment to the Rust community to have these people. Another critical problem is the extremely slow compiler. It really should be two orders of magnitude faster. There has been extremely heavy lifting to get it just percentages faster, that will not be enough. There is really no objective reason for a Rust compiler to be slow. C++ has unfortunate historical baggage that slows it down, but Rust doesn't have any of that. I don't see how to get a good compiler for Rust short of writing a new one. If an undergraduate class can all write a Java compiler in a semester, why is there still only one, slow, Rust compiler? * * * Go might survive if it can break out of its cloud niche. Cloud is trendy now, but trends change. Other languages have had much wider usage than Go has, and faded. Nothing about Go makes it uniquely suited for coding cloud operations. As it gets more complex, its ease of adoption and fast compilation will both become less pronounced.

71 points by kristoff_it 6y ago

“Swift Syntax is Poorly Suited for Functional Programming“ - sad but very true. On the other hand it’s a weird statement to make in an article about Zig, because Zig is much worse.

jdmoreira 6y ago
I was surprised by the statement since I use Swift mostly as a functional programming language. Sure you need to avoid classes and restrict yourself to value types but I enjoy the syntax. Immutability is guaranteed, closure syntax is not that clunky, the type system is great, extensions are amazing for namespacing and protocols / generics solve all my polymorphism needs. The language is huge though and getting bigger (which I don’t enjoy).
- zepto 6y ago
  I like Swift more than any other curly brace language, and I use it for functional programming. I have pure Swift apps in the App Store and continue to work on Swift projects. But compared to something like OCaml or Haskell, the syntax is just plain nasty for real fp. It feels clumsy and verbose - like wearing a pair of hob-nail boots for ballet dancing. However, I think they made a good trade off in terms of balancing readability, power and progressive disclosure.
  - johnnycerberus 6y ago
    I wouldn't call OCaml or Haskell languages with nice syntax either. Are they powerful? Yes, but the syntax is not very appealing.
dnautics 6y ago
Being a avid user of functional programming and Zig, I don't find zig's syntax to be particularly bad for FP, though I don't typically program zig in an FP style. Could you be a bit more specific about what you mean?... (I have done this: https://www.youtube.com/watch?v=fIxNEILcNGM https://www.youtube.com/watch?v=fIxNEILcNGM) And I have coded Zig in a style that resembles Elixir code, which is basically: "use a different style for casing, never use the self syntactic sugar".

nurettin 6y ago

Ironically, this article got me interested in V.

setr 6y ago
If I remember correctly, V had a lot of controversy because the author failed to clearly communicate between what was planned, and what was already done, and wrote as if it were feature-complete with blisteringly fast compile times when it was in fact fairly simple in its general capabilities. So.. perhaps be interested in it with a grain of salt.
- renox 6y ago
  Also for non-optimised compilations, Zig devs are working on their own backend which should be much faster. That said, I don't know if I'm interested in Zig: I like comptime but passing around allocators doesn't seem pleasant I think I prefer Odin's 'context' concept.
  - dnautics 6y ago
    honestly passing around allocators is only a thing to worry about if you're a library writer, if you're a library consumer, just make a global GP allocator for your program, and pass that in when you need it.
deleted 6y ago
[deleted]
forgotpwd16 6y ago
Supposing you got interested because of the speed it claims, comparisons on the site shouldn't be taken at face value. Fixing any errors* and for N=2 (2K prints), the times for some of the languages (running ten times and taking the average) are: C 0.24s (gcc 9.3.0, gcc $file) C++ 0.96s (gcc 9.3.0, g++ $file) Go 0.12s (go 1.15.2, go build $file) Nim 0.44s (nim 1.2.6, nim c $file) V 1.37s (v 0.1.29, v $file) Zig 16.9s (zig 0.6.0, zig build-exe $file) I guess Zig does some optimizations but not sure how to turn them off. Someone should do an analytical comparison for all of them and different values of N. *The generated V test doesn't work with the latest version as `;` between expressions throws a bad token error and zig requires `a` to be `.{a}`.

jedisct1 6y ago

Zig is a boring language. As in, if you already know another programming language, picking up Zig is going to be very fast and simple. Sure, it introduces some new concepts, comptime being the main one, but these are very easy to grasp, and you will immediately use them and understand their value. It’s a replacement for C as the compiler doesn’t get in the way, but still brings you safety features that C never had: checked arithmetic, slices, checked pointer casts, tagged unions, nice error handling, better memory management, defer, etc. It also has excellent support for WebAssembly. I must confess that Zig is the first language that I’ve been so excited about since Rust.

contravariant 6y ago
Out of interest could you explain exactly what you look for in a language that makes Zig a good replacement?
- 10000truths 6y ago
  For me, the best parts of it are: Very versatile metaprogramming (C’s macros make me puke), slices (if I had a nickel for every time I wrote a struct { thing_t* data; size_t len; }...), namespaces, and coupling of initialization and cleanup with defer/errdefer (gcc’s __attribute__((cleanup)) sucks to use).

FandangoRanger 6y ago

>medium nagsite C will never ever be replaced. It's just not happening.

AussieWog93 6y ago

https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline... "Any headline that ends in a question mark can be answered by the word no."

casion 6y ago
Then you read the wiki article and see that "yes" is the most common answer when actually studied. So, good point. Zig must be a great C replacement.

johnisgood 6y ago

I just use Forth. ;P

throw_m239339 6y ago

C will go away when operating systems stop begin written in C but language X or Z, no more, no less. If Linux was written in ADA or Turbo Pascal then people would be using ADA or Turbo Pascal instead of C. It's a chicken and egg problem. A lot of C programmers complain about the wildness of C++, but frankly, often complex C programs are that close to be their "own languages" with custom object systems, Macros and what not.

wishinghand 6y ago
Sounds like that'd be Redox (Rust) if it ever gets more funding.
pjmlp 6y ago
Thankfully there are already quite a few written in something else, but yeah C will survive as long as UNIX clones are kept around.

xedrac 6y ago

I think Zig might be better suited for Linux kernel development than Rust, even though I really love Rust. My biggest issue with Zig is that heap allocated memory must be manually freed. There is no RAII, smart pointers etc...

pjmlp 6y ago

Not really, unless it manages to cater the interest of a platform vendor. As much as I dislike it, fact is that C will stay around as long as UNIX clones, or POSIX implementations exit. So here efforts like Frama-C and Checked C are much more tailored for success. Then if we look at the OS landscape, we already have a mix of languages replacing C to certain extent. On mainframes, C was never relevant to start with, so the surviving ones from IBM and Unisys make a mixed use of their original systems programming languages, PL/S and NEWP, mixed mostly with C++. Whatever C like code is used, it is in the context of "compiles as valid C++" still. On embedded, besides C + language extensions (stuck at C89 in some domains), there are C++ based platforms like Arduino and ARM mbed, microEJ (Java + C), Pascal and Basic (a couple of surviving OEMs are still around), Oberon (Astrobe), Ada, Java and .NET bare metal, TinyGo and Rust are now doing their baby steps. The relevancy of C on embedded can be shown by Microsoft adopting it as the only language for Azure Sphere applications, despite the whole sales pitch about IoT security. Apparently despite all that talk, the market they are targeting is only interesting in buying, if the platform only speaks C. Currently developer requests for C++, C# and Rust support keep being nicely rejected. On research OSes we have GenodeOS now going with a mix of Ada/SPARK and C++. Windows is a mix of C, C++ and .NET, and the market pressure for C has won, as Microsoft gave in to their "you will only need C++ and .NET", and the more recent version of MSVC introduced support for C11 and C17. Most likely also caused by the need to support Azure Sphere and WSL development workflows. On ChromeOS, only the Linux kernel is C based, everything else is a mix of JavaScript, C++ and Rust. On Android, similarly, we have C for the Linux kernel and "legacy drivers", everything else is a mix of Java and C++. Project Treble also supports writing drivers in Java if one wishes to do so, and the reason why Google is having meetings about using Rust in Linux kernel is related to possible adoption of Rust in the Android world. Fuschia uses a mix of C++, Rust and Dart. I think none of the original C code still survives as pure C. Apple platforms use a mix of C, Objective-C, C++ and Swift. Then we had experimental OSes like Redox (Rust), Powernext (D), in production hypervisors like gVisor (Go), secure firmware like TamaGo from F-Secure, low level file system drivers like Weka.io (D),... C++ has gained a new wind on its sails as the main language for GPGPU programming, regardless of used directly or via language bindings. The only thing that might cut it, are better support for GPGPU programming from other languages, or some kind of GPGPU DSLs, then again NVidia is pretty much focused on first class support for C++ on CUDA, so. Game console SDK are all about C, C++ and now C# (thanks Unity). So, C replacements already exist, one just needs to step away from C cargo culture that there is no other systems language. On the other hand, there are domains where no matter what, C will remain the sole king. So we need to fix its warts without throwing away everything. However, Zig is a welcomed arrival to the party of compiled languages, maybe it will find its niche and make a couple of happier users anyway, even if it never makes a dent replacing C. That I what I consider a success for programming languages, having their own customer base that keeps the language alive.

ncmncm 6y ago

C already has a replacement, and that replacement is, manifestly, C++. Essentially all of the most demanding, highest paid system development is done in C++. The number of C++ programmers, judging from attendance at rapidly proliferating C++ conferences and seminars, including even ISO 14882 SC22/WG21 C++ Language, is growing faster than ever. Attendance at each WG21 meeting in the last several years has exceeded that of all previous meetings. By all means, learn niche languages. They bend your brain and make you a better programmer. Just don't imagine there will be a job waiting for you, using it. And, any code you write in it at work will probably be abandoned when you leave, as it will be too hard to hire a competent replacement who can maintain it. This means that the niche languages to learn are the ones that really do bend your brain. Rust, OCaml, F# are probably worth exploring. Zig, by that measure, probably isn't. The natural fate of almost any language is to die. Only a few get the miracle it takes to survive, as did (only) COBOL, Fortran, C, C++, Python, Java, and Javascript. There was a time when Pascal and Ada looked like they would survive, but the needed miracles did not arrive. There is no excuse for writing a new program in C, or, for a program that should be maintained over years, any niche language. There is no reasonable expectation that a language will still be known, over the life of the program.. It is just barely possible Rust and/or Go will survive. If they do, over the years they will get radically more complex.

tutfbhuf 6y ago
Basically everything related to cloud computing is written in Go nowadays. As long as there is kubernetes, containers and cloud there will be Go. I would say Go is at least here to stay for the next decade or two. For rust I would like to see (wide) linux kernel adoption, if that is going to happen, then rust will also be major for decades.
- ncmncm 6y ago
  It would be good if Rust doesn't die. In order not to die, it would need to get its adoption rate up by two or more orders of magnitude. That would require some big changes in how Rust conducts business, that I don't see any indications of beginning. Most important would be to cut the number who try it, and give up before they have got their legs under them. Changes in how borrow checker enforcement is applied could go a long way. But, even mentioning the topic, people come out of the woodwork shrieking that you want to turn off the borrow checker. It is a real embarrassment to the Rust community to have these people. Another critical problem is the extremely slow compiler. It really should be two orders of magnitude faster. There has been extremely heavy lifting to get it just percentages faster, that will not be enough. There is really no objective reason for a Rust compiler to be slow. C++ has unfortunate historical baggage that slows it down, but Rust doesn't have any of that. I don't see how to get a good compiler for Rust short of writing a new one. If an undergraduate class can all write a Java compiler in a semester, why is there still only one, slow, Rust compiler? * * * Go might survive if it can break out of its cloud niche. Cloud is trendy now, but trends change. Other languages have had much wider usage than Go has, and faded. Nothing about Go makes it uniquely suited for coding cloud operations. As it gets more complex, its ease of adoption and fast compilation will both become less pronounced.