tim-mcnamara

[tim-mcnamara]

The amazing Rust podcasts that have emerged in 2024

All of a sudden, the Rust community has a long list of podcasts! This is another indicator of the maturity of the Rust language community.

QnA with Friends

YouTube

Irine Kokilashvili (aka mamaicode and girlyops) who seems to have spent much of the last several months traveling all around Europe talking Rust at cloud conferences, has started a podcast (*) called QnA with Friends featuring fun, informal yet informative interviews with lots of people from their corner of the Rust world.

Here's an example of an interview with Zelda Hessler, a friend of mine from AWS works on the Rust SDK for AWS:

(*) There's no RSS feed to subscribe to. It's really a YouTube channel that has interviews uploaded to it. But that still counts, in my opinion.

Rust in Production

RSS • Apple Podcasts • Spotify • YouTube

Hosted by Matthias Endler, who runs the Rust consultancy Corrode.dev, Rust in Production focuses on interviews with industrial users of the language and others who have used it for production services.

Self-Directed Research

RSS • Apple Podcasts • Spotify • YouTube

SDR is hosted by Amos Wenger (fasterthanlime) and James Munns. IIRC, James was a founder of Ferrous Systems, and now runs his own consultancy called OneVariable. The idea is that each week they present to one another for 20-ish minutes.

Compose

RSS • Apple Podcasts • Spotify • YouTube

Then there's the podcast that I've started. Compose is also an interview podcast that tries to see how people have shaped software to shape the world.

I have spent many years wondering whether I should start a podcast -- the world doesn't really need another white guy talking about tech online -- but I finally pushed through the fear and self-criticism and did it anyway. Compose is ostensibly a podcast about Rust, but it's really a way to help celebrate people's efforts to build a better planet.

Rust Ship

RSS • Apple Podcasts • Spotify • YouTube

Rust Ship's an interview podcast by (now) Rust Foundation staffer, Marco Ieni. He's interviewed many of my favourite people from around the Rust community, including Lisa Passing, who is an artist that spends as much time helping others to create as creating herself.

Rustacean Station

RSS • Apple Podcasts • Spotify

As the GOAT of the Rust programming podcasting world, it's almost strange to think that anyone doesn't know about the Rustacean Station. Rustacean Station has a magazine format, where essentially anyone can upload an episode.

Here's an episode that features a guest you might recognise:

[tim-mcnamara]

My Rust Nation 2024

I've finally had a chance to pause after getting back from London. An immeasurable thank you to Ernest Kissiedu for the invitation to present.

Because I suck at selfies, but selfies are extremely popular, here is a selfie of me not looking at the camera:

A real business

Seeing my logo next to many others definitely made me take a breath and realise that I have created something meaningful. So many people have supported Tim Clicks, via financial contributions and positive messages during difficult times.

For people who have been following me for a while will know that my Rust consultancy, Accelerant, is less than a year old.

I decided to use the flagship Tim Clicks brand as the logo and it looks amazing. The branding work for Tim Clicks is all done by John at Underscorefunk Design and I recommend them wherever I can.

The conference began for me before the conference

If you're interested in podcasts, you should consider listening to the recording of the Twitter Space that I recorded with Ernest in the lead up to the event. It was wonderful to have the opportunity to chat about Rust and the opportunity that Rust offers the world:

Four talks in a week (including a full day workshop)

Rust London

Giving an impromptu lightning talk at Rust London was a fun highlight. I was able to rehearse a few lines from my talk, which was a nice bonus.

Rust in Enterprise workshop

I wasn't too sure what to expect when Ernest pitched the idea of hosting a workshop for the conference. I was already quite busy and overworked. In the end, it was a really incredible day.

Photo: Rust Nation via LinkedIn.

Talk: Unwrapping Unsafe

I spent weeks on this. Possibly more than 100 hours of research. After all of that time though, I decided to change the focus of talk radically to focus on explaining unsafe for the audience. It's strange to see that condensed down to 30 minutes or so. But there's bound to be another talk or two on this topic in the future.

Talk: 4 levels of error handling in Rust

Unfortunately, a speaker had to pull out. I offered to step in and am quite happy with the result.

The conversations are the best part

The talks are amazing, but the best part of a tech conference is the ability to shake hands. It was also really wonderful to connect with many people who I have only met online.

Possibly one of the most exciting points was to agree to start a partnership with Ben Wishovich, co-maintainer of Leptos, to provide full stack web development to clients.

Reflecting on a year

[Content warning: mental illness]

Flying home, I spent lots of time writing in my diary. Lots of that time spent coming back to my guilt at missing many deadlines for projects, such as my in-progress courses, which are very late. Suicidal thoughts have been a near-constant part of my background noise as an adult, and that background noise is much louder when I only have my own head to listen to.

Travel also imposes a large cost on my kids. I am almost constantly worried about my impact that my trips have on my girls. But I also know that we have lots of wonderful time together. I tend to work from home most the the time as well, which means that I get to spend more time with them than most Dads.

Connecting with me

I want to keep the discussions going, whether that means helping you with Rust or something else. Here are a few links:

