Unfortunate name. I thought this was about libz aka zlib.
Ok, we'll cut the title's z supply.
The Rust Libs Blitz
91–100 of 125 posts
Re: The Rust Libs Blitz
#92Earlier quoted context omitted.
We've seen this unsubstantiated denial before on YC, at "Why I’m dropping Rust"[1] and "Rust sucks if I fail to write X".[2] I once started going through the Rust library packages and listed uses of "unsafe". Try doing that. The previous discussions made a few things clear: - The big design-level problems with data structure safety are 1) partially initialized arrays, and 2) backlinks. The first is needed for growing…
> Foreign code remains a problem, and is inherently unsafe when calling unsafe languages. The most downloaded Rust crate is "libc". What could possibly go wrong there? Was it really a good idea to import unsafe "strcpy" into Rust? And what would you prefer a tool like Corrode use? Or programmers manually doing an initial "no refactoring" conversion pass from C or C++ to Rust? Should they all use their own ad-hoc libc…
(I will mention that shifting unsafe to libstd is a good thing, this way you have more eyeballs on it and it's reusable, with less chance of people messing it up elsewhere. This is why a large fraction of what's in libstd is unsafe stuff so that people don't end up implementing their own.)
Re: The Rust Libs Blitz
#93Earlier quoted context omitted.
I've seen this problem in the Elixir library ecosystem as well. Regardless of the package, people do see the value in contributing to the commons with PRs for "hard docs" (because they themselves will probably need to read them again later, and don't want to get tripped up again by reading false docs.) But nobody wants to contribute "soft docs" to anything but the language core. It feels like the real issue is that a…
Soft docs are harder and take longer, and as said elsewhere are not appreciated enough. If I'm writing an Elixir library for (what I think) my own use, I'll stop at typespecs, docstring with an example, and a short description. I'll only start doing the tutorial doc and/or blog post if others have interest in the library. There's just not enough time :/
The thing is, it's not that there aren't a lot of blog posts. There are! There's usually at least one blog post about any library I care to use. But it's only a blog post—it's something someone wrote at some point—and so it's not corrected for misapprehensions the author (who is usually not the author of the library) had about the idiomatic way to use the library, nor is it kept up to date with changes in the library like soft docs would be.
I don't think there's a dearth of people willing to write blog posts. There's just a dearth of people willing to do the equivalent job to what Wikipedia editors do for general-purpose articles: collating those "primary sources" into a single, coherent, up-to-date overview.
Re: The Rust Libs Blitz
#94Earlier quoted context omitted.
> I once started going through the Rust library packages and listed uses of "unsafe". Try doing that. That's ... exactly what I did? Talk about denial. I went through the libraries in my .cargo folder (which filters for libraries that actually get used , not just random libraries out there). I linked you to that audit in the comment. Yes, libstd contains a lot more unsafe, but that's kind of the raison d'etre of libs…
rustc-serialize is deprecated It's the fourth most downloaded crate.[1] Somebody may have "deprecated" it, but the users aren't paying attention. It's not listed as "deprecated" on its own Cargo page.[2] There's a weak note about deprecation on its Github page, but users don't look there.[3] It has 2,950,353 downloads, probably because other crates are pulling it in. Will it be in the new set of "approved" packages?…
Number of downloads is pretty terrible metric because nearly all downloads from a package repository are from automated/CI builds, not people. Depending on what's consuming a package, something which runs tests more frequently could easily inflate the number of downloads for any of it's dependencies.
Re: The Rust Libs Blitz
#95This 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…
I've seen this problem in the Elixir library ecosystem as well. Regardless of the package, people do see the value in contributing to the commons with PRs for "hard docs" (because they themselves will probably need to read them again later, and don't want to get tripped up again by reading false docs.) But nobody wants to contribute "soft docs" to anything but the language core. It feels like the real issue is that a…
I don't think blog posts lack merit.
There's only so much you can put in docs, and docs can only really encompass one way of learning things.
Blog posts help teach things in other ways, and having that diversity of approaches is great.
This is why, for example, I love Julia Evans' (http://jvns.ca/) work. Most of the blog posts don't really uncover undocumented stuff. They just explore the topic in a novel way, which some people may find more accessible.
Rust is open to importing blog posts into the docs; this has happened a few times (once to one of my own posts!). So I'm happy that there are blog posts out there.
That said, if you're writing a blog post, it's good to see if there are bits than can be put into the docs too.
Re: The Rust Libs Blitz
#96There’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 possibl…
Swift is probably the closest thing to this today, where new versions of the language ship with a migrator tool.
Re: The Rust Libs Blitz
#97Earlier quoted context omitted.
We've seen this unsubstantiated denial before on YC, at "Why I’m dropping Rust"[1] and "Rust sucks if I fail to write X".[2] I once started going through the Rust library packages and listed uses of "unsafe". Try doing that. The previous discussions made a few things clear: - The big design-level problems with data structure safety are 1) partially initialized arrays, and 2) backlinks. The first is needed for growing…
> which then turns up in the JSON decoder at ( https://github.com/rust-lang-deprecated/rustc-serialize/blob... ). There are no comments on the safety of that. Maybe there's a reason it's in a repository labeled "deprecated", namely that it's deprecated. The replacement serialization framework, serde, has exactly one appearance of "unsafe", in a function that is only compiled when you explicitly enable the "unstable"…
The thing is, you cannot decide which crate someone will depend on, regardless how it is labeled.
Re: The Rust Libs Blitz
#98Earlier quoted context omitted.
https://github.com/bluss/ordermap is 100% safe rust and pretty fast 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.
That "ordermap" is nice. Could that replace std::collections::hash_map as the main supported map crate? It imports std::collections::hash_map, which has unsafe code, but only for RandomState, which does not. If RandomState were pulled out of hash_map and moved to a crate with no unsafe code, that dependency could be removed and it would be safe crates all the way down. IMO "no unsafe code" is a stretch. "no unnecessa…
Sure, it could replace the stdlib hash map. It would regress performance for some usage and improve it for others. (And this makes it an unlikely candidate; pure improvements are a lot easier to get in.)
Re: The Rust Libs Blitz
#99Earlier quoted context omitted.
> which then turns up in the JSON decoder at ( https://github.com/rust-lang-deprecated/rustc-serialize/blob... ). There are no comments on the safety of that. Maybe there's a reason it's in a repository labeled "deprecated", namely that it's deprecated. The replacement serialization framework, serde, has exactly one appearance of "unsafe", in a function that is only compiled when you explicitly enable the "unstable"…
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?
Re: The Rust Libs Blitz
#100The 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.