Rust MMXVIII, but, like, from a casual perspective

*ring ring*

Hey all! So recently the Rust team asked folks to share their feedback on what they’d like to see happen in Rust during 2018. I’m not much of a Rustacean myself, but I, *cough*, dabble.

Ahem, anyway. Yeah. So this is going to be highly subjective, and probably rather specific. I’m someone who’s pretty comfortable with one language (JavaScript), but hasn’t done an awful lot of Rust.

So this is not a post outlining high level perspectives of what Rust ought to become in MMXVIII (pronounced: “mixveeee”). It’s not a debate of stability vs innovation. It’s a post about what I’ve struggled with every time I’ve picked Rust up from the shelf over the last year or so.

So now that the disclaimer is over — let’s dig in.

Clippy is tricky

Soooo Clippy. It has a fun name. It catches errors for you. And it tries to help out on things that the compiler doesn’t necessarily want to.

I’ve seen people often say things like: “Well, for feature x and y to land, our baseline is that it should pass the Clippy tests.” It seems people take Clippy pretty seriously, and I kinda get why.

Now what’s weird to me is the way Clippy is integrated in the ecosystem. It’s this one super important tool that everyone should be using — but is not part of Cargo. There’s not even a hint of it being supported in Cargo. I get that it’s part of rust-lang-nursery, and thus considered to be picked up as part of “rust core”… but… it isn’t yet.

I really wish clippy would be more closely integrated with Cargo. Cargo is meant to be this high level wrapper around rustc(1) that can do things like fetch remote packages, run tests, run bencmarks, create projects. From a user’s perspective I’m kind of wondering why linting isn’t part of this. I feel it would be a good fit, and it would make it easier for people to use Rust all together.

Binding to C is… well yeah

… umm yeah, so binding to C is not the worst. Bindgen is pretty amazing. But then I’ve also managed to get things to break without getting a good reason. So I was a bit confused, and not confident enough (read: didn’t want to invest the time) to figure out what was wrong.

I feel binding to C is an important part of Rust’s story. It’s already quite good, but I wish this part of the workflow would be lifted up to be amazing. rustc(1) is pretty great at telling explaining things, it’d be neat if Bindgen became as good, but like in its own right.

Does that make sense? I hope it does!

cargo install, but not really

So the other day I was not at home. I kinda forgot the exact location, but I was tethering off a friend’s phone. Now my friend wanted to grab a slice of pizza, and I was like: “Nah man, I’m going to stay back here and play around with OpenGL bindings.” And my friend was like: “Yeah okay, but I’ll be taking the internet with me.”

And I was like: “Oh wait up, I need like 2 more minutes to get these packages off Cargo.” And my friend was like: “Sure.”

Fast forward 5 minutes.

“Okay sweet! Let’s try to run this thing.”

“Cannot connect to internet.”

Ooops. So apparently Cargo requires an internet connection the first time you try and run a thing. That’s unexpected. I mean: npm, homebrew, and pacman don’t work that way. I was surprised Cargo did. I felt surprised, but also a bit disappointed. I feel this could be better.

[offline] computer says no

Three years ago I moved to Australia. There was an 8 week period in my life or so, where I spent 4 hours a day offline, commuting back and forth from Thirroul to Bondi through an internet deadzone.

In hindsight it was quite fun to be offline for so long. I learned how to navigate my node_modules directory. I learned how to look up things in man pages. I learned to how to make documentation available offline for later use.

Now the other week I was setting up a new laptop from scratch. I didn’t have a browser installed yet (or a window system, for that matter). But I figured I had vim, and that was enough to write some Rust, right? Wrong.

We need docs to write code. They should be of high quality. And they should be available. In my case I struggled to find docs for basically anything. C has manpages available for pretty much every function call. There’s a culture of making docs in .troff that work offline everywhere.

Are man pages ideal? No. But they’re a versatile tool that solves a particular set of problems well. Stuck in a terminal? man pages gotchu. Offline and no chance to tether? Welp, at least there’s man pages. Did you SSH into a server, and you’re trying to figure out what this one thing does? apropos <keyword> and you might get somewhere.

But yeah, .troff is weird to write, and man is by no means the end-all solution to all problems. However, for people in non-ideal situations they can be a great help. I wish Rust had a good story for offline documentation in less-than ideal situations. And no, it can’t rely on a browser. Think of situations that are worse than that. Literally a kernel + rustc .

Note: I’ve got this weird gripe where I’m super unsure how people will perceive this. Possibly the only :/ interaction I’ve had with the Rust community was when I brought up things about working in less-than-ideal situations. I hope this doesn’t get dismissed out of hand by people that can’t relate to working in situations that aren’t ideal. Instead, like, trying to understand the perspective might help the flow of people that don’t have the privilege of working with reliable infrastructure.

Rust & WASM, how do we publish?

I know, I know — it’s still the early days for Rust and WASM. People are figuring out how to make the WASM target for Rust work at all. However, there’s probably one thing above all that I wish would work well here.

I wish there was a good story on how to publish compiled WASM to npm. I know Ashley joined some important Rust leadership team that might have a say in this. So I’m guessing there’s a substantial chance that this might already be in the works (Ashley works at npm). But yeah, felt I needed to say this too, because, like, just in case.

Where is Cargo-Add?

$ cargo add should be a thing. There might be reasons why this isn’t in there. But from a user’s perspective, the lack of a single command to install a package from crates.io has weirded me out since like forever.

And yeah yeah, I know cargo-edit is a thing. But it shouldn’t be. Being able to install packages by name should be part of the Rust Experience, Standard Edition™.

Rustup!

Coming from Node, all I have is love for this tool. It’s so well done, and even though I’m sure it isn’t perfect — the fact that the install page on rustlang.org tells us what the right way is to install things is… amazing!

A note on Async

I’m really happy with the way Tokio is shaping up. The Rust community seems to be agreeing that it should be the way everyone does async programming, and that’s neat! I’m curious to see where it’ll end up — a fun stretch goal would be if async programming in Rust could become just as easy as in say: Node, or Go. But yeah, I’m probably not saying anything new here. Just felt like sharing that I’m happy about the way things seem to be going! :D

Calling Cargo Programmatically

Sooooo, being able to call Cargo programmatically would’ve made writing rustify easier. Maybe it can already be called programmatically. Maybe we need rustc bindings first. I’m not sure. This might be a total stretch goal.

But yeah, I’m pretty sure that if at some point there are stable, cross-language bindings for the Rust compiler, using it across languages might suddenly become a lot more convenient.

Wrapping Up

Hey, so, I think this is it. Thanks so much for reading it all the way through! I apologize for not using less words. I’m writing this on a Sunday, so I just let myself write.

I’m quite excited for how Rust (and its community) are shaping up. You’re all doing a stellar job!

Anyway, I’m bad at saying goodbye. But I should. So. Goodbye. And maybe. I’ll catch y’all later.

Bye.

*click*