11–20 of 125 posts
One thing I don't see here: It's difficult to integrate libs into e.g. parallel when they don't derive all the various things (Copy). Will a goal be to aim for deriving standards for libs looked at?
https://github.com/brson/rust-api-guidelines#interoperabilit...
Maybe the checklist should get a more prominent link or notice in the blog post. It took me a while to find it.
One thing I don't see here: It's difficult to integrate libs into e.g. parallel when they don't derive all the various things (Copy). Will a goal be to aim for deriving standards for libs looked at?
It's part of the checklist: https://github.com/brson/rust-api-guidelines#interoperabilit... Maybe the checklist should get a more prominent link or notice in the blog post. It took me a while to find it.
It's language design the way it should be: incorporating the cutting edge ideas from academia while still striving to cater to beginners; drawing on the strengths of other languages communities to build out good library and solutions to package management; designing everything in the open, and constantly seeking feedback from their users.
It's a great blend of theoretical CS, HCI, computer systems, and application development, and it's always fun to hear about what they're up to.
Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.
Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.
That unsafe code is filling a want or need, so otherwise people are going to use crates that haven't gone through the process, or even worse, roll it themselves.
Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.
I believe the stdlib one could be refactored, but I'm not sure. There are a lot of optimizations in that one.
IMO "no unsafe code" is a stretch. "no unnecessary unsafe code" is what it should be.
> The product of this process will be a mature core of libraries together with a set of API guidelines that Rust authors can follow to gain insight into the design of Rust and level up crates of their own interest. Is there a plan to make these things statically checkable by rustc/rustfmt/rust-tidy or some sort?
Yes! The statically checkable ones will be checked by rustc or Clippy. Though some of the guidelines are at a higher level than what those would be able to check. For example: rustc wouldn't be able to tell whether a particular one of your traits would be valuable to make accessible as a trait object.
My biggest gripe with the crate situation is that some of them require nightly. E.g. everything coroutines AFAIK.
Coroutines are kinda more like a language feature that people have hacked libraries to do codegen for instead, so IMO it's pretty understandable that it needs nightly.
Many of these libraries are prototyping designs that will eventually be proposed as part of the language.
Unfortunate name. I thought this was about libz aka zlib.