Last year I had to pick up Go for work. I'd been writing TypeScript and Python for years, so I assumed it would take a weekend. I watched a four-hour course at 1.5x speed, nodded along, and opened my editor on Monday.
I couldn't remember how to declare a map.
I'd seen it. Probably twice. But watching someone type make(map[string]int) isn't the same as reaching for it yourself with a ticket open and a standup in 20 minutes. It took me about three weeks to feel normal in Go, and most of that time went to relearning things I'd already "covered."
The second time I had to switch languages (Rust, for a side project), I did it differently. Here's what changed.
You aren't learning programming again
When you already know one language well, a new one is mostly a translation job. You know what a loop is, what a closure is, why you'd want a hash map. What you don't know is how this language spells those things, and which of your habits it's going to punish.
So I stopped starting with "Chapter 1: Variables." I started with a list of things I do every day in my main language and wrote down how to do each one in the new one:
- read a file and parse JSON
- make an HTTP request and handle the error
- define a type with a couple of methods
- map, filter and group a list
- write and run a test
- add a dependency
That's maybe 15 small snippets. For Rust it took one evening with the official Rust book and Rust by Example open side by side. For Go, Go by Example covers almost the whole list on its own, and I wish I'd found it before the four-hour course.
Hunt for the things that feel wrong
The translation list gets you writing code. The part that actually slows you down is the stuff with no equivalent in your old language. In Go it was error handling with if err != nil everywhere, and the way interfaces are satisfied implicitly. In Rust it was the borrow checker, which I fought for a good week.
I kept a separate note just for these. Every time the compiler yelled at me, or something behaved differently from what my TypeScript brain expected, I wrote one line: what I tried, what happened, and the fix. After two weeks that note was the most useful thing I owned. It was basically a personalised guide to my own bad habits.
Build something small and slightly annoying
Tutorials are designed so nothing goes wrong. Real projects aren't. Pick a thing you've built before in your main language, so the problem is familiar and only the language is new. A CLI that hits an API and writes a CSV is about right. Mine was a little tool that pulled my GitHub stars and tagged them by language.
Because I already knew what the finished thing should do, every bit of friction was a language lesson rather than a design problem. That's the fastest feedback loop I've found.
Close the video and write it from memory
This is the habit that made the biggest difference, and I resisted it for ages because it feels slow.
After watching a section of a course or reading a chapter, I'd close it and write the example again from scratch. No peeking. Usually I'd get 70% of the way and stall on some detail, like how Rust's match handles a Result, or where Go wants the receiver in a method. Then I'd look up only that piece.
Recognising code when you see it is easy. Producing it on a blank screen is the actual skill, and you only build it by practising the producing part.
Review before you forget, not after
My Go mistake was learning everything in week one and never looking at it again. By week three, the stuff I'd used daily was fine, and everything else had evaporated.
Spaced repetition fixes this, and you don't need anything fancy. Look at an idea a day after you learn it, then a few days later, then a week, then a couple of weeks. Each review takes seconds because you almost remember it. If you're curious how the scheduling math works under the hood, I wrote up an SM-2 implementation in JavaScript a while back.
For a language, a "review" is just: look at the title of a snippet ("Rust: read a file into a string"), try to write it, then check. Got it? Push it further out. Didn't? It comes back tomorrow.
Where Recl fits in
My Rust learning material was scattered everywhere. Chapters of the book, a couple of long YouTube talks, conference clips, a few blog posts on lifetimes, and some genuinely good short videos people posted on Instagram and X. Keeping a review schedule for all of that by hand fell apart quickly.
That's a lot of why I built Recl. You save a video, article, reel or podcast from your phone's share sheet or the Chrome extension, and it writes a summary of the key ideas (with timestamps for videos) and files it under a topic. Then it brings those ideas back to you 1, 3, 7, 14, 30 and 60 days after you saved them, so the reviews happen without you having to track them.
Two things helped specifically with learning a language. Timestamps meant I could jump straight to the ten minutes of a long talk that explained lifetimes, instead of scrubbing through an hour. And Ask lets you query your own saves, so "what did I save about Rust error handling?" pulls up the relevant videos and posts with sources.
It won't write the code for you. You still have to close the tab and type it out. Recl just makes sure you come back to it before it's gone.
The short version
When I compare the two switches, Go took about three weeks to feel comfortable, mostly spent relearning. Rust is a harder language, and it felt workable sooner, because I stopped consuming and started recalling.
Translate what you already know. Write down what surprises you. Build one small real thing. Rewrite examples from memory. Then come back to them on a schedule, because the snippet you learned on day two is exactly the one you'll need on day twenty.
I'm Spartan Rich, and I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, sorts them into topics, and uses spaced repetition so you remember what you learned.
Top comments (0)