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

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

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

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

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 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?

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!

A note on Async

Calling Cargo Programmatically

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

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*

@yoshuawuyts

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store