Sponsorship
Centered - Your work, done.
Centered is the fastest way to work. It’s the only To-Do list that actually helps you get your work done, thanks to:
Scientifically-designed Flow Music
AI Productivity Coach
Co-working Sessions
Distraction Blocking and so much more
Projects
Penpot
Penpot is the first Open Source design and prototyping platform meant for cross-domain teams. Nondependent on operating systems, Penpot is web-based and works with open web standards (SVG). For all and empowered by the community
language: Clojure, stars: 9256, watchers: 135, forks: 436, issues: 184
last commit: February 20, 2021, first commit: May 29, 2016
social: twitter.com/alotor
repo: github.com/penpot/penpot
Rust by practice
Learning Rust By Practice, narrowing the gap between beginner and skilled-dev with challenging examples, exercises, and projects. This book was designed for easily diving into Rust.
language: Rust, stars: 2316, watchers: 30, forks: 94, issues: 2
last commit: March 17, 2022, first commit: August 01, 2019
social: practice.rs/
repo: github.com/sunface/rust-by-practice
Starship
Starship is a cross-shell prompt that is fast, customizable, and feature-rich.
language: Rust, stars: 23,356, watchers: 156, forks: 972, issues: 302
last commit: March 20, 2022, first commit: April 02, 2019
social: twitter.com/StarshipPrompt
repo: github.com/starship/starship
Already subscribed? Why not share Console with the best engineer you know?
An Interview With Matan of Starship
Hey Matan! Let’s start with your background. Where have you worked in the past, where are you from, how did you learn how to program, what languages or frameworks do you like?
Back in college, I started a part-time gig play-testing games. Yes, the dream job. I was on a team responsible for ensuring that performance remained consistent between patches, so we were tasked with playing the same game levels every day and measuring the performance of nightly releases. After some research, a little AutoHotkey know-how, and learning about the Windows “perfmon” performance monitoring tool, I managed to automate 90% of my job, leaving me with most of the week to exercise this newfound programming muscle.
The computer would play a set of recorded inputs to play the game and would tabulate performance metrics while I spent my working hours learning what I’d need to go from Game Tester to Automation Tester. I learned all about Python, web development, and Selenium, and went on to get an automation job at a (now defunct) adware company. No, we didn’t “take care” of adware – we made it. It’s not the work I’m most proud of, but it was fascinating to see how the world of for-profit adware worked from the inside. In that time, I began working on my first few side-projects. Working with my friend Josh Star, we collaborated on a couple of websites for western anime fans: AniChart, a seasonal anime release tracker, and AniList, a social cataloging site for anime and manga to share and discover new media, which has seen some incredible growth over the last few years.
From there, I went on to work as an Engineer in Test at Shutterstock and Autodesk, developing internal tools, testing pipelines, and building out CI/CD infrastructure for others to be able to ship confidently and quickly. In that time, I picked up Java and JavaScript, and discovered the wonderful world of shells. After discovering Fish shell, I began working on Spacefish, which went on to become the predecessor of Starship.
I later went on to work at Auth0 on the Release & Test and Developer Productivity teams – building tools and services to reduce developer friction. I got to work on internal tools for project scaffolding, on-demand load testing, ephemeral deployments, among other things. Lots of fun, to say the least!
These days, I’m working at CodeSandbox as a Full-Stack Engineer, working on a new project that’s still under wraps. Can’t say a whole lot about it yet, but keep an eye out for exciting news from us. 😉
What does incredible growth look like? Also, where do you think this growth has come from?
Over the last year, we've crossed the 1M registered users mark, and are quickly approaching 2M. We've focused on building a delightful user experience, a rich and flexible developer API, and have a team of 40+ data moderators, making our database one of the most reputable up-to-date resources on anime and manga available. Community developers have created dozens of apps, extensions, and integrations, giving people the opportunity to use the site and its data however they'd like.
What is your favorite software tool?
I am loving the suite of Rust-made UNIX tool “upgrades” that have been coming out over the last few years that have been making their way into my home-manager config:
What are you currently learning?
I’m learning Japanese, focusing primarily on learning to read for now. I started learning out of an interest in Japanese media, but am now coming to love the ritual and self-discipline aspects of the long challenging process. Much like Rust, it requires you to take everything you’ve learned about languages and to throw it out the window. Everything from sentence structure to reading the individual kanji (logographic characters) is totally unlike any other language I’ve learned. I’m going through the WaniKani kanji course, which uses the spaced-repetition based Leitner System to show you flashcards to practice, right at the moment when you’re likely to begin forgetting them.
What have you been listening to lately?
When I’m at my desk, I usually play my evolving “Focus” playlist, which has been topped up with ambient progressive house – recent additions have been music by C418, WMD, Lane 8, and Kubbi.
When I’m out and about, I’m probably working away at my podcast debt. The ones that make it to the top of my PocketCasts are usually:
Soft Skills Engineering - A podcast about the non-technical parts of software development
Design Details - A weekly show with two designers talking shop
Criminal - Bite-sized true-crime podcast, telling a new story every couple of weeks
How did you find these artists?
I discovered C418, having heard his ambient tracks setting the scene in Minecraft. Outside of making game soundtracks, his album Excursions is excellent focus material!
The discovery of WMD, Lane 8, and Kubbi, I attribute to the serendipity of Spotify's Discover Weekly. It seems to know my tastes better than I do! 😄
Who, or what was the biggest inspiration for Starship?
Back when I first fell in love with Fish shell, I was eagerly looking to use one of those cool, environment-aware prompts like Spaceship ZSH. There wasn’t a whole lot like it, so I took the liberty of learning a little bit about how Fish prompts worked, and ported it over to Spacefish. The port was as much of a line-for-line port of the ZSH version as possible, which meant we got some occasional bugs from the original.
Whenever they released a feature, I’d diligently port it, and whenever I’d implement a bug-fix, I’d back-port it over to the ZSH version. This process led to a lot of duplicated effort that could’ve been better put to use implementing new features.
It was Denys Dovhan, the author of Spaceship ZSH, who first experimented with creating a cross-shell prompt in Node.js with his experiment, robbyrussell-node. His approach of creating one binary was considerably more flexible and easier to maintain than any shell-specific variant. Being able to write the prompt in Node.js, there were much easier high-level semantics, powerful testing libraries, cross-platform support, flexible configuration, and most importantly, the ability to support any shell with a few lines of shell-specific initialization code.
Unfortunately, it wasn’t without its drawbacks. As an interpreted language, the Node.js runtime could sometimes take hundreds of milliseconds to render the prompt. Having to wait that long for every terminal command and you really start to feel it.
Having heard that Rust was StackOverflow’s Most Loved Language for the fourth year in a row at the time, I was curious to see what the fuss was about. So after two months of studying Rust, inspired by Denys’ work on the Node.js cross-shell prompt, I started work on Starship. Right away, it was apparent how well-suited Rust was for making a performance and safety-sensitive tool like a cross-shell prompt. Performance was an order of magnitude faster than shell-native prompts, was much more reliable, and ran on any system without the need for any dependencies.
Are there any overarching goals of Starship that drive design or implementation?
Since its inception, Starship has evolved from being a performant, informative prompt to being an immensely customizable prompt “framework”. Most users stick with the defaults or just tweak a couple of things, but others use it as the centerpiece of their beautifully customized developer environment, allowing them to focus on styling the prompt, while we deal with the shell and tools integrations.
Accessible. Out the gate, Starship should be able to be used by anyone of all levels. From a command-line beginner to the authors of shells themselves – we keep the barrier to entry as low as possible for both installation and configuration. Installation should be no more than a couple of copy-pastes, and most common configuration can be done in just a few lines of TOML.
Consistent. Starship looks and behaves the same, no matter the operating system or underlying shell. For some shells, we’re able to harness powerful built-in features, while on others, we need to include them as part of our adapter logic for those shells. With those gaps filled, folks can confidently copy their Starship dotfiles from system to system without having to worry about the underlying system. It’ll always work.
Context-aware. Starship’s defaults make for a clean prompt that surfaces information you need, when you need it. When navigating the filesystem, you’ll see the prompt grow and shrink to provide contextual information based on the state of your working directory or system state. Enter a JavaScript project and see the Node.js runtime version installed on your system. Enter a read-only directory and see a lock indicator. If your battery dips below 10%, see a red battery gauge appear in your prompt.
What trade-offs have been made in Starship as a consequence of these goals?
Starship’s design has required a few big tradeoffs to allow for our prompt to be accessible and consistent across platforms and shells.
Right from the start, we had users asking when we would introduce async prompts: the ability to have parts of the prompt be shown after the prompt had initially been rendered. At the time, all the most popular shell prompts touted “async” as a powerful feature and a competitive advantage over older synchronous prompts.
Async support in prompts ranges from being pretty darn complicated to outright impossible to implement in some of our supported shells – but that’s not a problem!
Unlike most prompts, Starship, having been written in Rust, computes the prompt across multiple threads, allowing it to render the entire prompt as fast as some async prompts render a partial prompt.
Async isn’t a feature; it’s a means to an end. Another way to build a performant prompt.
Another compromise we’ve had to make has been ease of configuration versus granularity of configuration. The more precise we allow configuration to be, the more complex our configuration and documentation become, making it difficult for users to find the most common prompt tweaks that they’d want to make.
We’ve received requests to add control flow and logical operators to Starship – but rather than bulking up Starship with more and more advanced scripting features, we feel that users would be better off with a full-on scripting language in Starship. We’re currently exploring ways to add Lua or Rhai scripting support, or building a sort of “headless” Starship. By exposing an API of prompt primitives, prompt authors can spend their time thinking about how they want their prompt to look and feel, rather than how their prompt would best retrieve system information or installed tools and runtimes in a platform or shell-agnostic way.
What is your typical approach to debugging issues filed in the Starship repo?
Debugging issues used to require a lot of back-and-forths to get enough context about a user’s system, terminal emulator, shell configuration, and Starship installation. Even with a detailed issue template, users would fill out the parts they thought were relevant, or to the extent they knew how, requiring maintainers to walk them through the process of providing the relevant details.
Eventually, we added a tremendously helpful “starship bug-report” command, which opens the user’s browser and pre-populates a GitHub issue with all the relevant details we’d usually have the user write up for us. Most of the time, the team is able to zero in on the probable cause for an issue right from the initial bug report. If you have Starship installed, run the command and take a look at what we pull up for your system! 😄
Where do you see software development heading next?
I’ve been tumbling deep down the rabbit hole of CRDTs (Conflict-free replicated data types) and collaborative programming. Much in the way that Google Docs overtook Microsoft Word and Figma overtook Sketch for productive real-time collaborative teams, I think we’re still living in the past when it comes to programming.
We take turns writing code and manually handle merge conflicts because code is brittle. Our editors have little understanding of what we’re trying to accomplish when we replace some words with others. Two people changing separate parts of a codebase will still often lead to builds breaking and will require manual intervention to resolve.
I think that the next generation of programming languages will be designed to be built with conflict-free replicated ASTs, requiring the use of projectional editors over finicky text editors. Instead of editing text that converts to an AST, we could be manipulating the AST itself. By having a language that understands the changes the developer intends, we could make it impossible to produce changes that are unable to be merged, allowing developers to collaborate on the same codebase simultaneously.
Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!
Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at console.substack@gmail.com or mention us on Twitter @ConsoleWeekly!