sarah « the evolving ultrasaurus

Rust has a “community of developers empowered by their tools and each other” (via Katharina Fey in “An async story“). The Rust community helps each other through effective narrative documentation and attention to error messages, and the robust tooling around Rust drives momentum, overcoming some of the natural hurdles when diving into a new language.

Here’s my list of essential rust tools (so far):

The basics

rustup

The default tool when you install rust.

Rust has very good offline documentation (perfect for learning on long plane trips!). See rustup doc help for full list. Here are some highlights:

rustup doc --book              # Rust Programming Language book
rustup doc --rust-by-example   # collection of runnable examples
rustup doc --std               # Standard library API documentation

cargo

Cargo packages Rust code into crates. You can find published libraries at crates.io. After getting familiar with cargo.toml file which streamlines development and enables reproducible builds, I found command line management easier with cargo-edit:

cargo install cargo-edit
cargo add <crate>         # also provides rm, upgrade

Rust and Web Assembly

The Rust Wasm tooling has improved dramatically over the past year — wasm-pack is the “one-stop shop for building, testing, and publishing Rust-generated WebAssembly.” The rustwasm book is very good.

cargo install wasm-pack

rust-parcel

I’ve grown to dread building modern web apps with their complex JavaScript build tooling. In learning Rust, I discovered Parcel which lets you import .rs files from JavaScript. Under the hood, it compiles Rust to Web Assembly and hooks it all up into a tidy js src reference for my index.html. Simply breathtaking.

Parcel tool chain is idiomatic for NodeJS folk. npm run start will run a local server and watch your files.

npm init rust-parcel hello-rust-parcel
cd hello-rust-parcel

When you build your web app, it automatically prints out the kinds of things you should want to know. For many uses of Rust, compiled code size doesn’t matter, but for Web apps, it is important to keep an eye on download size:

npm run build

> create-rust-parcel@0.0.2 build /Users/sallen/src/rust/hello-rust-parcel
> parcel build index.html

✨  Built in 3.20s.

dist/rust_parcel_bg.d1b79d09.wasm    67.63 KB     13ms
dist/js.caa35af8.js.map              14.65 KB     11ms
dist/js.caa35af8.js                   7.49 KB    2.58s
dist/Cargo.8d29e058.toml              1.17 KB    1.16s
dist/index.html                         228 B    999ms

wasm on the edge?

Interesting to note that Web Assembly isn’t just for client-side browser code. WebAssembly on Cloudflare Workers creates potential for new edge capabilities.

TBD

I’m just scratching the surface as I learn Rust. My practical applications range from native client and server code, command-line tools along with my early Web app experiments. I don’t expect Rust to be my goto language for everything, but it’s fun to dive in and explore as I climb the steep learning curve of getting my code to reliably compile!

For people ahead of me on your Rust adventures, what essential tools am I missing?

Last night I attended ScalaBridge London. I met one student who had recently studied computer science and decided to focus on Scala because of all of her classes she enjoyed functional programming the most. Another student works with SAS (Statistical Analysis Software) and wanted to learn a new language for her own professional development.

The group was in the middle of a six week series, which is a neat format that they are trying out for the first time. This gives students the chance to get to know each other and work together in a cohort, diving deeper into practicing the language over time.

I was there at the kind invitation of Noel Welsh, since I am visiting London and organizing a London Bridge event on May 28th to introduce all of the local groups to each other. I took the opportunity to learn a little Scala too.

The students had progressed to learning structural recursion and one student showed a colorful Sierpinski triangle and explained how she generated the colors. In the photo below, you can see Noel acting as a low-tech projector, holding up the laptop, so the new Scala engineer could talk about her work.

Man holding laptop with graphic of triangles and woman smiling

Learning a little Scala coding

At first I was a bit skeptical of using graphics to learn a language which was not designed for that purpose, but the experience won me over. The concrete visualization of code is helpful and I found it as delightful as I did when I first learned basic on an Apple II many years.

I learned that Scala is strongly typed functional programming language that is light on syntax, not requiring characters at the end of statements and whatnot. Using the SBT console I made a little drawing, defining my own color purple and creating a value to reuse some code for each eye:

val purple = Color.rgb(80.uByte, 0.uByte, 150.uByte)
val eye = circle(10) fillColor Color.black on circle(20) fillColor Color.cornflowerBlue

The Creative Scala curriculum uses the Doodle library which has easy-to-use layout methods beside, above, below, on, and under. So I could write eye beside eye the same way that I can write 1 + 2. Like Ruby, operators are methods, and I could have written eye.beside(eye) or 1.+(2).

I overlaid the two eyes on a blue head, and attempted to create a mouth below:

(circle(10) fillColor Color.pink below eye beside eye 
on circle(50) fillColor purple).draw

pink circle mouth below left eye

Oops! This was not intentional, and ended up as a sweet graphical illustration of operator precedence — easily fixed by adding parentheses:

(circle(10) fillColor Color.pink below (eye beside eye) 
on circle(50) fillColor purple).draw

pink circle centered below both eyes

I think my logic error may have been a happy accident, since I think the lop-sided face is more expressive. In any case, the graphics made debugging fun — thanks Noel!

When Leah Silber reached out about my speaking at EmberConf, I was reluctant. I’m not doing much front end work these days, and the last time I looked at Ember was long ago when Yehudah Katz and Tom Dale held a feedback session for a very early version of their work. I changed my mind after an asynchronous text conversation with Leah, and listening to Yehudah talk about their work.

Attention to detail

Making software feel effortless isn’t effortless. I was impressed by the EmberJS team focus on backwards compatibility and agility, as well as the impressive performance of glimmer components. They were doing the kind of important, detailed work that doesn’t easily fit into a sound bite.

I told Leah that it reminded me of the work we do at Bridge Foundry, where significant positive change is composed of so many small actions. Leah echoed back all my feelings in her concise reply: “Reality is boring and full of hard work”

As I prepared for this talk, I realized that I don’t actually believe that reality is boring. Reality is messy and difficult. I thought about the hardship of when my kid was a toddler, of crumbs and sticky i-dont-even-know-what-that-was, being so bone tired all the time and also the wildflower in the kitchen and that moment of sun shining through the window casting a shadow on the wall that was so beautiful and I might not have noticed if not for a three year old that noticed everything.

So when I listened to the 2016 talk where Yehudah said that “instability is a drag on innovation” (Stability without stagnation, slide 5), I realized that we need to talk more about the people who are slowly and steadily fixing the broken things in this world. I was reminded of my colleagues in the government, both the techies who served a limited term, and the folks who dedicate their lives to service.

Small fixes to big problems

In the closing keynote for EmberConf 2019, I spoke about the parallels between the work of building (and fixing) software systems and the people systems that seem to rule our lives.

This talk was very much in the context of the Ember community, in honor of their hard work making good software that works well. I hope my words will inspire new voices to tell their own stories about what works well, of their own moments of mundane heroism or those they witness.

Notes

Below are some notes that I prepared in advance, that aren’t exactly what I said, and some things that I cut from the talk, since I always have more stories I’d like to tell.

Intro

At EmberConf 2019, Yehudah Katz in the opening keynote talked about the decisions we make, about how they encode our values and communicate to the world what we truly believe. Later in the day, Melanie Sumner talked about the things we choose to put in our software that no one asks for because we’re professionals.

We write tests and structure our websites for accessibility because we want our software to work and we choose frameworks that make our work easier. We choose to use the tools that give us power to move fast and make great things.

We live in a world where hype eclipses reality. You know how it goes… that new shiny thing that was invented yesterday makes headlines. Often when we put in the effort to make software that works well that doesn’t sound so exciting.

Maybe you have experienced that time when some heroic team worked weekends and nights to deliver in time and save the company, maybe you were even on one of those teams, I know I was, and at the time, sometimes I didn’t notice another other team that delivered solid code on time with no fuss. These days I think a lot about what we consider to be heroic.

Heroes are born through the stories we tell. We have the opportunity to define what we consider to be legendary. We each can decide what we value, the stories of success that we choose to tell.

Reality is messy. Designing and building things that are easy to use and work well is hard. It seems like people don’t want to hear about all the boring details. I’ll tell you a secret. The details aren’t boring. It’s just sometimes we need to work inside a broken system, or one that isn’t finished yet…. Reality is awesome, but things are little broken right now, things we see on the news, on twitter, things I can’t find in the Ember docs…

I joke, but sometimes it’s hard to know what to do.

Sometimes I just feel like reality is broken. This isn’t what I signed up for. This isn’t how they told me it was going to be… but I’m all grown up now, and I’ve picked up some techniques I’d like to share, about how we can change the rules

Today I’m going to share a few stories, a few details that I consider epic. And with these tales, I will share a very basic story of software engineers doing the thing we know how to do. Solving problems, shaping reality into something usable and practical. Because the world needs our skills.

Additional Notes, things I didn’t say

Abstractions make something more easily consumable — what are the essential things, or in a different context, the essential things?

What is success? have I adopted the mannerisms of the patriarchy? “Step forward, step back”

Do your homework! “This entire black history month has been like a terrible sociology 101 class where no one did the reading.” — Clint Smith

Alternate Conclusion

You’ve heard a lot of people here on stage say things. I’d like each of you to think about the stage upon which you live your own life. Each one of us has the power to change the world. In fact, we have no other option. With every word and action, we make change.

The world is pretty strange right now. People are divided. People are frustrated. No matter what side you are on, living in the world today, I think we can all agree that reality is broken. However, small actions can build on each other. Our presence has ripple effects that we rarely consider.

Who has the power to create this reality we live in? As it turns out, we all cooperate in making it so.

the evolving ultrasaurus

Sarah Allen's reflections on internet software and other topics

Author Archives: sarah

essential rust tools