I had similar concerns (also starting with rust). But for languages that could be used in many environments (including embedded) I think a small stdlib is good.
Perhaps there needs to be a separate low-rate-of-change set of reviewed libraries that can be used more easily without dependency explosion.
A small stdlib is good, and any crate that can, should allow for no_std. I think originally the justification for a small stdlib was so that people didn't deprecate parts of it with a better 3rd party lib. They would bring libs into std as it became obvious they were the de facto standard already. They just haven't been terribly aggressive about doing that.
I think if there was a no_std package and stdlib+ vetted and slower to change package (and available through yum or apt or a tgz instead of crates), safety and security critical applications would move towards it more quickly. It would also make air-gapped development networks easier to provision.
Comments
I had similar concerns (also starting with rust). But for languages that could be used in many environments (including embedded) I think a small stdlib is good.
Perhaps there needs to be a separate low-rate-of-change set of reviewed libraries that can be used more easily without dependency explosion.
A small stdlib is good, and any crate that can, should allow for no_std. I think originally the justification for a small stdlib was so that people didn't deprecate parts of it with a better 3rd party lib. They would bring libs into std as it became obvious they were the de facto standard already. They just haven't been terribly aggressive about doing that.
I think if there was a no_std package and stdlib+ vetted and slower to change package (and available through yum or apt or a tgz instead of crates), safety and security critical applications would move towards it more quickly. It would also make air-gapped development networks easier to provision.