5 ms·
It is also bad in following dependencies, and links the whole libraries. The result is like spaghetti, import on library and half of the standard libraries come
by erglkjahlkh 12y ago
It is also bad in following dependencies, and links the whole libraries. The result is like spaghetti, import on library and half of the standard libraries come with it. Some optimizations have been already done to prevent that, but the work is going to be still in progress for several versions.
- giovannibajo1 12y agoOn the other hand, rust has no standard library ("batteries") by explicit choice, so once the ecosystem will evolve, there would likely be multiple json or http libraries (just to name "low-level" libraries with widespread usage), and you might end up linking a few of them in a binary as indirect dependency.
- masklinn 12y ago> On the other hand, rust has no standard library ? http://doc.rust-lang.org/std/ http://doc.rust-lang.org/std/ > there would likely be multiple json or http libraries (just to name "low-level" libraries with widespread usage) The standard library used to build json in, that was actually split out to a standalone libraries for various reasons: https://github.com/rust-lang/rustc-serialize https://github.com/rust-lang/rustc-serialize > and you might end up linking a few of them in a binary as indirect dependency. That's not a counter-argument to erglkjahlkh's comment. In fact it's pretty much irrelevant: * Go works at a library level, when you import fmt you don't import encoding/json, and it's not loaded * The issue he outlines is mostly that Go does little to no dead code elimination, when a library is imported all of its content (and the content of its dependencies) will end up in the final library, even if you only access a small utility function
- pstuart 12y ago> Go does little to no dead code elimination Yet. With the rewrite of the compiler it is safe to assume that there will be many optimizations to come.
- masklinn 12y agoSadly no: one of the primary (if not the primary) goal of Go's developers is compilation speed, and with Go being intrinsically slower than C the post-rewrite available budget for possible optimisations (whatever the acceptance threshold they define) will be lower rather than higher.