I agree. Since nowadays the disk space saving argument is almost irrelevant the only thing in favor of shared libraries seems to be the automatic improvement of all dependents with one update. But I think history has shown that this is a major source of incompatibilities and since Julia software is not really supposed to be running public facing services the security argument is moot anyways.
> since Julia software is not really supposed to be running public facing services
Who said that? As far as I know, it was always intended as a general purpose language, and in my opinion, it’s already a pretty good one (and rapidly getting better), except for the fact that the library ecosystem is still limited in some areas.
If each package vendors its own deps, when the dep has a security vulnerability and needs an upgrade you need to hunt down every last location it exists in, instead of updating the single shared system dep and being done with it.
Apart from what sibling said, another issue is explosion of trust assumptions.
On my system, I obviously have to trust the Archlinux project not to serve me malware. When using Julia, I additionally have to trust the Julia project not to serve me malware. (See also: Python, Node, etc.) Obviously: less trust is better for security, ideally almost all installed software would be signed by Archlinux maintainers.
For comparison, the situation is kind of similar for Apple users; but on Windows, trust is extremely watered-down anyway (with or without Julia or Python etc.).
