6 ms·

I like the Zig language and tooling. I do wish there was a safety mode that give the same guarantees as Rust, but it’s a huge step above C/C++. I am also extrem

I like the Zig language and tooling. I do wish there was a safety mode that give the same guarantees as Rust, but it’s a huge step above C/C++. I am also extremely impressed with the Zig compiler. Perhaps the safety is the tradeoff with the comparative ease of using the language compared to Rust, but I’d love the best of both worlds if it were possible

hermanradtke 1y ago
I wish for “strict” mode as well. My current thinking: TypeScript is to JavaScript as Zig is to C I am a huge TS fan.
- rc00 1y ago
  Is Zig aiming to extend C or extinguish it? The embrace story is well-established at this point but the remainder is often unclear in the messaging from the community.
  - dooglius 1y ago
    Zig is open source, so the analogy to Microsoft's EEE [0] seems misplaced. [0] https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish?useskin=vector https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...
    - rc00 1y ago
      Open source or not isn't the point. The point is the mission and the ecosystem. Some of the Zig proponents laud the C compatibility. Others are seeking out the "pure Zig" ecosystem. Curious onlookers want to know if the Zig ecosystem and community will be as hostile to the decades of C libraries as the Rust zealots have been. To be fair, I don't believe there is a centralized and stated mission with Zig but it does feel like the story has moved beyond the "Incrementally improve your C/C++/Zig codebase" moniker.
      - Zambyte 1y ago
        > Curious onlookers want to know if the Zig ecosystem and community will be as hostile to the decades of C libraries as the Rust zealots have been. Definitely not the case in Zig. From my experience, the relationship with C libraries amounts to "if it works, use it".
        rc00 1y ago
        Are you referring to static linking? Dynamic linking? Importing/inclusion? How does this translate (no pun intended) when the LLVM backend work is completed? Does this extend to reproducible builds? Hermetic builds? And the relationship with C libraries certainly feels like a placeholder, akin to before the compiler was self-hosted. While I have seen some novel projects in Zig, there are certainly more than a few "pure Zig" rewrites of C libraries. Ultimately, this is free will. I just wonder if the Zig community is teeing up for a repeat of Rust's actix-web drama but rather than being because of the use of unsafe, it would be due to the use of C libraries instead of the all-Zig counterparts (assuming some level of maturity with the latter). While Zig's community appears healthier and more pragmatic, hype and ego have a way of ruining everything.
        Zambyte 1y ago
        > static linking? Yes > Dynamic linking? Yes > Importing/inclusion? Yes > How does this translate (no pun intended) when the LLVM backend work is completed? I'm not sure what you mean. It sounds like you think they're working on being able to use LLVM as a backend, but that has already been supported, and now they're working on not depending on LLVM as a requirement. > Does this extend to reproducible builds? My hunch would be yes, but I'm not certain. > Hermetic builds? I have never heard of this, but I would guess the same as reproducible. > While I have seen some novel projects in Zig, there are certainly more than a few "pure Zig" rewrites of C libraries. It's a nice exercise, especially considering how close C and Zig are semantically. It's helpful for learning to see how C things are done in Zig, and rewriting things lets you isolate that experience without also being troubled with creating something novel. For more than a few not rewrites, check out https://github.com/allyourcodebase https://github.com/allyourcodebase, which is a group that repackages existing C libraries with the Zig package manager / build system.
  - PaulRobinson 1y ago
    It's improved C. C interop is very important, and very valuable. However, by removing undefined behaviours, replacing macros that do weird things with well thought-through comptime, and making sure that the zig compiler is also a c compiler, you get a nice balance across lots of factors. It's a great language, I encourage people to dig into it.
  - yellowapple 1y ago
    The goal rather explicitly seems to be to extinguish it - the idea being that if you've got Zig, there should be no reason to need to write new code in C, because literally anything possible in C should be possible (and ideally done better) in Zig. Whether that ends up happening is obviously yet to be seen; as it stands there are plenty of Zig codebases with C in the mix. The idea, though, is that there shouldn't be anything stopping a programmer from replacing that C with Zig, and the two languages only coexist for the purpose of allowing that replacement to be gradual.