Join my Discord server, CLICKS LOUNGE. This is the best way to keep a conversation going.

Find me on LinkedIn. If you would like to add me as a connection though, please send me a note rather than sending an anonymous request.

Support me on Patreon.

At some point, I would like to expand this into a fuller post but I've promised myself to time-box this one and make progress on some other tasks.

Wishing you all the best!

[tim-mcnamara]

The coolest thing about Rust Nation UK 2024 confirmed all my worst fears about software supply chain security (and then xz made things worse)

Something super cool happened on stage in the closing keynote of Rust Nation UK 2024. Tokio 1.37 was released and published live. The audience cheered (watch the clip below for confirmation). I was very impressed.

I was also terrified. It confirmed that there's no external scrutiny placed on Tokio releases.

Tokio isn't just an open source side project that is made for fun. It sits at the centre of many of the world's most important messaging systems.

It is the kind of software that is ideal for nation states to attack.

Just from looking at the logos of its corporate sponsors, we can see that it's important to AWS, Microsoft Azure, Facebook, Discord and Dropbox.

Here's a screenshot from the way that the tokio.rs homepage looks today:

Anyone who is able to introduce a security back door through the project's internal processes will open many of the most important technology platforms that the industry has produces.

This isn't unique to Tokio, or to Rust. But the Rust community is especially vulnerable to supply chain security issues for (at least) 3 reasons:

Most projects are dependent on a very small number of crates

Those crates are maintained by a very small number of people

We trust that Rust has enough inherent safeguards

We expect that someone else would have checked the code

The current state is fragile at best. We (the West) face a very hostile security environment. I wholeheartedly support growing the number of contributors and increasing the accessibility of important open source projects, including Tokio. Let's also increase their security posture.

[tim-mcnamara]

Why did the early '90s spawn so many video game genres?

Perhaps I'm showing my age, but the density of games that were able to chart completely new territory is impressive.

Dune II - 4X strategy

Sim City - simulation games

Star Control II - open world procgen

Doom - first-person shooter

Monkey Island (or Age of the Tentacle) - adventure

Civilization - strategy

I'm not sure if they've had the same impact, but they had a massive impact on me.

XCOM: UFO Defense - still the scariest game I've ever played

Syndicate - I just keep thinking about it

Master of Orion II - another space 4X game

I haven't played nearly as many games as I used to recently, but here are some titles that created space for a new genre:

Cookie Clicker - clicker games

Minecraft - crafting

Stardew Valley - idle games

Why?

A few thoughts.

The 90s was an interesting time to be a game developer.

The skills that you honed on 8-bit systems could be used to create significantly more impressive games. The 16- and 32-bit systems that emerged in the 90s were wildly more powerful. Although it might look hobbled by today's standards, a 40Mhz 386 processor was a beast compared to what might have expected 10 years' prior.

A lot of the computing capabilities were new and demanded . Graphics cards and sound cards were being added to consumer devices. Some computers even had large resolution monitors, e.g. 640x480 .

Prince of Persia demonstrated that it was possible to for individual programmers and small teams to create seriously competitive titles. All that was required was some creativity.

You competition was arcade games in physical arcades. It would be late in the decade for developers to learn how to make use of Sony PlayStation, such as Crash Bandicoot.

Multi-player options were fairly limited, which meant that the single-player version needed to be really good.

A lot of the cultural expectations for what a video game should provide were not set. This allows game designers to discover

Small teams have less bureaucracy to deal with. There are fewer approvals needed to try something interesting.

Small teams didn't need to be ridiculously profitable to create something that was commercially successful. This provides space for more creativity. Just as how large movie studios need to re-hash old content and tropes because they need things to be commercially successful, large game studios are similar. They need to make lots of money because the games built by large teams are are expensive to make.

[tim-mcnamara]

Now is the time to bet big on Rust

For about 5 years now, tech giants have had access to a secret weapon: access to the world’s top Rust talent. With hiring freezes and layoffs as the trends du jour, they’re giving that access away.

Many of the strongest developers that I have known are currently looking for work. Even if teams are not affected directly by layoffs (yet), they’re still operating within a climate of fear and constraint. Everyone is worried if their job will be next to go. And even if they’re not directly affected, they’re riddled with survivor guilt and are constantly being distracted by corrosive discussions about the future of their team, their product and their company.

Why has Rust been a secret weapon?

There are very few companies in the world that can afford to pick an experimental technology. And even within those companies, it’s very difficult to persuade leadership to try things that are radically different. But sometimes, the status quo isn't good enough.

Google has faced critical security issues within its Bluetooth drivers in Android for many years. Despite valiant effort, they were unable to eliminate these vulnerabilities from within C++. This essentially forced them to consider alternative languages. They’ve recently announced that they’ve been able to use 1.5 million lines of Rust code into Android, without detecting any security vulnerabilities. This compares to 1 vulnerability to 1k lines of C++ code using similar analysis.

Microsoft has been similarly plagued by security vulnerabilities within Windows and other applications. Rust was first deployed heavily within Azure, but has steadily been seen as viable alternative to C++ in other areas. So much so that it’s now part of the Windows 11 kernel.

