Podcast appearances and mentions of steve klabnik

Last week, our colleague (and frequent Oxide and Friends guest) Steve Klabnik made some new friends on the Internet with a blog entry on AI discourse. Bryan and Adam were joined by Steve to try to de-polarize the discussion a little.In addition to Bryan Cantrill and Adam Leventhal, we were joined by special guest, Steve Klabnik, and valued listener, Julian Giamblanco (aka "Oatmealdealer").Some of the topics we hit on, in the order that we hit them:Steve's blog post: I am disappointed in the AI discourseOxF: A Baseball Startup with Paul Freedman and Bryan Carmel (The Ballers)OxF: Adversarial Machine Learning with Nicholas CarliniOxF: Hiring Processes with Gergely Orosz ("the RFD 3 podcast episode")OxF: AI Disruption: DeepSeek and CerebrasOxF: Reflecting on Founder Mode ("ego con")If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

Recently, a change to a utility in the Rust toolchain changed behavior in a way that impacted users. Rather than being a story of frustration and aspersions, it was a story of a community working... and working well together! Bryan and Adam were joined by Dirkjan Ochtman (of the rustup team) and Steve Klabnik to discuss.In addition to Bryan Cantrill and Adam Leventhal, we were joined by special guest, Dirkjan Ochtman, and treasured colleague, Steve Klabnik.Some of the topics we hit on, in the order that we hit them:Steve: A Happy Day For RustPRs needed!If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

Love Rust? Us too. One of its great strengths is its ecosystem of crates. Rain, Eliza, and Steve from the Oxide team join Bryan and Adam to talk about the crates we love.In addition to Bryan Cantrill and Adam Leventhal, we were joined by Rain Paharia, Eliza Weisman, and Steve Klabnik.Some of the topics we hit on, in the order that we hit them:prettypleasewinnowBlessed.rs crate listAdam's codegen templatemietteeliza_errorserde_path_to_errorratatuiRatatui episode on January 27th!modular-bitfieldlexoptloomOxF: Software VerificationpaloozaCDSCHECKER: Checking Concurrent Data Structures Written with C/C++ AtomicsThe Postcard Wire FormatpostcardBBQueue Explained [video]petgraphU2MatrixGraph in petgraph::matrix_graphWhat does ## (double hash) do in a preprocessor directive? - Stack Overflowsamitbasu/rhdl: A Hardware Description Language based on the Rust Programming LanguagehttpmockcaminoOxF: The episode formerly known as ℔OxF: Dijkstra's Tweetstorm - YouTubeevmapbuf-listIf we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

The annual predictions tradition returns for 2025! Bryan and Adam were joined by Simon Willison, Mike Cafarella, Steve Tuck, and Steve Klabnik to review past predictions and look 1-, 3-, and 6-years into the future.See the table of predictions on GitHub.

Paul Frazee joins Bryan, Adam, and the Oxide Friends to talk about the inner workings of Bluesky and the AT Protocol. Paul and the Bluesky team have been working on decentralized systems for years and years--very cool to see both the next evolutionary step in those ideas and their successful application in Bluesky!In addition to Bryan Cantrill and Adam Leventhal, speakers included our special guest, Paul Frazee, and slightly-less-special guest, Steve Klabnik.Some of the topics we hit on, in the order that we hit them:ScuttlebuttBluesky FirehoseBluesky JetstreamBluesky and the AT ProtocolBluesky Feed: Quiet PostersBluesky's bot invasion: AI accounts argue with everything you postAI Imagery labeleratprotoOxide starter packIf we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

What's even cooler than writing your own text editor or your own operating system? Building your own hardware from scratch with all the software written in Rust -- including firmware, the scheduler, and the hypervisor. Oxide Computer Company is one of the most admired companies in the Rust community. They are building "servers as they should be" with a focus on security and performance to serve the needs of modern on-premise data centers.In this episode, I talk to Steve Klabnik, a software engineer at Oxide and renowned Rustacean, about the advantages of building hardware and software in tandem, the benefits of using Rust for systems programming, and the state of the Rust ecosystem.

In software engineering, C++ is often used in areas where low-level system access and high-performance are critical, such as operating systems, game engines, and embedded systems. Its long-standing presence and compatibility with legacy code make it a go-to language for maintaining and extending older projects. Rust, while newer, is gaining traction in roles that demand The post Rust and C++ with Steve Klabnik and Herb Sutter appeared first on Software Engineering Daily.

In software engineering, C++ is often used in areas where low-level system access and high-performance are critical, such as operating systems, game engines, and embedded systems. Its long-standing presence and compatibility with legacy code make it a go-to language for maintaining and extending older projects. Rust, while newer, is gaining traction in roles that demand The post Rust and C++ with Steve Klabnik and Herb Sutter appeared first on Software Engineering Daily.

The Oxide Friends talk about about cultural idiosyncrasies--turns out we have a lot of them at Oxide! Some might even sound good enough for you to try out! Demo Fridays, morning water-cooler, no-meet Wednesdays, recorded meetings, dog-pile debugging (aka CSPAN for debugging), RFDs (requests for discussion), no performance review process...In addition to Bryan Cantrill and Adam Leventhal, we were joined by Oxide colleague Steve Klabnik.Some of the topics we hit on, in the order that we hit them:Bryan: Engineering a cultureMatt: It's Free Real EstateCliff: Who killed the network switch?OxF: Engineering CultureDemo DayJujutsuCovid as a catalyst for remote-friendly featuresWatercooler morning meetingNo-meet WednesdayOtM: Jeff RothschildNo (formalized) review processThe non-zero-sum value of praisePositive Coaching AllianceChat as the apple of discord (and remember email?! Or jabber??!!)DORAOxide RFDsRFD 68: Partnership as Shared ValuesMatthew Sanabria: Observability Companies to Watch in 2024"Chat""Rock and stone"If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

Sometimes Bryan gets trolled by a tweet and brings it to Adam and the Oxide Friends. This was a well-crafted troll: is innovation slowing? Are the most interesting problems solved. In a word: no. For many more words, listen in!In addition to Bryan Cantrill and Adam Leventhal, we were joined by Steve Klabnik.Some of the topics we hit on, in the order that we hit them:The TweetNate SilverSecularitySecular stagnationAngela Collier: physics progress in the last 70 years?Haber processCRISPR gene editingBook: Code Breaker by Walter IsaacsonLeonhard EulerDijkstra's algorithmRaftAntibioticAcquired: TSMCEUV lithographyIf we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

Bryan and Adam are joined by Oxide colleagues Josh Clulow, Patrick Mooney, and Steve Klabnik to discuss Helios, the operating system that runs on the Oxide Rack. Helios is a distro of illumos (derived from OpenSolaris, derived from Solaris, etc.). What's a distro? Why did Oxide choose illumos? Plenty of cross-generational appeal in this episode!Some of the topics we hit on, in the order that we hit them:The Helios github repoHacker News thread its releaseOmniOSRust Tier 2 supportBryan's talk on holistic bootOxide and Friends: Holistic BootOxide and Friends: Shipping Rack 1The Quality Death SpiralOxide's "St. Louis" branch of illumosBryan's sleeper bug from 1991illumos books (How's this for some SEO?!)If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

We love Rust at Oxide, but the haters aren't wrong: builds can be slow. Bryan and Adam are joined by Sean Klein, Rain Paharia, and Steve Klabnik to discuss techniques for analyzing and accelerating Rust builds.In addition to Bryan Cantrill and Adam Leventhal, speakers included Sean Klein, Rain Paharia, and the illustrious Steve Klabnik.Some of the topics we hit on, in the order that we hit them:go forth and vibe in this minecraft paradise I seededDinosaur bookRoslyn--timingsSteve's "outlining" exampleRain's cargo-hakariRain speeding up Omicron buildsBlog post on many of these topicsSean's fix to u32 overflow bugminiserdemoldDavid Tolnay on pre-compiled macros in wasmBuck2Build Systems à la CarteIf we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

Oxide Founder and CEO, Steve Tuck, joined Bryan, Adam, and Oxide Friend, Steve Klabnik, to talk about our recent announcements: general availability of the Oxide Cloud Computer, and raising $44m. The reception was (broadly) great! Bryan and Steve answered questions about the product, company, and launch.In addition to Bryan Cantrill and Adam Leventhal, we were joined by Steve Tuck and Steve Klabnik.If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

This episode is coming from the archives, originally recorded in May 2022 - James talks with Steve Klabnik from Oxide Computer about knowledge transfer within the Rust community, how learning-by-doing and reading datasheets help you develop, and how limits and regulations are put in place across many different fields.

Bryan and Steve Klabnik discuss Fred Brooks' essay "No Silver Bullets"--ostensibly apropos of nothing!--discussing the challenges to 10x (or 100x!) improvements in software engineering.In addition to Bryan Cantrill speakers on included Steve Klabnik, Ian Grunert, and Tom Lyon.Some of the topics we hit on, in the order that we hit them: No Silver Bullet by Fred Brooks Sub-podcasting (it's a thing!) this video: Fred Brooks speaking on No Silver Bullet Ruby on Rails demo (2005) Future of coding podcast Amdahl's law FizzBuzzEnterpriseEdition Knuth and McIlroy Approach a Problem If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

In an Oxide and Friends tradition, Bryan and Adam invite the community to share book recommendations.In addition to Bryan Cantrill and Adam Leventhal, speakers on included Steve Klabnik, Tom Lyon, Ian Grunert, Owen Anderson, phillipov, makowski, and saethlin. (Did we miss your name and/or get it wrong? Drop a PR!)Some of the topics we hit on, in the order that we hit them: Elon Jet High Noon: The Inside Story of Scott McNealy and the Rise of Sun Microsystems by Southwick, Karen Making PCR: A Story of Biotechnology by Paul Rabinow Sun Labs vs. SunSoft Water Fight 1992 Cyberville: Clicks, Culture, and the Creation of an Online Town Hardcover by Stacy Horn Built to Fail: The Inside Story of Blockbuster's Inevitable Bust Kindle Edition by Alan Payne A History of Silicon Valley - Vol 1: The 20th Century Paperback by Piero Scaruffi H-E-B Moby Dick by Herman Melville (Arion Press) A Psalm for the Wild-Built by Becky Chambers Endurance: Shackleton's Incredible Voyage by Alfred Lansing Into the Raging Sea: Thirty-Three Mariners, One Megastorm, and the Sinking of El Faro If Then: How the Simulmatics Corporation Invented the Future Hardcover by Jill Lepore UNIVAC and the 1952 Presidential Election NPR: The Night A Computer Predicted The Next President Doom Guy: Life in First Person by John Romero From Secret Ballot to Democracy Sausage: How Australia Got Compulsory Voting by Judith Brett Bryan had a reading list for his wedding?! (his wife confirms) The Fatal Shore by Robert Hughes Harp in the South by Ruth Park Cloudstreet by Tim Winton Death of the Lucky Country by Donald Horne 30 Days in Sydney by Peter Carey Leviathan by John Birmingham The Fatal Shore: The Epic of Australia's Founding by Robert Hughes Barbarians Led by Bill Gates by Jennifer Edstrom and, Marlin Eller Murray Sargent's account of how his Scroll Screen Tracer got Windows to work in protected mode Startup: A Silicon Valley Adventure by Jerry Kaplan DeviceScript Washington: A Life by Chernow California Burning: The Fall of Pacific Gas and Electric--and What It Means for America's Power Grid Command and Control: Nuclear Weapons, the Damascus Accident, and the Illusion of Safety by Eric Schlosser The Color of Law: A Forgotten History of How Our Government Segregated America by Richard Rothstein Acts of the Apostles: Mind over Matter: Volume Blue by John F.X. Sundman Thunder Below!: The USS Barb Revolutionizes Submarine Warfare in World War II by Eugene B. Fluckey Thinking, Fast and Slow by Daniel Kahneman The Man Who Solved the Market: How Jim Simons Launched the Quant Revolution by Gregory Zuckerman The Predictors: How a Band of Maverick Physicists Used Chaos Theory to Trade Their Way to a Fortune on Wall Street by Thomas A. Bass The Eudaemonic Pie: The Bizarre True Story of How a Band of Physicists and Computer Wizards Took On Las Vegas by Thomas A Bass Some of the other books mentioned in the Discord channel: Herr aller Dinge/Lord of All Things by Andreas Eschbach Debt: The First 5,000 Years by David Graeber The Sciences of the Artificial by Herbert A. Simon California Burning: The Fall of Pacific Gas and Electric--and What It Means for America's Power Grid by Katherine Blunt The Man Who Solved the Market: How Jim Simons Launched the Quant Revolution Hardcover by Gregory Zuckerman The Predictors: How a Band of Maverick Physicists Used Chaos Theory to Trade Their Way to a Fortune on Wall Street by Thomas A. Bass The Eudaemonic Pie: The Bizarre True Story of How a Band of Physicists and Computer Wizards Took On Las Vegas by Thomas A Bass Models.Behaving.Badly.: Why Confusing Illusion with Reality Can Lead to Disaster, on Wall Street and in Life by Emanuel Derman It's a Nonlinear World by Richard H. Enns Not technically books, but suggested reading nonetheless by folks in Discord: The Night A Computer Predicted The Next President by Steve Henn, NPR How a brilliant debugger (Scroll Screen Tracer by Murray Sargent) turned Windows OS into the IBM OS/2 crusher and gave Microsoft its killer product. DeviceScript: TypeScript for Tiny IoT Devices Bob and Ray | Slow Talkers of America | Audio Recording (YouTube) Ursula K. Le Guin The Maintenance Race by Stewart Brand If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

