Concerns on the Long Term Viability of Rust for Real World Applications

community
1

I've been developing and supporting a production-grade Rust ecosystem at a start-up now for three years. This isn't an experimental effort. We have two server systems we maintain and support multiple databases with both SaaS and on-premise infrastructure support models. We have developed FIPS-certified MPC encryption technology at our core. We support CLI, mobile, and web clients. We elected to build it all on top of Rust given the common promises of doing so around safety and performance.

Overall, we leverage Tokio and Axum as our primary frameworks and theses seem strongly supported. But, we also have a number of important secondary platforms. Increasingly, we're becoming concerned about the number of key crates that have remained at a 0.y.z version level with the resultant impacts on stability of their interfaces. And, it seems a growing number of key crates (r2d2 for maintaining the connection pool for Oracle being one example) seem to be abandoned by their maintainers with no clear path towards a succession plan in their ownership.

I bring all this up knowing I'm opening myself up for possible grief from the community, but in all seriousness I worry that these key issues around long-term viability of libraries in the Rust ecosystem will act as an anchor on the overall success of the Rust language which I very much love and admire.

I know some will comment around expectations being too high for what amounts to "free" resources such as these open source crates. And, there is a fairness to that. I'm not looking for handouts. I'm willing to put maintainer time into these key crates myself. But I am instead seeking to understand if we as a community have an overall plan for continuing to support these efforts. What is the path towards having new folks succeed unresponsive maintainers of key crates? (I use the "unresponsive" term not out of blame--I fully understand people move on and sponsors lose support from their "day job" bosses).

Does the Rust Foundation play a role here? Do they survey what libraries are needed to continue to boost Rust as a mainstream solution for corporate applications and then step in with grants and resources to keep these maintained and move them to 1.y.z releases?

In my personal life I'm headed towards retirement soon and would be willing to pitch in for the common good on some of these crates but there isn't even a clear path to doing so.

Thank you for your consideration.

19 Likes
2

I think this might be a red herring in your otherwise very well formulated post. Whether a library has no major version number or not doesn't really say much about how stable it is, in my experience. I like to contrast Rust's ecosystem (which indeed tends to look like crate maintainers follow 0ver more than they do semver) to Dart's ecosystem, where libraries tend to have major versions. So far, I've dealt with more breaking changes in the latter, compared to the former. pub.dev packages might look more mature and stable, but for me, so far they haven't been. With npm it has been the same story.

25 Likes
3

I think this might be a red herring in your otherwise very well formulated post. Whether a library has no major version number or not doesn't really say much about how stable it is, in my experience.

You have a good point there. It does seem to be a community reluctance to move off the 0.y.z. version. But, in practicality, the 0. gives corporate and security auditors heartburn. The Rust community is going against shops paying out the rear for the Java and C# world where these overlords see 0. as a sign of instability in a risk adverse climate. Again, I'm coming from the perspective of what it takes for Rust to continue to be taken seriously in these large corporate realms. Personally I dislike that it is this way but it is the red ocean I seem to find myself swimming in as a Rust advocate.

5 Likes
4

On this note, I guess not many folks read the 'about' page on 0ver before going down this path. The satire devil is in the details! :smiling_face_with_horns:

2 Likes
5

Unfortunately, as you said about handouts, this largely makes me think that these "large corporate realms" are often freeloaders -- kinda like lots of package managers have been talking about lately (Rust Foundation Signs Joint Statement on Open Source Infrastructure Stewardship - The Rust Foundation).

If you're talking about things like "maintaining the connection pool for Oracle", then if you want "large corporate realm" support, talk to Oracle to get them to make/support the library and charge you millions of dollars a year to do so because Oracle.

As the most common licence choice for rust-related things says,

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

Practically, the only options to get more support is to talk to the maintainers are either

  1. Pay them to maintain it to your standards, or
  2. Find out that they're not interested in doing that at terms you're interested in, and maintain it yourself.

