3 ms·

> 1. What development environment are other developers using with very large code bases? Is the tooling responsive? It’s solid. If you’re coming from Visual St

> 1. What development environment are other developers using with very large code bases? Is the tooling responsive? It’s solid. If you’re coming from Visual Studio, you’ll dig IntelliJ with the Rust plug-in. > 2. Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? It’s painful. I don’t know if there’s a timeline. But I’m positive someone can say more. Edit: See Steve's response. He would know. > 3. Most of the code I write is in F#. The nice thing is, there is basically .NET library for everything under the sun. For example, over the weekend I was looking for a library that could decode OBD-II data from a car, and with a quick DuckDuckGo search I was able to find three or four. In a large-ish project, how often do Rust users typically find themselves coming up short for that kind of stuff? Obviously it varies a ton by domain, but maybe someone could tell me whether the answer is "you'll probably write all wrappers for 3rd party APIs yourself" or "there's a decent chance there's a library out there that you can adapt." If you’re expecting the F# (and .NET) ecosystem, you’ll likely be satisfied. In fact, it might be better. If you’re expecting the Python ecosystem, you’ll need to wait (or contribute back).

mercurial 9y ago
> 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).
- kbenson 9y ago
  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] 1: https://metacpan.org/pod/Task::Kensho https://metacpan.org/pod/Task::Kensho
  - mercurial 9y ago
    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. See for instance https://github.com/ErichDonGubler/not-yet-awesome-rust https://github.com/ErichDonGubler/not-yet-awesome-rust There are quite a few use cases not listed here, obviously.
  - bonesss 9y ago
    > 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.

mercurial 9y ago

> 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).

kbenson 9y ago
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] 1: https://metacpan.org/pod/Task::Kensho https://metacpan.org/pod/Task::Kensho
- mercurial 9y ago
  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. See for instance https://github.com/ErichDonGubler/not-yet-awesome-rust https://github.com/ErichDonGubler/not-yet-awesome-rust There are quite a few use cases not listed here, obviously.
- bonesss 9y ago
  > 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.