On this week's show, Adam Leventhal posed questions from Hacker News (mostly) to Oxide founders Bryan Cantrill and Steve Tuck. Stick around until the end to hear about the hardest parts of building Oxide--great, surprising answers from both Bryan and Steve.They were also joined by Steve Klabnik.Questions for Steve and Bryan:[@6:38] Q:Congrats to the team, but after hearing about Oxide for literal years since the beginning of the company and repeatedly reading different iterations of their landing page, I still don't know what their product actually is. It's a hypervisor host? Maybe? So I can host VMs on it? And a network switch? So I can....switch stuff? (*)A:Steve: A rack-scale computer; "A product that allows the rest of the market that runs on-premises IT access to cloud computing."Bryan: agrees[@8:46] Q:It's like an on prem AWS for devs. I don't understand the use case but the hardware is cool. (*)I didn't understand the business opportunity of Oxide at all. Didn't make sense to me.However if they're aiming at the companies parachuting out of the cloud back to data centers and on prem then it makes a lot of sense.It's possible that the price comparison is not with comparable computing devices, but simply with the 9 cents per gigabyte egress fee from major clouds. (*)A:Bryan: "Elastic infrastructure is great and shouldn't be cloistered to the public cloud"; Good reasons to run on-prem: compliance, security, risk management, latency, economics; "Once you get to a certain size, it really makes sense to own"Steve: As more things move onto the internet, need for on-prem is going to grow; you should have the freedom to own[@13:31] Q:Somebody help me understand the business value. All the tech is cool but I don't get the business model, it seems deeply impractical. You buy your own servers instead of renting, which is what most people are doing now. They argue there's a case for this, but it seems like a shrinking market. Everything has gone cloud. Even if there are lots of people who want to leave the cloud, all their data is there. That's how they get you -- it costs nothing to bring data in and a lot to transfer it out. So high cost to switch. AWS and others provide tons of other services in their clouds, which if you depend on you'll have to build out on top of Oxide. So even higher cost to switch. Even though you bought your own servers, you still have to run everything inside VMs, which introduce the sort of issues you would hope to avoid by buying your own servers! Why is this? Because they're building everything on Illumos (Solaris) which is for all practical purposes is dead outside Oxide and delivering questionable value here. Based on blogs/twitter/mastodon they have put a lot of effort into perfecting these weird EE side quests, but they're not making real new hardware (no new CPU, no new fabric, etc). I am skeptical any customers will notice or care and would have not noticed had they used off the shelf hardware/power setups. So you have to be this ultra-bizarre customer, somebody who wants their own servers, but doesn't mind VMs, doesn't need to migrate out of the cloud but wants this instead of whatever hardware they manage themselves now, who will buy a rack at a time, who doesn't need any custom hardware, and is willing to put up with whatever off-the-beaten path difficulties are going to occur because of the custom stuff they've done that's AFAICT is very low value for the customer. Who is this? Even the poster child for needing on prem, the CIA is on AWS now.I don't get it, it just seems like a bunch of geeks playing with VC money?(*)A:Bryan: "EE side quests" rant; you can't build robust, elastic infrastructure on commodity hardware at scale; "The minimum viable product is really, really big"; Example: monitoring fan power draw, tweaking reference desgins doesn't cut it Example: eliminating redundant AC power suppliesSteve: "Feels like I'm dealing with my divorced parents" post[@32:24] Q (Chat):It would be nice to see what this thing is like before having to write a big checkSteve: We are striving to have lab infrastructure available for test drives[@32:56] Q (Chat):I want to know about shipping insurance, logistics, who does the install, ...Bryan: "Next week we'll be joined by the operations team" we want to have an indepth conversation about those topics[@34:40] Q:Seems like Oxide is aiming to be the Apple of the enterprise hardware (which isn't too surprising given the background of the people involved - Sun used to be something like that as were other fully-integrated providers, though granted that Sun didn't write Unix from scratch). Almost like coming to a full circle from the days where the hardware and the software was all done in an integrated fashion before Linux turned-up and started to run on your toaster. (*)A:Bryan: We find things to emulate in both Apple and Sun, e.g., integrated hard- and software; AS/400Steve: "It's not hardware and software together for integration sake", it's required to deliver what the customer wants; "You can't control that experience when you only do half the equation"[@42:38] Q:I truly and honestly hope you succeed. I know for certain that the market for on-prem will remain large for certain sectors for the forseeable future. However. The kind of customer who spends this type of money can be conservative. They already have to go with on an unknown vendor, and rely on unknown hardware. Then they end up with a hypervisor virtually no one else in the same market segment uses.Would you say that KVM or ESXi would be an easier or harder sell here?Innovation budget can be a useful concept. And I'm afraid it's being stretched a lot. (*)A:Bryan: We can deliver more value with our own hypervisor; we've had a lot of experience in that domain from Joyent. There are a lot of reasons that VMware et al. are not popular with their own customers; Intel vs. AMDSteve: "We think it's super important that we're very transparent with what we're building"[@56:05] Q:what is the interface I get when I turn this $$$ computer on? What is the zero to first value when I buy this hardware? (*)A:Steve: "You roll the rack in, you have to give it power, and you have give it networking [...] and you are then off on starting the software experience"; Large pool of infrastructure reosources for customers/devs/SREs/... in a day or less; Similar experience to public cloud providers[@01:02:06] Q:One of my concerns when buying a complete solution like an iPhone (or an Oxide rack

Erin Kissane joins Bryan and Adam to talk the new social network "Bluesky" through the lens of her blog post "Blue Skies Over Mastodon". Long-time friends of Oxide and social-media aficionados Time Bray and Steve Klabnik also helped shed light on technical and social aspects of the net network.Blue Skies Over Mastodon (with Erin Kissane and Tim Bray)We've been hosting a live show weekly on Mondays at 5p for about an hour, and recording them all; here is the recording from May 1st, 2023.In addition to Bryan Cantrill and Adam Leventhal, we were joined by special guest Erin Kissane and long-time acquaintances of the show Tim Bray and Steve Klabnik.Some of the topics we hit on, in the order that we hit them: Erin's blog post Blue Skies Over Mastodon Mastodon blog (5/1) A new onboarding experience on Mastodon] Tim's blog post from November Bye Twitter "Buy the rumor, sell the news" Hellthread "Skeet" is to "Tweet" is to "Toot" (aka "Publish") skyline.gay Bluesky blog Composable Moderation Lobsters Phanpy So you've been publically shamed by Jon Ronson If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

The Rust Foundation caused a fracas with their proposed new trademark rules. Bryan and Adam were lucky enough to be joined by Ashley Williams, Adam Jacob, and Steve Klabnik for an insightful discussion of open source governance and communities--in particular as applied to Rust.Rust Trademark: Argle-bargle or Foofaraw?We've been hosting a live show weekly on Mondays at 5p for about an hour, and recording them all; here is the recording from April 17th, 2023.In addition to Bryan Cantrill and Adam Leventhal, we were joined by Ashley Williams, Adam Jacob, and Steve Klabnik.Some of the topics we hit on, in the order that we hit them: Succession The Simpsons (explaining the title of this episode) The Wire The Wire at 20 Podcast The Register: Rust Foundation Apologizes for Trademark Policy Jomboy (our aspiration) Ice Weasel Pamela Chestek Bryan's talk from Node Summit 2017: Platform as a Reflection of Values Linux Foundation form 990 Rust Foundation Board Rust Foundation participation rules If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

This week we're joined by Steve Klabnik, an engineer at Oxide Computer Company. He was formally on the Rust Core team, co-author of the Rust book, and a lot of other things. We talk about how he got into Rust, why you might choose rust and how he uses Rust in his day to day.https://steveklabnik.com/https://twitter.com/steveklabnikJoin our patreon for the full episode https://www.patreon.com/devtoolsfm.TooltipsWant to hear use talk about our tooltips? Join our patreon! https://www.patreon.com/devtoolsfmAndrewhttps://sandpack.codesandbox.io/docs/advanced-usage/nodeboxhttps://www.clack.cc/JustinGet a labeler! (Here's mine)https://github.com/hyperfiddle/electricStevehttps://github.com/dtolnay/cargo-llvm-lines

Yael Grauer joined Bryan, Adam, Steve Klabnik, and the Oxide Friends to talk about her recent Consumer Reports article on memory safety and memory safe languages. How do we inform the general public? How do we persuade practitioners and companies? Thanks for joining us, Yael!In addition to Bryan Cantrill and Adam Leventhal, we were joined by special guest Yael Grauer, and Steve Klabnik.Some of the topics we hit on, in the order that we hit them (experiment in turning the show live-chat into notes): Nahum: https://www.backblaze.com/blog/the-3-2-1-backup-strategy/ if anyone wants to read up on the 3-2-1 Backup strategy.

Oxide and Friends: January 23rd, 2023Revisiting UnikernelsWe've been hosting a live show weekly on Mondays at 5p for about an hour, and recording them all; here is the recording from January 23rd, 2023.In addition to Bryan Cantrill and Adam Leventhal, speakers on January 23rd included Steve Klabnik, Dan Cross, and others.Some of the topics we hit on, in the order that we hit them:Bryan's 2016 blog post Unikernels are unfit for production If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!Give feedback

Richard talks with Steve Klabnik about his experiences being a major contributor to Ruby on Rails, and then to Rust, and now to a scratch-built operating system at Oxide.

Oxide and Friends Twitter Space: July 18th, 2022Across the Chasm with RustWe've been holding a Twitter Space weekly on Mondays at 5p for about an hour. Even though it's not (yet?) a feature of Twitter Spaces, we have been recording them all; here is the recording for our Twitter Space for July 18th, 2022.In addition to Bryan Cantrill and Adam Leventhal, our special guests were Steve Klabnik and Luqman Aden. Other speakers included Dan Cross, Tim McNamara, and others. (Did we miss your name and/or get it wrong? Drop a PR!)Some of the topics we hit on, in the order that we hit them: @0:27 let_chains are stable in Rust 1.64 Adam's tweet The stabilization PR, with the full saga leading up to stabilization As Steve mentions, the feature dates all the way back to 2017 and extends the Swift-inspired if let expressions Rust has had for a while Some Rust features, like async functions in traits, are huge rabbit holes Discussion about Rust's commitment to stability and how it's enforced with things like crater As an example of the process leading to burnout in programming language communities: Guido stepping down as BDFL after PEP 572 (Assignment Expressions, "the walrus operator") Discussion about Ruby also taking stability seriously: flip-flops weren't removed in Ruby 2.0 in part because of this pretty incredible snippet from Yusuke Endoh Quines and variations, Yusuke Endoh's Qlobe (reproduced here), their infamous quine-relay, and their other projects The G-Portugol programming language The unstable features mechanism in Rust ("first class support for experimental features") and how this allows for user experimentation Exclusive range patterns in Rust and some of their perils, specifically in tock Contrasting the Rust unstable feature mechanism with Haskell language pragmas: the former requires a nightly compiler to use, the latter does not @18:20 Discussion about the Rust process; going from RFC to stable Rust The Rust inline assembly feature (tracking issue) The Rust RFC repo The Generic Associated Types (GATs) Rust RFC hubris is on nightly Rust but with an allow list of features Naked functions in Rust (tracking issue), Destructuring assignments, #[cmse_nonsecure_entry] Talking about LWN-style reports and curation as a way to lessen the pain of using Zulip style chat platforms for discussion LWN is hiring, looking for someone to keep up with Rust development, among other things [[partial notes]]

Highlights from This Week in Rust - Issue 446, presented by Allen and Tim, with Nell Shamrell-Harrington, co-hosting for the first time in 2022. Contributing to Rustacean Station Rustacean Station is a community project; get in touch with us if you'd like to suggest an idea for an episode or offer your services as a host or audio editor! Twitter: @rustaceanfm Discord: Rustacean Station Github: @rustacean-station Email: hello@rustacean-station.org Timestamps & referenced resources [@00:00:00] Welcome [@00:00:10] - Introduction [@00:00:52] - Agenda [@00:01:27] - Interview with Nell Shamrell-Harrington about editing This Week in Rust [@00:06:21] Submitting an article to This week in Rust TWIR Github Repository github.com/rust-lang/this-week-in-rust TWIR Twitter account @thisweekinrust [@00:07:42] Call for volunteers to co-host an episode [@00:08:38] - Quote of the week I wrote a bespoke time-series database in Rust a few years ago, and it has had exactly one issue since I stood it up in production, and that was due to pessimistic filesystem access patterns, rather than the language. This thing is handling hundreds of thousands of inserts per second, and it's even threaded. Given that I've been programming professionally for over a decade in Python, Perl, Ruby, C, C++, Javascript, Java, and Rust, I'll pick Rust absolutely any time that I want something running that I won't get called at 3 AM to fix. It probably took me 5 times as long to write it as if I did it in Go or Python, but I guarantee it's saved me 10 times as much time I would have otherwise spent triaging, debugging, and running disaster recovery. “Configuring uWSGI for Production Deployment” (2019) by at Peter Sperl and Ben Green from Bloomberg uWSGI's max-requests and max-worker-lifetime options are intended to reduce the chance of memory leaks affecting production workloads [@00:14:47] - Crate of the week: osmpbf A Rust library for reading the OpenStreetMap PBF file format (*.osm.pbf). It strives to offer the best performance using parallelization and lazy-decoding with a simple interface while also exposing iterators for items of every level in a PBF file. OpenStreetMap Humanitarian OpenStreetMap Team (HOT OSM) [@00:16:40] Official Notices [@00:16:43] - Rust Compiler June 2022 Steering Cycle [@00:21:24] Highlights [@00:21:51] (async) Rust doesn't have to be hard Rust Is Hard, Or: The Misery of Mainstream Programming Stack Overflow Developer Survey: Most loved programming language [@00:28:28] clippy book [@00:29:40] Rolling co-lead roles for T-compiler [@00:36:33] Hyper vs Rocket - Low Level vs Batteries included Rust is surprisingly expressive (2013) by Steve Klabnik [@00:40:00] Macro Patterns - A match made in heaven by Conrad Ludgate [@00:41:11] Web Scraping with Rust by Gints Dreimanis Hyper with Sean McArthur [@00:44:09] Trivia About Rust Types: An (Authorized) Transcription of Jon Gjengset's Twitter Thread by Jimmy Hartzell [@00:46:01] Rust language's explosive popularity comes with challenges by Ed Targett “A proactive approach to more secure code” (2019) by Microsoft Security Response Center Project Zero team at Google [audio] Rust Foundation with Rebecca Rumbul Credits Intro Theme: Aerocity Audio Editing: Tim McNamara Hosting Infrastructure: Jon Gjengset Show Notes: Tim McNamara Hosts: Tim McNamara, Nell Shamrell-Harrington and Allen Wyma.

