9 ms·
The Rust Libs Blitz
- eriknstr 9y agoThe 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 would have liked to participate in the survey. I've done a little bit of beginner programming in Rust in order to try and learn the language. However I haven't yet used it to implement anything actually useful so I wouldn't say "yes, I use Rust". It's been a while since last I did something in Rust but I wouldn't say "no, I stopped using Rust" because to me that implies that I have decided that Rust is not for me, which is not something that I feel, I want to use it, I just keep pushing it down on the list of things to do because other more immediate desires and problems keep popping up.
- seqastian 9y agoSo, just take YES and move on? Surveys are about trends not about absolutes.
- Nomentatus 9y agoI would have thought he should say NO, or maybe that he quit given his situation. So maybe he could roll a dice* for the answer - but that wouldn't really provide information. One more slot wouldn't hurt. *"roll a die" for those who prefer more atavistic conventions - see research on Latin plurals rendered in English over time and with regard to frequency of use.
- emmelaich 9y agoI'm in the same boat but answered no. I'll go with the grandparent coment and suggest that an option indicating that you've tinkered and dabbled with it and no more. (Sorry, a more appropriate wording doesn't come to mind at the moment)
- divs1210 9y ago> i use it in production > i use it for hobby projects > i have played with it > i have never used it Clojure survey had something along these lines
- stuaxo 9y agoI'm also in the category of having tried it a couple of times, but never hit the velocity to be able to write anything myself.
- dasmoth 9y agoI 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 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.
- JasonSage 9y agoI had the exact same reaction—it is very off-putting. 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.
- cies 9y agoI would be thrilled to have my code reviewed! Quite often I see requests for "please critique my code" in subreddits of several programming languages. 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.
- steveklabnik 9y agoMost 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.
- dasmoth 9y ago
- mintplant 9y agoMay I suggest the bytes crate [0]? It's one of those small libraries providing a key building block (mutable and immutable byte buffers), and is a dependency of tokio-io and any other crate which implements tokio-io's Encoder/Decoder traits. [0] https://crates.io/crates/bytes https://crates.io/crates/bytes
- brson 9y agoYes, thank you for the suggestion. I agree that's a good candidate and will note it on thread.
- modeless 9y agoUnfortunate name. I thought this was about libz aka zlib.
- PopsiclePete 9y agoI thought it was a political title about new Democrat contenders challenging Republicans in the Rust Belt, after the recent health-care drama.
- AndyKelley 9y agoandy@xps ~> python3 >>> "Libz" == "libz" False
- gue5t 9y agoAlso works in python2 for those of us stuck in the 1950s.
- mrob 9y ago>>> title_case("Libz") == title_case("libz") True
- AndyKelley 9y agotouché
- dom0 9y agoThat actually confused me as well :)
- dang 9y agoOk, we'll cut the title's z supply.
- wyldfire 9y ago> 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?
- dtolnay 9y agoYes! 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.
- Manishearth 9y ago(Also, if this isn't clear, clippy is more than happy to accept PRs for criteria like these.)
- ronjouch 9y agoBeginner question: what would make a crate non-statically-checkable?
- Manishearth 9y agoA 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.
- moosingin3space 9y agoI 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.
- Animats 9y agoDoes 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.
- eridius 9y agoWhy do you say premature? Maps, for example, being such a crucial and widely-used data type, should be optimized as much as possible. There's nothing premature about using `unsafe` to build a highly-efficient Map.
- Animats 9y agoLet's see the benchmarks justifying the use of "unsafe" for maps. Maybe there's a better way to do it without much of a performance penalty. It's a good way to find out what optimizations the compiler is missing. It may even turn out that unsafe code written early no longer is a performance win, since the Rust compiler is getting better at optimizing out redundant subscript checks. When you start looking through Rust libraries, "unsafe" turns up way too often.
- leshow 9y agoUnsafe rarely turns up in any of the libraries I've used. Where are you getting this from?
- Manishearth 9y ago(The hashmap that is used in the winning rust benchmarksgame entry is 100% safe, fwiw) > When you start looking through Rust libraries, "unsafe" turns up way too often. You keep making this claim without substantiation. Yes, there is some level of unnecessary unsafe, but certainly not "way too often". I recall going through all the crates in my .cargo and finding very little unnecessary unsafe, and showing you the audit: https://news.ycombinator.com/item?id=13280347 https://news.ycombinator.com/item?id=13280347 Please stop throwing around this claim without substantiation.
- bpicolo 9y agoOne 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?
- no_protocol 9y agoIt's part of the checklist: https://github.com/brson/rust-api-guidelines#interoperability 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.
- bpicolo 9y agoAh cool, thanks for the link.
- jhasse 9y agoMy biggest gripe with the crate situation is that some of them require nightly. E.g. everything coroutines AFAIK.
- Manishearth 9y agoThe coroutine libraries are the codegen ones, yes? 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.
- moosingin3space 9y agoSince Rust 1.15, most libraries that require nightly seem to be this kind of prototyping, at least to my eye.
- z1mm32m4n 9y agoI really love seeing articles like this come out about Rust. 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.
- deleted 9y ago[deleted]
- newsat13 9y ago> I really love seeing articles like this come out about Rust. Yeah, me as well. It's a perfect marriage of academic know how and pragmatism. Very exciting year for Rust.
- stcredzero 9y agoThere’s a countervailing mindset which, in its harshest terms, says “the standard library is where code goes to die” This can be addressed in a language with sufficient annotation and good parser tools. In some future language, there should be a unification between the version control, the de-facto codesharing site, language/library versions, and syntax-driven tools to automatically rewrite code. It should be possible to "publish" a language and its libraries such that any breaking changes will automatically be updated when you switch library versions. (This should also be applicable to Entity-Relation diagrams and Object-Relational mappings -- those can be treated as a versioned library.)
- solidsnack9000 9y agoSwift is probably the closest thing to this today, where new versions of the language ship with a migrator tool.
- skybrian 9y agoThe problem is that the number of possible combinations of versions grows rapidly as you add versions. This makes testing harder, as it spreads the community thin - everyone's using a different combo than everyone else. To avoid that, you need to standardize on a blessed set of versions to be tested together, much like assembling a release of a Linux distro. People will still swap in alternate versions of libraries occasionally, but keeping things mostly standard and a few cherry-picks is still better than everyone choosing differently.
- stcredzero 9y agoThe problem is that the number of possible combinations of versions grows rapidly as you add versions. The point is not to let people hang out in whatever obscure snowflake version-set they want to. The point is to make migration going forward as painless as possible. However, that expectation is not so much about the tooling as it is about the developer/language community. To avoid that, you need to standardize on a blessed set of versions to be tested together, much like assembling a release of a Linux distro. Yes, there should be this! However, you will still have some stragglers and outliers -- this is what the historical reality shows us. The point of such tooling is precisely to minimize the pool of stragglers, not to maximize them!
- dmix 9y agoThis 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 cohesively how) you would want to use the various functionality. This makes a strong assumption you are already deeply familiar with the usecase and implementation concept. This may apply to Rust as well. Rust will likely attract experienced developers, much like Haskell, where in most cases a decent level of code quality would be anticipated. But one of the hardest things to get right as an OSS developer is documentation. You're often so busy with the burden of maintenance that the explanatory side gets sidelined. Especially as a library and the underlying language evolves. So I hope this is a priority focus during their reviews. [1] https://news.ycombinator.com/item?id=14266462 https://news.ycombinator.com/item?id=14266462
- ketralnis 9y agoYes, 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
- simias 9y agoMost of the time I find that the lib's github's README.md contains the introduction and overview that I want to understand how the library works. Unfortunately it's not in the docs themselves, but I hear that the Rust team is working on improving that. See for instance the "image" crate docs: https://docs.rs/image/0.13.0/image/ 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.md https://github.com/PistonDevelopers/image/blob/master/README...
- aturon 9y agoYes, and that's definitely something we hope to address with the Blitz, both by beefing up top-level library docs, and through the Cookbook.
- microcolonel 9y agoRust 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.
- kzrdude 9y agoSome of the format rfcs basically went against the most dominant style (for example where clauses), so things are changing around.
- hackcrafter 9y agoThere is definitely a changing Rust definition of good code hygiene in terms of how to write code in the most "Rustic" way, but in terms of code formatting, there is already rustfmt[0] [0] https://github.com/rust-lang-nursery/rustfmt https://github.com/rust-lang-nursery/rustfmt
- tveita 9y agoClippy has some checks for naming convention beyond what rustc and rustfmt does. Not nearly as much as https://github.com/brson/rust-api-guidelines https://github.com/brson/rust-api-guidelines, but the wrong_self_convention check helped me make sense of the as/to/into conventions. https://github.com/Manishearth/rust-clippy https://github.com/Manishearth/rust-clippy
- kibwen 9y agoI'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 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!
- xbpx 9y agoThanks for the reminder, done!
- rjammala 9y agoThanks, I just took it.
- seeekr 9y agoheads up: On page 15 it feels like the questions are not written from a user-centric point of view any more, while the previous ones were excellent. "The Rust project" has an unclear or at least less significant meaning to me as a user than probably to someone working on increasing Rust adoption, which I gather the first 2 questions on p. 15 are about? ("Rust project" could also mean "that thing you're working on using Rust", to me as user/dev. Usually you folks call it "Rust language" or something with "community" etc.) Great survey otherwise, just about to finish it!
- luck_fenovo 9y agoIt 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.
- ben0x539 9y agoI unironically agree with this. That's not a use of the generic German word for lightning, it's a specific reference.
- Retra 9y agoYes, it is a well known fact that Germans have no word for 'lightning' anymore. Such a tragedy that 75 years later, we're still supposed to be fighting the Nazis on their terms.
- dang 9y agoPlease don't do this here. We detached this subthread from https://news.ycombinator.com/item?id=14275990 https://news.ycombinator.com/item?id=14275990 and marked it off-topic.
- bhickey 9y agobstrie is coming by my place tomorrow, we're going to take a stab at overhauling `rand`. We must've been discussing this for two years.
- brson 9y agoOh great. Keep us updated.
- ssdfe 9y agoI 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.
- MoSal 9y agoI wrote cargo-esr[1], an alternative tool for searching crates, with the purpose of narrowing down good choices. Feedback welcome. [1] https://github.com/rust-alt/cargo-esr https://github.com/rust-alt/cargo-esr
- IshKebab 9y agoYeah I agree. It would be unfortunate if for example I were to register a crate called 'json' or 'http' or whatever but make it shit.