Hacker News Reader

Comment by jfaucett | Hacker News Reader

looking at these libraries that are non-extant makes me think that Rust won't be production ready for quite a time still...

The List:

1. HTTP

2. Crypto

3. Unicode

4. I18n & Localization

5. Date/Time

6. Generic SQL

These are things you can't just throw together quickly, it takes years to do these things right.

EDIT: I see your points guys, wrapping up C code will make some of these things go pretty quickly, and your also right about a lot of production apps - at least low level systems stuff - not dependening on hardly any of these. I suppose I was thinking of this as an app developer, and if your talking about creating desktop apps in Rust, like a Browser or a SQL-Editor etc, every one of these libs has to be at least pretty darn good - otherwise its just a headache for you as a dev.

View on HN

I wouldn't go so far as to say Rust will not be production ready until we have all of this. First of all, not all apps need all of these things; especially systems-level apps don't need most of this. Second, you can easily bind to C libraries that provide these things, making Rust just as production-ready as C is.

Of course, that isn't to diminish the importance of having high-quality, safe, idiomatic implementations of these things, but that shouldn't stop you from using Rust in production.

It depends on what your production needs are, and how much of the gaps are filled in by unofficial libraries in the meantime (e.g. there are Rust crypto libraries, but none that are officially endorsed). Production-readiness comes in degrees, especially for a community project like Rust that has a relatively small paid team.

Although the internationalization story looks pretty bad, I'm heartened by my firm impression that no language does it well, that serious apps (like Firefox) tend to roll their own. One of our driving philosophies in Rust is to get actual production quality subsystems into the standard library by proving them in applications like Servo.

Fortunately, Rust has a lovely C FFI, so for the time being any Rust library can just be a thin mapping over an existing implementation in C (the OP even suggests this for both Unicode and crypto libs). As years go on the API can remain the same while the underlying C bits get gradually replaced with Rust.

Out of that list, C++ has standard crypto and date/time, but it's production ready.

There's nothing stopping Rust from having a healthy ecosystem of third-party libraries that provide that functionality. Yes, including C libraries.

Reply on news.ycombinator.com