Rust is bigger than systems programming

It’s not just large companies building core software infrastructure that can make use of this technology. Rust is a good fit whenever your business is concerned about cost. And right now, everyone is concerned about cost.

Rust code is cheap to run. Rust-based applications use less RAM and RAM is expensive. Tilde’s story from migrating from Ruby on Rails is illustrative. Their server agent went down from needing 5GB of RAM at rest to 50MB.

It’s easy to build and deploy Rust applications. Its sophisticated build system and rich package ecosystem work well together. You won’t need to worry about dependency hell or path mismatches at runtime.

Rust code is reliable. Your operations teams will love how easy it is to get something online and keep it available. You’ll never encounter a null pointer exception in Rust. Null pointers don’t exist within the language.

Web services, whether they’re deployed in a traditional manner or use the serverless model, are an ideal fit for Rust. There is no garbage collector which can affect tail latencies or create load spikes.

But it’s still scary

Adding a new programming language to the technology stack is still a difficult challenge. You’re right to be conservative and prudent. But you shouldn’t close the door completely to new ideas.

Adding another language complicates the build process. Suddenly you need to have some system that understands multiple languages.

It’s hard to hire Rust developers because it’s hard to evaluate them. Your senior developers don’t know Rust and therefore don’t know how to rank candidates. There’s also the problem of finding competent Rust talent. Rustaceans lurk in strange corners of the Internet.

Many people have been scared off by stories of Rust’s steep leaning curve (learning cliff?).

These problems and others are all tractable with the right advice and support.

Now — and here comes the pitch — I am one of the people affected by the layoffs I mentioned at the start of the post. My role at AWS, leading Rust education across Amazon, was dis-established this month. I was wildly successful internally helping the teams building the world’s largest web services learn Rust. And so, I want to replicate that success more broadly.

I am starting a business called Accelerant to enable teams to successfully validate and adopt Rust. If seeking advice is something that would be useful to you, please send me a note! tim@accelerant.dev.

[tim-mcnamara]

A template proposal for adopting Rust at work

