3 ms·

That comment doesn't really seem to support your statement. He may or may not be rooting for Zig, but it seems to be a stretch to derive that from this statemen

That comment doesn't really seem to support your statement. He may or may not be rooting for Zig, but it seems to be a stretch to derive that from this statement, "I have been checking on the progress for a while, and I like what I see, but I haven’t coded in it." In the same thread on Rust when asked, "What’s a better modern choice?", the response was: "Rust would be the obvious things [sic], and I don't have any reason to doubt it would be good, but I haven't implemented even a medium sized application in it." https://twitter.com/ID_AA_Carmack/status/1299574198365495297?s=20 https://twitter.com/ID_AA_Carmack/status/1299574198365495297...

abnercoimbre 6y ago
I did say "it seems" to emphasize that. Fair enough though. C is so much of a lingua franca -- especially at the ABI boundary -- that any language wishing to "replace" it must properly absorb C. Zig is the language in town succeeding in that effort.
- bluejekyll 6y ago
  Could you point to areas where you see Rust's support of the C ABI as being less than adequate than Zig? I haven't used Zig but have read about it, and am unaware of where it has improvements over Rust in this area. The specific issues I personally have run into with Rust and the C ABI are varargs (possible just not simple) and then dealing with function interfaces defined through CPP macros. Are there others you've seen?
  - abnercoimbre 6y ago
    Zig is a C compiler [0]: "Not only can Zig compile C code, but there is a very good reason to use Zig as a C compiler: Zig ships with libc" This is what I mean by properly absorbing C. Below that section, you'll also read: "One of the primary use cases for Zig is exporting a library with the C ABI for other programming languages to call into." It is unclear that Rust has shown that level of public commitment. And hey, one could argue that this stuff doesn't matter: Go famously tried to change its calling conventions. Their functions like to return at least three words, but C-based ABIs reserve at most two registers for function results, forcing Go to have their function return values on the stack. [0] https://ziglang.org/#Zig-is-also-a-C-compiler https://ziglang.org/#Zig-is-also-a-C-compiler
    - bluejekyll 6y ago
      Thanks. I didn’t actually realize Zig is itself a C compiler. Rust has pretty great support for the C ABI based on my usage. Using both the bindgen and the cbindgen tools to import/export C ABI, is really simple. The Rust language is committed to always supporting the C ABI, where functions and types are marked as such, for example: 'extern "C" fn', and for types '#[repr(C)]' Thank you for the links to Zig.
      - AndyKelley 6y ago
        There's nothing stopping Rust from doing exactly what Zig does with also being a C compiler. It's not so much a language feature as it is a compiler feature. In fact you might even say that Zig paved the way for Rust to do exactly this. I think it's pretty in line with the goals of the project and I wouldn't be surprised if they decided to go for it. It's pretty fun because Rust was a huge inspiration for Zig, and so for it to turn around and then offer improvements back to Rust is a beautiful cycle :)

abnercoimbre 6y ago

I did say "it seems" to emphasize that. Fair enough though. C is so much of a lingua franca -- especially at the ABI boundary -- that any language wishing to "replace" it must properly absorb C. Zig is the language in town succeeding in that effort.

bluejekyll 6y ago
Could you point to areas where you see Rust's support of the C ABI as being less than adequate than Zig? I haven't used Zig but have read about it, and am unaware of where it has improvements over Rust in this area. The specific issues I personally have run into with Rust and the C ABI are varargs (possible just not simple) and then dealing with function interfaces defined through CPP macros. Are there others you've seen?
- abnercoimbre 6y ago
  Zig is a C compiler [0]: "Not only can Zig compile C code, but there is a very good reason to use Zig as a C compiler: Zig ships with libc" This is what I mean by properly absorbing C. Below that section, you'll also read: "One of the primary use cases for Zig is exporting a library with the C ABI for other programming languages to call into." It is unclear that Rust has shown that level of public commitment. And hey, one could argue that this stuff doesn't matter: Go famously tried to change its calling conventions. Their functions like to return at least three words, but C-based ABIs reserve at most two registers for function results, forcing Go to have their function return values on the stack. [0] https://ziglang.org/#Zig-is-also-a-C-compiler https://ziglang.org/#Zig-is-also-a-C-compiler
  - bluejekyll 6y ago
    Thanks. I didn’t actually realize Zig is itself a C compiler. Rust has pretty great support for the C ABI based on my usage. Using both the bindgen and the cbindgen tools to import/export C ABI, is really simple. The Rust language is committed to always supporting the C ABI, where functions and types are marked as such, for example: 'extern "C" fn', and for types '#[repr(C)]' Thank you for the links to Zig.
    - AndyKelley 6y ago
      There's nothing stopping Rust from doing exactly what Zig does with also being a C compiler. It's not so much a language feature as it is a compiler feature. In fact you might even say that Zig paved the way for Rust to do exactly this. I think it's pretty in line with the goals of the project and I wouldn't be surprised if they decided to go for it. It's pretty fun because Rust was a huge inspiration for Zig, and so for it to turn around and then offer improvements back to Rust is a beautiful cycle :)