As a hobby project, I have developed a work related tool in Rust and my company is now looking into the possibility to ship it to our customers.
However, there is a major issue with it, something we call the “FOSS hell”. My company has a policy that, for each dependency and for Rust std lib itself, it needs a FOSS analysis and approval to use, which involves checking the license, checking the source code to make sure it does not break export restrictions in regards to strong encryption etc.
More than that, the approval to use is valid only for a specific version (e.g. 1.1) and has to be repeated for new major or minor versions (e.g. 1.2).
This takes a huge amount of time, mainly due to the amount of small crates that are very common in the Rust world (I pasted the list of dependencies my tool has). I think this will become a major problem for Rust in the enterprise area.
I think the std lib has to grow faster by incorporating 3rd party libraries, e.g. http client, ssl support, logging, regex, good serialiser/deserialiser with long term support plans etc.
What is the long term plan for Rust in regards to std lib evolution?
Here is my list of dependencies:
unicase v1.1.0 threadpool v0.1.4 unicode-width v0.1.3 pkg-config v0.3.6 httparse v1.1.0 strsim v0.3.0 matches v0.1.2 language-tags v0.2.0 regex-syntax v0.2.2 gcc v0.3.20 typeable v0.1.2 libc v0.2.2 memchr v0.1.7 ansi_term v0.7.0 libz-sys v1.0.0 openssl-sys-extras v0.7.1 cmake v0.1.11 bitflags v0.1.1 winapi-build v0.1.1 aho-corasick v0.4.0 kernel32-sys v0.2.1 envvar v0.1.2 libssh2-sys v0.1.34 rustc-serialize v0.3.16 openssl-sys v0.7.1 regex v0.1.43 unicase v1.1.0 winapi v0.2.5 time v0.1.34 advapi32-sys v0.1.2 traitobject v0.0.1 lazy_static v0.1.15 ws2_32-sys v0.2.1 strsim v0.4.0 log v0.3.4 bitflags v0.3.3 openssl v0.7.1 vergen v0.0.16 rand v0.3.12 env_logger v0.3.2 num_cpus v0.2.10 hpack v0.2.0 solicit v0.4.4 ssh2 v0.2.10 docopt v0.6.78 uuid v0.1.18 num v0.1.28 url v0.5.0 cookie v0.2.2 serde v0.6.6 mime v0.1.1 hyper v0.7.0