A template for you, an employee at "ForkJoin" to you adapt. An AI writing assistant wrote most of it. If you have suggestions for improvement (it's not quite as polished as I would like), please contact me on LinkedIn, Mastodon or Twitter.

Subject: Enabling Rust as a choice for our software developers

Dear [Stakeholders/Management],

I am writing to propose that we investigate the possibility of adopting the Rust programming language here at ForkJoin.

Background

Rust is a modern, high-performance programming language that emphasizes safety, concurrency, and speed. Since its initial stable release in 2015, Rust has gained significant popularity and has been consistently ranked among the top programming languages in recent years. Notable tech leaders like Microsoft, Google, Meta, CloudFlare, Dropbox, Discord and Amazon have adopted Rust for various projects. Their experience shows that it can be a worthwhile choice for integrating into a tech stack.

I believe that adopting Rust incrementally, while investing in a Rust education program will greatly benefit our company in the long run.

Objectives

Improve our company's competitive advantage by adopting Rust in suitable projects. This will improve the experience for our customers and reduce operational costs.

Equip our software engineers with knowledge and skills in the Rust programming language, enabling them to develop high-quality, reliable, and efficient software.

Foster a culture of continuous learning and innovation within the engineering team.

Enhance our company's reputation as a forward-thinking organization and attract top talent in the industry.

Adoption Pathway

I propose that we establish a stakeholder group to help ensure that any adoption or perhaps even transition is smooth, well-planned, and aligned with our goals.

The group's tasks could include:

Developing evaluation criteria: The stakeholder group must establish clear and measurable criteria for evaluating the success of Rust adoption. These criteria should encompass various aspects, such as team members' skill acquisition, project performance, code quality, maintainability, and overall impact on the organization's goals. By defining these criteria upfront, we ensure a structured and objective approach to evaluating the adoption process.

Pilot the use of Rust: To gain practical insights and minimize risks, the stakeholder group should oversee the implementation of pilot projects using Rust. These pilot projects can involve integrating Rust into smaller, non-critical components of existing projects, such as cron jobs or CLIs, or developing new projects, perhaps serverless microservices, entirely in Rust.

Assess its effectiveness: As the pilot projects progress, the stakeholder group must continuously assess Rust's effectiveness in meeting the predefined evaluation criteria. This includes monitoring progress, gathering feedback, and analyzing project outcomes. By doing so, the stakeholder group can identify areas for improvement, make data-driven decisions, and determine whether Rust is providing the desired benefits.

Endorse broader usage of the language: If the pilot projects demonstrate that Rust is successful, the group can recommend broader usage. This endorsement may involve scaling up training programs, allocating resources to support Rust adoption in larger projects, and promoting Rust as a preferred language for suitable use cases.

Proposed Education Program Structure

The Rust market is still immature. To mitigate the risks in this area, we should consider a parallel effort invest in an professional development program focused on Rust for software engineers here at ForkJoin.

Here are some of the components of a program to support our staff leaning Rust:

Self-paced learning: Offer to purchase copies of well regarded books and other material for those employees who request them.

Project-based Learning: Assign small-scale Rust projects to engineers for practical application of their newly-acquired skills.

Online Courses: Enroll our engineers in reputable Rust courses, of which there are many choices.

In-house Workshops: Organize regular workshops led by internal or external Rust experts to provide hands-on experience and address specific questions.

Mentoring Program: Over time, pair experienced Rust developers with less experienced team members to facilitate knowledge sharing and accelerate learning.

Conclusion

Investing in Rust at ForkJoin will not only elevate our software engineering team's skillset but also enhance our company's competitiveness. By adopting Rust, we will be better equipped to tackle complex, performance-critical projects with increased confidence and efficiency. We'll reduce operational costs while increasing the performance of our applications.

Thank you for considering this proposal. I am confident that this initiative will prove to be a valuable investment in the company's ability to ship products, our team's professional growth and the overall success of ForkJoin.

Sincerely,

[Your Name] ForkJoin

[tim-mcnamara]

What is the a moneyball metric for business?

This won't be an original idea – but I wonder if startups all chase the same metrics and therefore amazing businesses never thrive because they're not recognisd and supported.

Moneyball (the book at least) was all about the fact that Billy Beane discovered a metric that others were ignoring - percentage to first base. Every other coach focused on much more heroic stats, such as percentage of hits and number of home runs.

I wonder if there's something like that for business. There are many stats that are on everyone's dashboard, such as churn, monthly active users. Most startups use the same methodologies, listen to the same podcasts, take notice of the same influencers, and so on.

What is the metric that everyone misses?

[tim-mcnamara]

Agile isn't about speed, it's about direction

Agile development is “faster”. But, it’s not about velocity, rather it enables you to correct your orientation. Adoption an agile process won’t make you move faster, but will still help you get to the destination sooner.

The term agile left software long ago and has crept into almost everywhere in business. Unfortunately, it’s often misunderstood and rarely well implemented.

Agile doesn’t make your team magically speed up its ability to close tickets. Instead, it speeds up the team’s decision-making process. It’s about orientation, not velocity. An agile workflow is one where you are able to quickly adjust direction based on short feedback cycles.

In an ineffective agile workplace, it can feel like sprints are every two weeks so that there’s greater management oversight. In an effective agile team, sprints last two weeks to enable the team to regularly check that it's building something that customers actually want to have built. That's why it's important to have customers close to your product development teams.

[tim-mcnamara]

Autocomms

The transition from horse to combustion engine was an important one for humanity. For the first time, people were able to move between cities of their choosing at faster than walking pace. I will risk being laughed at by predicting that we’ll see similar transition for communication within the next 10-20 years.

Consider ChatGPT. In 3 years’ time, it will be seen as impressive — yet slightly quaint and dated — technology. The service can explain elegantly explain many topics. It’s better than Wikipedia at Wikipedia’s primary purpose, to provide an overview of an unfamiliar topic. It can generate this concise summary of a technical topic within 5 seconds or so:

Hello, are you able to explain the term "angular momentum”? Yes, I can certainly explain the concept of angular momentum. In physics, angular momentum is a measure of the rotational inertia of an object, which is the tendency of an object to resist changes in its rotational motion. It is defined as the product of the object's mass, its velocity, and its distance from the axis of rotation. The greater the angular momentum of an object, the harder it is to change its rotational motion. The angular momentum of an object can be expressed mathematically as: L = I * w where L is the angular momentum, I is the moment of inertia of the object, and w is the angular velocity of the object. Angular momentum is a vector quantity, meaning it has both magnitude and direction. The direction of the angular momentum vector is determined by the right-hand rule, which states that if the object is held with the thumb of the right hand pointing in the direction of the angular velocity vector, the fingers will curl in the direction of the angular momentum vector. I hope this helps! Do you have any more questions about angular momentum?

Only physics teachers would be able to do something similar unprompted. Most of us would require some reflection to recall the topic and to consider how to phrase the response.

But, ChatGPT is more than an instant recall machine. Where it really excels is in its ability to quickly adapt the tone and style. I’m much more impressed with its answer to this follow-up question than its ability to recite facts:

Could you please rephrase your explanation to be more appropriate for a high-school aged audience. Perhaps use golf or sports cars in your examples. Sure! Here's a simpler explanation of angular momentum that might be more appropriate for a high school-aged audience: Angular momentum is a measure of how much an object wants to keep spinning. For example, if you hit a golf ball with a club, the ball will have angular momentum because it wants to keep spinning after you hit it. The more mass the ball has and the faster it's moving, the more angular momentum it will have. It's kind of like how a sports car can be harder to turn because it's heavier and going faster - it has more "oomph" to keep going straight. On the other hand, a smaller car or one that's going slower might be easier to turn because it doesn't have as much angular momentum. Just like a vector has both magnitude (size) and direction, angular momentum also has both. The direction of the angular momentum depends on how the object is spinning. You can use the right-hand rule to figure out the direction: if you point your thumb in the direction of the object's angular velocity (how fast it's spinning), your fingers will curl in the direction of the angular momentum. I hope that helps! Do you have any more questions about angular momentum?

