111–120 of 125 posts
Rust sorta has a de-facto code style. It'd be interesting to add tooling to cargo to make it obvious how to comply with the evolved standard style for Rust.
Earlier quoted context omitted.
I realize that statically checking for tests is reducible to the halting problem, but would it be possible to have some sort of code-coverage checker that would make sure all externally-facing functions have non-zero coverage? That could be used to construct a checklist for a library developer.
Code coverage in itself isn't a very useful metric. Classic example is big test with no asserts will get you pretty good coverage. There's a rather computationally intensive technique called mutation testing where you introduce bugs into code (e.g. change + to -, flip conditionals, etc.) and check that tests fail.
You don't need to completely dismiss other testing techniques. Mutation testing can be useful at the same time that code coverage is useful.
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"? > Everything else with unsafe code is an optimization. Often a premature one. Rc, Arc and Box require unsafe code for the obvious reasons that are not premature optimisations. Any attempt to use a syscall (look at the nix crate which wraps libc with safe APIs) requires unsafe code. Unsafe doesn't mean "this code is bad". It is tr…
https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-...
This is something Haskell could really benefit from. Largely just through writing documentation for common libraries. A post was recently on the frontpage of HN about using Haskell in production [1] that divided the common documentation experience between "hard" and "soft" docs. Far too often with Haskell you only get the 'hard' docs where you get descriptions of functionality and functions but it lacks why (and cohe…
Yes, this is very true of most rust docs that I've seen as well. Lots of libraries have the auto generated docs describing the functions and types usually at a per-module level but fewer have anything higher-level
See for instance the "image" crate docs: https://docs.rs/image/0.13.0/image/
A simple API doc, I don't know where to start. But then if I go to the repo I find a nice intro with some example code: https://github.com/PistonDevelopers/image/blob/master/README...
I realise this is being done with the best of intentions and will probably be a big net positive in practise, but something about the way it has been presented here rubs me up the wrong way. In short, the blog post makes very little mention of the role of the primary author(s) of the libraries in question, beyond "Every two weeks, hold a library team meeting [...] with the author in attendance." While I imagine the r…
Most of the crates being focused on are either maintained by the libs team already, or are authored by a member of the libs team. It turns out that the people on the libs team have written a lot of widely used and pretty solid libraries ;) Nobody is forcing stuff on random crate authors; if they didn't want to participate, then that's 100% okay.
As a prospective crate author - and every programmer is a prospective crate author - i interpreted this as saying that if i publish a crate which people find useful, i might be getting an unexpected visit from the Rust Police.
It is an unfortunate name. I don't know why, given how inclusive the Rust community usually is and how eager they were to remove master/slave terminology, that they would choose to announce this effort under the banner of Nazi war tactics.
I do wish cargo packages were namespaced a la Github. Squatting on usernames is one thing, but package and project names are often the only way you hear about something. cargo react-svg might be a terrible project or a good quality one maintained by facebook, but you wouldn't know from the name. Because of the name, it'll be at least somewhat downloaded if that's a common need. It makes grouping by org difficult too.
Feedback welcome.
Earlier quoted context omitted.
But you can read the dependency list or even the code and decide whether to use it or not?
Not in the presence of binary dependencies. Also the amount of CVEs in FOSS projects show that even the process of code review for patches isn't enough.
Earlier quoted context omitted.
Not in the presence of binary dependencies. Also the amount of CVEs in FOSS projects show that even the process of code review for patches isn't enough.
You mean, in projects written in languages that are unsafe from beginning to end rather than in small blocks?
Those patches also come in small blocks.
The article also links the state of rust survey. I visited the survey with intent to answer it but the first question "Do you use Rust?" only has the following three alternatives for an answer: - "Yes" - "No, I stopped using Rust" - "No, I've never used Rust" When making a survey the alternatives for the answers are very important. I feel that none of these alternatives apply to me. That's bad. Unfortunate because I…