101–110 of 125 posts
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…
Earlier quoted context omitted.
The thing is, you cannot decide which crate someone will depend on, regardless how it is labeled.
But you can read the dependency list or even the code and decide whether to use it or not?
Also the amount of CVEs in FOSS projects show that even the process of code review for patches isn't enough.
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 reality will be quite different, this sounds an awful lot like "oi, you, code review in my office now!"
One of the attractions of working on open source is that it offers more scope for autonomy and individual recognition than the typical commercial software job. It's slightly alarming that this doesn't seem to be recognised here.
As I say, I'm sure the reality will be fine (and I remain very keen to give Rust a serious try when time permits), but the rather collectivist presentation here is a tiny bit off-putting.
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…
It's not just this, either, a lot of the top-down communication in the Rust ecosystem has a feel like this. I'm not sure what to make of it, except that I think their attitude is probably too authoritative.
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…
Must say that I agree with you that the authors do not seem to take a very central role in the process as described. But I see that more as an easy fix in the announcement text.
I'm going to use this opportunity to second the suggestion that people consider taking this year's Rust community survey: https://blog.rust-lang.org/2017/05/03/survey.html . I know it's mentioned in the post, but I figure the number of people reading the comments is much larger than the number who actually click through the link. :P And even if you don't or have never used Rust, we still value your feedback!
Earlier quoted context omitted.
A guideline like "your tests should test all major functionalities of an API" can't be statically checked for example. It's not about the crate being non checkable, it's about the check being something that needs a human to look at.
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.
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.
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…
Nobody is forcing stuff on random crate authors; if they didn't want to participate, then that's 100% okay.
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.
I still feel there's a slightly-unfortunate ambiguity in the linked announcement post, though.
Earlier quoted context omitted.
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.
Thanks, that puts a slightly different perspective on things! I still feel there's a slightly-unfortunate ambiguity in the linked announcement post, though.
Words are hard.