One thing that I’m not so happy with is its chirpy (over-)confidence. When you ask it to provide references or citations, it fabricates them. So, it’s not able to replicate Wikipedia’s second use, to provide a good starting point for references to more thorough treatments. I’m sure that similar features will come.

Transitioning to the automobile has had painful consequences. Cars created urban sprawl. They kill many people every day. I wonder what side effects we’ll see from this rapid growth of new AI.

[tim-mcnamara]

Superficially simple

One of the great mysteries is how we as a species are able to to get anything done. Is it because we are so good at tricking ourselves to believe it's going to be easy?

Some things are very difficult and very expensive (however you measure cost). Many structures built centuries ago took centuries to build. For example. the Colonge Cathedral wasn’t finished until 600 years after construction started. Which projects starting this year are likely to be finished after 2222?

Perhaps one of the reasons why anything gets built at all is that our brains need to underestimate the work involved at the beginning of a project and once we discover how hard things are, we’re too emotionally invested to give up. My book would never have been started if I had known the costs involved up-front, nor would it have been completed if I hadn’t already done so much work on it and promised so many people that it would be done. Even when part of my brain tried to tell me that the sunk cost fallacy was real, I kept moving forward.

Software engineers appear to particularly bad at this. Or, at least, they’re much more vocal about how terrible other people’s software is and how much cleaner their implementation would be. I mean, curl could be written in a weekend. Twitter could be written in a weekend. This one is so common, it’s almost a meme.

It’s terrible that we don’t immediately stop ourselves when we begin to believe things like this. We wonder why we can’t make accurat estimates. And yet I keep entertaining ideas like rewriting Apache Kafka, RabbitMQ or a database. This week it’s been an itch to write an ActivityPub server.

Formally, this phenomenon is known as the Planning Fallacy. Even people who study its effects are prey. It was one of the first cognitive biases discussed by Daniel Kahneman and Amos Tversky in 1979. To counter-act it, here are two strategies:

write a plan and commit - once you’ve done the analysis and understood the space, you’re actually less likely to fall behind [doi:10.3758/MC.36.4.791]

smaller tasks are easier to estimate - try to split the project into as many tasks as possible [doi:10.1002/1099-0992(200011/12)30:6%3C873::AID-EJSP22%3E3.0.CO;2-U]

[tim-mcnamara]

Programming Language Lifecycle

Programming languages emerge, thrive and then wilt.

This in an incomplete essay that's being published to attract early feedback. Perhaps send me an email if you would like to provide a comment?

Emergence

Someone introduces a new programming language to the world. They're unsatisfied with the status quo and believe that they owe it to the world--or at least themselves--to try to do better.

The book, Masterminds of Programming, is largely an edited transcription from interviews with 27 programming language designers, who were creators or formative figures of 17 languages. It's really interesting to read some of their views. The dissatisfaction is palpable.

Tom Love, one of the creators of Objective-C:

We weren't completely happy with any of the choices available in those days.

[...]

Brad basically said, "I think most of the capabilities that they're talking about in Smalltalk I could figure out how to add to C."

Bertrand Meyer, the creator of Effel, describes why he created his language:

Eiffel was born out of necessity. I designed a programming language because I needed to write software and everything I had was unsatisfactory.

Bjarne Stroustrup's initial thoughts on C++ are similar:

No language that could do both existed in 1979, or I would have used it. I didn't particularly want to design a programming language; I just wanted to help solve a few programs.

(Aside: Bertrand Meyer has recently made his own book. Introduction to the Theory of Programming Languages freely available for download from his website.)

At some point, the language is released. Larry Wall describes this tendency of programmers to believe that they can do better as hubris. Perhaps another view is willful ignorance.

The people attracted to the community are excited. They're necessarily contrarian. They believe in the ideals of the language. Adopting a novel programming language is a process of curiosity and/or protest. The largest thing written in the language is the compiler.

Growth

There's a wonderful phase of growth. Everyone knows each other. Everything is fresh. There is no legacy code. People talk about the potential. And yet, for most languages, there is no adoption.

Programming language ecosystems are social systems. While the compiler or interpreter works, you need to convince people to try it out. And perhaps more importantly, you need to convince people to help out.

There are packages to create, tutorials to write, and talks to give. Someone needs to maintain the package manager--your language does have package manager, right? Essentially, during this phase, things start to get boring.

Stability

At some point, stability becomes a feature and change becomes risky. Important programs are written in the language. The people who were attracted to the language because it was novel and interesting begin to leave.

Python was able to push through this. I believe that the Python 2 to Python 3 transition was (eventually) sucessful because Python (accidentially) attracted a new set of people—data scientists using pandas and interactive web notebooks—who were not interested in retaining backwards compatibility.

Perl could not bridge this gap. The gap between Perl 5 and Perl 6 was too vast. The people who programmed it Perl 5 wanted to program in Perl 5. There was no new tranche of fresh programmers who could embrace and

Death

In some sense, programming languages cannot die. Even if you are the last remaining SNOBOL4 programmer, the programs that have already been written will linger. As a form of written communication, software often outlives us.

And yet, they do die. This starts as soon as the number of programmers departing the community exceed the numbers of people joining. To avoid this, always foster a welcoming tone.

Projects started in the language are risky.

Photo by Raelle Gann-Owens on Unsplash, digitally altered to reduce footprint using Dither Me This.

[tim-mcnamara]

Surf by Tim McNamara

4 colour dithered image. Based on an original by Tim Marshall, used under licence.

[tim-mcnamara]

Creating an Easy Mode for Rust

Rust has a reputation for being difficult to learn. This perception directly conflicts with one of the community aims: empowerment. Doubt breeds fear. And fear makes it harder for people to justify learning a new skill.

Rust provides the world with an opportunity to write software that’s resource efficient and resistant to security concerns. Any time that someone is put off from attempting to learn the language because they perceive it to be too hard—or that they’re inadequate—is a failure.

The Rust community is attempting to address this. The Lang Team’s roadmap for Rust 2024 is explicitly designed to make the language and its ecosystem “more ergonomic”.

This post is my attempt to provide some places where people learning Rust encounter issues. The original intention was to find a few things that could be addressed within the language itself. Unfortunately, most of the papercuts that I’ve found are outside of the core language.

Some guiding principles:

every decision point (“do I use cargo or rustup?”, “should I use HashMap or BTreeMap?”) is a place for confusion

the impression of prospective users matters more than people who are already invested

Improving First Impressions

We must place beginners first. Being welcoming to new users is essential to Rust’s overarching goal of empowerment. We don’t need growth for growth’s sake, but we don’t want people walking away from Rust because they’re discouraged.

Too many places to look

For a casual observer, there are too many places to look for resources with official or quasi-official status.

Some observations and recommendations:

“rustup” means nothing to someone who isn’t already involved with the Rust project. Let’s evaluate moving https://rustup.rs/ to https://install.rust-lang.org.

The Rustlings course is hosted in Github. This could be ported to rustdoc format and provided under https://doc.rust-lang.org/. This would enable people to run it locally with rustup.

Only 1 of three books listed under “application domain” at https://www.rust-lang.org/learn are hosted at https://doc.rust-lang.org/. Are the other two less stable? I know that these were created by working groups, but outsiders do not.

Too many commands

At some point, many heavily used commands should be consolidated under a single command-line tool called rust. This would become cargo, rustc, and rustup as well as fold in clippy and rustfmt.

Too much friction for tiny projects

My hunch is that people start with a new language by starting small. Rust should be fun for programming small utilities.

Let’s make it trivial to get started. Because so much Rust depends on third-party crates, it’s hard to create a Rust program that fits in a single file. I would love to see something like cargo-script become a first-class part of the ecosystem.

Let’s also provide a first-class interactive option. Many people attracted to Rust come from dynamic languages, where a build step isn’t necessary. The evcxr (Evaluation Context for Rust) project should probably be folded into the the overall Rust.

It should be easy to spin up a local playground. The playground provides a very useful service: it enables people to experiment without needing to invest a lot of effort.

Helping People to Build a Mental Model of Rust

Learning Rust well involves learning to navigate a social landscape that is rich in jargon and implicit cultural norms.

What is the difference between String and &str?

If the Rust community finds a way to quickly answer this question–which happens to be the most-highly rated question on Stack Overflow for the #rustlang tag– to people who are new to Rust, then it will succeed as a general purpose programming language. Without a concise answer, Rust will remain mysterious to many.

Understanding String vs &str implies an understanding of the ownership system, which implies an understanding of the lifetime system. That probably means that you’ve been exposed to pointers, references and perhaps even aliasing. There’s usually a discussion about mutability intertwined here. Gaining an intuition of data types that represent text benefits from understanding encodings, which benefit from understanding how CPUs operate.

I’ve yet to find a way through this for complete beginners. Learners with that already know another systems programming language have a distinct advantage here.

The common strategy is to tell users that they should “Just use String for now”. Everyone knows that this is only a half-answer. An answer designed to give learners some time. But it’s not even a half-answer. It won’t take long before they encounter an function’s parameter that takes &str (or worse AsRef<str>) as an argument.

Hard to find defaults

Every time that you place a decision point in front of your users, you introduce cognitive load. Cognitive load is particularly expensive for beginners, who need to retain lots of details in working memory to make progress while writing.

The Rust community values precision. We care about how our values are laid out in memory. We want to give developers strong type safety so that they can write robust programs.

Unfortunately for new users of Rust, there are often multiple choices for things that seem like there should be none.

Which numeric type is “right”?

When should I use &str, String, Cow, T: Display, T: AsRef<str>, T: Into<string> or any of the other options?

HashMap vs BTreeMap for mapping keys to values

It’s difficult to understand what the difference is between a few similar-sounding traits, e.g. ToString vs ToOwned vs Into<string> and Debug vs Display.

