6 ms·

What interests me most by zig is the ease of the build system, cross compilation, and the goal of high iteration speed. I'm a gamedev, so I have performance req

What interests me most by zig is the ease of the build system, cross compilation, and the goal of high iteration speed. I'm a gamedev, so I have performance requirements but I think most languages have sufficient performance for most of my requirements so it's not the #1 consideration for language choice for me. I feel like I can write powerful code in any language, but the goal is to write code for a framework that is most future proof, so that you can maintain modular stuff for decades. C/C++ has been the default answer for its omnipresent support. It feels like zig will be able to match that.

FlyingSnake 1y ago
I recently, for fun, tried running zig on an ancient kindle device running stripped down Linux 4.1.15. It was an interesting experience and I was pleasantly surprised by the maturity of Zig. Many things worked out of the box and I could even debug a strange bug using ancient GDB. Like you, I’m sold on Zig too. I wrote about it here: https://news.ycombinator.com/item?id=44211041 https://news.ycombinator.com/item?id=44211041
osigurdson 1y ago
I've dabbled in Rust, liked it, heard it was bad so kind of paused. Now trying it again and still like it. I don't really get why people hate it so much. Ugly generics - same thing in C# and Typescript. Borrow checker - makes sense if you have done low level stuff before.
- int_19h 1y ago
  If you don't happen to come across some task that implies a data model that Rust is actively hostile towards (e.g. trees with backlinks, or more generally any kind of graph with cycles in it), borrow checker is not much of a hassle. But the moment you hit something like that, it becomes a massive pain, and requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) or patterns like using indices instead of pointers which are counter to high performance and effectively only serve to work around the borrow checker to shut it up.
  - dwattttt 1y ago
    > the moment you hit something like that, it becomes a massive pain, and requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) or patterns like using indices instead of pointers If you need to make everything in-house this is the experience. For the majority though, the moment you require those things you reach for a crate that solves those problems.
  - carlmr 1y ago
    >requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) Um, what? Unsafe Rust code still has a lot more safety checks applied than C. >It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any of Rust’s other safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block. https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
  - Ar-Curunir 1y ago
    I’m sorry, but your comment is a whole lot of horseshit. Unsafe rust still has a bunch of checks C doesn’t have, and using indices into vectors is common code in high performance code (including Zig!)
  - creata 1y ago
    > patterns like using indices instead of pointers which are counter to high performance Using indices isn't bad for performance. At the very least, it can massively cut down on memory usage (which is in turn good for performance) if you can use 16-bit or 32-bit indices instead of full 64-bit pointers. > "unsafe" (which is strictly more dangerous than even C, never mind Zig) Unsafe Rust is much safer than C. The only way I can imagine unsafe Rust being more dangerous than C is that you need to keep exception safety in mind in Rust, but not in C.
    - whytevuhuni 1y ago
      Not quite, you also need to keep pointer non-nullness, alignment and aliasing safety in Rust, which is very pervasive in Rust (all shared/mutable references) but very rare in C (the 'restricted' keyword). In Rust, it's not just using an invalid reference that causes UB, but their very creation, even if temporary. For example, since references have to always be aligned, the compiler can assume the pointer they were created from was also aligned, and so suddenly some ending bits from the pointer are ignored (since they must've been zero). And usually the point of unsafe is to make safe wrappers, so unafe Rust makes or interacts with safe shared/mutable references pretty often.
- sapiogram 1y ago
  Haters gonna hate. If you're working on a project that needs performance and correctness, nothing can get the job done like Rust.
  - LAC-Tech 1y ago
    unless you have to do anything that relies on a C API (such as provided by an OS) with no concept of ownership, then it's a massive task to get that working well with idiomatic rust. You need big glue layers to really make it work. Rust is a general purpose language that can do systems programming. Zig is a systems programming language. (Safety Coomers please don't downvote)
    - saghm 1y ago
      What does it even mean to be able to "do systems programming" but not actually be a "systems programming language"? I would directly disagree with you, but what you're arguing is so vague that I don't even know what you're trying to claim. The only way I can make sense of this is if you literally define a "systems programming language" as C and only other things that are tightly tied to it, which I guess is fine if you like tautologies but kind of makes even having a concept of " systems programming language" pretty useless.
    - bbkane 1y ago
      And yet Rust in the one in the Linux and Windows kernels, so people must think it's worth the effort. https://threadreaderapp.com/thread/1577667445719912450.html https://threadreaderapp.com/thread/1577667445719912450.html is certainly a glowing recommendation
      - LAC-Tech 1y ago
        Kernels are big pieces of software. Rust is used for device drivers mainly, right? So in that case you write an idiomatic rust lib and wrap it in a C interface and load it in. Actually interfacing with idiomatic C APIs provided by an OS is something else entirely. You can see this is when you compare the Rust ecosystem to Zig; ie Zig has a fantastic io-uring library in the std lib, where as rust has a few scattered crates none of which come close the Zig's ease of use and integration. One thing I'd like to see is an OS built with rust that could provide its own rusty interface to kernel stuff.
