docs.rs VS crates.io

> So it’s built into GitLab and GitHub? BitBucket?

No. It's built into the toolchain which every Rust developer has installed.

> How easy is it to use on windows (i.e. is it is easy as opening a .h in notepad and reading it)?

A easy as on Linux or macOS from my experience.

> How easy is it to use from a command line environment with vim or emacs bindings?

Not sure I understand the question; use how exactly? You either have a binding which runs `cargo doc` and opens the docs for you, or you use an LSP server and a plugin for your editor in which case the docs are integrated into your editor.

> I shouldn’t have to install a toolchain (let alone rely on a web browser) to read API documentation.

If you want you can just read the source code, just as you do for any other language, because the docs are right there in the sources.

For publicly available libraries you can also type in `https://docs.rs/$name_of_library` in your web browser to open the docs. Any library available through crates.io (so 99.9% of what people use) have docs available there, so even if you don't have the toolchain installed/are on your phone you can still browse through the docs.

I know what you're going to say - what if you don't have the toolchain installed and the library is not public? Or, worse, you're using a 30 year old machine that doesn't have a web browser available?! Well, sure, tough luck, then you need to do it the old school way and browse the sources.

You can always find a corner case of "what if...?", but I find that totally unconvincing. Making the 99.9% case harder (when you have a web browser and a toolchain installed, etc.) to make the 0.1% case (when you don't) easier is a bad tradeoff.

As a general rule (for established libraries at least), the docs for rust crates stored on https://docs.rs are pretty good. This comes from having docs being built-in to the tooling, so it's really easy to deliver docs in a consistent format.

I felt that way about node and yet node lead to an explosion of poorly written and designed packages and constant notifications about needing to upgrade project X because it depended on Y which depends on Z and Z has some DoS issue if you pass the wrong regex to it.

I don't feel confident that rust won't go the same way when I tried to update the rust docs (https://github.com/rust-lang/docs.rs)

    cargo build

Now JSR have changed this situation. After publishing the package, we can view API docs of each version (similar to docs.rs in Rust or pkg.go.dev in Go). All we have to do is to write few lines of JSON. Optionally you can publish a package from GitHub Actions by adding only few lines to a workflow file. Any other setup (install packages, write config for document generator...) is not needed.

Working in combination with CodeWhisperer in your IDE, you can send whole code sections to Amazon Q and ask for an explanation of what the selected code does. To show how this works, we open up the file.rs file cloned from this GitHub repository. This is part of an open source project to host documentation of crates for the Rust Programming Language, which is a language we are not familiar with.

Looks like a great initiative – I wish there was a reliable TS/JS equivalent of https://docs.rs (even considering rustdoc's deficiencies[1]).

I went through this exercise recently and so far my experience with trying to produce documentation from a somewhat convoluted TS codebase[2] has been disappointing. I would claim it's a consequence of the library's public (user-facing) API substantially differing from how the actual implementation is structured.

Typedoc produces bad results for that codebase so sphinx-js, which I wanted to use, doesn't have much to work with. I ultimately documented things by hand, for now, the way the API is meant to be used by the user.

Compare:

https://ts-results-es.readthedocs.io/en/latest/reference/api...

vs

https://tsdocs.dev/docs/ts-results-es/4.1.0-alpha.1/index.ht...

Rust Search Extension adds a section on docs.rs menubar which lists the features of a crate in a nice and easy to access format.

📝 Note: At the time of writing this post, I couldn't really locate the init function docs.rs documentation. It didn't seem easily accessible through any of the current HAL implementation documentation. Nevertheless, I reached the signature of the function through the source here.

Rust Crates are a Game-Changer 🎮:The ease of releasing a crate with `cargo publish` and the convenience of rolling out new versions amazed me. The auto-generated docs on Docs.rs. is an amazing tool, especially with docstring formatting. Doc tests serve as a two-fold tool for documenting the code and ensuring it's up-to-date.

I've found I manually type out certain subsets of URLs where possible[0], maybe that's subconsciously associated with my impression that Google Search results have gotten worse and worse over the years.

[0] https://en.wiktionary.org/wiki/ and https://docs.rs/ come to mind.

I've been ramping up on the embedded Rust ecosystem over the last few weeks. I'm pretty excited about it partly because it makes this aspect of embedded development much more approachable. On https://crates.io I can usually find a driver for whatever peripheral I want to use in my project. And the driver usually implements the embedded-hal [1] interface, so the more I get familiar with that interface, the easier it becomes to implement any arbitrary peripheral into my project. In the event that there does not already exist a crate for my peripheral, I have an extensive ecosystem [2] of open source driver code that I can refer to in order to figure out how to implement the driver.

I think this could help with the "dark art of reading datasheets" problem. E.g. last night I was curious about how the driver for a 28BYJ-48 stepper motor would work, so I looked at the code [3] for its driver and got a pretty good sense of what's going on. If I were to now attempt to read the datasheet, a lot of it would now make sense. In other words I think it's too daunting to read a datasheet and then try to implement code. The way to get comfortable with datasheets is to first look at code and then find the relevant parts of the datasheet.

[1] https://github.com/rust-embedded/embedded-hal

[2] https://crates.io/keywords/embedded-hal-driver

[3] https://github.com/MnlPhlp/uln2003

I often hear this and am confused; not only are things like ['object soup'](https://jacko.io/object_soup.html) possible and straightforward (putting things in collections and referring to them by indices), I never concretely hear why a graph or doubly-linked list becomes uniquely difficult to implement in Rust (and would genuinely be curious to learn why you feel this way). If you needed such data structures anyway, they're either in the standard library or in the many libraries ('crates' in Rust-lingo) available on [Rust's package registry](https://crates.io/)---using dependencies in Rust is very straightforward & easy.

Rust Package Registry (crates.io)

crates.io is the central repository/registry for Rust crates. It's a crucial part of the Rust ecosystem.

Oh dear.

I see Redis Inc. have decided to go full Nagios.

Never go full Nagios.

Though admittedly Nagios' attempt to pull similar assholery wrt CPAN did end up being a source of some amusement to me: http://p3rl.org/Nagios::Plugin

I hope the http://crates.io team react similarly.

Spin 3.0 introduces a workflow for this type of development in the hopes of making it seamless to do things like write a library for some compute intensive task in Rust and use that as a dependency in a JavaScript application. Or perhaps you’re not a Rust developer and don’t feel like learning it overnight? No problem. Fetch a component someone else already built from an OCI registry. Component dependencies can be stored, discovered, and fetched from OCI registries giving you the npm/NuGet/crates.io style experience but for Wasm. Now, I think this particular feature is wild and could go on about it for at least a thesis, but there are even more Spin 3.0 topics to discuss so feel free to dig deeper in the component dependencies documentation here and in the demo later on.

Rust: crates.io

Rust has a rich ecosystem of frameworks and libraries that let you read, parse, and manipulate text files, interact with cloud services and databases, and perform any other job that your project's development workflow may require. And because of its strong typing and tight memory management, you are much less likely to write programs that behave unexpectedly in production.

All the code discussed in this article can be accessed through this repository. For integration with existing projects consider using keyword_extraction crate available on crates.io.