xedrac 1y ago
I like Zig as a replacement for C, but not C++ due to its lack of RAII. Rust on the other hand is a great replacement for C++. I see Zig as filling a small niche where allocation failures are paramount - very constrained embedded devices, etc... Otherwise, I think you just get a lot more with Rust.
- xmorse 1y ago
  Even better than RAII would be linear types, but it would require a borrow checker to track the lifetimes of objects. Then you would get a compiler error if you forget to call a .destroy() method
  - throwawaymaths 1y ago
    no you just need analysis with a dependent type system (which linear types are a subset of). it doesn't have to be in the compiler. there was a proof of concept here a few months ago: https://news.ycombinator.com/item?id=42923829 https://news.ycombinator.com/item?id=42923829 https://news.ycombinator.com/item?id=43199265 https://news.ycombinator.com/item?id=43199265
- rastignack 1y ago
  Compile times and painful to refactor codebase are rust’s main drawbacks for me though. It’s totally subjective but I find the language boring to use. For side projects I like having fun thus I picked zig. To each his own of course.
  - nicce 1y ago
    > refactor codebase are rust’s main drawbacks Hard disagree about refactoring. Rust is one of the few languages where you can actually do refactoring rather safely without having tons of tests that just exist to catch issues if code changes.
    - rastignack 1y ago
      Lifetimes and generic tend to leak so you have to modify your code all around the place when you touch them though.
ksec 1y ago
>but I’d love the best of both worlds if it were possible I am just going to quote what pcwalton said the other day that perhaps answer your question. >> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compiler, dudes. > That exists; it's called garbage collection. >If you don't want the performance characteristics of garbage collection, something has to give. Either you sacrifice memory safety or you accept a more restrictive paradigm than GC'd languages give you. For some reason, programming language enthusiasts think that if you think really hard, every issue has some solution out there without any drawbacks at all just waiting to be found. But in fact, creating a system that has zero runtime overhead and unlimited aliasing with a mutable heap is as impossible as finding two even numbers whose sum is odd. [1] https://news.ycombinator.com/item?id=43726315 https://news.ycombinator.com/item?id=43726315
- skybrian 1y ago
  Yes, but I’m not hoping for that. I’m hoping for something like a scripting language with simpler lifetime annotations. Is Rust going to be the last popular language to be invented that explores that space? I hope not.
  - hyperbrainer 1y ago
    I was quite impressed with Austral[0], which used Linear Types and avoids the whole Rust-like implementation in favour of a more easily understandable system, albeit slightly more verbose. [0]https://borretti.me/article/introducing-austral https://borretti.me/article/introducing-austral
    - renox 1y ago
      Austra's concept are interesting but the introduction doesn't show how to handle correctly errors in this language..
      - 1y ago
throwawaymaths 1y ago
in principle it should be doable, possibly not in the language/compiler itself, there was this POC a few months ago: https://github.com/ityonemo/clr https://github.com/ityonemo/clr
pjmlp 1y ago
Most of Zig's safety was already available in 1978's Modula-2, but apparently languages have to come in curly brackets for adoption.
- chongli 1y ago
  languages have to come in curly brackets for adoption Python and Ruby are two very popular counterexamples.
  - pjmlp 1y ago
    Not really, Ruby has plenty of curly brackets, e.g. 5.times { puts "hello!" }. In both cases, while it wasn't curly brackets that drove their adoption, it was unavoidable frameworks. Most people only use Ruby when they have Rails projects, and what made Python originally interesting was Zope CMS. And nowadays AI/ML frameworks, that are actually written in C, C++ and Fortran, making Python relevant because scientists decided on picking Python for their library bindings, it could have been Tcl just as well, as choices go. So yeah, maybe not always curly brackets, but definitly something that makes it unavoidable, sadly Modula-2 lacked that, an OS vendor pushing it no matter what, FAANG style.
    - pklausler 1y ago
      Which AI/ML frameworks are written in Fortran?
      - pjmlp 1y ago
        Probably none, it was more a kind of expression, given the tradition of "Python" libraries, that are actually bindings to C, C++, Fortran libraries.

