>We asked both current and potential users what most stands in the way of their using Rust, and got some pretty clear answers:
>1 in 4: learning curve
>1 in 7: lack of libraries
>1 in 9: general “maturity” concerns
>1 in 19: lack of IDEs (1 in 4 non-users)
>1 in 20: compiler performance
>None of these obstacles is directly about the core language or std; people are generally happy with what the language offers today. Instead, the connecting theme is productivity—how quickly can I start writing real code? bring up a team? prototype and iterate? debug my code? And so on.
I don't really see how this conclusion was reached from that data. The "learning curve" is almost certainly a reflection of the language being a little esoteric and the demands of the borrow checker. And "lack of libraries" is partly a comment on the ecosystem, but also partly shows that std is obviously lacking for some needs. Finally, "general maturity concerns" refers to worries that the language or std will keep changing, as is assumed they have not been perfected yet.
Those are the top 3 concerns and to me, both seem to relate directly to the language or standard library.
I also don't think library maturity is necessarily the only problem that makes working with libraries difficult at time. You can get burned pretty easily by someone not having e.g. Send + Sync on an essential library data structure. (Though maybe there's a way around it other than forking?) That metadata ends up being very important
Send + Sync are automatically implemented for a type X if all of X's constituents are also Send + Sync. In practice, this means that unless you're using unsafe code, Cell/RefCell or Rc, then the Right Thing will just happen automatically. If you are using Cell/RefCell/Rc/unsafe, then you need to think carefully about your synchronization story anyway, so it's typically not something you just forget to do.
Key word is "directly". Of course everything is about the language, eventually. But that doesn't mean that the solution for something exists inside the language. Learning curve can be addressed with docs and diagnostics, for example. Not everything needs to be (or can be, because stability) addressed by the language.
>1 in 4: learning curve
>1 in 7: lack of libraries
>1 in 9: general “maturity” concerns
>1 in 19: lack of IDEs (1 in 4 non-users)
>1 in 20: compiler performance
>None of these obstacles is directly about the core language or std; people are generally happy with what the language offers today. Instead, the connecting theme is productivity—how quickly can I start writing real code? bring up a team? prototype and iterate? debug my code? And so on.
I don't really see how this conclusion was reached from that data. The "learning curve" is almost certainly a reflection of the language being a little esoteric and the demands of the borrow checker. And "lack of libraries" is partly a comment on the ecosystem, but also partly shows that std is obviously lacking for some needs. Finally, "general maturity concerns" refers to worries that the language or std will keep changing, as is assumed they have not been perfected yet.
Those are the top 3 concerns and to me, both seem to relate directly to the language or standard library.