Hi. (long intro - question in the end)
I am highly experienced in C++ , did also some Java and Python, and I am currently learning Rust and evaluating if Rust would be the best fit for a new project. From my own experience the most obvious choice would be C++ and I am sure I would succeed in a new project with that language.
But I have been getting more information on Rust, watching videos and now reading the Rust book and I am quite convinced that Rust aligns well with my programming style and offers significant advantages.
So, I already bought into the pitch that Rust is a language for the next 40 years.
What I am not quite as much convinced is about using crates/frameworks from crates io is a good long term choice. For example, I saw some video from Steve Klabnik showing how to do a web service using tower-web which seemed quite interesting (JFuture 2018: Steve Klabnik - Building Scalable Web Services in Rust - YouTube), but as I look at github and crates.io it seems not even to be maintained anymore . Also I read that the maintainer of actix-web gave up and some other people are taking over the project.
These things make me question whether it is worth to really base a project on some existing framework instead of writing something totally fitting my needs from scratch.
So the question is: which crates are mature enough and widely used to make sure they will still be relevant and maintained in 5-10 years? I am particularly interested in frameworks for webservices , but I would also would like to hear about frameworks which help generally in programming. (e.g. concurrency, logging, etc)
If your life depends on having your application's dependencies available for the next 5, 10 .. years then I suspect it is up to you to snag the source and stash it away in repos under your control. That is the approach taken by those who want to be able to reproduce and continue to develop their code well into the future. To the point of having their own archives of all the tools they use and even keeping old machines to run them on.
If your life depends on having having many hundreds of people around the world maintaining your applications dependencies, adding new features, fixing bugs, adapting to new environments, etc then you might be expecting a bit too much. If not being greedy.
As such the situation with Rust and it's crates is no different than that of C++ and all the random libs people use with it.
My feeling is that anything I use in my Rust programs today will still build and work the same in a decade or more to come. Even if nobody does any maintenance on it ever again. That is the promise we have from the Rust creators for backwards compatibility as the Rust language evolves in the future.
crates.io is actively maintained, and it's part of the Rust project. Rust isn't going anywhere, and I think it's safe to bet that both Rust and crates-io will be around in 10 years.
crates-io has a policy of keeping all published crates. They won't delete any crates, unless there's a legal reason to do so. The crates will be still there in 10 years. They may be unmaintained, but the old code will be there for you to use.
Rust is past 1.0, and promises to maintain backwards compatibility. There have been cases where new additions to the standard library or compiler bugfixes caused small breakage in some creates. It's never anything big. In 10 years your project may need to fix a couple of lines of code to build (not to different than taking a C project written for a 10-year-old compiler version and getting it to compile with the latest compiler).
I think there's a critical distinction here between framework crates and more focused library crates.
Are there any web framework that'll be maintained with minor changes for the next 40 years? I wouldn't bet on any of them being mature enough right now to be confident in that. But the problem with frameworks and that domain is that even the mature ones in other languages change drastically. Look at AspNet in C#, for example: it's changed pretty drastically in far less than 40 years.
On the other hand, there's something like regex. It's quite a complicated implementation, to be as fast as it is, but it works on stable and the domain mostly isn't changing. So I suspect that it'll still exist in decades (assuming Rust still does), and even if it didn't ever get updates I wouldn't mind all that much, since it would still do what I need.
This is why I chose the Piston ecosystem of crates; all is modular and designed to work with various backend graphics utils as well as any other code one may want to integrate around the piston boilerplate. Piston has been around for a long time already, enabling one to pick and choose crates for your use case.
I've found potentially good tutorial code from 5 years ago that won't compile...so I'm converting it to current crates. Thus far, I've found the points of conversion to be few, but sometimes complicated.
Particularly regarding trusting frameworks vs more specialized, smaller libraries that is a very good point.
My fear is indeed more towards frameworks.
Just out of top downloads on crates io , it should not be a problem to rely on things like rand, serde and log, right?
Regarding webservices frameworks, any view on them?
My general litmus test involves browsing through the docs and source code, asking myself whether I’d be willing to make and maintain a private fork should the maintainer go AWOL. If yes, it’s fine; otherwise, it will take some more serious thought:
How likely is it to break?
How critical is the functionality it enables?
How complex is the best alternative, whether that’s a different crate or writing something bespoke?
Certainly rand, serde and log will not be a problem. As was already mentioned, they will continue to work infinity without modification, so the requirement is low even for less well-used and well-loved crates.
As for web frameworks, they will also continue to work, so it depends on whether they do what you need. I have a maybe 5-year old web app that I wrote with rouille, which I've been wishing to switch to warp (which I use for new projects), but there's just no motivation because it keeps working just fine, so why bother? But if you're creating the next Facebook and expect to keep implementing new features for decades and having new expectations of your web framework for those decades, then you probably do want to be more careful. Look at the GitHub page and see how it's progressing, how many users it seems to have, and how many developers.
The biggest risk here is that web browsers are an ever-evolving target— support for old protocols steadily degrades as new ones are developed and deployed. That cycle generally takes at least a decade to run its course, though.
My vague impression is that there's still a bunch of experimentation going on, as well as async.awaitifying. I don't think things have coalesced to "the two winners" yet.
The are web yet site is pretty much on spot, so that I can understand the status of things. Thanks a lot!
And 2e71828, "asking myself whether I’d be willing to make and maintain a private fork should the maintainer go AWOL.", is a pretty good question to make before adopting something. Thanks.