hermanradtke 1y ago

I wish for “strict” mode as well. My current thinking: TypeScript is to JavaScript as Zig is to C I am a huge TS fan.

rc00 1y ago
Is Zig aiming to extend C or extinguish it? The embrace story is well-established at this point but the remainder is often unclear in the messaging from the community.
- dooglius 1y ago
  Zig is open source, so the analogy to Microsoft's EEE [0] seems misplaced. [0] https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish?useskin=vector https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...
  - rc00 1y ago
    Open source or not isn't the point. The point is the mission and the ecosystem. Some of the Zig proponents laud the C compatibility. Others are seeking out the "pure Zig" ecosystem. Curious onlookers want to know if the Zig ecosystem and community will be as hostile to the decades of C libraries as the Rust zealots have been. To be fair, I don't believe there is a centralized and stated mission with Zig but it does feel like the story has moved beyond the "Incrementally improve your C/C++/Zig codebase" moniker.
    - Zambyte 1y ago
      > Curious onlookers want to know if the Zig ecosystem and community will be as hostile to the decades of C libraries as the Rust zealots have been. Definitely not the case in Zig. From my experience, the relationship with C libraries amounts to "if it works, use it".
      - rc00 1y ago
        Are you referring to static linking? Dynamic linking? Importing/inclusion? How does this translate (no pun intended) when the LLVM backend work is completed? Does this extend to reproducible builds? Hermetic builds? And the relationship with C libraries certainly feels like a placeholder, akin to before the compiler was self-hosted. While I have seen some novel projects in Zig, there are certainly more than a few "pure Zig" rewrites of C libraries. Ultimately, this is free will. I just wonder if the Zig community is teeing up for a repeat of Rust's actix-web drama but rather than being because of the use of unsafe, it would be due to the use of C libraries instead of the all-Zig counterparts (assuming some level of maturity with the latter). While Zig's community appears healthier and more pragmatic, hype and ego have a way of ruining everything.
        Zambyte 1y ago
        > static linking? Yes > Dynamic linking? Yes > Importing/inclusion? Yes > How does this translate (no pun intended) when the LLVM backend work is completed? I'm not sure what you mean. It sounds like you think they're working on being able to use LLVM as a backend, but that has already been supported, and now they're working on not depending on LLVM as a requirement. > Does this extend to reproducible builds? My hunch would be yes, but I'm not certain. > Hermetic builds? I have never heard of this, but I would guess the same as reproducible. > While I have seen some novel projects in Zig, there are certainly more than a few "pure Zig" rewrites of C libraries. It's a nice exercise, especially considering how close C and Zig are semantically. It's helpful for learning to see how C things are done in Zig, and rewriting things lets you isolate that experience without also being troubled with creating something novel. For more than a few not rewrites, check out https://github.com/allyourcodebase https://github.com/allyourcodebase, which is a group that repackages existing C libraries with the Zig package manager / build system.
- PaulRobinson 1y ago
  It's improved C. C interop is very important, and very valuable. However, by removing undefined behaviours, replacing macros that do weird things with well thought-through comptime, and making sure that the zig compiler is also a c compiler, you get a nice balance across lots of factors. It's a great language, I encourage people to dig into it.
- yellowapple 1y ago
  The goal rather explicitly seems to be to extinguish it - the idea being that if you've got Zig, there should be no reason to need to write new code in C, because literally anything possible in C should be possible (and ideally done better) in Zig. Whether that ends up happening is obviously yet to be seen; as it stands there are plenty of Zig codebases with C in the mix. The idea, though, is that there shouldn't be anything stopping a programmer from replacing that C with Zig, and the two languages only coexist for the purpose of allowing that replacement to be gradual.

xedrac 1y ago