System76 reveals a new tool to make Pop's desktop faster than the rest, and we break down that recent Btrfs defrag infinite loop bug. Plus, a batch of essential project updates.

System76 reveals a new tool to make Pop's desktop faster than the rest, and we break down that recent Btrfs defrag infinite loop bug. Plus, a batch of essential project updates.

System76 reveals a new tool to make Pop's desktop faster than the rest, and we break down that recent Btrfs defrag infinite loop bug. Plus, a batch of essential project updates.

Oxide and Friends Twitter Space: December 13th, 2021The Pragmatism of HubrisWe've been holding a Twitter Space weekly on Mondays at 5p for about an hour. Even though it's not (yet?) a feature of Twitter Spaces, we have been recording them all; here is the recording for our Twitter Space for December 13th, 2021.In addition to Bryan Cantrill and Adam Leventhal, speakers on December 13th included special guests Cliff Biffle and Steve Klabnik as well as Laura Abbott, Rick Altherr, James Tucker, Simeon Miteff and MattSci. (Did we miss your name and/or get it wrong? Drop a PR!)Some of the topics we hit on, in the order that we hit them: Hubris and Humility context tweet Cliff's written version of his Hubris talk Hubris Fervently Anticipated Questions FAQ [@8:07](https://youtu.be/cypmufnPfLw?t=487) Prehistory of Hubris, Cliff's story Project Loon wiki [@14:23](https://youtu.be/cypmufnPfLw?t=863) Did Cliff know what he wanted to build at Oxide? Tock embedded OS QNX Unix-like real-time OS [@17:55](https://youtu.be/cypmufnPfLw?t=1075) Laura on evaluating existing OS options [@22:03](https://youtu.be/cypmufnPfLw?t=1323) Alignment of values and goals with other projects Bryan's 2017 Platform as a Reflection of Values video ~30mins [@25:00](https://youtu.be/cypmufnPfLw?t=1500) Steve: convincing low-level people that they are allowed to have nice things RISC-V ROPI/RWPI Specification (Embedded PIC)Position-independent code wiki [@28:59](https://youtu.be/cypmufnPfLw?t=1739) Secure FPGAs? Laura Abbott's Exploiting Undocumented Hardware Blocks in the LPC55S69 write-upAnd DEF CON talk with Rick Altherr [@32:20](https://youtu.be/cypmufnPfLw?t=1940) Early implementation, journal club Jonathan Shapiro 2003 Vulnerabilities in synchronous IPC designs paper Heiser and Elphinstone's L4 Microkernels: The Lessons from 20 Years of Research and Deployment paper [@37:20](https://youtu.be/cypmufnPfLw?t=2240) Microkernels. Mach L4 microkernel family wiki Jochen Liedtke Bryan decides not to go to graduate school Fuchsia OS [@51:09](https://youtu.be/cypmufnPfLw?t=3069) Origin of Humility. Debugging  Tockilator Semihosting [@1:03:15](https://youtu.be/cypmufnPfLw?t=3795) Archive files, self-descriptive binaries, debugging [@1:10:33](https://youtu.be/cypmufnPfLw?t=4233) CORRECTION Windows does have a package manager: Windows Package Manager was released May 13, 2020 [@1:14:15](https://youtu.be/cypmufnPfLw?t=4455) Build tools and build systems cargo xtask [@1:18:59](https://youtu.be/cypmufnPfLw?t=4739) DWARF  Ada language [@1:25:01](https://youtu.be/cypmufnPfLw?t=5101) Tock: Rust kernel, C userspace  IDL Ozymandias [@1:32:28](https://youtu.be/cypmufnPfLw?t=5548) build.rs build scripts  Simeon's story, code generation Software-hardware codesign [@1:52:14](https://youtu.be/cypmufnPfLw?t=6734) Conway's law [@1:54:30](https://youtu.be/cypmufnPfLw?t=6870) Diagnosing problems, failing tasks, formatting error messages Joe Rozner and Rick Altherr getting Hubris and Humility running on a STM32, tweet from Dec 1, and video ~2hrs If we got something wrong or missed something, please file a PR! Our next Twitter space will likely be on Monday at 5p Pacific Time; stay tuned to our Twitter feeds for details. We'd love to have you join us, as we always love to hear from new speakers!

In this episode - aptly named "The return of the Rust" our two heroes host a very special guest: no other than Steve Klabnik of Rust fame himself. Needless to say, this hipster programming language which is on everbody's mind at the moment (apart maybe from a few lost souls still crying over spilled coffee) plays a very important role in this show in addition to the newly founded Rust Foundation hosting such eclectic members such as Microsoft, Mozilla, Google and Facebook just to name a few looking after the language. Links: Rust: https://www.rust-lang.org Rust Foundation: https://foundation.rust-lang.org Steve Klabnik: https://steveklabnik.com Ruby on Rails: https://rubyonrails.org PyOxidizer: https://github.com/indygreg/PyOxidizer Mercurial: https://www.mercurial-scm.org actix controversy: https://github.com/actix/actix-web/issues/289 OpenSearch: https://aws.amazon.com/blogs/opensource/introducing-opensearch

The major shift in the Linux landscape this week that was hardly noticed, and our thoughts on COSMIC from System76. Plus Google adds its weight behind Rust in the Linux Kernel, and the new security features landing in WSL2.

The major shift in the Linux landscape this week that was hardly noticed, and our thoughts on COSMIC from System76. Plus Google adds its weight behind Rust in the Linux Kernel, and the new security features landing in WSL2.

The major shift in the Linux landscape this week that was hardly noticed, and our thoughts on COSMIC from System76. Plus Google adds its weight behind Rust in the Linux Kernel, and the new security features landing in WSL2.

Steve Klabnik joins Doc Searls and Shawn Powers to talk about Rust. Rust, which was started at Mozilla, has grown to become one of the world's most relied-upon and fastest growing programming languages. Klabnik literally wrote the book on Rust. In the show, he visits how it differs from C++ and other alternatives, some of the many ways it is used, the large and familiar names (e.g. DropBox) that depend on it, the community culture around it, how open source and free software work are changing as we move toward a post-COVID world. Hosts: Doc Searls and Shawn Powers Guest: Steve Klabnik Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Sponsor: Melissa.com/twit

Steve Klabnik joins Doc Searls and Shawn Powers to talk about Rust. Rust, which was started at Mozilla, has grown to become one of the world's most relied-upon and fastest growing programming languages. Klabnik literally wrote the book on Rust. In the show, he visits how it differs from C++ and other alternatives, some of the many ways it is used, the large and familiar names (e.g. DropBox) that depend on it, the community culture around it, how open source and free software work are changing as we move toward a post-COVID world. Hosts: Doc Searls and Shawn Powers Guest: Steve Klabnik Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Sponsor: Melissa.com/twit

Steve Klabnik joins Doc Searls and Shawn Powers to talk about Rust. Rust, which was started at Mozilla, has grown to become one of the world's most relied-upon and fastest growing programming languages. Klabnik literally wrote the book on Rust. In the show, he visits how it differs from C++ and other alternatives, some of the many ways it is used, the large and familiar names (e.g. DropBox) that depend on it, the community culture around it, how open source and free software work are changing as we move toward a post-COVID world. Hosts: Doc Searls and Shawn Powers Guest: Steve Klabnik Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Sponsor: Melissa.com/twit

Steve Klabnik joins Doc Searls and Shawn Powers to talk about Rust. Rust, which was started at Mozilla, has grown to become one of the world's most relied-upon and fastest growing programming languages. Klabnik literally wrote the book on Rust. In the show, he visits how it differs from C++ and other alternatives, some of the many ways it is used, the large and familiar names (e.g. DropBox) that depend on it, the community culture around it, how open source and free software work are changing as we move toward a post-COVID world. Hosts: Doc Searls and Shawn Powers Guest: Steve Klabnik Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Sponsor: Melissa.com/twit

Steve Klabnik joins Doc Searls and Shawn Powers to talk about Rust. Rust, which was started at Mozilla, has grown to become one of the world's most relied-upon and fastest growing programming languages. Klabnik literally wrote the book on Rust. In the show, he visits how it differs from C++ and other alternatives, some of the many ways it is used, the large and familiar names (e.g. DropBox) that depend on it, the community culture around it, how open source and free software work are changing as we move toward a post-COVID world. Hosts: Doc Searls and Shawn Powers Guest: Steve Klabnik Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Sponsor: Melissa.com/twit

Steve Klabnik of Rust joins Doc Searls and Shawn Powers on FLOSS Weekly. Powers asks Klabnik to discuss and compare the Rust programming language to the popular C++ language. Why choose to use Rust over C++? For more, check out FLOSS Weekly: http://twit.tv/floss/618 Hosts: Shawn Powers and Doc Searls Guest: Steve Klabnik You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

Steve Klabnik of Rust joins Doc Searls and Shawn Powers on FLOSS Weekly. Powers asks Klabnik to discuss and compare the Rust programming language to the popular C++ language. Why choose to use Rust over C++? For more, check out FLOSS Weekly: http://twit.tv/floss/618 Hosts: Shawn Powers and Doc Searls Guest: Steve Klabnik You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

Steve Klabnik joins Doc Searls and Shawn Powers to talk about Rust. Rust, which was started at Mozilla, has grown to become one of the world's most relied-upon and fastest growing programming languages. Klabnik literally wrote the book on Rust. In the show, he visits how it differs from C++ and other alternatives, some of the many ways it is used, the large and familiar names (e.g. DropBox) that depend on it, the community culture around it, how open source and free software work are changing as we move toward a post-COVID world. Hosts: Doc Searls and Shawn Powers Guest: Steve Klabnik Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Sponsor: Melissa.com/twit

Steve Klabnik joins Doc Searls and Shawn Powers to talk about Rust. Rust, which was started at Mozilla, has grown to become one of the world's most relied-upon and fastest growing programming languages. Klabnik literally wrote the book on Rust. In the show, he visits how it differs from C++ and other alternatives, some of the many ways it is used, the large and familiar names (e.g. DropBox) that depend on it, the community culture around it, how open source and free software work are changing as we move toward a post-COVID world. Hosts: Doc Searls and Shawn Powers Guest: Steve Klabnik Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Sponsor: Melissa.com/twit

Steve Klabnik joins Doc Searls and Shawn Powers to talk about Rust. Rust, which was started at Mozilla, has grown to become one of the world's most relied-upon and fastest growing programming languages. Klabnik literally wrote the book on Rust. In the show, he visits how it differs from C++ and other alternatives, some of the many ways it is used, the large and familiar names (e.g. DropBox) that depend on it, the community culture around it, how open source and free software work are changing as we move toward a post-COVID world. Hosts: Doc Searls and Shawn Powers Guest: Steve Klabnik Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Sponsor: Melissa.com/twit

Steve Klabnik of Rust joins Doc Searls and Shawn Powers on FLOSS Weekly. Powers asks Klabnik to discuss and compare the Rust programming language to the popular C++ language. Why choose to use Rust over C++? For more, check out FLOSS Weekly: http://twit.tv/floss/618 Hosts: Shawn Powers and Doc Searls Guest: Steve Klabnik You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

Steve Klabnik of Rust joins Doc Searls and Shawn Powers on FLOSS Weekly. Powers asks Klabnik to discuss and compare the Rust programming language to the popular C++ language. Why choose to use Rust over C++? For more, check out FLOSS Weekly: http://twit.tv/floss/618 Hosts: Shawn Powers and Doc Searls Guest: Steve Klabnik You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

In this episode, we talk about Atlassian’s remote work policy, Fortnite’s battle with Google and Apple, and Twitter’s new API. We then speak with Ashley Williams and Steve Klabnik, engineers on the Rust core team, about how recent restructuring and layoffs at Mozilla impact the future of the Rust programming language. Show Notes DevDiscuss (sponsor) Triplebyte (sponsor) CodeNewbie (sponsor) Vonage (sponsor) Atlassian Fortnite Fortnite Introducing a new and improved Twitter API Rust Laying the foundation for Rust's future RustConf

Tobi is a developer, leader, benchmarker, Rubyist, Elixir fan, learner, teacher and agile crafter by passion. He loves collaboratively creating just about anything people enjoy - be it the Ruby User Group Berlin, SimpleCov, benchee, or other projects while thinking about new ideas to push boundaries. Currently he's helping companies onboard onto Elixir and creating wonderful web applications in his journey as a freelancer. Show Notes Ruby User Group Berlin (https://www.rug-b.de/) rubycorns (http://rubycorns.club/) SimpleCov (https://github.com/colszowka/simplecov) benchee (https://github.com/bencheeorg/benchee) shopify (https://www.shopify.com/) pivorak (https://pivorak.com/) Aaron Cruz (https://www.parallelpassion.com/13) Shoes 4 (https://github.com/shoes/shoes4) why the lucky stiff (https://en.wikipedia.org/wiki/Why_the_lucky_stiff) wroclove.rb (https://wrocloverb.com/) Arne Brasseur (http://devblog.arnebrasseur.net/) Steve Klabnik (https://steveklabnik.com/) AlphaGo (https://en.wikipedia.org/wiki/AlphaGo) 2 hard problems tweet (https://twitter.com/minsuk_chang/status/1277502761697861632) Theory X and Theory Y (https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y) Piotr Szotkowski (https://www.parallelpassion.com/14) code curious (https://www.codecurious.org/) Ruby Monstas (http://rubymonstas.org/) metasploit (https://www.metasploit.com/) The Agile Samurai (https://www.amazon.com/o/ASIN/1934356581/parpaspod-20) Rework (https://www.amazon.com/o/ASIN/0307463745/parpaspod-20) A Guide to the Good Life (https://www.amazon.com/o/ASIN/0195374614/parpaspod-20) Tao Teh King (https://www.amazon.com/o/ASIN/087573040X/parpaspod-20) The Art Of War (https://www.amazon.com/o/ASIN/1599869772/parpaspod-20) The Manual: A Philosopher's Guide to Life (https://www.amazon.com/o/ASIN/1545461112/parpaspod-20) RSA Animate: Drive (https://www.youtube.com/watch?v=u6XAPnuFjJc) Punished by Rewards (https://www.amazon.com/o/ASIN/0618001816/parpaspod-20) Recommendations Sophie's World (https://www.amazon.com/o/ASIN/0374530718/parpaspod-20) All Quiet on the Western Front: A Novel (https://www.amazon.com/o/ASIN/0449213943/parpaspod-20) Drive: The Surprising Truth About What Motivates Us (https://www.amazon.com/o/ASIN/1594484805/parpaspod-20) Tobias Pfeiffer Twitter (https://twitter.com/PragTob) Personal Page (https://www.pragtob.info/) Parallel Passion Patreon (https://www.patreon.com/parpaspod) Twitter (https://www.twitter.com/parpaspod) Instagram (https://www.instagram.com/parpaspod) Facebook (https://www.facebook.com/parpaspod) Credits Headway (https://unsplash.com/@headwayio) for the header photo Tina Tavčar (https://twitter.com/tinatavcar) for Parallel Passion logo Jan Jenko (https://twitter.com/JanJenko) for intro/outro music

Steve Klabnik is an accomplished open source maintainer having worked on a huge number of projects. He is most well known for his work on Ruby, Rails, and Rust. During our interview, we talk about Steve's journey as a developer and the how open source has shaped his career. Steve's internet home: https://twitter.com/steveklabnik

Carol Goulding: @Carols10cents | GitHub | Blog | Integer 32 Show Notes: 00:58 - Going Into Business Using Rust 03:42 - Getting Paid to do Open Source 05:31 - Prototyping Projects in Rust 06:21 - Why Rust? (Benefits) 09:58 - The Language Server 14:52 - Error Messages 19:46 - The Rust Programming Language Book 23:35 - Crates.io 27:41 - The Backend 31:11 - Working with Rust and Ember Together 33:31 - Rust Belt Rust Conference 35:59 - Integer 32 Resources: The Rust Programming Language Book The Frontside Podcast Episode 51: Rust and APIs with Steve Klabnik Rust For Rubyists Working Effectively with Legacy Code by Michael Feathers Clippy Cargo rustlings Python Koans Rust - exercism.io No Starch Tokio Diesel Rocket Nickel Iron Pencil Rust Belt Rust Conference RustFest.EU RustConf Transcript: STEPHANIE: Hello, everybody. Welcome to The Frontside Podcast. This is Stephanie Riera. I am a developer here at The Frontside and with us, we have some very special guests. We have Chris Freeman who is a former Frontsider. He is a developer at a startup here in town in Austin called OJO. I'm going to let Chris introduce Carol Nichols. CHRIS: Hi, everyone. Today we've get Carol Nichols. She is involved in a lot of different things related to the Rust programming language. She is on the Rust community team. She is the co-author of the Rust book. She's the co-founder of a Rust consulting company called Integer 32 and she's the maintainer of Crates.io. How are you doing today, Carol? CAROL: I'm great. Thank you for having me on the show. CHRIS: Thanks for joining us. I have a lot of questions for you. I'm very interested in Rust but I am especially interested in some of the stuff you're doing that's kind of ancillary to it, namely you decided to go into business using a pretty new programming language that in some ways, I think is a little bit niche-related to some other things that people might go into business for say, web development. I was hoping maybe you could talk about what is Integer 32? What led you to starting this business? What kind of consulting work do you find working in something like Rust? CAROL: Integer 32 is my husband and I, Jake Goulding and we decided to form this company because we really wanted to get paid to work on Rust. We think Rust is really interesting and that is moving the industry forward and we see a future in Rust. As far as we can tell, we are the first Rust-focus consultancy in the world, which either makes us trendsetters or really stupid. I'm not sure about that yet but we're figuring it out. We consider ourselves pretty qualified to be running a Rust consultancy. As you mentioned, I'm the co-author on the book. I've been working with Rust for a couple of years now. Jake has the most points on Stack Overflow in the Rust tag. We've got a lot of experience in getting to know Rust. We've been watching the development, helping people learn Rust so we are offering a bunch of different services. One is to build an MVP or a prototype for Rust so that companies can evaluate whether Rust would be a good fit for their problem, without diverting their whole team to be able to learn Rust enough to evaluate it properly. We've done some prototypes. We're also interested in doing training and pairing so we have some training, things in the works. We've also gotten some jobs that are adding to open source libraries in Rust. The ecosystem is still being built up and there's a lot of libraries that do whatever the person who wrote them need them to do but they're not feature complete so if someone else just needs that extra feature on some library, they can pay us to add it if they'd like. One of the things I really want to do with my consultancy is have our proprietary work subsidize our open source work because I really wanted to get paid for open source stuff. We have a different rate that we charge for a proprietary versus open source. We've had a few gigs that are adding stuff to open source libraries and I love those because we're not only benefiting the company who needs something but we're benefiting the entire community. CHRIS: When you say you work on an open source thing, do you mean like a company that happens to be a consumer of an open source library would pay you to add a feature? Or is it the maintainers of the libraries themselves are coming to you and hiring help? CAROL: So far, it has been the former but we have talked to some people about the latter but open source projects typically don't have much funding. I think that's a little rarer but definitely, were open to companies paying us to add what they need to a library. CHRIS: Has there been any friction there like you kind of showing up and say a company is paying us to try and add features to your project? Do the maintainers ever pushback or are they very happy to just have someone helping? CAROL: Yes, so far no. All the maintainers we worked with have been amazing. We're not going to come in and rewrite the whole project. We're going to come in and work with their style and make any modifications they want to be able to incorporate into their library. But as I said, a lot of libraries are gotten to a certain point and I think the maintainers would like their libraries to become more feature complete but everyone only has so much time and you don't necessarily know what's useful to people but this is a very, very strong signal that this library would be useful to someone if only it had this little extra thing. I think most maintainers are open to making their libraries more feature complete to be more useful to more people. CHRIS: Yeah, that is a pretty sweet deal from the standpoint of an open source maintainer. It's nice enough when people show up to help at all. It is especially nice to show up to help and aren't motivated by money. CAROL: Yeah. CHRIS: That's very cool. When it comes to prototyping things with Integer 32, what kind of projects are people coming to you and asking you to prototype in Rust? CAROL: A lot of them are existing projects that they have and written in something else that they want to either perform better and be safer as opposed to rewriting it in C or C++ to get performance out of it. Sometimes, they want something to interface with other Rust things. We're starting to see projects like that but mostly, they have a hunch that Rust will be good for their projects and solve some problem they're having with their current implementation. We scope their projects way down to whatever will let them evaluate, whether Rust is a good fit or not and we go with that. CHRIS: Cool. STEPHANIE: Going from there, the question that I have is why Rust? I don't know a lot about Rust so I'd like to know what would be some of the benefits of using Rust, if you're familiar with programming. If you are in web development like I'm familiar with Ember, why would I like to use Rust or learn Rust? CAROL: I could talk all day about this. I really love working with Rust. I feel like it is adding more tools to help me to write better code and taking care of little details that usually I would have to spend a lot of brainpower thinking about to get right all the time. But now I can actually concentrate on whatever it is I'm trying to get done and let the compiler take care of those details for me. The way it's implemented, it happens really fast. The way I got into Rust was I'm a Rails developer previously to this job and I spend a lot of time optimizing Rails, looking for places where essentially too many Ruby objects and memory leaks and [inaudible] a lot of trying to make Rails go faster. At some point, you can't. There's only so far you can take Ruby and Rails so I look at where I want my career to go next and I love making things go faster but I'm terrified of C. I should be nowhere near production C. You have to spend years learning all the quirks and all the ways that C can go wrong and crash and be insecure. Around this time, I know you had Steve Klabnik on the show, in the previous episode. Steve is from Pittsburgh, where I am and he came home for Christmas one year and came to a Ruby meet up and was talking about this new language called Rust and how awesome it was. Steve gets distracted by new awesome things all the time so I was like, "Yeah, yeah, okay, whatever." The next year, he came home for Christmas again and was still talking about how awesome Rust was. At that point, I was like, "There's got to be something to this." At that point, he was writing his book, 'Rust for Rubyist' which has lead into his work on the Rust programming language book. I was like, "Rust for Rubyist? I can handle this. This is something I can do and capable of," so I started reading his book and submitting corrections and things which is again, how I got involved with the Rust programming language book. If you've ever gotten the error 'undefined method on nil' or 'undefined is not a function' in JavaScripts, like in production at runtime that happens all the time. That's just normal in Ruby and JavaScript land. Rust prevents those problems at compile time so there's no null, there's no nil. It's strongly typed so it checks that you have the thing you think you have before your code even can run. There's no garbage collector so you don't have memory leaks. The system of ownership and borrowing and the borrow checker and lifetimes which is weird. It's tricky to get your head around at first because it's different than any other language. But once you get that that's the part that enables your code to go faster without needing the garbage collector. You actually don't have to think about your memory management as much as you would in C, where you have to say, "Please give me some memory." Okay, I'm done with it now. You are manually managing your memory but you don't have to think about it as much because the compiler is thinking about it for you, if that makes sense. CHRIS: I have a follow up question, kind of related to the fact that Rust is kind of performing at the level of C or C++ but a lot more friendly in the fact that both you and Steve and I think a lot of other people, have come to Rust from scripting languages, from higher level languages. I remember at first that I started paying attention on Rust like right before the 1.0 happened, I thought it sounded interesting and wrote it off because it was just insane and I had only ever done Python and JavaScript and higher level things. In a relatively short time, it has developed a level of ergonomics that I'm envious of, even in the 'more comfortable' languages, things like Cargo, things like the compiler is really great but now the compiler has really friendly and informative error messages so that 'undefined is not a function' never happens but when you try to make it happen, it now shows you like, "No, no, no. On this exact line, in this place, this is where you're doing it wrong." But I recently heard it and I'm curious if you know anything about it that there's also development on a Rust language service, kind of like I guess TypeScript test, where it's a whole set of tools that you can run under the hood that any editor can plug into so that you just get this tool box of things to help you develop in Rust that are all packaged up and handed over and all you have to do is hook into it. Have you try that at all? Are you familiar with that? CAROL: I am not. I've been watching but I haven't worked on it and I haven't tried it out yet. I am excited for the language server because it's going to enable IDEs to do more interesting things. Coming from Ruby where it's so dynamic that you can't do things like ensure that you renamed all of the places and method it's called because you can't know that. I've read books like Michel Feathers' Working Effectively with Legacy Code and a lot of the chapters in that talked about leaning on your IDE, on your refactoring tools to do automated refactoring. RubyMine has a few of those things but not all of them because it's just impossible so I'm really looking forward to having real refactoring tools that can let you do automated refactorings and things like that that are possible in other statically-typed languages but with Rust in an IDE. I haven't used an IDE in years because I haven't found them to be useful but once the language server is up and running, I'm thinking about going back to an IDE so it's definitely exciting. CHRIS: That's some pretty cool right now. There's one called Clippy which I love because of the name like it takes you back to my Microsoft Word days. There's a lot of very good stuff that they have added that I didn't expect from a 'systems language' but it has definitely benefited from a lot of things that people in the scripting world have learned. CAROL: One of the goals of 2017 for the core team is increasing people's productivity in Rust so getting people over the learning curve, providing them with tools like the language server and making it easier for people to build things in Rust without having to manage things around Rust. Just Cargo in itself has made systems programming so much better. I see people who develop in C and C++ who really try to minimize the amount of libraries they bring in because that makes your build system so much more complicated and you have to have libraries in the right place and so much more can go wrong. But with Cargo, it's just Cargo install and you have a Cargo.lock and cargo.toml that manages versions. It just work so it's been interesting watching people figure that out and change their opinions on bringing in dependencies with npm and JavaScript and Bower and Ruby Gems that we're all used to like, "Oh, there's a gem for that. Let's just pull that in and go." Systems people have been really reluctant to do that but Cargo is enabling that to be better and easier which is really exciting to watch. I want anyone listening to this who thinks, "I can't do system programming. It was too hard." No, you totally can. You can do Rust. Rust is going to let you do this and that's why Rust is really exciting because it's enabling a whole new group of people to get into the systems programming space where things need to be optimized and faster and letting people build these sorts of things without having the programs be vulnerable to crashes and security bugs and things like that. It's really, really exciting. CHRIS: Very cool. STEPHANIE: I'm curious in Rust, if there's an error, how would you know that there's an error? Is the whole thing going to stop? Is it going to break? Do you get a useful stack trace? What would I expect to see? CAROL: A lot of the errors in Rust are at compile time. It won't even let you try to run your code if you have certain kinds of problems and they tried to move as much as possible into that compile time space. There are always going to be things that you can't catch a compile time like the user enters a number that's too big for whatever you're trying to do. That's still going to be a runtime error because we can't possibly know what a user is going to put in when you're compiling. They've done a lot of work on the compiler errors as Chris was talking about, to make them friendlier and point here's where your error is, here's why it's happening, here's a hint as to how you might want to fix it. This has been really great. I was volunteering in a local code school with students just starting Ruby and I'm used to Ruby's error messages by now but they were just getting started and getting all sorts of errors and I was like, "Wow, these error messages are not helpful at all," and I forgot how bad that is and how confusing it can be for a beginner to just think you understand, think you have got it working and then you go and run the code and it's just like 'string is not a symbol' or whatever. The worst is when you forget to close the block and just expected to see [inaudible] end of file instead and it's not helpful at all. I was just like apologizing the whole time like, "I'm sorry. This is telling you that you need to write 'end' at the end of the file," but it's not telling you that in any way you could possibly know that. That made me appreciate much more all of the work that's going into Rust error messages that are really trying to help. Some people talk about, especially the borrow checker, fighting the borrow checker like they're not used to having a compiler tell them their code is wrong so often so people talk about fighting the borrow checker a lot but it's not trying to fight with you. It's not trying to make you feel bad about your code. It's trying to help you make your code better and prevent errors that might happen at runtime by catching them earlier. I actually have a little project called Rustlings that is full of little snippets of Rust that intentionally don't compile. You run them and you get an error message right away and your job is to read the error message and learn how to fix it. When I was starting out, I was really frustrated because I was trying to do something and I would get an error message and I would have to stop whatever is doing to deal with the error message. I was like, "If I could just get some practice just dealing with the error messages and learning how to fix them so that when I'm trying to do something else, I already have experience fixing that kind of error," so that's how that project came to be and people found that useful. I haven't had much time to work on it lately but it could definitely use more examples because I think people are used to error messages that are not helping. People used to back traces that are really long and don't say anything useful. Sometimes, you don't stop and read and think but the Rust error messages are really trying to help you and often times, they are telling you exactly what you need to do to change the code to work. I think getting practice seeing the compiler as more of a pair who is trying to help you and not someone who's trying to reject all your code is a different mindset that I don't think people are used to but I think it's really useful. STEPHANIE: That's excellent. I was going to ask you if there are any resources or any repos to check out for someone who is interested in getting into Rust. It's funny, last night I was poking around with Python and there's something similar to Rustlings. It's called Python Koans and it's basically like what you're already familiar if you do web development. You want to get your test to pass so it'll tell you, you need to think about this one or you need to meditate on this and then you try to get it to pass and then it says you have reached enlightenment or you have not yet reached enlightenment and you have to sit there and think about it and then run it again. It's very useful in trying to get started with language in a way that you are already sort of familiar with. CAROL: Yeah, I've definitely gotten inspiration from the Koans project that have existed in other languages. There's also an exercism track for Rust that people found really useful and of course, I'm working with Steve Klabnik on the Rust programming language book. We're rewriting the whole thing so there's an existing version that if you go to the Rust documentation and click on book, you'll get the existing version which is complete but the new version is going to be way better. Especially with the explanations of ownership and borrowing, people have said that the new version is way, way better than the old version. Someone even made the analogy of doing medical research and you see that trial case is doing so much better than the placebo case that is not ethical to continue the trial. It's more ethical to stop the trial and use the new thing because it's helping so many people. Someone was like, "You need to replace the old book with the new book right now because it's so much better," but the new book isn't complete yet. The new book is in a different repo which we can put in the show notes so I'd recommend starting with the new book and then working back and forth with the old book once you run out of content. But we're getting closer all the time so hopefully, that should be done and printed by No Starch sometime in 2017 -- CHRIS: Woah! It's being printed by No Starch? CAROL: Yeah. CHRIS: That's cool. I didn't know that. Congratulations. CAROL: I thought Steve mentioned that in the last one. CHRIS: He may have but he talked about it a long time ago and I thought he always meant the old one. How long have you been rewriting the Rust book for? CAROL: It's been a while. CHRIS: Longer than I knew about then, probably. CAROL: It's kind of like software. It's more work than you think it's going to be and estimating, it's going to be done when it's done. If you kept telling people, "It's going to be out on this time," and like Steve, "There's no way it's not getting done by then," so now he's not allowed to say it when it's going to be out. CHRIS: Nice. CAROL: I'm really grateful to see this opportunity because I don't think I would have written a book on my own and I'm learning a whole lot about the process of writing a book. It turns out there's a lot of editing, a lot of back and forth, a lot of trying to build a narrative through this long stretch of text so that you're building on top of what you've already covered and not introducing things that aren't mentioned. It's a lot of work and I'm learning a lot and I have no idea when it's going to be [inaudible] because I think there's more work that I still don't know about coming, as we get closer to going to print. It's definitely one of those things that you can't make agile because you've got to put it on paper that costs money and it's going to be around a long time at some point. It's definitely a different kind of working that I'm used to with software. CHRIS: Although, I have to say, I clicked around and I think this is the new version: Rustlings.Github.io/Book. Is that the new one? CAROL: Yes, that's the new version. CHRIS: There is a lot here and it's not quite what I would have expected to see here like it's not done yet. I've been clicking links and I have yet to find one that says 'to-do'. CAROL: I think 15 through 20 are like outlines right now. We're maybe three-quarters through with the content but then we have to go through revisions and editing and copyediting. CHRIS: I'm looking at the headings and I was a big fan of the first Rust book but I can already see it calling out things I wish had been hit on more specifically in the original book. There's a lot of good looking stuff here so I'm excited about this. I'm going to go and read this thing. CAROL: I'm excited for people to read it. CHRIS: Earlier, you were talking about one of the things that is really nice about the Rust tooling is that Cargo makes it really easy to bring in dependencies. I happen to know that you are recently, I believe the maintainer of Crates.io which is where all of Cargoes crates, which are the libraries are hosted. Is that correct? CAROL: That is correct. I have commitment Crates.io now which is very exciting. Crates.io is like Ruby Gems or npm. It's the site where people publish their libraries and you can go and search for a library for what you need. As part of the Rust 2017 goals, we want to make it easier for people to find high-quality libraries that do the things they needed to do. I've been doing some work on adding badges and categories. Rust makes major decisions on the language and on things through an RFC process, which I think Ember is doing now too. I forget which way we stole that. Do we steal it from Ember or did you steal from us? I can't remember. CHRIS: If I remember right, I think -- I could be wrong, Twitter -- Ember did it first. Rust borrowed it and then added the 'how do we teach this?' section. I think Ember took that back and added it to their RFCs. CAROL: Okay, I'm super excited about that section. Now, when you propose a change of language, you have to go through this RFC process where you write up what you want to change, why you want to change it, any downsides, any alternative designs. Then the community talks about it and makes comments when you revise it and things like that. Now, there's a new section that just got added. That's 'how do we teach this?' Before something can be stabilized in the language, you have to document it. This is still kind of starting to take effect but I'm super excited about it because people can't use something unless they know how to use it. Right now, Steve's the only person getting paid full time to work on the documentation and I need him to write the book so I'm excited that more people will be thinking about documentation and thinking about how to help people use their new features. Anyway, I have an RFC about how to rank Crates within a category that we're trying to work through. In some automated ways, we can recommend different Crates for different purposes. I'm working through that with the community to try and figure out how to best recommend Crates in different circumstances. Crates.io is written in Rust and it performs really well. It just got added to the Heroku things so you can deploy it too. Looking at the analytics and their response times for is just like the Ruby apps I work on would be thrilled to have these stats. The backend of it is Rust, the frontend is Ember and [inaudible] who was an Ember person is also interested in Rust and he thinks Rust on the backend and Ember on the frontend worked really well together. He's always trying to figure out ways that we can work together. Crates.io is an existing project that I'm still learning Ember. There's lots of words I don't really understand about like components and Bowers. I would love Ember help on Crates.io. I'm starting to pull out issues that would be good at first time issues or more Ember-focus or I have some idea of how to fix that I could help someone fix. I'm starting to tag those things with 'has mentor' in our labels so I love for people to come check out issues on Crates.io who know JavaScript and know Ember and might want to get into Rust because there are definitely some issues that need a little bit of frontend, a little bit of backend so it might be a good way for people to get into Rust. CHRIS: Very cool. I'm personally very interested in that and will likely hit you up. But I'm sure many of our listeners will as well because I think we have a lot of Ember-friendly listeners so look Carol up because it sounds like she could use some help. Actually, I'm curious, the backend, I know that pretty recently, Rust has kind of gone through this period of kind of explosion in terms of Rust as a web language. There have been a number of different things that have come out pretty recently for a web framework in Rust or there's that Tokio thing. I know Diesel is like the ORM for Rust in talking to databases. It looks like it's about to hit 1.0. There's a lot of stuff happening so I'm curious, what are you using to write the backend. I know you're using Rust but are you using one of these frameworks or have you rolled your own? How's that work right now? CAROL: Crates.io is one of the first web apps that has been written in Rust. Actually, if you look at the backend code, you'll see SQL being built by hand. It's going to the Rust postgres library so it has SQL injection protection. All the things are [inaudible] so don't worry about that but they're still like SQL with the Rust code so it's not using an ORM yet. I'm going to have to look up. There is a library that is using that I'm blanking on the name of it for but it's very low level. It just let you send HTTP requests and let you respond to HTTP. We're in kind of a Cambrian explosion period with Rust web frameworks. There's a lot of different ones. One that I'm excited about that I haven't gotten to tryout yet is Rocket. That was just released. The thing I love about Rocket is that everyone's really excited about it because it was announced and they have an awesome website with lots of awesome docs so that should be a lesson to any open source project that's launching is if you want to get excited about it, you've got to launch some docs. That will help so much. There's a lot of different frameworks happening. They're still little trilobites and little animals that can't walk on land on their own quite yet so there's still no Rails. There's the pieces of Rails. There's Diesel which would act like a record. There's Nickel and Pencil and Iron and Rocket. Tokio is the async framework that is getting more and more stable by the day. We got to try it out on a project recently and it's pretty fun. I still am working on wrapping my head around promises and futures and working in that way but I think as that stabilizes and people use that, that is going to cause like another explosion of libraries that enable really fast but safe web backend stuff, which I think is really exciting. If you're looking for the Rails experience of being able to plug things together and nicely, just declare a few things, it works but not quite there yet. But if it excites you to try out new things and figure out the best ways to do the things you want to do in Rust, this is a great time to jump in and help. CHRIS: I will say the Rocket website is beautiful and it even has this templating section, a testing library section. This is very exciting. It really looks like as the closest thing to a Rail-style web framework that I've seen in Rust so far. People should definitely check this stuff out. I'm curious, I know a lot is really interested in Rust and Ember, which doesn't surprise me because lots is really interested in Ember in general, which I think is awesome. But is there anything specific about working with the Rust and Ember together that seems, especially well suited or even like some gotchas that you guys have run into? One of the things I'm thinking of is like Ember is really big into JSON API spec and I don't know if Rust has a JSON API library for serializing things in that format. Is that something you guys have to tackle at all? CAROL: There might be. I'm not sure. Crates.io is using the Rust API adapter for Ember so we might not be keeping up with the latest of Ember. But I know there are people who want them to interface them better with each other. Actually, that's an interesting thing. Both Ember and Rust are on a six-week release trains sort of things so the way Rust people will say -- I don't know if Ember people do -- is stability without stagnation so they're both changing. Rust has backwards-compatibility guarantees so the code you wrote with Rust 1.0 is still going to compile today. You might have some warnings and there's probably new cooler stuff that you could switch to but it's still going to compile. I'm not sure about Ember's upgrade path things. Someone just sent in a pull request that we merged like three days ago to upgrade us from two Ember point versions. There were a couple of things that like [inaudible] and we weren't doing quite right and we had to fix. It's been interesting to kind of fit together, keep both of the sides, update it and upgrade it and continuing on using the best things. But I think they have similar philosophies around making things better all the time. CHRIS: Yeah, the whole stable upgrade path and backwards-compatibility guarantees is definitely mirrored on the Ember side of things. I can see that being a little kind of comforting place to be knowing that both your frontend and your backend are not going to suddenly just break on you one day because some new feature came out that breaks your router or something. That's very cool. One of the thing that I know you're involved in -- you're involved in a lot of things -- when it comes to Rust, it's very cool. But you also run or a co-run a conference, right? Rust Belt Rust? CAROL: Yeah, we had our first year in 2016 in Pittsburgh. I ran Steel City Ruby before then so I love running conferences and I love having them near me one, because it's convenient and I get to trick all of my friends into coming to visit me. But two, because there's a lot of tech stuff happening in the Rust Belt and places that aren't San Francisco or New York. People don't necessarily know about that and people who live here don't necessarily have the opportunities to travel as easy to conferences. I sort of start Rust Belt Rust, one because of the pun opportunity and one of our speakers drew a little bar graph. There were three conferences last year. There was Rust Fest in Europe which has [inaudible] amount of Rust. There's RustConf, the official Rust Conference in Portland that has a lot amount of Rust and then Rust Belt Rust has double the amount of Rust in its name so we're the Rust-serious Rust conference. We're going to do it again, in 2017 we're going to move it to a different Rust Belt city. I'm not going to say which one yet but we're closing in on a date and a venue in the Rust Belt city so watch out for an announcement on that. It was a lot of fun. We had a day of workshops and then a day of single-track talks and a lot of time for conversation. A bunch of the core team members came out and it was fun talking with a friend of mine who was trying out something with Tokio. This was in October so Tokio was still working towards their first big release and he was trying to do something with Tokio. I looked over and I saw Carl Lerche, Alex Crichton and Aaron Turon standing together and talking like 30 feet from us and I was like, "If only the three people working on Tokio were nearby to answer your question --" so he just walked over and talked about Tokio with them. I love getting people together to talk to other people working with things, talk to the people who are working on the things they're using and meeting the people behind the names on the internet so I love running conferences and having events like that. STEPHANIE: Carol, you have a Rust consultancy called Integer 32. How is that going? CAROL: It's going pretty well. We're learning a lot. One of the reasons I wanted to start it is because I felt like I wasn't learning more in my job. In my Rails job, I felt like I had kind of tapped out with that knowledge. In starting a business, I get to learn a lot of stuff like sales and marketing and taxes and invoices. Sometimes, I even get to program a little. We're still learning how to effectively find our target customers. We do have availability, if anyone listening is interested in hiring some Rust experts. Right now, I'm trying to figure out when can we bring more people on the team. I'm trying to decide if we can have an intern for the summer. It should be fun so yeah, it's going pretty well. It's been a slow build but we're lucky enough to have savings and be able to spend some time building our business but it's been really gratifying to feel like I'm in charge of my destiny somewhat, as opposed to the whims of a company. STEPHANIE: And if I were interested in some Rust consulting, what would be the best way to reach you? CAROL: We have a website at Integer32.com and a contact form on there. STEPHANIE: Thank you so much for speaking with us, Carol. It was a pleasure. I feel like I learned a lot about Rust. CAROL: Thank you for having me. STEPHANIE: All right, y'all. That's it from us. Thank you so much for tuning in. Until next time. Bye-bye.

Steve Klabnik @steveklabnik | Blog | GitHub Show Notes: 02:56 - Getting Into Rust 05:51 - Working on Rust for Mozilla 07:01 - Writing Documentation and Preventing Burnout 13:24 - The Rust Programming Language 18:45 - Rewriting Firefox in Rust 21:20 - High-level Functions 25:23 - Typesystem and Concurrency 36:35 - Rust and Web Developers; Digging Into Rust on a Deeper Level 43:46 - The Rust Ecosystem and Using Rust on a Day-to-Day Basis 48:38 - The Rust Book Resources: Rust For Rubyists Cargo Servo Application Binary Interface (ABI) MetaLanguage (ML) Tokio Systems Programming intermezzOS Steve Klabnik: Exploring Ruby Through Rust What's new with “The Rust Programming Language”? rustbook Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast episode 51. I'm here, my name is Charles Lowell. I'll be hosting today. With me is Chris Freeman, also of The Frontside and with us is Steve Klabnik. Now, most of you probably heard of Steve before. My first encounter with Steve was actually at the LoneStarRuby Conference back in... Gosh, I don't know. It was many, many years ago and he was giving a talk on Shoes, which I also had never heard of before. It was a wonderful story of a code archaeology project where he was kind of investigating, rehabilitating, and in carrying forward a project that the 'why the lucky stiff' had done. That was a wonderful introduction but it was certainly not the last time that I encountered him in his writings and in talks and stuff, mostly within the Ruby community. But it popped up again and again, talking about Rust APIs and always making a point to take a good knowledge that he'd learned and spread it around. Personally, I've lost track of Steve or hadn't really heard much of what he was doing for a while. But then Chris came into the office and he was always talking about this language called Rust. While I've heard Rust, Chris was just all about it and wanted to have Steve come on the show because it turns out that Steve, you've been really, really, really into Rust these last few years and sounds like concentrating most of your work there. STEVE: That is totally true and accurate. Also to go back a bit, that means that you are in attendance for my very first conference talk ever. CHARLES: Really? STEVE: That was literally the first one. CHARLES: Wow, it was a great start. That was a great story. It was educational and also touching. STEVE: Thank you. It's actually interesting because what happened was is that someone else who works on Shoes have encouraged me to submit to RubyConf and I was like, "Who would want to hear me talk at a conference?" I submitted the talk and RubyConf accepted it and I was really excited. Then a bunch of other conferences noticed and two other conferences had asked me to give a talk before RubyConf happens and LoneStar was one of them and it was the first one chronologically. That moment was also very special to me as well. CHARLES: Fantastic. What year was that? STEVE: I want to say it was like 2012 or 2011. It's really hard for me to pay attention to time and date. My history is so complicated that I often forget. I've literally told people that I'm 10 years old or younger than I am because I would like mess up to date on the things. It just happens. CHARLES: Yeah, but it was a while ago and it's been quite a journey, in between now and then. STEVE: Yeah, definitely and you're also definitely right. It is now literally my day job to work on Rust so it is definitely the focus of most of my efforts. Partly, why I made that happen was because it was the focus of all my hobby efforts before I made my job. It's definitely been a couple of years that I've been a full-time on all the Rust stuff. CHARLES: How was it that you actually got into Rust? How did you hear about it before everybody else and how did it capture your attention? STEVE: I've always liked programming languages and learning different programming languages. Ruby was sort of where I became known professionally. But it wasn't the first language that I knew and I knew it was never going to be the last. As much as I always loved Ruby and I'm like literally have a tattoo on my body so I will be with Ruby forever. I always try to learn new stuff and I find it exciting. I'm from middle of nowhere, Pennsylvania in the suburbs of Pittsburgh on a cattle farm and I was visiting my parents for Christmas one year. There's not really a whole lot to do out of the very small town so I was just reading the internet, as usual and it turns out that that was the day that Rust 0.5 had been released. I saw this release announcement go by and I was like, "I vaguely heard of this programming language once or twice maybe. I don't have anything to do. Let's give it a try." I downloaded and installed it. I looked at their tutorial and the tutorial has a problem that a lot of tutorials had, which is I read it, I said, "This all makes sense," I tried this down to write a program, and I had no idea how to actually write a program in it at all. I'm just completely confused. I couldn't actually apply the sort of syntax stuff that I learned. At the same time, I was going to be working on this hypermedia book -- that was my plans for that trip -- as always, you just rewrite your tooling over and over again. You [inaudible] like, "Just don't write the thing. Write the tools that make the thing," so I wanted to try out a new way to take mark down and generate PDFs in HTML, involving pandoc. I sort of had that all set up and I said, "Well, let me give this a try run. What I'm going to do is I'm going to write down what I learned in Rust as I learned it," and sort of from a Ruby programmers perspective, I'll use that and working with my new tooling to see if it works to actually work on the real book and it will also help me understand Rust better because one of the reasons why I do all this sort of teaching and advocacy is because I think it helps me learn. Just as much as I like helping other people learn stuff, I find that the repetition and being forced to explain something to someone else really make sure that I understand what I'm talking about. That's what the thing called Rust for Rubyist became boring. I'm a sucker for alliteration and that sort of became the first to tutorial for Rust from outside of the Rust projects proper. From there, I went on to submit some pull requests because everything's open source so I wrote some documentation and funny enough, my first ever pull request to Rust was actually rejected based on procedural grounds. At the time, they didn't actually accept pull request to master, they accept this other weird branch and GitHub don't have the ability to re-target the branch of the pull request. I also, always like this story because the thing that I now on the core team of, like my first attempt at getting involved was wrong and was turned down. But I'd fixed that pull request issue and got that in but it is kind of kept working on an open source capacity for a while and then decided to ask Mozilla if I can make it my job. Luckily they said yes. CHARLES: Wow, so what? Your job at Mozilla, like you just kind of showed up and said, "I would like to have a pretty cool, awesome job, working on this brand new language," and they were like, "Sure, come on in?" STEVE: To some degree, yes. That's one way of putting it. There is always the devil in these details. The first thing is that that wouldn't have worked if I had wanted a different kind of job. But when someone comes to you and says, "I would like to write documentation for you all day," you go, "Oh, my gosh. This literally never happens." If I had wanted to like work on the compiler, I'm pretty sure they would have said no. But because they knew documentation was important and they wanted documentation and because I had already been basically doing that job in an open source way, it's like I've had a year-long interview already. Then finally, they actually didn't have headcount at the time so I actually moved on as a contractor initially and had to do some freelance work and then eventually, once we were able to hire a new person kind of got it in. They're like a cool kid story. It's like, "Oh, yeah. I totally asked Mozilla for my perfect dream job and they just gave it to me," but like that's not really the way that it works. CHARLES: Got you. That actually leads me into a question that I have wanted to ask you. You write a very good documentation as your day job and documentation is extremely hard. For me, it is extremely hard to get and stay motivated to document something that I've worked on. I think that is probably a common enough experience for programmers. We don't recognize because we use documentation that it's extremely valuable and yet, it still this thing that is just a constant uphill battle. I'm curious, how do you manage to stay motivated to write documentation for an entire programming language over the span of years? STEVE: As I'm often want to do, this has like three or four different components. I guess, there's a couple of different things involved. The first one is that I actually got accepted to go to English grad school, although I ended up not pursuing that. Like writing, it's something I have just always enjoyed. I got a Bachelor in Computer Science but then I was going to go to grad school for English and due to university shenanigans, it didn't really work out. They told me I was going to get a free ride and then accepted me and then they were like, "Oh, wait sorry. You have to pay for this." And I was like, "Wait, sorry. No, I'm not doing this anymore. That's ridiculous." That's kind of always a predilection for writing and I think that the reason why that is because I grew up basically like on Slashdot and eventually then on Dig and Reddit and all these other things. I've kind of been writing a couple paragraphs a day, basically every day in my life since I was a little kid. I think that's something that's sort of like underappreciated. Documentation is hard but it's like a skill, like any other thing. Programmers will say, "I really want to learn TDD so I'm going to make myself do some TDD, I'm going to practice it, I'm going to focus on it and that's going to be a skill that I'm going to improve," and then they see documentation, and they kind of think it's this thing that you either have the skill or you don't. But writing is just another thing like anything else that you can practice at and get better. I think maybe it's because it's a little bit farther away from the wheel house of what you do day to day, that people aren't as interested in it but it is something you're truly interested in, I think the best way to get better is just to do it and do it a lot. I say this is I'm kind of in the middle of a little bit of writer's block at the moment to be honest. Then finally, I think the other reason that I'm motivated about docs is that I actually believe that documentation is an exercise in empathy. Like good documentation, the ideal as a programmer, the ideal thing that happens in documentation is I have a question about how to use something, I go to the documentation, and it says the exact sentence that answers my exact question. As those varying degrees of vaguely gives you the right idea, versus literally tells you exactly what to do. I think that the way that you can accomplish that excellent documentation is by understanding what your users need and then preemptively figuring it and/or writing that down. I think that that requires being able to put yourself in their shoes to some degree. I'm not going to say that that's a thing that I am perfect at but I think that a valuable skill when trying to improve docs's like figure out what they actually need and then give it to them. It's doesn't always have to be in that order, like sometimes people will fail to find the thing they need, tell you what you need, and then you give it to them. That's a strategy I've used a lot and that's one reason why I hang out in the Rust IRC all the time, helping people is for a very long time, I would like sit in IRC, someone would ask a question, I would answer the question, I'd go look in the docs and see if they could have figured out themselves. If they couldn't, that would be might next doc PR. It's just like even if it's just a couple sentences like add the question from IRC into the documentation and then just do that over and over and over again and then eventually, people start learning from the docs instead of actually ask questions because they already found what they needed. CHARLES: Right. I have a question about that because once you develop those skill, I think you also still run the risk of like burning out. I know that one of the reasons I tend to always fall back to like, "I'm going to spend my time doing coding instead of documentation," Or, "I'm going to spend my time --" Even with TDD is a great example is like with TDD you get to experience those short term wins. I think that kind of prevents you from burning out, where sometimes when I'm writing documentation, it feels like I'm screaming at the void. I might be screaming really loud and really, really well but I feel like a lot of times, I'm not experiencing those wins and I'm wondering if you have any tips for like experiencing those wins. Or getting that feedback to kind of keep you motivated and keep you doing the job. Also, trying to push the level of your own documentation skill and communications skill. STEVE: Yeah, experiencing the wins is definitely a part of it. But one of the other things that is sort of part of it is that like I do the opposite. I do a lot of coding but that's my side projects. When I get fed up with writing documentation, I maintain the [inaudible] implementation that Cargo uses to resolve Rust packages, for example. If I'm feeling a little stuck on docs, I'll go write some software and then come back to the docs so that kind of help with burnout. Another thing is that I think I'm just like perpetually in a state of just barely above burnout anyway so that also sort of factors in I guess. You know, it's like Bruce Banner. The secret is that I'm always angry so -- CHARLES: So you work on open source, is that what you're saying? STEVE: Yeah, exactly. We're working on open source all the time. I've been lucky enough to make open source as my job for, basically almost my entire professional career. Although not totally. You know, at some point, you just kind of get used to it. But in terms of experience and the wins, this is also one of the reasons why I like to teach beginners specifically is that beginners allow you to remember what it's like to be a beginner, which is also part of building the empathy. By interacting with beginners a lot, you also get a lot of those wins because beginners usually ask easy questions so it's easy to figure out the answer that stuff. Then you've got that positive feedback loop kind of going. To me it's maybe not IRC literally for every project but answering questions on Stack Overflow, or whatever message board forum you have, or Twitter, like actually interacting with other people. For me at least, that's how I get that kind of sense of not screaming into the void that you have to like go into the void and find the other people there, I guess, that I'm just like come to you necessarily. CHARLES: Speaking of empathy for beginners, it just occurred to me that we didn't actually talk about what Rust is. We probably should do that. Why don't you tell us a little bit about the Rust, language, as well as, you've mentioned Cargo and [inaudible] ecosystem for us as well? Let's talk about that. STEVE: Yeah, totally. Basically, Rust is a new-ish. I should stop saying new because it's almost not really at this point. A kind of new-ish programming language, heavily sponsored by Mozilla in development. Its idea is to become a new low-level programming language. But I always hesitate when I say this because one of my old pitches for Rust used to be like, "Rust could be used anywhere. You can use C." Then people go, "I would never write, C is so cool. Rust is not for me." I'm like not do that. But the reason that people don't use C is a lot of the problems that we are also trying to fix. I guess the primary differentiator for Rust in terms of like programming languages theory is that it is safe and safety as they got specific meaning. But basically C is a very dangerous sharp tool and you can cut yourself and people who use those tools often do cut themselves, whereas Rust is like it's got a safety guard on it. It's a compiled language so its compiler actively prevents you from making some of the worst mistakes that you can make in a low-level programming language like C. It turns out that when you start building up these sort of safe abstractions on top of these really fundamentally low-level details, you actually end up with a relatively high-level programming language. I talked to a lot of people, for example from JavaScript or Ruby world or Python world who come to Rust that are modulus, some libraries, and other things. This is actually high-level enough that I feel like I could do this instead of review JavaScript all day and I would be just as comfortable. The other day, I did a little bit pair programming and we actually recreated a JavaScript library in Rust that had virtually the same interface because like you can actually build relatively high-level things so pass an enclosure to a function that does some stuff is totally normal and Rust world. That's also very familiar to people that come from the Ruby, JavaScript, Python background. Also then, as part of that is we also culturally like Rust the projects, not Rust the programming language, really, really cares about helping people understand what systems programming and like lower-level programming means. A lot of people will not program and in C or C++ because they have no idea how to get help or to learn because many people in the low-level space have this RTFM attitude or like, "If you don't know what you're doing, then get out of here," whereas in Rust world, if you ask an extremely basic question, we're like, "Welcome. We would love to have you. I would be very happy to like walk you through," like explaining how that works on these kind of low-level details. Part of the culture of Rust is to bring this sort of low-level programming to people that have rejected it before for various reasons. The reason that Mozilla cares and the reason Mozilla sponsored the project is that Firefox is written in C++, so like four million lines of C++ last I checked. Last time we did a security audit of a really pants-on-fire, terrible security bugs in Firefox, I go to this website and now they run arbitrary code on my machine kinds of terrifying bugs. Basically happened because C++ is dangerous and sharp. If you screw up, there's the kind of bad things that can happen. About 50% of those security issues in Firefox would be eliminated at compile time by the Rust compiler. That's a really huge win in general so the idea is that we are slowly rewriting Firefox and Rust over time. That's one angle of why Mozilla cares about Rust. The second part is Servo, which is a rendering engine that's built in Rust from the ground up. If you think about Firefox proper, it's got Gecko as the rendering engine inside that actually determines where things go on the page and stuff. We're also writing a new one of those from scratch called Servo in Rust. That was also to prove that the language was doing the kind of things that we need it to do. But also Servo is an impressive piece of technology in its own right so it might become its own thing and/or bits and pieces of it are already making their way into Firefox. It's kind of also a way to improve our core products. That's why Mozilla cares. CHRIS: I was curious with Servo and Servo is the layout engine. Do you know if there are any plans to write a JavaScript runtime in Rust? STEVE: That question is complicated. Sort of what it boils down to is that a Git is inherently kind of unsafe by Rust definition of unsafety. It's actually controversial like when I talk to people that work on JavaScript engines, they're pretty much 50/50 split between, "Oh, yeah. Totally Let's absolutely rewrite the whole thing in Rust because we rewrite it every two or three years anyway from scratch so why not use Rust next time," to, "Since it's massively unsafe anyway, I don't see what benefit I would actually get so why not just stick with what we know." It's like very extreme ends. It's definitely feasible but I don't know if it's going to happen and/or when exactly. CHARLES: There were two questions that I had kind of to unpack some of the things that you said in there that were just really interesting to me. You said Mozilla plans to incrementally rewrite Firefox in Rust, where it's currently four million lines of C++. Now, how does that actually work where you're talking about swapping out large parts of the runtime with something that's written in a completely separate language? How does that communication happen between those language boundaries? STEVE: There's this concept called an ABI, not API. It may sound very similar -- Application Binary Interface. What this really boils down to is assembly language does not have function calls. That's not a concept, that's in assembly. People have come up with, "If I write a function and I map it to assembly code, what's the convention about how I do things like passing an argument and return values? How those all that stuff actually work?" Because assembly is so low-level, there are multiple different ways that you can make that happen. There's a number of different specifications how to make that work so C, the programming language, has a very straightforward ABI so any programming language that knows how to call C functions, uses these convention at the assembly level to do the function call. What you can do with Rust is you can say, "Please make this Rust function follow the C calling convention," in that way, any sort of thing that knows how to call C functions can call Rust functions directly. By doing that, you can sort of say like take a chunk of code, write it in Rust, expose a C interface, and then anything that knows how to talk to C, which is virtually everything, can talk to Rust equally as well. For example, one of the earliest production uses of Rust was actually inside of a Ruby gem because Ruby can be extended to C and Ruby knows how to have C extensions. It doesn't actually need to know that it's literally written in C. It just needs to know how to generate the assembly to call the correct functions. That's actually like a thing. Basically, the process is like write a component in Rust, expose this language independent wrapper, and then call into it like you would in C code. CHARLES: So it's really, just they're sharing memory and sharing is like right there in the process and there's no overhead for the intercommunication, it sounds like? STEVE: Yeah, exactly. You could also do all the regular things with JSON-RPC over a socket or whatever if you wanted to. The most efficient way is to literally include it as your binary just like anything else. CHARLES: Which kind of leads me into my next question, which is Rubyist and Pythonista people coming from JavaScript, one of the reasons we don't like to write in C is because, as you mentioned, they're so sharp so we have safety so that you don't have to worry about memory allocation for the most part, the garbage collector kind of has your back there. You access things by reference so you never have to worry about accessing memory. That's not there but kind of the conventional wisdom is that that all comes with a pretty big cost. It's like really, really expensive. I know when I was getting into Ruby and I was explaining a lot of the pushback I got from people doing C and even Java, it was like, "It's going to be super slow because all those high-level features that you love so much, you're paying a lot. A lot for them." My understanding is that's not really true with Rust. Is that fair to say? STEVE: Well, Rust does not have a garbage collector so, yes, it does not pay that cost because it doesn't exist. Now, that also raises a bunch of other interesting questions and basically what it boils down to is a compiler and especially one that has a typesystem, basically asks you to declare certain properties of your code like this function takes one argument only and it's always a string. That's sort of what type safety means. It kind of like a fundamental level. One of the ways that Rust uses type safety is to say, "This pointer to this memory always points to valid memory," and you have to be able to demonstrate that to me at compile time. From those couple of sentences, that sounds extremely complicated but it turns out that most programming code is written in a way that actually works this way. For example, like I'd talk to Yehuda Katz a number of times because we're friends, he also works on the Rust project and he's also well-known in JavaScript and to you all, I would assume. It turns out that the style of Rust code I write is actually extremely similar to the style of JavaScript code that I write is just sometimes there are some tweaks. It is true that those features often do take up a lot of memory and/or rely on any sort of expensive, from a low-level perspective, way of doing things. But it turns out that's actually more of a function of the way that the programming language is made in semantics. You could design a programming language that feels very similar but as very different underlying characteristics. For example, Closures in Rust, the compiler is smart enough to know that if you don't actually capture an environment. Say you're going to add one to every number in a list. You want to do like .map, pass in a closure that takes one argument X and adds one to every single X and then collect that up into like the map join kind of thing, to collect into a new array. That closure that you had passed a map, while it's a closure, it's taking that one argument X and doing X + 1, so it's not really capturing an environment at all. There's actually no reason to allocate a bunch of extra memory because it turns out, it's the same thing as a regular function. The compiler is able to optimize that call away completely to the same thing as if it was a normal function and not a closure, and therefore, you're paying no overhead. Even though, like syntactically, it looks kind of like a closure. Then you're kind of think of that applied to almost everything in Rust. For example, Rust has methods but almost all of them are actually statically dispatched at compile time, as supposed to dynamically dispatched, where you need to look through some sort of object hierarchy because we don't really have inheritance. There's no way to say like this might result to a colon, this class or this class is super class, or this class is super class so I have to do this runtime look up to call functions that just doesn't actually really exist. Part of it is through the fact that these coding patterns don't strictly require this stuff. It's just the way those languages are built and part of it is because as we were building a language, we were extremely sensitive to not include features that would require this really heavy overhead. In a language, that's like a low-level of focus on details, it's extremely hard to talk about the details without code. There's a lot of details, it turns out. CHRIS: One thing that I'm very curious about and one of the things that drew me to Rust actually is the fact that its typesystem is, I guess an ML typesystem. It is like much more [inaudible] to something that you would see in a functional programming language like Haskell, than you would like a regular C++ or Java. CHARLES: Now, a Chris-acronym alert. What is an ML-style typesystem? CHRIS: I'm sure Steve can answer this better than I can but it's a typesystem that uses the Hindley-Milner algorithm for type inference. It does a lot of the heavy lifting for you, in terms of correctness. Is that correct? STEVE: Yeah, I would say more accurately, ML is a programming language. It's the name of the language so by saying like an ML-like typesystem, he means like a Java-type typesystem. It's like a similar statement but about a different language. I always forget what ML stands for specifically but like OCaml has got ML at the end so like OCaml is one of the languages that sort of the family of ML. There's like two branches of functional programming, which of course everything is wrong when you try to organize things this way. Like you could also argue Lisp as a third but there's kind of like the Haskell-style and the ML-style are these two big pillars of functional language stuff and Rust tends to be in the ML sort of family. There's lots of common features between families of programming languages and all that kind of stuff. I think the ultimate point that Chris is trying to make is when I say that Rust is a typesystem, I do not mean it's like Java. There is a wide variety of typesystems and they do all sorts of different things and actually Java has been getting increasingly better over the years as well. But it is much more canned to a functional language in the typesystem, which I think is what you were getting at and serves the actual question, right? CHRIS: Yeah. Actually, I just looked it up and ML stands for MetaLanguage. It is actually is going to serve my question really well. ML was originally designed for theorem improving in math, which is part of why it works really well in functional programming languages. But it also makes sense if you use Rust, how the compiler work from the kinds of things that it catches, like a relatively low effort on your part because it is originally designed to completely prove out a theorem so the compiler is doing that to your program. That leads to my question which is I recently heard someone else on the Rust core team talk about one of the things that Rust really seeks to improve upon is concurrency and parallelism, which is historically very hard. To do that, you could use things like mutexes or reference counting, which Rust has. But they also lean extremely heavily on the typesystem itself to sort of guarantee that your concurrent code is actually going to run safely. On one hand, I'm interested in hearing you expound on that but I'm also really curious how the C, C++, Java programmers take to that sort of thing in Rust because as I understand it, that is a pretty novel approach to that kind of problem. I wonder if there's like pushback from the existing low-level systems community on that stuff. STEVE: I'll do the second part first because it's a little simpler. One thing that I will say is we sort of didn't appreciate over time because we were creating Rust for ourselves, roughly the C++ programmers are working on Firefox, which we had to say for ourselves because I was not literally one of those people but you get the idea, is like assuming that C++ people would be the primary audience. But it turns out that a lot of people that programming C or C++ are pretty happy with it and they like doing things that way. They're a lot smaller of a population than the number of programmers who do not program of those languages, which is true for any language, basically. The sum of all other people is bigger than your specific thing. What that means, I think that in retrospect this seems obvious but at the time, it was like hard to figure out or I definitely did not understand this at that time, that most people would come to Rust from not C or C++ than they would from C and C++, just even by virtue of numbers alone. A lot of the people who are not doing it are not doing it for reasons. They've already rejected it for some sort of purpose and the people who are still doing it often are like happy with what's going on. There's definitely a little skeptical at times of the kinds of things that we can accomplish. Also, our success has been pushing C++ specifically to grow a lot of safety things so we hear a lot of people say like, "In five years, C++ is going to have this tooling that's going to make it also pretty safe, even if it's not as safe as Rust. I'll just wait for that instead." Surprise, low-level programmers are extremely conservative bunch in many instances. The first part, which is the bigger and more interesting one, the typesystem is absolutely how concurrency works in Rust. This is extremely powerful for a number of different reasons. The first one, and I think the fundamental reason why it's done this way is that typesystems don't have any runtime overhead. When you're in a performance-heavy language, that's really the key. Originally, a long ago in Rust, we actually had a garbage collector even, like a very long time ago in Rust. The primary goal was always safety and we thought the only way to accomplish that was with lots of runtime checking, heavy runtime, and all these things. Over time, as the typesystem grew, we realized we could use more and more of a typesystem to eliminate more and more of the runtime because types are checked to compile time so they have no overhead cost, which is awesome. Like Rust references, doing this validation that they're always valid is completely a compile time construct that at runtime, they're literally the same thing as C pointers. That's one reason why the typesystem is really heavily useful for concurrency because you want things to be safe. We also don't want to slow them down. The whole point of concurrency in many instances is to get a speed up. If you introduce too many safety checks to make sure that your concurrency stuff works, you lose all the gains that you were trying to get from being concurrent in the first place. Having that like as low-cost as possible is extremely important. The second one is that concurrent problems are extremely difficult to debug because you need to recreate the exact set of circumstances under which the bug happens. If you have a bug because you have two threads that have a particular access pattern on a particular variable and that's where the bug is introduced, good luck coercing your operating system scheduler into scheduling those two threads at exactly the same way as when the bug happens. To some degree of the way that you fix a lot of concurrency bugs is by introducing an extreme amount of logging and then just kind of let it run and praying that you hit into the situation that causes the bug. That really brutal and doesn't really work. By using the typesystem and verifying it upfront, you just know it will work at runtime because you've already proved the concurrency property before your code even runs. It's also just like a better debugging experience, I think in general. The way that we accomplish this task is extremely novel. I guess I should also say extremely novel to working programmers, like almost all Rust is built off of existing research that has been known in academia for a relatively long time. That's actually one of the places where it gets the name from, it's like taking ten-year old ideas that have a little bit of rust on them, that have found usefulness and bringing them to [inaudible] research. Anyway, the way we accomplish this basically is the typesystem in the standard library, the way that you spin up a new thread, it has a particular type signature and the type signature says, "Only allow the types to be sent to this new thread. There are safe to pass between threads," and/or like, "Only allow references between this thread and that thread of types that are safe to use across thread." What that means is that when you try to spin up a thread and you passes a thing that doesn't work, you get a typesystem error. It turns out this is not concurrent safe collection so it does not have the prerequisite types so therefore, you cannot pass on this thread and you're done. That's sort of like at a core level of how these things work. Then for example, mutex is a type that does have that property so by sticking with non-concurrency thing into a mutex, now you can share it safely. That means we've guaranteed that the compile time that you'd safely done this transfer between threads and that kind of thing. It's not just about mutexes but that's sort of the general approach. The last thing I want to say briefly because I just said a whole bunch of things. I'm sure, I've raised a ton of questions here is that the other powerful thing about using the typesystem for concurrency guarantees is that other people can extend it. If you write a library in Rust, your library will be exactly as concurrency safe as the standard library and as the language itself. It's not like we provide the set of concurrent collections and then we vetted our own implementations and then you're kind of your own or building your own stuff. You can use those exact same types to help guarantee properties on your stuff. Also build alternate threading situations, as well that use the same things and the ecosystem all works together so everything is just concurrency safe by default because it's like a property of typesystems that are being built into the runtime or something. CHRIS: I know that recently, there's been a lot of, I guess excitement about this library called Tokio. It's not like there's future that kind of like promises in JavaScript, then there have been abstractions just kind of consistently being built up but it seems like Tokio is the next step and it's building towards a whole stack of higher-level concurrency things. Is what you just said enables that kind of thing to happen? STEVE: Yes. Tokio is using those exact same typesystem features in order to guarantee that when you have a chain of promises, to use the JavaScript terminology instead of future things, that you make sure that they're safe. This is not literally implemented yet but Tokio, for those who are not paid hyper attention to the Rust space because this is a cutting-edge, the library is gearing up for an initial release in the next week or two. Soon after you hear this or maybe right before you hear this, it's just going to be released. It's extremely cutting edge. But in some ways it follows sort of the node model of concurrency. There's event loops, you chained together, we call them futures, you call them promises together, you put that pile a future chain and do an event loop and watch the concurrency kind of go. One example of how Rust can do cool things is you could -- this is not implemented yet but it will be in the future -- run, let's say, five event loops on five different threads. Then you just tell the framework, "Please run this future chain onto one event loop. I don't care which one," and then it will automatically load balance across the five threads and five event loops because you've guaranteed the compile time that everything is safe to pass between threads so we know that that's just trivial to do and therefore it's like not a big deal. We can add those heavy duty features without worrying about introducing very subtle bugs, which is really cool. CHRIS: That kind of leads me to my next question, which is at The Frontside, we are pretty into web development, in case you didn't know. I am someone who follow Rust a lot and I find it very interesting. But for the most part, I don't have a need to do systems programming on a regular basis. I also wouldn't even really know where to start, if I wanted to do systems programming. As I learned Rust, I tend to always gravitate towards wanting to do things that I would probably do in Ruby or Python, like write the back-end for some web app or something. That goes okay but Rust is very much still in the process of building those abstractions to the point that it's relatively digestible. So I have a couple of questions. One is do you see Rust being a thing that would be used by web developers a lot more broadly and two, how would you recommend that people like me who aren't really familiar with systems programming start to really dig into Rust on a deeper level? STEVE: I would like to think that web programmers will use Rust more often and to be honest, originally, I was extremely skeptical of this. But it's been changing rapidly as time has gone on. Part of that is because as we've gained more experience, actually in programming in Rust, the fact is Rust used to be a lot less ergonomic than it is and now it's fairly ergonomic and will only get more so in the future. That's something that web people or at least, I come from Ruby so Rubyist care a lot about ergonomics, maybe more than anything else frankly. I'm not sure it's the first tool that you'll reach for but I do believe that sometimes, it makes a lot of sense. As one example that I will use, there's not a whole lot about this but basically, npm has started using Rust on the server side for powering the registry. They have three services in production now but they were basically like JavaScript as a language we all know what is the best language for doing this. We have a service that needs a little more oomph so maybe let's rewrite that in Rust instead and use it for those kind of things. I think that there's a lot of situations for web developers where they don't realize they have the power to make things faster without just adding on more servers. I think that's kind of like a compelling sort of [inaudible]. Any sort of background job like any sort of job queue thing is like often better written in a faster language but you would not reach for that faster language first because traditionally, those faster languages have been terrible to use. I think we continue to win on the ergonomics and continue to win the libraries that web developers will reach for Rust like more often than not. In terms of the learning rest on a deeper level, I think that one of the initial things and sounds like maybe you personally are a little past that but maybe not the people who listen this podcast is that I do think that sort of building the things that you would normally build in Ruby or JavaScript or Python is the good first step. For example, right now Advent of Code has been like a really fantastic way of having these little programming projects. If you haven't seen AdventOfCode.com, it's like every day in December up until Christmas, there's a new programming project that you can build the thing in. I've been doing those in Rust and that's a lot of fun and it's a good way to practice and gain some basic literacy. But after that moving at a low-level stuff, my personal thing and I know something you've expressed interest in the past is my side project is building an operating system in Rust. More so, than just that the pitch is, "You've written JavaScript before. Let's write an operating system together. Here is this companion book and I'll show you how," and that's called intermezzOS. It's like I'm basically trying to rebuild an operating systems curriculum but in Rust instead from nothing, like we start off with assembly code and move up into Rust code. CHARLES: Now, you can't even use anything like all the things that we've been describing like threads, kernel level callbacks. You get none of that, right? You have to implement it all from scratch. You can't use POSIX or whatever. You know, 90% of your code ends up going through. STEVE: It turns out that and it's sort of like for reasons that hopefully I'll be able to fix in the future, you need about like 200 lines of assembly code before you get into Rust and then you basically don't need to use assembly again, really. It's not that big of a barrier in terms of [inaudible] things and its copy-paste stuff that I explained extremely heavily so it's like totally an accomplished real thing. Then you're in a real programming language and you can do more normal things on top of it. But one thing about that because it is my side project, the kernel is actually farther along than the tutorial is and I actually need to find some time to write more of the freaking tutorial but this is kind of my personal long-term project over the next, let's say, decade and to have a completely free and open source tutorial for you to learn about operating system developments. That's one of the things I've been doing. Another one that I think that is really extremely useful is once you gain some amount of literacy on this, you can actually start to learn more about how your regular programming language works. I've been giving this conference talk recently. It's called 'Exploring Ruby Through Rust', and I'm like, "Once you know this low-level stuff and you gain this literacy, you can look at the source code of your language as interpreter and learn stuff about it and you can contribute to it maybe even." Maybe that's not the most practical thing or whatever but now that I've spent a bunch of time with Rust, I understand Ruby on a far, deeper level than I ever did before because now I'm not afraid to go poke around in the internals and learn how it really works under the hood and I understand what those internals do far better. Maybe five years ago, I could have told you like, "Ruby is garbage collector. It's extremely basic. But I don't really know what that means." And now I can be like, "Ruby has this mark and sweep generational garbage collector. But it's not compacting or concurrent yet but maybe in a year or two. Now, that's not just a bunch of buzzwords because I have this low-level literacy." CHRIS: Yeah, that's definitely something. I forgot about but every time I go learn something in Rust and initially this happens a lot. Every time I do that and I go back to JavaScript or something else, I find that Rust inadvertently taught me something about the language that I actually work on every day. Especially, when it comes to things like references, values, and the difference between them and debugging weird prototype behavior in JavaScript became so much easier after I had spent some time working with Rust and had had to like actually deal with passing around references or dealing with life times or having the compiler yell at me for a lot of things that I thought were totally normal. Then I'm going back to JavaScript, it's like, "Wait a second --" Suddenly a lot of these pieces are starting to fit together and before what was just as weird mystery, now I can totally see what is happening and start to think about how to fix it. Even though I don't even have the same tools that I do with Rust, it still is extremely useful from that perspective. STEVE: That's awesome. I'm glad to hear it. That's how I definitely felt with Ruby for sure. CHARLES: You know, in terms of actually using it for day to day stuff, is there other plans, is the ecosystem already supporting things, say, a web framework? Like a low-level web framework like Sinatra or Express or even higher one like Rails. STEVE: I guess, like you've already qualified it as web stuff. But I would say, in a broader sense, whether or not Rust is ready today for you, it depends entirely on the ecosystem. I feel like 80% is productive in Rust as I did ever in Ruby. But that's only if there's a library that I don't have to rewrite myself because it doesn't exist yet. That number is actually growing rapidly so I just look because it's like the end of the year and our package ecosystem is actually doubles. This is a request from earlier. I didn't expect Cargo so Rust basically has bundler or yarn/npm built into the language itself. We distribute it with Rust and we have all that great package ecosystem shenanigans. Another great example of Rust over a language like C is the tooling. Basically, what happened was Yehuda and I kind of showed up in Rust world and we're like, "Why are you still using make files. We know a better way." And they're like, "Okay." Then he builds the equivalent of bundler for Rust. Then everyone's like, "Oh, yeah. This is way better. We're not using make files anymore." The tooling situation is very familiar to a dynamic programming language person because we literally had the same people write the tools. That also means you can share packages freely and briefly so operating system development thing is totally intense to be able to use your package manager to download packages to help you build an operating system. For example, X86 has custom assembly instructions that you need to use when interacting with the hardware and someone has already built a package on [inaudible] that wraps the inline assembly up in a nice to use Rust functions. I can just include that package and use it when building my operating system, which is totally mind-blowing. The npm is sort of feel into OS development is just real intense and cool. Back to the ecosystem thing, though. For web application specifically, it's good and also bad. There's actually multiple different web frameworks already at different levels of comparison. For example, you have Nickle which is kind of like Sinatra and you have Pencil, which is kind of like Flask and Python, which is also kind of like Sinatra. Then you have Iron, which is kind of like expressed in JavaScript. There's also like I know of at least two. One of is has been worked on but it's not been actually released. But the code is at least open source yet. I know a second that is being developed fully in private that has not had any public release yet. Then when the Tokio stuff comes out, People are going to be building new frameworks on top of the new async shenanigans and/or porting the async stuff into the existing frameworks. We kind of have a lot of options but there's also a lot of churn and activity and stuff going on in that space so that either terrifies you or makes you enthusiastic. They're basically is like that. We definitely don't have a Rails yet. I don't think that's because a Rails will never exist but because it's a much bigger project to build a Rails than to build a Sinatra. CHARLES: Yeah, and you just need those foundational pieces there in place before you really want to attempt that. STEVE: And I think Tokio is the real foundational piece and it's just taken us a long time to put it all together. The initial tests in Tokio, we could do a 'Hello, World' benchmark like the tech and power benchmark. Some of you are already familiar with those things, or not, they're like 'Hello, World' benchmark. We actually got faster than they are fat than all of them. It just edged out the fastest Java, which is currently the reigning benchmark on it. That's like extremely compelling. Even if after all this stuff is built on top of it but it's taken us a while to build those foundations and we're just getting that point like Tokio is going to have a release, hopefully before Christmas. I've been assured by the end of the year and then people are going to build stuff on top of it and it's just going to explode from there. Here's another little interesting pitch. I'll give you for this, is that one of the things I like about Rust on early ecosystem is it means that if you want to be that person who built the library that does X that everyone uses, there's lots of opportunity in Rust world right now. Where there's a lot of foundational libraries that you could be the person who wrote that thing when everyone knows and loves and uses. Like JavaScript is still kind of there. In Ruby, every library basically exists already so there's no more room to build a foundational thing. But if you're someone who likes working on open source and that story is compelling to you like getting involved in a younger ecosystem, it means that you can have a much larger impact. I maintained the [inaudible] library that things used. The only reason that's true is because I was around before we had one and then Yehuda wrote the initial version and now, I'm maintaining it. There's tons of space out there so if writing a web framework is the thing that's interesting to you, Rust is a great place to explore and actually doing that at the moment. CHARLES: Steve, one of the things that I know you do is you actually write the Rust Book. I heard that you're also in the process of rewriting it along with Carol Goulding, I believe. I was wondering if you could tell us a little bit about that. STEVE: As part of this Steve getting the job right in the docs on Rust thing, I kind of working on lots of stuff so up to Rust 1.0, we knew we needed to have some long form explain all the things that Rust so that became what's called the Rust programming language which I named so because the C programming language and the C++ programming language, the names of the foundational books for those languages so I wanted to continue kind of in that tradition. But there is some problems with that which is I'll say that I'm a little harder on my own work than I think other people are so I hear people tell me all the time that they love the Rust Book and that it's like one of the best programming books that have ever written. But I think it's not that great. The reason why is also because I just know that the way in which I wrote it. You have to remember that Rust 1.0 happened in May of 2015. We were working on language for six or eight years before 1.0 happened so there was lots of changes, language is changing on a daily basis. Now, it's super stable like super, super, super stable. But what that also means is in some like deeper philosophical sense, nobody had had experience programming in what really was Rust yet because we were still like finishing building it's so like how do you write a book on a language that like the precursor language is what you're using and you're trying to see like what is it going to actually end up being like at 1.0. Because it's not like we can just say, "It's done. Now, go write a book, Steve and then we'll release it at that time." The circumstances in which I wrote the original book were I had a very intense deadline of this has to be done by the 15th of May. While the language was coming together, it takes a couple months to put together a book so I had to make sure that the stuff I was starting I would need to go back and re-fix. That also means that I was like much more vague in some places where pieces were still falling into place and you're like, "This is definitely going to be the same. But this might change so I'm going to leave that part off," and then I just have to plow through because the deadline. All those things coming together means that I kind of put together this book that while good and I'm proud of the work that I did, I can do much better. At this point in time, we now have a full year and a half after Rust 1.0 has come out. I know the struggles that people have when learning Rust. I know the ways in which they succeed or fail and I've talked to a lot of people so I'm sort of rewriting the book now, bringing that knowledge and understanding in as well as the fact that the language just been around for a minute so it's much easier. As part of that, I brought on Carol. She goes by Carol Nichols or Goulding. She both has her maiden name and her married name. She's been one of my best friends for a very long time so I'm extremely happy that she's my co-author on this book. The two of us together and working on doing the rewrite, I think that it is possibly the best thing I've ever done or worked on as far as books go, like I'm extremely happy with it and you can read it online right now, if you want to and see if I'm right or wrong about that. But I think it's a far better book than the original book was. It's actually going to publish at No Starch as well. We're donating all the proceeds to charities since we're being paid to actually write the book in the first place, like [inaudible]. It's going to be a much, much easier and better way to learn the language, I think as well. CHARLES: If we want to check that out, where can we find the new version? STEVE: I'll give you a link to put in show notes or whatever as well. But it's Rust-Lang.GitHub.io/book. There's also just like a book repo in the Rust Lang organization on GitHub. All things in Rust is being developed fully in the open so you can read the drafts and see what's been done where. We're getting towards the end, slowly but surely so I'm hoping that's going to be done relatively soon. CHRIS: Well, I'm looking forward to it. CHARLES: Fantastic. Sounds like the documentation is there. It's excellent. The community is there. It's excellent and from what I'm hearing like the kind of the tower of the ecosystem is really being built up. It's not as high as a bunch of other places but it's definitely high enough to jump in and get your feet wet. If you're you know coming from almost any walk of programming. STEVE: It's a lot of work but we seem to be doing good. CHARLES: All right. Well, thanks for stopping in and talking about this with us, Steve. STEVE: Thanks so much for having me. It's been a lot of fun. CHARLES: Yeah, and now Chris, we do need to kind of figure out what is going to be our Rust project here at The Frontside. CHRIS: I'm up for that challenge. CHARLES: Yeah, that'll be some Christmas homework. All right-y. Take care everybody and thanks, as always, for listening. We'll see you next week.