There was an argument on Slack about Julia’s new static compiler and the potential concern for biasing the language in favor of a static one or even a non-allocating one. I can see this creating a lot of issues where some package authors writing a package for games might not be seriously concerned with garbage collection, while those concerned with hard real-time applications might.
Another factor is that one should ideally not pay for what they don’t use. For example, if GC is not required, no GC.
To align the expectations of stakeholders, I believe packages should ideally be clear on the stance they take. For example, if a package intends to rely on the full Julia compiler, it should be marked as such. Ideally, there should also be an analysis package that can analyze what part of the Julia runtime it needs. These are, of course, ideal. I don’t want to place any undue burden on any package developer. Some might not be sure either. Some might not want to perform extra work, even if it’s just a simple checklist. Still, the list would be a useful convention for those happy to cooperate.
Another issue would be that the exhaustive list could be infinite. For example, a Julia package that calls Java library might need JVM for the runtime to work, those relying on commercial software might need special licenses, and so on.
Still, let’s not let the perfect be the enemy of good. Let’s focus on what some people are primarily concerned about such as the Julia compiler and the Julia GC. What should the list of package runtime requirements include?
For example, a package for an embedded real-time control might say…
Compiler: No.
GC: No.
and so on.
What should the list include?
I’m not a very good programmer, but if my small question can contribute to the Julia community in a small way, I’m willing to help.