Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I find Rust the language does make it possible to avoid allocation and copying for lots of types, but the library ecosystem hasn't agreed on types to do that in API boundaries.

You often end up with e.g. `String`, especially in async libraries that need `:Send+Sync+'static` so lifetimes are right out. Now you can't avoid allocations and copies, you can't even reuse a single `String` buffer because the callee takes ownership. No, `Cow` is not an option, it has a lifetime parameter and if it was 'static we're right back where we started. `Arc<str>` could arguably have been an option but I can't say I have ever seen that in a library's public API.

This kind of code isn't just slower than C, it's slower than Go where unsafe heap object sharing is the path of least resistance because there's no clone() anyway. Go doesn't even optimize CPU-bound code well, but if you use one of these APIs heavily then avoiding allocations and copies can more than make up for it. It's a big If, but it's happened to me with mature, official async libraries.

Rust the language isn't the problem here, we need better shared 'static types to land in the standard library so crates aren't afraid to put them in their API surfaces. Strings are an obvious starting point, but vectors and maps should follow.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: