71–80 of 125 posts
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.
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…
> 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…
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? Or will all the crates that use it be fixed?
Again, denial. Not seeing many links from the "everything is OK, don't need to look at this" crowd.
[1] https://crates.io/ [2] https://crates.io/crates/rustc-serialize [3] https://github.com/rust-lang-deprecated/rustc-serialize
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…
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
There’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…
The 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 o…
That's pretty much the Stackage/LTS Haskell model. Seem to be working pretty well there.
Earlier 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?…
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…
It feels like the real issue is that anyone who considers themselves a writer, as well as a programmer, tends to have a blog; and that people who have blogs are incentivized to write "soft docs" as tutorial blog posts for their blogs, instead of as encyclopedia-style or cookbook-style additions to the given library's docs.
I wonder if a programming language could adopt a Code of Conduct discouraging tutorial blog-posts in favor of soft-doc PRs...
Earlier 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?…
The most downloaded stat appears to be for the most downloaded of all time. Considering the difficulty of using serde on stable until recently, it's not surprising that it has been downloaded so much and would continue to be as projects move away from it.
> It's not listed as "deprecated" on its own Cargo page.
This is true, however as you said the GitHub page and the docs page both mention that. Unless one already knows how to use the crate, they are probably going to check the docs and see the deprecation. Although having a deprecation notice on crates.io does seem prudent.
> Again, denial. Not seeing many links from the "everything is OK, don't need to look at this" crowd.
You kind of skipped over the part where the parent poster explained why it wasn't even a big deal in the first place. It really feels like you're grasping at straws to make a point and I don't see why. No one seems to be denying that a lot of unsafe code is potentially bad, but there is really no solid proof that there is an unreasonable amount of unsafe usage. In fact, the parent has mentioned and linked to a list of such usages. If you're going to make such an extraordinary claim I think it behooves you to provide more than just a handful of examples.
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…
There was actually a thread on /r/haskell a few months ago [0] in response to an HN comment. In that thread, a few libraries were mentioned as examples of having amazing docs.
For instance, Gabriel Gonzalez writes a Tutorial module for his libraries, which introduces the basics of the library and shows you the big picture. The tutorial walks you through different pieces of the library, how to use them, and how they come together.
It's hands down one of the most effective ways of documenting I've ever seen and I'd love to see other communities' take on it.
To point out a specific example, you should check out Turtle's tutorial [1].
[0]: https://www.reddit.com/r/haskell/comments/5khts3/on_haskell_...
[1]: https://hackage.haskell.org/package/turtle-1.3.3/docs/Turtle...
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.
> 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 true that unsafe code should be treated very carefully, but it's purpose is so that a sufficiently clever human can implement safe code that the insufficiently clever compiler cannot verify.
Really it should've been called trustme rather than unsafe. ;)