Why are there so many ways to convert types? When should I use the as keyword? What about .into(), T::from(), and .try_into().

We should get better at giving guidance.

Difficult to know which crate to use

Rust has a rich crate ecosystem backed by crates.io, which provides semantic versioning and immutable versions. This allows for rapid and robust innovation by library authors, backed with dependability. This ecosystem also has its downsides.

The no namespaces policy of crates.io is vulnerable to name squatting and individual crates, that often written by a single author, are vulnerable to side-channel attacks.

I think that there may be a space for a another crate registry that provides curated crate collections, probably within reserved namespaces. (If I had a few million dollars, that would be my startup idea!)

This situation is difficult to navigate, especially for beginners. Our crates have cute names rather than descriptive names. It takes some experience to know that parking_lot is the crate for excellent synchronization primitives.

Perhaps one of the ways to address this is to provide curated crate collections.

Everyone’s most loved programming language

Learning Rust feels hard for many people. More significantly, people put off learning Rust because of a perception that it might be too hard.

It’s often argued that Rust’s ownership and lifetimes concepts are novel and therefore difficult. I wonder whether this is entirely true. All programming languages have difficult concepts. My suspicion is that the difficulty in learning Rust is partially caused by factors that sit outside of the core language. What do you think?

You’re welcome to contact me by email or on Twitter. This post is also being discussed on r/rust.

[tim-mcnamara]

Sometimes, a for loop is best

It can feel polished to always use a functional style. In Rust, for example, programmers often use .map(|x| { ... }) to apply a transformation to the data being processed. This is generally an elegant idiom, but can feel forced.

Creating an inner closure adds syntactic noise to the program via the vertical bars, and new variable name(s).

Taking advantage of .map() and its uncommonly seen cousin .for_each() can lead to somewhat hostile style. It forces programmers that mostly used imperative languages, such as Java and Go, to spend extra time to parse and interpret your intent.

If you're applying a complex transformation, consider sticking with a for loop. You'll feel less fancy, but your code will be simpler.

[tim-mcnamara]

That time I was interviewed for a BBC 4 programme.

[tim-mcnamara]

1x Programming

It’s actually okay to be a 1x programmer. Or even a 0.7x programmer.

Programming is a tool, little more

It’s absolutely fine to treat programming like a tool, rather than something that has value in and of itself. If you’re worried about not being good enough, I assure that skill will come over time. If you’re making progress, extending yourself and somehow avoiding burnout - then you’re doing well.

What do I mean, “like a tool”? Well, programming is a tool in the sense that most programming is done to achieve something other than programming.

Spending three hours in front of a screen might enable you to start a business, to pursue some creative outlet or perhaps to fix some problem in the world. But, under this mindset, programming has no a value in itself.

If there was a better tool than programming to achieve your aims, you would be perfectly entitled to learn that instead. A formal way to describe this would be to say that programming’s value is purely instrumental, or its value is derived from the other things that you produce with it.

That’s not to say that you’re not entitled to refine your skills and improve your productivity. However, I want you to know that you’re not a lesser person because you’re not able to produce 10x of something that’s almost immeasurable, like software. It turns out that some programmers are at least 10x more productive than others, however no one is born as a better programmer.

Here are some principles that I think hold merit. I haven’t ranked them in any particular order. I hope that you feel like they’re slightly provocative. I don’t want this list to seem like it is in any sense canonical. I’m learning too. So feel free to pick and choose!

Principles of the 1x programmer

Software is a team sport

Even if you’re coding for yourself, you’re still coding for a team. Your future self will not have the same cognitive context that you do currently. Therefore, you should always code in a way that respects the people who are following you.

One of the best introductions to this type of socially minded programming is called Building Software Together (freely licensed under CC-BY-NC 4.0) by Greg Wilson and contributors.

Our aim is to teach you how to be a compassionate programmer: one who cares as much about the well-being of their colleagues and users as they do about their own. This focus is not entirely altruistic—everything you do to help others also helps your future self—but now that we all know how much harm software can do, we hope you’ll be interested in some practical idealism.

Learn through mimicry

Find the best software written in your programming language of choice. Usually, the language’s standard library is a good place to start. Look for patterns. Try to consider how you would implement things.

Small children learn by copying others. Why shouldn’t adults?

Being a computer scientist is less useful than you might think

​​Synthesis is essence of software engineering, whereas abstraction is the essence of computer science. Your job as a software developer will be to synthesise something new from composable pieces. What you create should be simple to understand and extend.

You are unlikely to implement sophisticated data structures and algorithms.

I don’t agree with everything that pg writes, but this struck out.

99.5% of programming consists of gluing together calls to library functions.

The time to fix things is now

Your team isn’t going to have fewer priorities next week or next month. There will not be an opportunity to do the wholesale rewrite that the code base deserves. The only way to improve a code base is incrementally.

I learned this through John Ousterhout’s book, A Philosophy of Software Design. The overall suggestion that I took away from the book is that if your team is struggling with a spaghetti code base, its members should be investing about 10-20% of their total development time cleaning it up.

You’re paid to build