I like Zig as a replacement for C, but not C++ due to its lack of RAII. Rust on the other hand is a great replacement for C++. I see Zig as filling a small niche where allocation failures are paramount - very constrained embedded devices, etc... Otherwise, I think you just get a lot more with Rust.

xmorse 1y ago
Even better than RAII would be linear types, but it would require a borrow checker to track the lifetimes of objects. Then you would get a compiler error if you forget to call a .destroy() method
- throwawaymaths 1y ago
  no you just need analysis with a dependent type system (which linear types are a subset of). it doesn't have to be in the compiler. there was a proof of concept here a few months ago: https://news.ycombinator.com/item?id=42923829 https://news.ycombinator.com/item?id=42923829 https://news.ycombinator.com/item?id=43199265 https://news.ycombinator.com/item?id=43199265
rastignack 1y ago
Compile times and painful to refactor codebase are rust’s main drawbacks for me though. It’s totally subjective but I find the language boring to use. For side projects I like having fun thus I picked zig. To each his own of course.
- nicce 1y ago
  > refactor codebase are rust’s main drawbacks Hard disagree about refactoring. Rust is one of the few languages where you can actually do refactoring rather safely without having tons of tests that just exist to catch issues if code changes.
  - rastignack 1y ago
    Lifetimes and generic tend to leak so you have to modify your code all around the place when you touch them though.

ksec 1y ago

>but I’d love the best of both worlds if it were possible I am just going to quote what pcwalton said the other day that perhaps answer your question. >> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compiler, dudes. > That exists; it's called garbage collection. >If you don't want the performance characteristics of garbage collection, something has to give. Either you sacrifice memory safety or you accept a more restrictive paradigm than GC'd languages give you. For some reason, programming language enthusiasts think that if you think really hard, every issue has some solution out there without any drawbacks at all just waiting to be found. But in fact, creating a system that has zero runtime overhead and unlimited aliasing with a mutable heap is as impossible as finding two even numbers whose sum is odd. [1] https://news.ycombinator.com/item?id=43726315 https://news.ycombinator.com/item?id=43726315

skybrian 1y ago
Yes, but I’m not hoping for that. I’m hoping for something like a scripting language with simpler lifetime annotations. Is Rust going to be the last popular language to be invented that explores that space? I hope not.
- hyperbrainer 1y ago
  I was quite impressed with Austral[0], which used Linear Types and avoids the whole Rust-like implementation in favour of a more easily understandable system, albeit slightly more verbose. [0]https://borretti.me/article/introducing-austral https://borretti.me/article/introducing-austral
  - renox 1y ago
    Austra's concept are interesting but the introduction doesn't show how to handle correctly errors in this language..
    - 1y ago

throwawaymaths 1y ago

in principle it should be doable, possibly not in the language/compiler itself, there was this POC a few months ago: https://github.com/ityonemo/clr https://github.com/ityonemo/clr

pjmlp 1y ago

Most of Zig's safety was already available in 1978's Modula-2, but apparently languages have to come in curly brackets for adoption.

chongli 1y ago
languages have to come in curly brackets for adoption Python and Ruby are two very popular counterexamples.
- pjmlp 1y ago
  Not really, Ruby has plenty of curly brackets, e.g. 5.times { puts "hello!" }. In both cases, while it wasn't curly brackets that drove their adoption, it was unavoidable frameworks. Most people only use Ruby when they have Rails projects, and what made Python originally interesting was Zope CMS. And nowadays AI/ML frameworks, that are actually written in C, C++ and Fortran, making Python relevant because scientists decided on picking Python for their library bindings, it could have been Tcl just as well, as choices go. So yeah, maybe not always curly brackets, but definitly something that makes it unavoidable, sadly Modula-2 lacked that, an OS vendor pushing it no matter what, FAANG style.
  - pklausler 1y ago
    Which AI/ML frameworks are written in Fortran?
    - pjmlp 1y ago
      Probably none, it was more a kind of expression, given the tradition of "Python" libraries, that are actually bindings to C, C++, Fortran libraries.