[sobeston]

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]

Absolutely, hence a toolchain thing.

[pcwalton]

Are you sure that we should be shipping all targets by default into one monster download? This doesn't seem particularly scalable.

[coder543]

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/

[pcwalton]

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]

No one (that I've seen) is suggesting to include those SDKs, which you probably don't even have the rights to redistribute anyways.

I provided both Zig and Go as examples of what people are looking for, and their downloads are neither obscenely large nor do they include those massive SDKs.

So yes, you have a weird definition of "target" that no one else here is using, and it is disingenuous for the conversation. rustup can already add additional targets after installation, are you suggesting this downloads 10GB SDKs? Definitely not, and that sounds irrelevant. (Even once you do this, the toolchain experience is not as good as what Zig or Go offer.)

Compare what Zig and Go do to what Rust does, not some strawman argument that would require users to download 10GB of SDK with the Rust toolchain. Alternatively, find me someone who is saying they think these multi-gigabyte SDKs should be included, because I don't see that anywhere in this conversation.

People here are complimenting what Zig currently does, which takes less than 40MB compressed. Zig can cross compile to Windows just fine. There are limitations to everything, but what Zig and Go offer is strictly better than what Rust offers in terms of the out-of-box cross compilation experience, and it isn't unduly burdensome on the developers like your proposed 10GB download.

[pcwalton]

My nightly-x86_64-unknown-linux-gnu lib directory is 148MB. This is because it includes several libraries in both rlib and so format (static vs. dynamic linking), asan/lsan/msan/tsan variants, and so forth. You could easily imagine that ballooning to 1GB if we shipped all tier 1 targets. This is what I mean by shipping all targets not being scalable: it might have seemed so in the early days when the libraries were smaller and the targets fewer, but not now.

[steveklabnik]

100% sure? No. Mind you, I'm on MSVC, where I already need an extra ~1gb download to get the system linker.

We could still do a few different things to make this story better for users, even if it's not literally identical.