6 ms·

`zig cc` cross-compiles C, not Zig.

by woogley 5y ago

skohan 5y ago
No but I mean why the Zig cross compilation story is better than Rust according to this thread
- woogley 5y ago
  I see. I'll let the real experts add some insight but I don't think language complexity has much to do with it, considering Rust compiles to an IR first anyway. And I would say Rust has a good cross-compilation story as it is. In 2016 (!) I managed to get Rust to compile my SDL2 game to a mipsel device that used a custom GCC toolchain (http://www.gcw-zero.com/develop http://www.gcw-zero.com/develop)
- steveklabnik 5y ago
  Nothing about 'zig cc' is related to language semantics, it is entirely a toolchain feature. Language semantics do have some bearing on cross compiler difficulty, but IMHO it's not a major factor, especially within the sorts of languages that Rust and Zig are. The largest factor I can think of (compile-time code execution) exists in both Zig and Rust. It's possible I'm forgetting something, though. It doesn't exist in Rust because nobody has proposed it or implemented it, simple as that.
  - sobeston 5y ago
    I think Zig does cross compilation (ignoring for the moment, projects with C dependencies) better because it comes out-of-the-box with the libraries and headers needed to target a lot of systems. In Rust, you typically get additional toolchains via rustup, whereas Zig works on all of the targets with a single install.
    - steveklabnik 5y ago
      Absolutely, hence a toolchain thing.
      - pcwalton 5y ago
        Are you sure that we should be shipping all targets by default into one monster download? This doesn't seem particularly scalable.
        coder543 5y ago
        The whole toolchain for Zig, which appears to include complete cross compilation, is less than 40MB compressed[0]. I would hardly call that a "monster download". I think developers can spare that much space. Besides, storage space is scaling much faster than the number of available targets, so I don't see how this could be "not particularly scalable" unless you either have a weird definition of "target" or predict there's going to be a sudden explosion in the number of targets. Go also makes cross compilation to any supported target a breeze in the default toolchain download, and it is an incredible convenience for the developer. [0]: https://ziglang.org/download/ https://ziglang.org/download/
        pcwalton 5y ago
        The Xcode download, which is the only officially-supported way to develop native apps on macOS and iOS, is 9.8 GB and gets larger with every update. The Windows 10 SDK is 4 GB and likewise is only getting larger. Sure, you can develop some apps with only a subset of the SDK. But, as a language project, do you really want to be in the business of optimizing and subsetting every single OS SDK? I think a lot of the issue here comes down to targeting server workloads and command-line tools vs. apps using more of the OS libraries. In practice, Go focuses on the former kinds of apps, so shipping all targets is a more viable approach for them. But when you start getting into apps that want to use a larger swath of the platform facilities, then the size of the platform SDKs starts to become an issue.
        coder543 5y ago

`zig cc` cross-compiles C, not Zig.

skohan 5y ago

No but I mean why the Zig cross compilation story is better than Rust according to this thread

woogley 5y ago
I see. I'll let the real experts add some insight but I don't think language complexity has much to do with it, considering Rust compiles to an IR first anyway. And I would say Rust has a good cross-compilation story as it is. In 2016 (!) I managed to get Rust to compile my SDL2 game to a mipsel device that used a custom GCC toolchain (http://www.gcw-zero.com/develop http://www.gcw-zero.com/develop)
steveklabnik 5y ago
Nothing about 'zig cc' is related to language semantics, it is entirely a toolchain feature. Language semantics do have some bearing on cross compiler difficulty, but IMHO it's not a major factor, especially within the sorts of languages that Rust and Zig are. The largest factor I can think of (compile-time code execution) exists in both Zig and Rust. It's possible I'm forgetting something, though. It doesn't exist in Rust because nobody has proposed it or implemented it, simple as that.
- sobeston 5y ago
  I think Zig does cross compilation (ignoring for the moment, projects with C dependencies) better because it comes out-of-the-box with the libraries and headers needed to target a lot of systems. In Rust, you typically get additional toolchains via rustup, whereas Zig works on all of the targets with a single install.
  - steveklabnik 5y ago
    Absolutely, hence a toolchain thing.
    - pcwalton 5y ago
      Are you sure that we should be shipping all targets by default into one monster download? This doesn't seem particularly scalable.
      - coder543 5y ago
        The whole toolchain for Zig, which appears to include complete cross compilation, is less than 40MB compressed[0]. I would hardly call that a "monster download". I think developers can spare that much space. Besides, storage space is scaling much faster than the number of available targets, so I don't see how this could be "not particularly scalable" unless you either have a weird definition of "target" or predict there's going to be a sudden explosion in the number of targets. Go also makes cross compilation to any supported target a breeze in the default toolchain download, and it is an incredible convenience for the developer. [0]: https://ziglang.org/download/ https://ziglang.org/download/
        pcwalton 5y ago
        The Xcode download, which is the only officially-supported way to develop native apps on macOS and iOS, is 9.8 GB and gets larger with every update. The Windows 10 SDK is 4 GB and likewise is only getting larger. Sure, you can develop some apps with only a subset of the SDK. But, as a language project, do you really want to be in the business of optimizing and subsetting every single OS SDK? I think a lot of the issue here comes down to targeting server workloads and command-line tools vs. apps using more of the OS libraries. In practice, Go focuses on the former kinds of apps, so shipping all targets is a more viable approach for them. But when you start getting into apps that want to use a larger swath of the platform facilities, then the size of the platform SDKs starts to become an issue.
        coder543 5y ago