The Tech Doesn't Matter

Always focus on goals first. Technology is only the tool that we use to achieve them. — Dave Farley

The problem you’re trying to solve, your goal, is what’s important. The tech simply isn’t important so long as you can get it to do what you want. Very few of your users are going to care what JavaScript framework you’re using. You can write a backend in TypeScript. You can write a frontend in Rust. You can design around your favorite language’s cold start times. You can performance tune a garbage collector.

Shut Up And… Build

My good friend, the same friend who previously suggested I use WordPress for this site, couldn’t care less about picking programming languages. His one metric is what’s the easiest for him to get things done with. He just wants to “build things.” (I recently happened across this blog post discussing the fact your tech stack is not your product. I’d say Mike Wakerly and my friend would agree on most everything in that piece.) He’s right… Truly. I know he’s right. I see it with a clarity that is painful, and yet…

This Vs That

I am an incurable optimizer. I am always looking for some mythical “best” solution. Good isn’t good enough. I want to have the best solution. Since best in many of these technical arguments is largely subjective, I am often reminded of the concept of a Pareto-optimal solution. I try to come up with a set of agents representing the criteria I would grade the technology on. For example, if I’m discussing an optimal programming language, I might look to optimize my legibility of the syntax, developer tooling/experience, community support, performance, and enforced correctness.

(Truth be told, I’m probably misunderstanding Pareto efficiency. Feel free to reach out on Twitter to show me the error of my ways.)

I agonize over these kinds of decisions. For example, right now I’m constantly debating between going deeper in to Rust or TypeScript. JavaScript fails for me on enforced correctness, so TypeScript takes its place as the top competitor in terms of community support. Rust takes the cake for enforced correctness but that legibility… To be clear there are languages that might exceed Rust in enforcing correctness, but, as with JavaScript, they fail be on the Pareto front. I long for that correctness, but I struggle with accepting that syntax, that steep learning curve.

This is not going to be a Rust vs TypeScript post, but let’s look at it just a little bit.

Rust

I very much enjoy ThePrimeagen, and I’ve heard others besides argue the Rust learning curve is overblown or quickly overcome with time on task. I’ve heard arguments it’ll be overcome by the long-term maintenance issues you don’t experience. Maybe all that is true.

TypeScript

Lex Fridman has posited JavaScript will “win.” I can’t disagree, but I also can’t go be a happy JavaScript developer. I feel JavaScript makes it too easy to write horrible code. Sure, you can write horrible code in any language, but JavaScript makes it easy. So… let’s talk a little about TypeScript. TypeScript adds some guardrails to JavaScript. I like that. And you want a framework? What color do you want that in? The syntax is also far more legible than Rust. (Yes, all of my measures have been subjective. Yes, one could very reasonably argue the smaller number of frameworks (or not using any) would be better than there being a new one every 42 seconds.)

Okay, I promised this wouldn’t be anything approaching a real Rust vs TypeScript post, so let’s leave it at that.

Guess What

The tech doesn’t matter, unless it matters to you. If it matters to you Rust helps to ensure correctness, use it. If you like the myriad frameworks and choices of TypeScript, use it. If it really matters to you, make a choice. Just try not be like me. Try to avoid paralysis by analysis. It doesn’t help you solve problems or achieve your goals.