> If you’re expecting the F# (and .NET) ecosystem, you’ll likely be satisfied. In fact, it might be better.
Not even close (100k unique packages on nuget, 13k crates on crates.io). On the other hand, you have easy interop with C (which doesn't give you stuff like safety, idiomatic error handling or nice APIs, but it's occasionally better than coding it yourself).
It's not about total packages, but about quality of packages and whether they provide good coverage of most problem spaces.
NPM claims to have close to 500k packages. Should we assume it solves 5x the problems that the .NET ecosystem does, that that perhaps by the 50th implementation of leftpad, there's some cruft on there?
That's not to say that Rust's package ecosystem is large enough or sufficient in comparison to .NET, just that raw package count gets to be an extremely poor indicator of quality after a certain level has been reached.
As a point of reference, I approach this from Perl and CPAN, which is one of the oldest large fully featured package networks. At this point, the problem is usually not finding a package that provides a solution, but finding the right package out of what's available. Different solutions exist, but a good curated list of well implemented solutions to common needs can help quite a bit.[1]
Well, an order of magnitude of difference is a hint that, whatever the quality of the existing crates, there are definitely areas for which you are going to be hard-pressed to find a good solution (say, localization), or a solution at all.
It is not a sign that there is anything wrong with the Rust ecosystem, it has a very active community and things are moving in the right direction, it is not just as full-featured as more mature ecosystems out there.
> raw package count gets to be an extremely poor indicator of quality after a certain level has been reached.
Broadly speaking I think the best indicators are always going to be domain specific -- which set of packages is most used within the context of what you're doing? A million awesome packages for Excel automation aren't much help, per se, for huge file chunking or BigData work.
From that point of view it's more relevant to look at the size of the successful projects in that market that resemble your technical goals.
Not even close (100k unique packages on nuget, 13k crates on crates.io). On the other hand, you have easy interop with C (which doesn't give you stuff like safety, idiomatic error handling or nice APIs, but it's occasionally better than coding it yourself).