From everything I've seen, trying to force things on community crate maintainers just results in them abandoning the crate -- and perhaps doing other things like yanking all versions in spite.

This is why The Open Source Definition – Open Source Initiative exists: the only sustainable plan is to ensure that everything can be forked later should it become necessary.

(Whether that's because it was abandoned, because it was relicensed, because it removed a feature you used in a major version, whatever. Even if it's still "maintained" it might change in ways you don't want to use.)

The foundation can't maintain every crate every corporate user of Rust thinks is important -- especially corporate users who aren't members of the foundation.

If a majority of the foundation corporate and project members think supporting a crate is an important use of the foundation's very limited funds, then maybe it could for some low-touch things, but I bet particular non-free database connectors aren't going to pass that ever. Even things like Rust Foundation Launches Rust Innovation Lab with Rustls as Inaugural Project - The Rust Foundation -- where RusTLS is about as good an exemplar for this as could be -- is more about giving them things like a place to hold a bank account (to facilitate donations from others), not a commitment that the rust foundation will use its own funds to maintain the crate.

17 Likes
6

In which case they need to reach out to the crate authors with feedback.

I have two crates with thousands of downloads and zero feedback. Do people download the crates because they have an interesting name? Was the download accidental? Is the crate a core element of their product? I have no idea.

I simple do not know if they are or are not ready to be 1.0.0 versions. There is zero chance I’m going to make that transition until I know the interface is stable.

9 Likes
7

Something I got the idea to do recently is write down, in a pinned issue in my library’s issue tracker, what I think it’ll take for the library to “properly” reach 1.0. Ideally, documenting this for any library would:

  • Encourage others to contribute towards making it happen (or advocate for narrowing the scope, instead).
  • Avoid being perpetually 0.x merely because the library never feels done, by writing down criteria that can then be either achieved or deliberately changed.
25 Likes
8

I totally agree with you.

I certainly don't have many hopes that Oracle is going to put much into supporting Rust given their stake in the success of Java. Personally, I would not mess with Oracle. But, it is required for the customer base we are trying to pursue. I do wish SeaORM supported it because I have to jump through double-hoops to support Oracle and support other databases for which I use SeaORM to cover. But, I'm sure for similar reasons, SeaORM doesn't see any benefit in investing in Oracle.

1 Like
9

Easy to say, but very hard to implement in reality if I understand the intent of your comment. It's pretty hard for us as a start-up to push back on a major Fortune 500's audit department and say, "Trust us, this open source library we use is secure and well maintained. If you disagree, you need to go do the research yourself." This is a sure strategy for not winning any customers.

With respect to feedback to crate owners, I do try to provide that.

1 Like
10

I love this! Thank you

11

Who is that "we"?

You could (and probably have to) maintain such support yourself. Not a lost of interest in the community I imagine given how Oracle tends to behave.

I don't know how seaorm works, but perhaps you could even contribute such support back to the project and sign up for maintaining that part of the library. That would be the open source way of doing it after all...

If all you do is take and not give back, then you really don't get to complain.

5 Likes
12

Okay, I want to keep this short and to the point. Rust forces you to grow up.

  1. You want something better, build it better.
  2. You want something not yet made, build it.

If you are nice, contribute back. If not, well, that's up to you. The entire idea of telling maintainers what to prioritize to entertain your corporate clients is ridiculous because it's foremost your problem to solve because that is what you get paid for. If they don't pay you, I don't think the Rust community or zero version numbers are at fault. Think deeper about your value proposition.

I maintain multiple crates, I've contributed to an ASF project, the Bazel project and the Diesel project. In all cases because of either 1) or 2). These are your first two options.

Recently, i had a similar thorny issue about dealing with an external crate. In the end, I replicated those public interface I was using of that crate and reimplemented all of them as internal crate. This enabled me to apply fine grain optimization, add custom functionality, remove tricky macros, and eliminate the last bit of unsafe. Insourcing is your third option.

Do I have more code to maintain? Obviously yes, but in the grand scheme of things having another 50k LoC in my repo makes no meaningful difference. Instead, I get peace of mind that regardless of what happened, my stuff keeps working.

As I said, Rust forces you to grow up. You have three viable options to handle your Oracle integration code.
The choice is yours.

7 Likes
13

I think your (or your company’s) attitude is a bit wrong-headed. If you rely on crates that haven’t reached 1.0.0, the real issue isn’t the ecosystem, it’s that you’re waiting for others to solve the problems that block your business.

How many crate maintainers has your company actually offered sponsorship or support to, specifically to help them reach 1.0.0?

This isn’t about adding new features. It’s about giving maintainers a small push and a bit of funding so the crate can confidently be marked as stable and production-ready.

That would make a lot of people happy:

  • The maintainer, who finally gets appreciation and some well-deserved money.
  • Your customers’ auditors, because dependencies are clearly stable.
  • The department buying your company’s product, because their auditors are satisfied.
  • Your company, because happy customers keep buying.
  • You, because your employer can give you higher paychecks.
  • And the Rust community as a whole, because more crates reach true production readiness.
7 Likes
14

I have a different take on this and have experience with many large companies. The easiest way to stop having to justify each "open-source" library is to stop disclosing the details to your customers. At the end of the day your company is responsible for the binaries you host or provide to customers. You can vendor dependencies, and then upgrade as needed. We have good success at pushing back against these requests or only providing limited information that we think is useful. IT departments in general are just using basic rules that keeps the "IT Security" person in a job and adds very little value.

1 Like
15

Wait until you find out that cargo itself has major version 0[1].

  1. cargo -V/--version was changed to write the version of rustc instead of its own version when 0.27.0 was released precisely due to this absurd notion of "1.0 stability". ↩︎

4 Likes
16

I really hope that you do not act on this advice in practice. For most crates you legally obliged to disclose their use in your software as clearly stated in their licensing terms. Obviously, it's highly unlikely for crate authors to sue you for such infringement, but it's both legally and morally wrong.

2 Likes
17

I totally agree. Many of these responses, including ones that don't deliberately try to insult me, have gone off the rails. I cannot lie to the security audit department about which crates I'm using. And, as you point out some licenses specifically require disclosure.

2 Likes
18

Cargo isn't the problem because its code is not wrapped into delivered binaries that need to be audited. To be clear, I personally have no problem with zero version crates. What I'm trying to point out is that the risk and compliance arms of many large enterprises whom, I assume, the Rust community would want to deliver products which are accepted to, do have a problem with zero version crates.

5 Likes
19

You missed the part about us being a start-up. I personally have, do, and will contribute to open source projects. What we're talking about here are open source projects which provide critical components of infrastructure but whose capabilities are outside the scope of our own expertise. We are, not and nobody can be, experts in every topic. It is not practical for a small company to simply write the code they need for every task for a large solution.

The other aspect that is being missed here is the concern about crates that are going unmaintained, have dozens of contributed PRs that aren't getting merged, and issues that are going unanswered. These crates are being contributed to by the community. But, the contributions are going nowhere and there is no clear path set out by the maintainers for new maintainers that do have the time and expertise to take over the effort. I AM WILLING to take over as maintainer in some cases. But there is no path to doing this.

3 Likes
20

It's sad you must resort to accusing me of being immature. I have developed and maintained commercial software applications since the late 80s. I've contributed to, do contribute, and will continue contributing to open source projects. I am a believer and supporter of the open source ethos since Peterson came up with the term. I am not "telling maintainers what to prioritizes to entertain [my] corporate clients". This is not my point at all. I simply raise two issues that are an anchor on Rust's ability to compete with other more entrenched platforms such as Java and C# in the commercial marketplace: the persistence of long-term zero-version crates that give compliance and security auditors heartburn; and, the lack of a clear path for others to maintain popular crates where their current maintainers are no longer reacting to posted issues nor accepting contributed PRs.

8 Likes