- dgb23 1y ago
  Both are great languages. To me there's a philosophical difference, which can impact one to prefer one over the other: Rust makes doing the wrong thing hard, Zig makes doing the right thing easy.
raincole 1y ago
I wonder how zig works on consoles. Usually consoles hate anything that's not C/C++. But since zig can be transpiled to C, perhaps it's not completely ruled out?
- jeroenhd 1y ago
  Consoles will run anything you compile for them. There are stable compilers for most languages for just about any console I know of, because modern consoles are pretty much either amd64 or aarch64 like phones and computers are. Language limitations are more on the SDK side of things. SDKs are available under NDAs and even publicly available APIs are often proprietary. "Real" test hardware (as in developer kits) is expensive and subject to NDAs too. If you don't pick the language the native SDK comes with (which is often C(++)), you'll have to write the language wrappers yourself, because practically no free, open, upstream project can maintain those bindings for you. Alternatively, you can pay a company that specializes in the process, like the developers behind Godot will tell you to do: https://docs.godotengine.org/en/stable/tutorials/platform/consoles.html https://docs.godotengine.org/en/stable/tutorials/platform/co... I think Zig's easy C interop will make integration for Zig into gamedev quite attractive, but as the compiler still has bugs and the language itself is ever changing, I don't think any big companies will start developing games in Zig until the language stabilizes. Maybe some indie devs will use it, but it's still a risk to take.
haberman 1y ago
> I feel like I can write powerful code in any language, but the goal is to write code for a framework that is most future proof, so that you can maintain modular stuff for decades. I like Zig a lot, but long-term maintainability and modularity is one of its weakest points IMHO. Zig is hostile to encapsulation. You cannot make struct members private: https://github.com/ziglang/zig/issues/9909#issuecomment-942686366 https://github.com/ziglang/zig/issues/9909#issuecomment-9426... Key quote: > The idea of private fields and getter/setter methods was popularized by Java, but it is an anti-pattern. Fields are there; they exist. They are the data that underpins any abstraction. My recommendation is to name fields carefully and leave them as part of the public API, carefully documenting what they do. You cannot reasonably form API contracts (which are the foundation of software modularity) unless you can hide the internal representation. You need to be able to change the internal representation without breaking users. Zig's position is that there should be no such thing as internal representation; you should publicly expose, document, and guarantee the behavior of your representation to all users. I hope Zig reverses this decision someday and supports private fields.
- deleted 1y ago
  [deleted]
- eddd-ddde 1y ago
  Just prefix internal fields with underscore and be a big boy and don't access them from the outside. If you really need to you can always use opaque pointers for the REALLY critical public APIs.
  - haberman 1y ago
    I am not the only user of my API, and I cannot control what users do. My experience is that users who are trying to get work done will bypass every speed bump you put in the way and just access your internals directly. If you "just" rely on them not to do that, then your internals will effectively be frozen forever.
    - nicoburns 1y ago
wg0 1y ago
Zig seems to be simpler Rust and better Go. Off topic - One tool built on top of Zig that I really really admire is bun. I cannot tell how much simpler my life is after using bun. Similar things can be said for uv which is built in Rust.
- FlyingSnake 1y ago
  Zig is nothing like Go. Go uses GC and a runtime while Zig has none. While Zig’s functions aren’t coloured, it lacked the CSP style primitives like goroutines and channels.
- 9d 1y ago
  Zig is like a highly opinionated modern C Rust is like a highly opinionated modern C++ Go is like a highly opinionated pre-modern C with GC
  - deleted 1y ago
    [deleted]
  - cgh 1y ago
    In a previous comment, you remarked you don’t even know Zig.
    - 9d 1y ago
      I don't.
    - LexiMax 1y ago
      I do. I find his osmosis-based summation accurate.
      - 9d 1y ago
        Yay!
- gf000 1y ago
  Go should be as much in this discussion as JavaScript.
