Hacker News new | past | comments | ask | show | jobs | submit login

The cross compiling features of Zig look fantastic! Installation is so easy, just downloading and extracting a single file.

Should every compiler stack have prioritized cross compilation over other features? (I vote: YES). Cross compiling programs has always been a PITA for most languages.

It would be great if Zig cc could be paired with vcpkg [1] for a nice cross-compiling development environment. Looks like vckpg requires a C++ compiler though.

1: https://github.com/microsoft/vcpkg






Which reasonably-popular modern languages can be reasonably said to have ignored cross compilation? Interpreted languages like JavaScript and Python obviously don't have any problem, JIT languages like .NET and Java explicitly have a cross-platform layer, and modern compiled languages like Go and Rust specifically have cross-compilation as a goal. Rust still needs a libc though, but that's not Rust's fault, that's the result of trying to work together with the system instead of DIYing everything. (see: problems with Go doing system calls on BSDs, Solaris, etc)

You can't look at C which started in the 1970s and C++ which started in the 1980s and have expected them to even consider cross-compilation, when Autoconf wasn't even released until 1991.


I think the benchmark should be distribution. For instance, you mention "JavaScript and Python obviously don't have any problem", but say you want to create a distributable program for the 3 major operating systems, based in one of those languages, and you can't assume the user will have an installed interpreter. I don't think you will find any _standard_ solutions.

Most other languages make it _possible_ to generate some sort of artifact usable from different operating systems but not necessarily easy. I think Java only relatively recently included a standard way to create a bundle including a minimal JVM distribution with an app to make it usable when the user doesn't have an installed JVM (and again, there were a bunch of different non standard solutions of varying quality before that). Even now I wouldn't say the Java solution is easy to use.

I could continue in this fashion with different languages, but you get the idea.

I heard go is pretty good in ease of cross compilation, and well, looks like Zig is doing great in this area too. Ah! .net core is apparently pretty good in this area these days too.


That's moving the bar though. Only in the past decade or so has it become reasonable ("reasonable") to include entire runtimes together with an application. Java started in 1995, Python started in 1991. This was an era when one of Java's main targets was SIM cards and other highly minimal devices, so not only would the target already have a JVM, but it would be wholly impractical to ship your own. Even on desktops, downloading just a fraction of Java for each program would be a massive waste of limited bandwidth and disk space.

For that reason, Java and Python didn't start out with fully self-contained bundles as a design goal. It just wasn't practical in the 90s. Obviously, yes, if they had managed to correctly predict and plan for three decades of technological improvement, then sure, we'd be working in a very different technological landscape. But they couldn't possibly have, and solutions built on the old languages are always fraught with disagreement. So, we use new languages, like Go and Rust, which are developed with modern needs in mind.


> I think the benchmark should be distribution. For instance, you mention "JavaScript and Python obviously don't have any problem", but say you want to create a distributable program for the 3 major operating systems, based in one of those languages, and you can't assume the user will have an installed interpreter. I don't think you will find any _standard_ solutions.

Well, there are web browsers and servers. They distribute javascript programs and run them.


Interpreted environments like Node.js, Python, and Ruby absolutely have this problem since many popular packages utilize native extensions. Distribution is still a challenge.

Note that on linux hosts at least, for most target platforms, being able to cross compile with clang is only one single install of the right packages away.

Portability depends on a great deal more than just object code formats. The list of OS environment functions to call to achieve anything useful is radically different from one target to another.

This is what makes porting hard work. Cross-compiling is only the first step of a long trip.


I think a problem comes when you want to distribute your compiler potentially independent from your OS and/or linker and/or C library.

But it's also fair to say that if we had always considered those things as inseparable parts of the "compiler suite" that might have made everyone better off.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: