E.g. try to cross compile Metal shading example for iOS from Linux with zig, or do a Win2D UWP rendering application from Linux with zig.
The system API problem can be solved by shipping automatically generated API bindings (similar to what Microsoft does with the Rust bindings to the Windows APIs, a similar project for Zig is underway). Once those bindings exist, no Windows SDK is needed anymore and cross-compiling should "just work".
PS: Zig actually ships with the mingw headers in the default installation (e.g. windows.h, d3d11.h, dxgi.h etc are all there), I haven't actually tried to cross-compile a Windows executable using the Win32 APIs though, but it looks like it should work already.
Reverse engineering is legal in the US (unless bound by contract).
And to go back to my examples, headers and libraries alone won't make it, without the remaining toolchain to create the appropriate package.
If you want to cross compile C stuff e.g. a Win32 GUI app with Direct X or get OpenGL bindings for SDL though those all work just fine if you provide the SDK files same as you would compiling natively. The advantage being now you can do all builds from a single build instance just by feeding it the libraries and a target platform.
I don't see shipping all targets all the time to be a particularly scalable solution in general. When you start including all libraries necessary to develop actual apps, the download size will eventually get so big that people will complain. Just make it easy for developers to get the targets they need, but don't ship everything by default.
For Mach (the Zig game engine I'm working on), I have a Zig build script which fetches the required parts of the macOS and iOS SDKs from GitHub to enable cross compilation from Windows/Linux -> macOS. Zig's linker, zld, enables that to work easily.[0]
For SDL.zig, they have also achieved cross compilation for most targets out of the box[1].
Contrast this to say, Go or Rust, where most GLFW and SDL bindings require mucking around with the system dependencies. It doesn't just work out of the box, I think that's really unfortunate and hope other languages work more towards painless installation of C-binding dependencies.
It seems to be what Flutter is doing, and it must be a ton of work.
Lately I've cross-compiled a few times Linux/Windows programs, and the only thing I had to do (assuming that the underlying crates are compatible, and that the development libraries are in place, which is required for any language) was:
rustup target add x86_64-pc-windows-gnu
rustup toolchain install stable-x86_64-pc-windows-gnu
cargo build --target x86_64-pc-windows-gnu
There are surely issues with individual crates, and possibly with lower-tier targets, but to characterize this procedure as "user-hostile" doesn't make sense.
Rust totally craps out if you try to make a binary or dylib and you don't already have cross-compilation toolchain on your OS. It's doable from a Linux distro that has cross packages and a GNU target. It's a PITA for anything else, including anything from Windows and macOS hosts.
`zig cc` is actually useful even for cross-compiling Rust projects, because some Rust crates depend on C libraries.
This has been the status quo for so very long. Usually these projects are maintained by different teams. IMO musl is more accessible than glibc and that's part of what makes it easier to distribute. Arm and x86 coexisting for as long as they have is a factor, and so is Kelley's ambition to make this use case well-supported. nostdlib is also well-supported by Zig btw.
That's not to say that it's impossible to do something like that in a C++ compiler but it's going to be more work than there is benefit. Tangentially related: https://twitter.com/__phantomderp/status/1416108650809241601
C++ also tries to bring in modern programming research when it makes sense, but that also explains why it's like an octopus with extra legs nailed on.
For example, move semantics are a peg leg for the octopus. Should an octopus have a peg leg? I'm not a biologist of any sort, but my guess is "No". I can see why C++ wanted to add move (without this performance in some scenarios is just awful) and yet since C++ didn't start out having move semantics and can't give up backward compatibility it has to shoehorn them in with this awkward "hollowed out object" idea. The result is performance still isn't where it could be and the feature is unergonomic.
I also think you're really missing out on the "compile C code easily too" thing. That isn't very pleasant at all in Rust today.
(Finally, one reason it’s so big is that we ship binaries. This ships source. std-aware cargo could really help here.)
So much this. Cross compiling pure Rust code is really easy today but as soon as you have a C dependency in your dep tree, you're gonna have a bad time.
I'd guess that a lot of Rust developers currently do development on their target platform, but that's because cross compiling is such a pain. If it were as easy as zig or go then things might well be differen.
My understanding was that most people were using "cross" docker images for "cross-compilation", because setting up native actual cross-compilation was quite involved.
Yes, people, including myself, use 'cross' precisely because it isn't as easy as "just use rustup to install the desired target." 'cross' has a bunch of Docker images that set up the cross compilation toolchains, and those images represent a fair amount of domain knowledge that I don't have to tediously acquire to use it.
It doesn't exist in Rust because nobody has proposed it or implemented it, simple as that.
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.
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.
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.
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.
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
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."
I'm honestly pretty disappointed at your participation in this thread. It seems like you're going out of your way to assume the worst possible interpretation of what folks are saying.
But Zig’s approach isn’t actually about making everyone compile more things from scratch. It doesn’t compile libc from scratch any time you select a new target. Reading the article you can see the extreme lengths it goes to to avoid this.
The main thing that’s missing from Rust is target-specific libc.so/etc, and an appropriate linker for every target. If you try cross compiling anything, you will soon run into this problem; your system will not have the correct target libc or an appropriate linker. You can generally only change one part of the triple before the experience starts falling apart. I can cross compile for iOS/tvOS/etc on my Mac; that’s about it.
Zig manages to solve this for all its targets by pre-processing simplifications of the various libcs, which are then bundled into the Zig binary (as 3 very small files). It generates a useless but linkable .so file from the preprocessed files for any target on the fly. It gets you the correct libc headers. Then it uses LLD instead of making you hunt around on Ubuntu forum posts finding and downloading the correct GNU linker for your specific architecture. So you don’t link to a real libc, but you don’t have to compile one either. (Until you want to execute a binary with QEMU, but usually non-simulated target machines have a libc.so already.)
(Aside: Golang solves this by not depending on libc at all, by reimplementing most of it including the syscalls in Go, and I believe by using its own multi-target linker. Many pros and many cons, but an approach Google is happy to sponsor.)
If you’re saying this approach would be infeasible for Rust std/core, then yes obviously. It’s statically linked, you can’t get away with a fake .so file.
But that was never really the issue. Rustc can build std’s rlib files for any target effortlessly. And yet cross compiling is still a pretty poor experience. The state of the art for Rust developers at the moment is rust-embedded/cross, which solves the same libc+linker problem that Zig does, naively, by literally using Docker and per-target Ubuntu images to download prebuilt GCC and libc packages from Apt. Basically we can do way better than that, because Zig showed us how.
See this Dockerfile for what I mean: https://github.com/rust-embedded/cross/blob/master/docker/Do...
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.
We could still do a few different things to make this story better for users, even if it's not literally identical.
Since advent of multiarch, crosscompilation does not seem harder than regular compilation. Just install package with gcc for target arch and required libraries for target arch (using the same way as gcc and libraries for host arch).
Compared to Zig, cross-compilation in C/C++/Rust seems downright user-hostile: you have to obtain the correct cross-sdk, but it won't tell you which one, or how to get it (some combos don't even exist), or even where to put it. If you don't guess everything correctly, it will fail with inscrutable errors, or worse, only fail at runtime on the target machine.