We would also need to pay for the cost and such of building, hosting, and distributing all of that...
There are other middle grounds too. There's certainly interest, it's just not trivial. If it was, we'd do it!
Contrast this with C and C++, where it's common to #ifdef in an entirely different program depending on the flags.
It's certainly possible to do something like this in Rust, but in practice it's rare.
Good CI configuration can definitely help to catch these issues, but it's obviously an extra effort for projects to set up. The alternative could be to simply avoid feature flags and always compile everything, which depending on the project might or might not be the better option.
On the other hand, I'm guessing that by "custom flags" you're referring to compiler-level flags that influence codegen, which rustc doesn't have that many of, and most of the ones that rustc does have are for controlling things that people might reasonably expect to be nontrivial work to change in the first place (e.g. linker/symbol options, cross-compilation/platform options, LLVM/gritty optimization/instrumentation options). Of the rustc codegen options that ordinary users might want to play around with, I see only two: one for turning off arithmetic overflow checks (which makes all integers act like their overflowing equivalents from the stdlib), and one for determining the general strategy of what happens when a panic occurs. The latter is unlikely to cause problems because the default behavior is a superset of the configurable behavior, and for the former any silent problems in misconfigured users would manifest as panics for everyone else, so there's a good chance the problem would be fixed upstream regardless.
The most valuable company in the world has significantly more resources than we do.
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
And yes of course it is given that apple's resources is vast to say the least.
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 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.
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.
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.
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.
"Infect" the eco-system? That is not the way make business.
There’s that but there’s also issues like ABI stability (and the lack thereof), compilation flags, hosting (infrastructure and its cost), distribution mechanisms, …
There’s an issue on cargo dating back to 2015 (#1139) but there’s a lot of efforts needed to think about the problem, then actually solve it.
I think it is only a matter of time until such cargo gets its "Maven".
Incidently one of Swift announcements at WWDC was the support of binary packages in Swift Package Manager.
Of course, if Cargo supported pre-compiled dependencies, I am guessing that it would be smart enough to only recompile the dependencies that are using non-default features.
What is it that triggers such a "full" build though? Obviously in some CI scenarios you might start from scratch, but in an edit/compile cycle, you'd never be hitting those 5 minutes, correct?
If you clean your build folder, things will need to be rebuilt from scratch. Likewise if you change your compiler version.
If it does, then the long compile times are almost never encountered for neither developers nor CI. So are they really problematic?
How hard is the caching to set up, especially in a CI setting?
Cargo caches by default and you can specify the path that it stores artifacts. Most of the cache story is about what your chosen provider uses to specify build steps, etc
While I was watching its output, I realized that in Rust, all the dependencies are compiled; I'm used to Java+Maven or JavaScript+NPM where compiled dependencies are used instead, and that tends to be pretty quick (provided your network pipe is wide enough). I'd be curious to learn why Cargo re-compiles from scratch instead of offering pre-compiled binaries as well. I guess part of it is related to different target platforms, but it seems like if the top 5 platforms were targeted and had compiled resources available, you could reduce compile times for those platforms by a significant amount.
On the other hand, the error messages I ran into along the way were quite good at pointing me in the right direction about how to fix them, which saved more time than the extra compile time cost, relative to the Python-based alternative I had been trying to set up before that.