[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.

[coder543]

Yes, the Zig (and Go) developers have clearly put a lot of effort into ensuring the size of their toolchain remains reasonable. I fully believe the Rust developers could achieve similar results as well, if they really wanted.

Until then, the lack of a great cross compilation experience out of the box is just a limitation of the Rust toolchain. It's an acceptable limitation in many situations, but I don't buy your repeated arguments on this HN discussion that it is unclear that this is desirable to fix. Clearly many people in this discussion alone disagree with your position, and my own anecdotal discussions with other developers in real life aligns with this discussion. YMMV, obviously.

[pcwalton]

> Yes, the Zig (and Go) developers have clearly put a lot of effort into ensuring the size of their toolchain remains reasonable. I fully believe the Rust developers could achieve similar results as well, if they really wanted.

I strongly disagree. These are different languages. Rust leans heavily on generics and monomorphization. It implements most language operations, like ptr::offset, in the language itself, increasing the size of library metadata. It supports tools like the sanitizers. It has a rich serializable MIR format so that generics can be embedded at a higher level than just machine code and a lower level than source.

It is absolutely not true that nobody "really wants" smaller binaries. Rust already did a fair bit of experimentation with running crate metadata through gzip, etc. years ago (turns out there are some thorny tradeoffs around compilation time vs. on-disk storage when you go that route). I can't speak to Zig, knowing less about it, but with Go there were conscious language design decisions that favor binary size over runtime performance (e.g. hash table lookups all going through a single function instead of being specialized). This is fine! But it's contrary to the idea that Rust could achieve smaller binary sizes if we "really" wanted to.

> Until then, the lack of a great cross compilation experience out of the box is just a limitation of the Rust toolchain.

Rust has a great cross-compilation experience. It's as simple as:

    $ rustup target add arm-linux-androideabi
    $ cargo build --target=arm-linux-androideabi

That's it. One more command than Zig or Go, to install the toolchain you need, and then you're off to the races.

[burntsushi]

The difference is really not just one command. I suggest you go out and actually try Zig cross compilation or at least read more about it. Andrew Kelley has written a lot about it. The work impressed me so much that it was one of the things that provoked me to become a financial supporter of Zig. (Even though I haven't written a line of Zig yet.)

Cross compilation in Rust is better than C or C++. But it's still a big pain.

I really think you are underestimating what the Zig folks are doing. Please investigate more deeply.

In particular: "Zig does not ship with any pre-compiled libraries; instead it ships with source code, and builds what it needs on-the-fly."

[pcwalton]

Do you think that Rust would be a better language if everything had to be compiled from source?

[coder543]

> That's it. One more command than Zig or Go, to install the toolchain you need, and then you're off to the races.

Except it's not the same. Zig also cross-compiles C code beautifully, and lots of Rust code depends on C libraries. That "one additional command" does not solve cross compilation to an equivalent degree as Zig.

Go code tends to avoid C because of the heavy penalty that CGo imposes, so the cross compiliation experience is usually good there, but for different reasons than Zig.