4 ms·
Node.js (w/ NPM) is dynamic in nature and its modules are stored in the module cache by an absolute path key calculated from the relative path of the module whi
by mmgutz 11y ago
Node.js (w/ NPM) is dynamic in nature and its modules are stored in the module cache by an absolute path key calculated from the relative path of the module which is being required at RUN-TIME. Go cannot do that at RUN-TIME. It must resolve all dependencies at compile time.
Are there any statically typed languages that solve the diamond dependency issue elegantly?
- hollaburoo 11y agoRust
- mmgutz 11y agoSo it can resolve dependencies of different versions? For example if there are three packages that each depend on different versions? foo v1.0.1 foo v2.0 foo v1.5
- dbaupp 11y agocargo follows http://semver.org/ http://semver.org/, so that will promote the 1.0.1 dependency to the 1.5 one. It's also safe to link multiple versions of a single package into a single process, so the final result of depending on all three of those (transitively) will be an artifact that links to foo v1.5 and foo v2.0. Of course, the two versions are incompatible, so if one tries to get them to interact (e.g. pass a type from v1.5 into a function from v2.0), there'll be errors. However, these will be static type errors, instead of some strange runtime behaviour.
- teacup50 11y agoJava, by prioritizing API compatibility across releases and having compiler-checked types. The result being that unless you hit a particularly crappy piece of software, it's save to just pick the later version of two dependencies and use that.
- grogenaut 11y agolol, you mean like the vm itself with different xml parsers between 1.4, 1.5, 1.6, and other built in restrictions in other areas. Also with allowing and then disallowing manipulation of certain namespaces (esp the core ones). It's a problem a human has to get involved with at some point no matter what.
- teacup50 11y agoAnecdotal exceptions aren't proof of universal truth.