I'm working on "The Land of Rust", a story-driven book that teaches Rust programming to children (9+) and complete beginners using space adventures with Ferris the Crab.
The goal is to make Rust the first programming language kids fall in love with.
Currently 8 chapters are ready. The first chapters cover Hello World, variables, functions, and ownership with simple metaphors.
Thank you for your feedback! I really appreciate it.
You're absolutely right — visuals are extremely important for children's books. That's one of my next priorities. I'm planning to add illustrations (Ferris the Crab and scene visuals) very soon.
Regarding compensation: this project is currently a passion project and fully open source. My main goal is to make Rust more accessible and fun for kids. If it grows, I might consider a paid version later, but for now I'm happy to keep it free and open.
Would love to hear any other suggestions you have!
Best,
Jafar
I'm sorry for being that guy, but I think that Rust as first language, particularly for a kid, is a lot to take in. I'd start by learning the basics of programming, which is already plenty.
I'm not sure Python has a mascot, but it's a relatively clean and "learning-friendly" language, and there's an interactive interpreter. Since it has a GC memory model, you don't need to learn the extra layers of memory management and, most difficult of all, ownership and lifetimes, which can't be avoided in Rust.
PS: Little nitpick: I also see "composition over inheritance"—it's worth reading "Design Patterns" to see what they truly meant by that; I know these words are often misinterpreted out of context as "composition is better than inheritance".
PS 2: I should've started by that, but I find the idea in general to be great.
I heavily second that. If your goal is teach children programming basics, the basics themselves must be the core focus. Rust goes well beyond the basics, by its design and nature.
What I could imagine Rust being much more suitable for, is teaching kids "how computers work under the hood". Marketed as "become the computer wiz among your class mates" or such. Heavily prefixed with a bunch of friendly warnings along the lines of:
Hey, we're going to learn lots of stuff here. Lots of interesting stuff, and lots of difficult stuff. Some of it is so interesting (and so difficult!) that even the biggest, the smartest, and the most clever among the adults need a bit of time for their "eureka!" moment. You can learn it too! Just don't be afraid, or discouraged, if something seems way too hard or confusing at first. We've been there too! We didn't like being afraid or discouraged either. But it was so worth it!
and then showing a bunch of cool tricks and memory layouts and system calls and whatnot. That way, you'd be teaching them the programming itself, along with the why we program the way we do, along with what is actually going on behind the hood when we tell the machine to do this or that, along with why Rust the language in particular is such a good tool for us to do just that.
In deed it does. That does not mean one could not just stick to some basics during an introduction to programming for youngsters. One does not have to dump all of it on them at once.
After all, mathematics goes well beyond integers, counting and arithmetic. But we start kids off with that.
No, maybe it's possible to introduce references as late as possible, but it's not possible to wait for very long before they become indispensable. Here, those topics are already in chapter 4.
I think the risk is that the complexity of Rust discourages a kid reading a book like this. Another more beginner-friendly language could be used for a first book (I think that interactivity is also important at that stage), and maybe something like this for a more advanced exploration. Let's say one or two birthdays later.
The text is also full of telltale icons and formatting: it looks awfully like it's been written by an LLM. I think kids shouldn't be exposed to that so early, not before they have a solid sense of criticism...
Instead you learn bad habits that plague you forever. The only reason people have trouble with ownership and lifetimes is lack of support for these concepts in most languages. Once upon time people were saying that while loops and functions are problematic concepts and are “hard to learn” — yet today it's hard to find a single beginner's tutorial that doesn't teach these. Even arguments where similar: “I betcha can't structure this” is not dissimilar from “how can you make lifetimes work in this or that idiom, that I like”.
Ownership and lifetimes may be tricky to deal with, in some advanced cases, but basics are trvial to teach, particularly for a kid: owner is the one who puts toys away, lifetime is period of time where you can use someone's else toys. And… that's it. More advanced ownership can also be discussed with “real world” metaphors: two or even ten kinds may borrow your tablet and watch the movies, if they don't touch the controls, but if they want to rewatch the episode then they need to establish some kind of order to prevent tears.
And so on. We already had that discussion: two main reason why people perceive ownership and lifetimes hard concepts to learn are the fact that other languages don't have them and also the fact that official book (and many other books) try to teach you simple concepts (ownership and borrow) using really complicated knowledge about how they are implemented.
I would argue that good Rust book should do things in the opposite order: it would teach you ownership and lifetime using “real world” metaphors — and then, when you know these, you may introduce stack and heap as a mere implementation details that make ownership and lifetimes possible.
I would not delay introducing references for too long. That does not mean getting into a discussion of stack, heap etc. That is implementation detail. Rather I would imagine some analogies more targeted at the youngster. It's not so conceptually hard to describe that a thing (variable) lives inside a function and does not exist outside of it. And therefore a reference to that thing is likely not valid after that function has returned. It's not so conceptually hard then to talk of creating longer lived items, in a Box, that will exist as long as something has a handle on it. And so on.
Kids coming in unburdened with C, what "references"? You ment to say the short term and long term borrows...?
(Feel free to discard as rant/unsupported, am currently lazy to look back for sources)
I believe i've read on some unrelated search that 9yo typically do not have al the "brain parts" grown / mechanisms managed yet that are required for programming details per se - elision, deduction, systematic separation and/or sequencing of process etc.
Not really. You claimed that one had to "unlearn" bad habits, which is why it's hard for experienced people to learn Rust. But it's not a popular opinion, simple because it's not how it works: ownership, borrowing rules and lifetimes are indeed additional concepts to learn that add to the rest, not something that had to be subtracted from the rest.
They might appear as simple concepts, but they have heavy and complex consequences, no matter how they're explained. It requires an additional level of thinking above the other concepts.
The best way for someone to learn is to proceed step by step. Let's not forget that we choose a programming language to answer a need, not because others have said it was cool. The needs of children who might take to programming are very different from the needs of programmers that must build a safe and performant system-level application.
Thanks @Redglyph! ,totally get your point—Rust's definitely not the easiest first language. The book's more about sparking curiosity than teaching every Rust detail, though. And good catch on the composition note, I'll clarify that! Appreciate the feedback
Thanks @marlez! This actually came from workshops I ran with 400-500 kids aged 7-11. It's just v1, and I'm counting on feedback like yours to help shape it into something that really works for younger learners. You're right—9-10 year-olds already know their way around a computer, so the goal is to build on that without overwhelming them. Appreciate it!
Nah what? By that argument it would seem. 9 year olds do not have the "brain parts" required for learning maths. Yet at that age we have generally taught them quite a lot of it. Or at leat it was so back in my day.
Also, so what if they don't have the brain parts? From about that age I was building electronic things, wiring up microphones, head phones and batteries, soon using transistors to build circuits from a kids electronics kit. I remember not having the "brain parts" to understand much about what I was doing, those circuit diagrams were unfathomable to me. That does not mean I did not have fun tweaking and experimenting with that stuff, and a lot of frustration when things did not go as guessed they might. Lack of brain parts did not mean I did not learn something and presumably help grow those missing parts
I can't believe kids are any less curious or more stupid than I ever was.
Thanks @ZiCog! Love the electronics kit story—that's exactly the spirit. This book actually came from workshops with 400-500 kids aged 7-11. It's just v1, and I'm counting on feedback like yours to help shape it into something that really works for younger learners. You're right: curiosity and tinkering come first, understanding follows. And yeah, 9-10 year-olds already know their way around a screen—we're just building on that. Appreciate the perspective!
Thanks everyone for the awesome feedback so far! @khimru@Redglyph
Just a quick note: once the remaining 10 chapters are translated to English, I'll be revising the whole book based on your suggestions. Also planning to turn each chapter into a small game—so the concepts stick better for kids.
If you've got thoughts on any chapter, feel free to drop me an email at jgh.rust@gmail.com or just open an issue/PR on the repo. Every bit helps!
. A father .