If you think that you’re employed to write software, then you’ve not thought hard enough.

You’re employed to make money – or save money – for someone. And the way to do that is probably through programming.

The phrase is terrible, but it’s worth repeating anyway. Make sure that you “add value”.

This matters because sometimes – perhaps often – working on the boring thing that no one wants to work on is really the thing that you should be doing.

Simplicity really helps

We all want to write simple software, as hard as that is. Ideally, your code should be simple enough so that a junior programmer who doesn’t like you can understand it.

Ironically, simple code probably has a shorter lifespan than complex code. Complex and difficult code remains fixed because people are afraid to change it. Complex code is very hard to test. And without regression tests, we don’t know if we’ve broken behaviour. So it becomes brittle.

API beats algorithm

Syntax matters. One of the lessons from the success of Kenneth Reith’s requests package — which completely took over from the standard library’s own implementation of making web requests — is that the (public) API is more important than every millisecond that you save from implementing the perfect algorithm. Users care about convenience. Convenient code is easy to write, easy to read and easy to maintain. However, it’s also important to understand what comprises your “Porcelain API” and your “Plumbing API”.

Other people make mistakes

The majority of us are better drivers than average. I’m sure the same is true for programming. Brains are imperfect.

It’s impossible for you to assess your own skill level.

If you want adoption, software is just the start

If you care about adoption, there’s lots of work to do once the code has been written. That is, unless you’re Fabrice Bellard, I guess.

This, to me, is the ultimate reason why being a 1x programmer (even in a professional setting) can be sufficient. You might be able to contribute to other areas that someone who is focused purely on the code is not able (or, more commonly, unwilling) to do. 10x programmers care about the code. Everything else is secondary.

Users care about themselves. To them, they need to be the primary priority. This rift causes a problem when open source maintainers decide that their users are indeed secondary. But that might be the theme of a future post.

Please improve this list

What have you learned in the course of your learning journey? Please let me know. I have plenty to learn.

Thanks to Nimo Naamani for helping me fix some typos and grammar issues.

[tim-mcnamara]

Tech is a team sport, let's look out for each other

Last month was tough, this month is tougher and Christmas will be hell.

You're not the only one who is finding it difficult to sleep at the moment. Your team members are working too many hours. Your customers are worried about the effect that the outbreak will have on their kids' education. Their kids are worried about the effect COVID-19 is having on their parents' ability to stay employed.

October 10th was World Mental Health Day. If you haven't taken 2 minutes to watch this short video produced by the WHO, I suggest you do so. It's quite heartening.

Within a COVID-19 outbreak, it's easy to focus on the immediate stressors. But those stressors can actually mask some underlying issues. For the technology industry, we've probably been avoiding mental health issues for too long. Even without the pandemic, members of the tech industry are in a structurally weak position:

The work is desk-bound. That limits opportunities for physical activity, which is a natural aid to mental well-being.

We can also easily work remotely. Consistent isolation means that there are fewer opportunities for our friends and colleagues to check in.

It's easy to slip into a pattern of long hours. Our work is on the computer and phone, which means that can be hard to leave work at work.

Stress

Doom scrolling is called doom scrolling for a reason. Here's a scenario you may be familiar with: your body is on high alert because the 1 pm press conference is due, so you check your phone. Jacinda is late. So you check Facebook, maybe a few other sites. After a few (e.g. 10) minutes, you realise that there's no press conference today. But every time you attempt to put down your phone, you feel something pulling you back to check again. That's your body is demanding a dopamine kick from the next headline.

If you're finding it hard to switch off, remember that it's okay to ask for help. Cortisol and other stress hormones have been swimming through your blood for weeks now. The effects of stress compound over time, so it can pay to be proactive rather than have the situation forced upon you by burnout.

Depression and anxiety

Symptoms of depression and burnout are more subtle than you may think. If your emotions are muted or greyed out - perhaps you don't look forward to something you used to love such as your morning coffee or your favourite show - this might be enough to detect that you're on a slippery slope. Other symptoms include being unable to concentrate, waking up early, and several others that are easy to pass off as something trivial.

Addressing things that feel trivial might actually be a very effective strategy. Just like preventing an infectious disease outbreak, it's much easier to intervene in your mental state at the start when signs and symptoms are relatively small. Waiting until you can't get out of bed in the morning means that your mental state has already affected you and those around you.

Neurodiversity

We're a male-dominated industry that's not known for its general level of emotional intelligence. Although it's a trope, there is some research to back up the decades-long cliché that technology jobs attract those with autism spectrum disorders (ASD) and attention-deficit disorders (ADHD).

Neuro-diversity is not widely understood. It's a fairly new term - I mean my spellchecker doesn't think that it's a real word. I mention it here because many people who are neuro-diverse also have comorbidities with anxiety and depression. They often blame themselves for being unable to be "normal". After years of growing up on the social fringe, they begin to resent themselves. A lack of awareness about neurodiversity means that their differences are only perceived as weaknesses. Yet in truth, neurodiverse individuals are able to excel in many areas that neurotypical individuals find difficult, boring or irrelevant.