Not yet.

The most valuable company in the world has significantly more resources than we do.

With hope for the presence of positive-minded folks with contribution time to spare: any suggestions of areas that could use help towards binary builds?

I would reach out to the Cargo team: https://www.rust-lang.org/governance/teams/dev-tools

Apple controlling the hardware makes it way easier though. At home, I compile Rust with CPU-specific features on about as many different hardware as Apple for their whole ecosystem!

> Apple controlling the hardware makes it way easier though.

I'm not sure that's really relevant.

Rather:

* apple has resources, lots

* apple wants to promote the use of swift, making it easier and more convenient is a good way to do that, binary dependencies reduce the complexity of the build process because you don't need to build dependencies

* apple has a vibrant ecosystem of small closed-source shops, binary-only distribution is useful for those, as well as for themselves

* promoting binary and eventually dynamically linked dependencies might mean the ability to dedup' on-system dependencies

I believe what they meant was that Apple needs to support less hardware variations. Compilers frequently have a host of flags that depend on CPU features which can potentially make the code behave slightly differently. If cargo was to implement this, they need to compile each package many times (with different configs) more than apple need to do so for Swift.

And yes of course it is given that apple's resources is vast to say the least.

> I believe what they meant was that Apple needs to support less hardware variations.

I understand that very well. My point is that they wouldn’t be doing it regardless if they didn’t want to, and if they really want to (for reasons I outlined) they have the resources to make it happen essentially regardless of the constraints or hardware breadth.

Apple also took a multi-year effort of designing a stable ABI for Swift as means to enable exactly this scenario.

The stable ABI was so Apple could ship Swift in the system. The fact that it enabled binary dependencies was more of a freebie.

Binary dependencies are really about supporting closed-source libraries. Because they’re in binary form it means there’s no ability to customize the build process, no build flags or optimization levels or anything else.

Apple also relies heavily on dynamic linking in general, so binary dependencies are likely going to dynamically link their own dependencies, thus removing a lot of the variability that would otherwise require recompilation.

If Rust is to be taken seriously as systems programming language, it needs to cater to a use case that is very important for a large set of C, C++ and Ada population.

Apple is doing this, because Swift is their next-gen systems programming language.

Swift supports static linking just fine as well.

Really, it is all a matter of which demographics Rust wants to be present.

And with Rust now being adopted by Microsoft and Google, I just see this need only increasing.

While I agree with your statement, the lack of binary linking has been a blessing in Go and Rust. The inability to give a binary "SDK" forces many companies to provide source (and in many cases open-source their library). I would find it very irritating if I can't navigate into the library source at least during debugging.

Go tooling supports binary dependencies, where the only source provided by the packages is the documentation for go doc.

It just looks like everything is source code when not taking the effort to read through all dependencies.

It doesn't force companies at all, only those that are comfortable shipping source libraries end up adopting such languages.

I used to work for a company that shipped encrypted Tcl source code and provided the necessary interpreter hooks to access the code in its encrypted form.

> It doesn't force companies at all, only those that are comfortable shipping source libraries end up adopting such languages.

Yes, and the others are left behind and don't get to participate in (and infect) the ecosystem. Sounds like a win to me.

> I used to work for a company that shipped encrypted Tcl source code and provided the necessary interpreter hooks to access the code in its encrypted form.

Surely.. if the interpreter can decrypt the code then so can the user? Minification and obfuscation are of course still possible, but the whole encryption thing seems pointless.

Tools like IDA are always a possiblity, the large majority of customers are willing to go that far.

"Infect" the eco-system? That is not the way make business.