7 ms·

I think Zig's biggest advantage is that it's just C without the warts, or footguns as is said in the Zig world. The comptime feature is probably the most excit

I think Zig's biggest advantage is that it's just C without the warts, or footguns as is said in the Zig world. The comptime feature is probably the most exciting thing I've seen in a while. I've looked at Rust and feel it's more of a competitor to C++, Java and C#. Whereas Zig is C done right.

deleted 6y ago
[deleted]
johnisgood 6y ago
> The comptime feature is probably the most exciting thing I've seen in a while Just please do not make the mistake of believing that it is unique to Zig. Factor brings the best of Forth and Lisp together, so meta-programming or extending the language is possible quite easily, for example. You could extend the syntax or add constructs pretty easily, and so forth. Anyways, an example can be found here: https://rosettacode.org/wiki/Compile-time_calculation#Factor https://rosettacode.org/wiki/Compile-time_calculation#Factor but this barely scratches the surface. It does not mention `<< ... >>` which evaluates some code at parse time. You can execute code before the words in a source file are compiled. https://docs.factorcode.org/content/article-literals.html https://docs.factorcode.org/content/article-literals.html https://docs.factorcode.org/content/article-syntax-literals.html https://docs.factorcode.org/content/article-syntax-literals.... https://docs.factorcode.org/content/article-syntax-immediate.html https://docs.factorcode.org/content/article-syntax-immediate... https://docs.factorcode.org/content/word-flags{,literals.html https://docs.factorcode.org/content/word-flags{,literals.htm... I remember when I did something like: SYMBOL: aligned-16-char << : 16-byte-alignment ( c-type -- c-type ) 16 >>align 16 >>align-first ; char lookup-c-type clone 16-byte-alignment \ aligned-16-char typedef >> when I was working on some binding. You could use it in a struct like: STRUCT: foo { bar aligned-16-char[16] } ; Or something like this is pretty typical (when writing bindings/ffi): << "libotr" { { [ os windows? ] [ "libotr.dll" ] } { [ os macosx? ] [ "libotr.dylib" ] } { [ os unix? ] [ "libotr.so" ] } } cond cdecl add-library >> Those are just some examples, but it is pretty powerful. It supports (and encourages) interactive development. Profiling and debugging is a breeze and highly detailed and useful, you can easily disassemble words (functions), you can get a list of how many times malloc has been called in some circumstances, there is runtime code reloading (a vocabulary that implements automatic reloading of changed source files[1]), and so on. And on top of all this, you can compile your stuff to an executable that is less than 4 MB! And of course you do not have to do stack shuffling at all, you can easily use locals which is useful for math equations and whatnot. Plus did you know that the Factor compiler supports advanced compiler optimizations that take advantage of the type information it can glean from source code? The typed vocabulary (yes, it is not part of the language, but implemented as a vocab) provides syntax that allows words to provide checked type information about their inputs and outputs and improve the performance of compiled code. I would like to repeat because if this was not the case, I would have never bothered with it: you can create a single executable file that is less than 4 MB of size if you wish so! Of course it encourages interactive development, but still, it is great to have an optimizing compiler that can do all this easily. And mind you, this part is also written in Factor itself and is available as a vocabulary (vocab). [1] There is a vocabulary named io.monitors and loaded source files across all vocabulary roots are monitored for changes. You can read more about it here: https://docs.factorcode.org/content/article-vocabs.refresh.html https://docs.factorcode.org/content/article-vocabs.refresh.h... --- So all in all, I think Factor is great. I was shocked at how modern (and how many) libraries it has, especially considering only a handful of people have been working on it. Slava Pestov created the language, and some people joined him later on. If you want to learn more about it, start here: https://concatenative.org/wiki/view/Factor https://concatenative.org/wiki/view/Factor. There are videos, there are papers, there are lots of resources to get started. :) The language misses a couple of things, but it is being worked on.
- gridlockd 6y ago
  > Just please do not make the mistake of believing that it is unique to Zig. Factor brings the best of Forth and Lisp together... What is unique to Zig is that it has these features without bringing together "the best of Forth and Lisp". Sometimes, just being pedestrian is a virtue.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - moomin 6y ago
    But comptime is kind of LISP's unique feature, it's just called macros. EDIT: In fairness, Zig's presentation is pretty likeable. You can do a comptime expression pretty trivially in LISP, a comptime parameter or block would require actual effort.
    - patrec 6y ago
      No. There is a real difference between staged computation of the type that zig has and macros in common lisp, scheme/rust have (so much for lisp's uniqueness BTW). In common lisp you can do completely arbitrary computation at compile- (or read-)time in zig you cannot and crucially you are also not responsible for manually ordering the "stages". E.g. in common lisp you have use eval-when to make sure that stuff is available at the right phase, whereas zig works out the dependency for you.
      - creata 6y ago
        Can you please provide an example of Zig "working out the dependency"? I'm struggling to make sense of your comment.
        patrec 6y ago
kristianpaul 6y ago
Although Rust syntax might feel familiar with other languages the point of comparison shouldn't end there. The Rust language community is big and growing (including the number of Crates) and the mindset behind writing safe code is actually what got me interested in the first place. I’m glad that other languages are inspired by that and are able to provide some of those features on their specific niches (like in the case of Zim is simplicity)
sacado2 6y ago
Yes. I think Zig is a safer C, while Rust is a safer C++. C programmers will be more excited by Zig than by rust, and the opposite is true for C++ afficionados.
- pron 6y ago
  Those are nice taglines, but while Rust is a safer C++ in the sense that it is a language that espouses C++'s design philosophy and has a similar feel to it, Zig is something new altogether. The only thing that makes it more similar to C than to C++ is that C is an extremely simple language, as is Zig, while C++ is an extremely complex language. But other than that, Zig is a low-level language that is its own family, and with a design that is radically different from either C or C++; it's hard to compare it to anything, really. Zig goes well beyond C in its power of abstraction to match C++/Rust, but it does so in a very different way than C++/Rust.
  - jonahx 6y ago
    > in the sense that it is a language that espouses C++'s design philosophy Could you elaborate on this?
    - pron 6y ago
      They're low-level languages -- with all the attention to low-level detail all low-level languages require -- that aim to appear like high-level code on the page. All the same details are still there, and you must confront them when changing the code, but they don't appear as text when you look at the code.
- JoshTriplett 6y ago
  > C programmers will be more excited by Zig than by rust I'm a C programmer. I haven't touched C++ since before C++11 became a thing, and I prefer C to C++. I'm much more excited by Rust.
- roca 6y ago
  The safety guarantees of Rust are much stronger than Zig's. For example Rust statically prevents use-after-free and data races, and Zig doesn't (and I don't think anyone expects it ever to). To me this matters more than which one is more like C or C++ (partly because I don't think Rust is very much like either).
steveklabnik 6y ago
"Rust is a competitor to C++, not C" is a meme, and there's some truth there, but I don't think it's all that accurate. I know lots of folks who prefer C to C++, but still like Rust. I do think that these sorts of language comparisons are useful, but they don't always generalize. Partially this is because what a language means to each person can vary. As long as they're understood in a very coarse grained way, I think they can still make sense, but it's tricky!
- mumblemumble 6y ago
  > I know lots of folks who prefer C to C++, but still like Rust. I'm one of those people, and, while I have yet to use Rust or Zig for any real work, at least so far I also see Rust as being more directly a competitor to C++, and Zig as the more direct competitor to C. Or perhaps I should say analogue. Because, it's true, I might choose Rust over C. I'm even tentatively planning to, for one project that's still in the idea phase, and that I would normally have wanted to do in C. Though that's not really because I see Rust as being more C-like. It's more that I see choosing Rust as being perhaps more likely to be worth the extra effort than I've found to be the case for C++.
  - steveklabnik 6y ago
    Yes, it also can matter what you even mean by "competitor." Some people take it to mean "similarity in language features." Others can take it to mean "would I choose it as a substitute." Some take it to mean "would I choose it as a substitute for this specific domain or project." I've seen this play out a number of times. "Rust cannot compete with C, because C is too entrenched in embedded." "I do embedded development in Rust, so it can." "Well, I work with these chips that Rust can't target yet, so it can't, for me." None of these statements are incorrect, but they can lead to huge back-and-forths. Words are hard.
    - deleted 6y ago
      [deleted]
- drran 6y ago
optymizer 6y ago
I've been enjoying D as "C done right". I find it a pleasure to use.
- wk_end 6y ago
  D is much more "C++ done right" (and then some). C and Zig are very barebones, close-to-the-metal language. D has garbage collection, classes, templates, exceptions, built-in dynamic arrays and hash tables, and on and on and on. The "Features Overview" page makes me go cross-eyed [1]. Yes, you can turn many of these things off or ignore them and just use D as a better C, but the same could be said of C++ (for some definition of "better"). Or most languages, really, if you squint enough. [1] https://dlang.org/comparison.html https://dlang.org/comparison.html
  - dnautics 6y ago
    I almost feel like D is "go done right" (I am aware that D precedes go).
  - optymizer 6y ago
    Yes, and people do use C++ as a better C to get OO and a stronger type system, at the cost of compilation times (and the usual C++ pitfalls). I use D as better C. I use it as better C++ at times. Once ownership/borrowing [1] is stable, I'll use it as a better Rust too. For close-to-the-metal code, I use D's inline assembler [2]. "To go any lower level than that, you'd need a miniature soldering iron and a very, very steady hand." (Andrei Alexandrescu) [1] https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... [2] https://dlang.org/spec/iasm.html https://dlang.org/spec/iasm.html
  - p0nce 6y ago
    But native code is native code, there isn't a magical layer underneath that would make Zig closer to the metal than D, unless perhaps the voluntary Undefined Behaviour zig is willing to take such as those for loops.
  - tastyminerals2 6y ago
ironmagma 6y ago
It's almost just C without the warts; I wish someone would make a language that was both as good as Zig or Rust, and could be compiled to C code. The dependency on LLVM rules out a lot of embedded use cases, because some chipsets require forks of LLVM, or worse, proprietary C compilers or forks of GCC or something else, to run. Would be nice to have a language that just works everywhere.
- qppo 6y ago
  I feel like the onus should be on chip makers to write LLVM backends because proprietary C compilers and GCC forks almost universally suck. I understand why they don't, but it's just disappointing on both ends of the pipeline. That said, ARM is great, and you can target most ARM chips with LLVM. There's also the downside that transpiling to C locks you into an ABI, which limits what compiler developers can do towards the end of the compilation passes.
- Jayschwa 6y ago
  > I wish someone would make a language that was both as good as Zig or Rust, and could be compiled to C code. Zig will eventually have this feature. It is a work-in-progress: https://github.com/ziglang/zig/blob/master/src/codegen/c.zig https://github.com/ziglang/zig/blob/master/src/codegen/c.zig
nine_k 6y ago
The whole comptime stuff is very un-C.
- 59nadir 6y ago
  But a strict improvement on the preprocessor madness that you have to get into with C. Having `static if`-like behavior is much preferable to `#ifdef` and the like and other things falling out of that system is just a bonus. It's tempting to view `comptime` as additional complexity, but the truth is that it replaces a much more complicated and hard-to-work-with system. That one is just one that people have gotten used to over decades.

deleted 6y ago

[deleted]

johnisgood 6y ago

> The comptime feature is probably the most exciting thing I've seen in a while Just please do not make the mistake of believing that it is unique to Zig. Factor brings the best of Forth and Lisp together, so meta-programming or extending the language is possible quite easily, for example. You could extend the syntax or add constructs pretty easily, and so forth. Anyways, an example can be found here: https://rosettacode.org/wiki/Compile-time_calculation#Factor https://rosettacode.org/wiki/Compile-time_calculation#Factor but this barely scratches the surface. It does not mention `<< ... >>` which evaluates some code at parse time. You can execute code before the words in a source file are compiled. https://docs.factorcode.org/content/article-literals.html https://docs.factorcode.org/content/article-literals.html https://docs.factorcode.org/content/article-syntax-literals.html https://docs.factorcode.org/content/article-syntax-literals.... https://docs.factorcode.org/content/article-syntax-immediate.html https://docs.factorcode.org/content/article-syntax-immediate... https://docs.factorcode.org/content/word-flags{,literals.html https://docs.factorcode.org/content/word-flags{,literals.htm... I remember when I did something like: SYMBOL: aligned-16-char << : 16-byte-alignment ( c-type -- c-type ) 16 >>align 16 >>align-first ; char lookup-c-type clone 16-byte-alignment \ aligned-16-char typedef >> when I was working on some binding. You could use it in a struct like: STRUCT: foo { bar aligned-16-char[16] } ; Or something like this is pretty typical (when writing bindings/ffi): << "libotr" { { [ os windows? ] [ "libotr.dll" ] } { [ os macosx? ] [ "libotr.dylib" ] } { [ os unix? ] [ "libotr.so" ] } } cond cdecl add-library >> Those are just some examples, but it is pretty powerful. It supports (and encourages) interactive development. Profiling and debugging is a breeze and highly detailed and useful, you can easily disassemble words (functions), you can get a list of how many times malloc has been called in some circumstances, there is runtime code reloading (a vocabulary that implements automatic reloading of changed source files[1]), and so on. And on top of all this, you can compile your stuff to an executable that is less than 4 MB! And of course you do not have to do stack shuffling at all, you can easily use locals which is useful for math equations and whatnot. Plus did you know that the Factor compiler supports advanced compiler optimizations that take advantage of the type information it can glean from source code? The typed vocabulary (yes, it is not part of the language, but implemented as a vocab) provides syntax that allows words to provide checked type information about their inputs and outputs and improve the performance of compiled code. I would like to repeat because if this was not the case, I would have never bothered with it: you can create a single executable file that is less than 4 MB of size if you wish so! Of course it encourages interactive development, but still, it is great to have an optimizing compiler that can do all this easily. And mind you, this part is also written in Factor itself and is available as a vocabulary (vocab). [1] There is a vocabulary named io.monitors and loaded source files across all vocabulary roots are monitored for changes. You can read more about it here: https://docs.factorcode.org/content/article-vocabs.refresh.html https://docs.factorcode.org/content/article-vocabs.refresh.h... --- So all in all, I think Factor is great. I was shocked at how modern (and how many) libraries it has, especially considering only a handful of people have been working on it. Slava Pestov created the language, and some people joined him later on. If you want to learn more about it, start here: https://concatenative.org/wiki/view/Factor https://concatenative.org/wiki/view/Factor. There are videos, there are papers, there are lots of resources to get started. :) The language misses a couple of things, but it is being worked on.

gridlockd 6y ago
> Just please do not make the mistake of believing that it is unique to Zig. Factor brings the best of Forth and Lisp together... What is unique to Zig is that it has these features without bringing together "the best of Forth and Lisp". Sometimes, just being pedestrian is a virtue.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- moomin 6y ago
  But comptime is kind of LISP's unique feature, it's just called macros. EDIT: In fairness, Zig's presentation is pretty likeable. You can do a comptime expression pretty trivially in LISP, a comptime parameter or block would require actual effort.
  - patrec 6y ago
    No. There is a real difference between staged computation of the type that zig has and macros in common lisp, scheme/rust have (so much for lisp's uniqueness BTW). In common lisp you can do completely arbitrary computation at compile- (or read-)time in zig you cannot and crucially you are also not responsible for manually ordering the "stages". E.g. in common lisp you have use eval-when to make sure that stuff is available at the right phase, whereas zig works out the dependency for you.
    - creata 6y ago
      Can you please provide an example of Zig "working out the dependency"? I'm struggling to make sense of your comment.
      - patrec 6y ago

kristianpaul 6y ago

Although Rust syntax might feel familiar with other languages the point of comparison shouldn't end there. The Rust language community is big and growing (including the number of Crates) and the mindset behind writing safe code is actually what got me interested in the first place. I’m glad that other languages are inspired by that and are able to provide some of those features on their specific niches (like in the case of Zim is simplicity)

sacado2 6y ago

Yes. I think Zig is a safer C, while Rust is a safer C++. C programmers will be more excited by Zig than by rust, and the opposite is true for C++ afficionados.

pron 6y ago
Those are nice taglines, but while Rust is a safer C++ in the sense that it is a language that espouses C++'s design philosophy and has a similar feel to it, Zig is something new altogether. The only thing that makes it more similar to C than to C++ is that C is an extremely simple language, as is Zig, while C++ is an extremely complex language. But other than that, Zig is a low-level language that is its own family, and with a design that is radically different from either C or C++; it's hard to compare it to anything, really. Zig goes well beyond C in its power of abstraction to match C++/Rust, but it does so in a very different way than C++/Rust.
- jonahx 6y ago
  > in the sense that it is a language that espouses C++'s design philosophy Could you elaborate on this?
  - pron 6y ago
    They're low-level languages -- with all the attention to low-level detail all low-level languages require -- that aim to appear like high-level code on the page. All the same details are still there, and you must confront them when changing the code, but they don't appear as text when you look at the code.
JoshTriplett 6y ago
> C programmers will be more excited by Zig than by rust I'm a C programmer. I haven't touched C++ since before C++11 became a thing, and I prefer C to C++. I'm much more excited by Rust.
roca 6y ago
The safety guarantees of Rust are much stronger than Zig's. For example Rust statically prevents use-after-free and data races, and Zig doesn't (and I don't think anyone expects it ever to). To me this matters more than which one is more like C or C++ (partly because I don't think Rust is very much like either).

steveklabnik 6y ago

"Rust is a competitor to C++, not C" is a meme, and there's some truth there, but I don't think it's all that accurate. I know lots of folks who prefer C to C++, but still like Rust. I do think that these sorts of language comparisons are useful, but they don't always generalize. Partially this is because what a language means to each person can vary. As long as they're understood in a very coarse grained way, I think they can still make sense, but it's tricky!

mumblemumble 6y ago
> I know lots of folks who prefer C to C++, but still like Rust. I'm one of those people, and, while I have yet to use Rust or Zig for any real work, at least so far I also see Rust as being more directly a competitor to C++, and Zig as the more direct competitor to C. Or perhaps I should say analogue. Because, it's true, I might choose Rust over C. I'm even tentatively planning to, for one project that's still in the idea phase, and that I would normally have wanted to do in C. Though that's not really because I see Rust as being more C-like. It's more that I see choosing Rust as being perhaps more likely to be worth the extra effort than I've found to be the case for C++.
- steveklabnik 6y ago
  Yes, it also can matter what you even mean by "competitor." Some people take it to mean "similarity in language features." Others can take it to mean "would I choose it as a substitute." Some take it to mean "would I choose it as a substitute for this specific domain or project." I've seen this play out a number of times. "Rust cannot compete with C, because C is too entrenched in embedded." "I do embedded development in Rust, so it can." "Well, I work with these chips that Rust can't target yet, so it can't, for me." None of these statements are incorrect, but they can lead to huge back-and-forths. Words are hard.
  - deleted 6y ago
    [deleted]
drran 6y ago

optymizer 6y ago

I've been enjoying D as "C done right". I find it a pleasure to use.

wk_end 6y ago
D is much more "C++ done right" (and then some). C and Zig are very barebones, close-to-the-metal language. D has garbage collection, classes, templates, exceptions, built-in dynamic arrays and hash tables, and on and on and on. The "Features Overview" page makes me go cross-eyed [1]. Yes, you can turn many of these things off or ignore them and just use D as a better C, but the same could be said of C++ (for some definition of "better"). Or most languages, really, if you squint enough. [1] https://dlang.org/comparison.html https://dlang.org/comparison.html
- dnautics 6y ago
  I almost feel like D is "go done right" (I am aware that D precedes go).
- optymizer 6y ago
  Yes, and people do use C++ as a better C to get OO and a stronger type system, at the cost of compilation times (and the usual C++ pitfalls). I use D as better C. I use it as better C++ at times. Once ownership/borrowing [1] is stable, I'll use it as a better Rust too. For close-to-the-metal code, I use D's inline assembler [2]. "To go any lower level than that, you'd need a miniature soldering iron and a very, very steady hand." (Andrei Alexandrescu) [1] https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... [2] https://dlang.org/spec/iasm.html https://dlang.org/spec/iasm.html
- p0nce 6y ago
  But native code is native code, there isn't a magical layer underneath that would make Zig closer to the metal than D, unless perhaps the voluntary Undefined Behaviour zig is willing to take such as those for loops.
- tastyminerals2 6y ago

ironmagma 6y ago

It's almost just C without the warts; I wish someone would make a language that was both as good as Zig or Rust, and could be compiled to C code. The dependency on LLVM rules out a lot of embedded use cases, because some chipsets require forks of LLVM, or worse, proprietary C compilers or forks of GCC or something else, to run. Would be nice to have a language that just works everywhere.

qppo 6y ago
I feel like the onus should be on chip makers to write LLVM backends because proprietary C compilers and GCC forks almost universally suck. I understand why they don't, but it's just disappointing on both ends of the pipeline. That said, ARM is great, and you can target most ARM chips with LLVM. There's also the downside that transpiling to C locks you into an ABI, which limits what compiler developers can do towards the end of the compilation passes.
Jayschwa 6y ago
> I wish someone would make a language that was both as good as Zig or Rust, and could be compiled to C code. Zig will eventually have this feature. It is a work-in-progress: https://github.com/ziglang/zig/blob/master/src/codegen/c.zig https://github.com/ziglang/zig/blob/master/src/codegen/c.zig

nine_k 6y ago

The whole comptime stuff is very un-C.

59nadir 6y ago
But a strict improvement on the preprocessor madness that you have to get into with C. Having `static if`-like behavior is much preferable to `#ifdef` and the like and other things falling out of that system is just a bonus. It's tempting to view `comptime` as additional complexity, but the truth is that it replaces a much more complicated and hard-to-work-with system. That one is just one that people have gotten used to over decades.