9d 1y ago
> C/C++ has been the default You're not really going to make something better than C. If you try, it will most likely become C++ anyway. But do try anyway. Rust and Zig are evidence that we still dream that we can do better than C and C++. Anyway I'm gonna go learn C++.
- flohofwoe 1y ago
  C++ has been piling more new problems on top of C than it inherited from C in the first place (and C++ is now caught in a cycle of trying to fix problems it introduced a couple of versions ago). Creating a better C successor than C++ is really not a high bar.

FlyingSnake 1y ago

I recently, for fun, tried running zig on an ancient kindle device running stripped down Linux 4.1.15. It was an interesting experience and I was pleasantly surprised by the maturity of Zig. Many things worked out of the box and I could even debug a strange bug using ancient GDB. Like you, I’m sold on Zig too. I wrote about it here: https://news.ycombinator.com/item?id=44211041 https://news.ycombinator.com/item?id=44211041

osigurdson 1y ago

I've dabbled in Rust, liked it, heard it was bad so kind of paused. Now trying it again and still like it. I don't really get why people hate it so much. Ugly generics - same thing in C# and Typescript. Borrow checker - makes sense if you have done low level stuff before.

int_19h 1y ago
If you don't happen to come across some task that implies a data model that Rust is actively hostile towards (e.g. trees with backlinks, or more generally any kind of graph with cycles in it), borrow checker is not much of a hassle. But the moment you hit something like that, it becomes a massive pain, and requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) or patterns like using indices instead of pointers which are counter to high performance and effectively only serve to work around the borrow checker to shut it up.
- dwattttt 1y ago
  > the moment you hit something like that, it becomes a massive pain, and requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) or patterns like using indices instead of pointers If you need to make everything in-house this is the experience. For the majority though, the moment you require those things you reach for a crate that solves those problems.
- carlmr 1y ago
  >requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) Um, what? Unsafe Rust code still has a lot more safety checks applied than C. >It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any of Rust’s other safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block. https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
- Ar-Curunir 1y ago
  I’m sorry, but your comment is a whole lot of horseshit. Unsafe rust still has a bunch of checks C doesn’t have, and using indices into vectors is common code in high performance code (including Zig!)
- creata 1y ago
  > patterns like using indices instead of pointers which are counter to high performance Using indices isn't bad for performance. At the very least, it can massively cut down on memory usage (which is in turn good for performance) if you can use 16-bit or 32-bit indices instead of full 64-bit pointers. > "unsafe" (which is strictly more dangerous than even C, never mind Zig) Unsafe Rust is much safer than C. The only way I can imagine unsafe Rust being more dangerous than C is that you need to keep exception safety in mind in Rust, but not in C.
  - whytevuhuni 1y ago
    Not quite, you also need to keep pointer non-nullness, alignment and aliasing safety in Rust, which is very pervasive in Rust (all shared/mutable references) but very rare in C (the 'restricted' keyword). In Rust, it's not just using an invalid reference that causes UB, but their very creation, even if temporary. For example, since references have to always be aligned, the compiler can assume the pointer they were created from was also aligned, and so suddenly some ending bits from the pointer are ignored (since they must've been zero). And usually the point of unsafe is to make safe wrappers, so unafe Rust makes or interacts with safe shared/mutable references pretty often.
sapiogram 1y ago
Haters gonna hate. If you're working on a project that needs performance and correctness, nothing can get the job done like Rust.
- LAC-Tech 1y ago
  unless you have to do anything that relies on a C API (such as provided by an OS) with no concept of ownership, then it's a massive task to get that working well with idiomatic rust. You need big glue layers to really make it work. Rust is a general purpose language that can do systems programming. Zig is a systems programming language. (Safety Coomers please don't downvote)
  - saghm 1y ago
    What does it even mean to be able to "do systems programming" but not actually be a "systems programming language"? I would directly disagree with you, but what you're arguing is so vague that I don't even know what you're trying to claim. The only way I can make sense of this is if you literally define a "systems programming language" as C and only other things that are tightly tied to it, which I guess is fine if you like tautologies but kind of makes even having a concept of " systems programming language" pretty useless.
  - bbkane 1y ago
    And yet Rust in the one in the Linux and Windows kernels, so people must think it's worth the effort. https://threadreaderapp.com/thread/1577667445719912450.html https://threadreaderapp.com/thread/1577667445719912450.html is certainly a glowing recommendation
    - LAC-Tech 1y ago
      Kernels are big pieces of software. Rust is used for device drivers mainly, right? So in that case you write an idiomatic rust lib and wrap it in a C interface and load it in. Actually interfacing with idiomatic C APIs provided by an OS is something else entirely. You can see this is when you compare the Rust ecosystem to Zig; ie Zig has a fantastic io-uring library in the std lib, where as rust has a few scattered crates none of which come close the Zig's ease of use and integration. One thing I'd like to see is an OS built with rust that could provide its own rusty interface to kernel stuff.
