Hacker News Reader

Comment by richardwhiuk | Hacker News Reader

This article takes ages to get to futures because the writer seems to want to go on some tour of Rust crates first.

Not to worry, we also spend some time messing with strace and GDB. I see it more as "giving a working knowledge of Rust" than a distraction. Some of these crates/tools are lifechangers, I wouldn't want folks to miss out on them.

I'm sorry yodelshady has run into a build error for cargo-edit (was it OpenSSL? screw OpenSSL) but also: the more folks run into these issues and report them, the sooner they're fixed. Also! I think cargo-edit should just be adopted by the default cargo distribution because it's all-around really good.

I only learnt about the logging and tracing crates existed from this blog post and I've already started using them, so thank you!

The Zero to Rust[1] series also has a fairly comprehensive look into these.

[1]: https://www.lpalmieri.com/posts/2020-09-27-zero-to-productio...

I have to agree with the first comment: Speaking as someone who was a tech trainer and writer of course materials, tutorial, etc. for a couple of decades, if ``carge-edit`` is not core to what you're trying to teach, leave it out. Get your own desires (ego) out of the way, and stick to teaching what you need to teach. Leave the distractions/side-tracks/proselytising to a separate lesson. You think of the lesson as "Giving a Working Knowledge of Rust"? Great! Then title it accordingly and don't dress it up in "futures" camouflage -- you're doing your readers/learners a disservice.

Many, many tutorials make this mistake.

> Then title it accordingly and don't dress it up in "futures" camouflage -- you're doing your readers/learners a disservice.

In their defense, the title is "Understanding Rust futures by going way too deep", and I think advice and tangents on best practices modules is easily covered by "going way too deep".

> you're doing your readers/learners a disservice.

Not every tutorial needs to be the same, cater to the same type of person, or try to explain things in the same manner. I think the bigger disservice to readers/learners would be to homogenize tutorials into what you think is best. That might work best for a certain type of person at a certain skill level, but that doesn't mean everyone will be served well by that. And as the comments here illustrate, it's not like there's a dearth of Rust futures tutorials and explanations. There's definitely room for a rambling, informal, irreverent, meandering take (it's the only thing that kept me reading until the end, or even past the first page or two).

This isn't a tutorial, nor a training, nor a course though, this is a cave exploration. Its going down the wrong paths, multiple times on purpose. So pack your bag, get your tools in order, we may not return. I really like this style, the wrong paths/side tracks have so much to teach us (more than the right paths).

As someone who's been a technical writer (albeit for years rather than decades), I think this is often good advice, but not here. As other people have pointed out, this isn't trying to be a Futures 101 or Futures for Total Beginners. The title or opening could maybe be clearer about its scope (although I think "way too deep" at least implies the author isn't covering the topic as directly or succinctly as possible), but I think the digressions are interesting to Amos' target audience and part of his style.

You have mistaken this for a tutorial.

I mean, we could also just let the guy write how he wants to write, since we're reading his stuff for free, and we aren't entitled to anything at all from him.

I enjoyed it, and I had never heard of cargo-edit before, and am really glad I now know about it!

Tracking issue on cargo-edit here: https://github.com/rust-lang/cargo/issues/5586

I too really, really want this. If only I had the energy to work up some patches...

I'd say this is a good explanation, but a bad tutorial[1]. Which is fine, they're different things. But if you want it to be a tutorial it should be focused on just Rust Futures, and the other stuff should be separated out.

[1] https://documentation.divio.com/

> we also spend some time messing with strace and GDB

Yes, and if I had learned about these a couple months ago it would have saved me ~8 hours tracking a bug down. So, thank you.

IMO if your article is long enough that it crashes MobileSafari, it should have a table of contents. Or it should be a book chapter. It’s a really obvious criticism of all of fasterthanlime’s posts that scarcely bears repeating at this point but they’re not getting any shorter. I get that he has a lot to say but I just don’t have time to wade through all of that. What slice of Rust users are both such noobs they haven’t heard of cargo-edit and can’t Google it, but also so advanced they are interested in implementing Future manually to deepen their understanding? It’s ok to teach both things but why together?!

Ok I promise I'm going to stop replying to those comments (because as you pointed out they show up on every post), but! Rust is not the only language with a decent type system out there.

I can definitely see some ML/Haskell/Scala/etc. folks who would quickly pick up on all the Future stuff, drawing parallels with their usual language of choice, yet being completely unaware of all the nice tooling around Rust. It's one of its main selling points for me!

Re cargo-edit specifically, it also lets me stay in flow while writing these: instead of having to repeat "we'll just edit Cargo.toml, make sure to have that under [dependencies], uh this time we need a feature so the right-hand-side needs to be an object, not a string" - instead I can just copy into the article the actual commands I run on my side, and if a quick paragraph about where that subcommand comes from unblocks even one person then it's worth it.

I wouldn’t worry too much about it. You have your style, and it clearly works for the people who like your work. Everyone likes different things, and it doesn’t make sense to force homogeneity. It’s ok to cater to niches.

FWIW, I fall exactly into that niche. I've never written a line of Rust in my life but am quite competent with Haskell and Ruby and have dabbled in at least half a dozen others. Seeing everyday `cargo` use made me think of bundler and the Future/Result type signatures were easy to map onto Async/Either and the like.

So yes, it's a long article but I didn't mind that in the least. Keep it up!

Ignore the naysayers in this thread; I don't really get why people think it's ok nitpick how you've decided to present a particular topic that you publish to the world free of charge. It's... kinda rude, IMO.

I really enjoyed reading this piece, and had never heard of cargo-edit, so thank you for that.

As a Scala person, I've actually struggled with Rust's Future, because it's quite different and requires a new mental model of how things work, which I think you did a great job providing.

> What slice of Rust users are both such noobs they haven’t heard of cargo-edit and can’t Google it, but also so advanced they are interested in implementing Future manually to deepen their understanding?

My colleagues. Many people are skilled programmers jumping into obscure problems with only a baseline level of familiarity with the greater environment.

Or for example me.

cargo-edit looks useful. None of the tutorials I've skimmed have mentioned it.

raises hand

I'm not sure how (or why) I'd google cargo-edit, because it's one of those things that you don't even think about until someone tells you about it, and then you're happy they did.

While I certainly wouldn't call myself a Rust expert, I'm no noob either, and am intensely interested in diving deep into topics like this. (Can we also dispense with the gatekeeping put-downs like "noob", please? It's unnecessary and rude.)

> It’s ok to teach both things but why together?!

Because the author felt like it, and since we're consuming his work for free, we're not entitled to tell him how to write?

Reply on news.ycombinator.com