dgb23 1y ago
Both are great languages. To me there's a philosophical difference, which can impact one to prefer one over the other: Rust makes doing the wrong thing hard, Zig makes doing the right thing easy.

raincole 1y ago

I wonder how zig works on consoles. Usually consoles hate anything that's not C/C++. But since zig can be transpiled to C, perhaps it's not completely ruled out?

jeroenhd 1y ago
Consoles will run anything you compile for them. There are stable compilers for most languages for just about any console I know of, because modern consoles are pretty much either amd64 or aarch64 like phones and computers are. Language limitations are more on the SDK side of things. SDKs are available under NDAs and even publicly available APIs are often proprietary. "Real" test hardware (as in developer kits) is expensive and subject to NDAs too. If you don't pick the language the native SDK comes with (which is often C(++)), you'll have to write the language wrappers yourself, because practically no free, open, upstream project can maintain those bindings for you. Alternatively, you can pay a company that specializes in the process, like the developers behind Godot will tell you to do: https://docs.godotengine.org/en/stable/tutorials/platform/consoles.html https://docs.godotengine.org/en/stable/tutorials/platform/co... I think Zig's easy C interop will make integration for Zig into gamedev quite attractive, but as the compiler still has bugs and the language itself is ever changing, I don't think any big companies will start developing games in Zig until the language stabilizes. Maybe some indie devs will use it, but it's still a risk to take.

haberman 1y ago

> I feel like I can write powerful code in any language, but the goal is to write code for a framework that is most future proof, so that you can maintain modular stuff for decades. I like Zig a lot, but long-term maintainability and modularity is one of its weakest points IMHO. Zig is hostile to encapsulation. You cannot make struct members private: https://github.com/ziglang/zig/issues/9909#issuecomment-942686366 https://github.com/ziglang/zig/issues/9909#issuecomment-9426... Key quote: > The idea of private fields and getter/setter methods was popularized by Java, but it is an anti-pattern. Fields are there; they exist. They are the data that underpins any abstraction. My recommendation is to name fields carefully and leave them as part of the public API, carefully documenting what they do. You cannot reasonably form API contracts (which are the foundation of software modularity) unless you can hide the internal representation. You need to be able to change the internal representation without breaking users. Zig's position is that there should be no such thing as internal representation; you should publicly expose, document, and guarantee the behavior of your representation to all users. I hope Zig reverses this decision someday and supports private fields.

deleted 1y ago
[deleted]
eddd-ddde 1y ago
Just prefix internal fields with underscore and be a big boy and don't access them from the outside. If you really need to you can always use opaque pointers for the REALLY critical public APIs.
- haberman 1y ago
  I am not the only user of my API, and I cannot control what users do. My experience is that users who are trying to get work done will bypass every speed bump you put in the way and just access your internals directly. If you "just" rely on them not to do that, then your internals will effectively be frozen forever.
  - nicoburns 1y ago

wg0 1y ago

Zig seems to be simpler Rust and better Go. Off topic - One tool built on top of Zig that I really really admire is bun. I cannot tell how much simpler my life is after using bun. Similar things can be said for uv which is built in Rust.

FlyingSnake 1y ago
Zig is nothing like Go. Go uses GC and a runtime while Zig has none. While Zig’s functions aren’t coloured, it lacked the CSP style primitives like goroutines and channels.
9d 1y ago
Zig is like a highly opinionated modern C Rust is like a highly opinionated modern C++ Go is like a highly opinionated pre-modern C with GC
- deleted 1y ago
  [deleted]
- cgh 1y ago
  In a previous comment, you remarked you don’t even know Zig.
  - 9d 1y ago
    I don't.
  - LexiMax 1y ago
    I do. I find his osmosis-based summation accurate.
    - 9d 1y ago
      Yay!
gf000 1y ago
Go should be as much in this discussion as JavaScript.

9d 1y ago

> C/C++ has been the default You're not really going to make something better than C. If you try, it will most likely become C++ anyway. But do try anyway. Rust and Zig are evidence that we still dream that we can do better than C and C++. Anyway I'm gonna go learn C++.

flohofwoe 1y ago
C++ has been piling more new problems on top of C than it inherited from C in the first place (and C++ is now caught in a cycle of trying to fix problems it introduced a couple of versions ago). Creating a better C successor than C++ is really not a high bar.