Also dear friends @RustyJoeM @sermuns
Oh, yes, absolutely. But here's the thing: ownership and borrow are simpler concepts that “arbitrary graph of objects that may reference each other”.
By your own rule they should be learned first.
It's precisely and exactly how it works.
Additional concepts don't necessarily make things hard to learn and use. Indeed typical high-level language have a lot of concepts that machine code doesn't have… and yet programming in machine code is not something people teach to a kids.
Ownership and borrow is much simpler model than “spaghetty of pointers” that most modern languages use.
Yes, it's not a capable — but it's simpler. And safer (when it works).
You certainly could: yet if you're planning to stick the basics (only) regardless, why use Rust to begin with? Either JS, or Python, or Ruby, or Scratch; are much more suitable for showing children "hey, let's a have box for humbers, let's put a number in it, let's print it out; isn't it fun?"
By the time your kid has written their first
fn main() {
let n = 42;
println!("Hello, world! Here's my number: {n}");
}
he's already going to wonder:
- what's
main? - why not
println!("My number is:", n)? - why is there an
!in betweenprintlnand("...")?
Compare that to Python:
n = 42;
print("hello", n) // `hello 12`
Exactly my point. You don't introduce mathematics by showing children partial differential equations, deliberately trivial and/or simplified as they must be.
Good luck with your book.
Apologies for my initial rather shallow on the go comment. Now i've found that school curriculums for my country indeed include even intro to logic & related stuff for that age.
I had one of those "I've read some well-funded looking things i dont recall in detail, but want to discuss" on the go moments... It must have been related to more abstract concepts that indeed are not a deal breaker for beginner stuff kids can manage.
I'm happy to see you're doing this, good luck! I don't really know whether ownership and borrowing can be taught to a 9 year old, but I really think it is worth trying, as an experiment at least. There are arguments (made by others in this discussion) that it should be possible, and we'll never know for sure unless someone tries it.
Thanks @RustyJoeM No worries at all—these discussions are exactly how things get clearer 
Yeah, curricula vary a lot, but you're right: kids can handle more than we sometimes assume.
Thanks! @jumpnbrownweasel Yeah, it's definitely a bit of a gamble haha. I'm not expecting kids to master the borrow checker after reading it, but figured if I can make the concepts feel less intimidating through stories, that's a win.
And , im here to test this 
I think the important thing is not to explain how borrow checker works, but to normalize complexity. Explain that compiler wants to know who would put toys away - and sometimes deciding that is hard, if there are many toys and many kinds who exchange them involved and they couldn't know in advance who would return back from the trip to the cinema first or last. This should help with understanding that borrow checker may not always be right, even if it tries very hard to understand explanations that are added to the rust program - but, more importantly, it's not always easy to answer the question about who is responsible, just like in real life.
A benefit of Rust is that it's really full stack in fact. Whatever kind of application you decide to write - a server, or a graphical app, or a bulk file processor, etc - you can build it in Rust without switching to another language.
That reminded me of crate differences. You could say it's akin to differences between watercolor, acrylic paint, or colored ink; each can create a painting, with different look-and-feel and different effort of making it.
This is such a good point—thanks for sharing it. 
I totally agree: the goal isn't to make kids "solve" the borrow checker, but to help them feel okay with the fact that some questions are genuinely tricky. I love your "who puts the toys away" metaphor—it's simple, relatable, and captures the spirit of ownership without getting technical.
I've actually tried to weave that mindset into a few chapters (e.g., when two characters want to borrow the same thing), but your framing is way cleaner. Mind if I borrow this idea for the next revision? 
Really appreciate you taking the time to think this through.
You probably can, but it wouldn't be my first choice for some applications, like anything GUI, quick prototyping, or (interactive) scientific calculus. Rust is more comfortable and more relevant for system programming projects.
You could say the same about versatility for other languages, too.
Maybe , But for a newbie that just know Rust , Full-Stack is winner.
The point is, there are easier, general-purpose (what you call "full stack") languages for someone who learns, and they're actually better at some of those things. Also, it's not really an important criterion when you're learning your first language.
For example, learning Python first isn't a silly idea:
- there's an interpreter, so you can learn in a REPL environment (like IDLE, which comes with the default installation)
- it's relatively worry-free when it comes to memory management (no manual allocation, no borrow checker)
- clear and powerful syntax
- always useful as a tool later; e.g. in scripts for data/file manipulation, quick prototypes, ...
- comes with a large library
- there are many good books and other resources to learn the language
On the negative side, it's not statically typed. There are other examples, of course.
While there are many good things to be said about Python, I think starting someone off on a duck typing language is likely to teach bad practices. I grant, that is opinion and maybe even prejudice, not fact.
Hey everyone,
Just wanted to drop a quick update since this thread has been incredibly helpful.
I've been reading through all your comments and I'm genuinely blown away by the thoughtful feedback. A few key themes kept coming up, and I wanted to share how I'm incorporating them into a rewrite of the first 10 chapters:
What's changing:
• Normalizing complexity over explaining mechanics: Instead of trying to make kids "solve" the borrow checker, I'm adding little "Sometimes it's hard!" moments that validate confusion—both in code and in life. (Shoutout to the comment about "who puts the toys away"—that framing is gold, and I'm weaving it in.)
• One consistent metaphor world: The whole book now lives in "Toy Town," where characters share, borrow, and return toys. Ownership = "who's responsible for putting this away," borrowing = "can I look at your toy for a sec?" etc.
• More interactive, visual exercises: Short, picture-based activities at the end of each chapter (no typing required). Think: "Circle who's responsible for this toy!" or "Why is the borrow-checker-nag worried here?"
• Parent/educator notes: Small sidebars with a plain-English explanation of the actual Rust concept, plus a link to the official book for grown-ups who want to go deeper.
What's not changing:
• The goal is still intuition, not expertise. If a kid finishes a chapter and thinks "Oh, that's why Rust complains about two people holding the same toy," that's a win.
• Raw, story-first tone. No jargon dumps. If a metaphor doesn't feel like something you'd say while playing with a kid, it's out.
I'm aiming to have the rewritten chapters up in the repo by this week. If you're curious to peek at the work-in-progress or want to toss in metaphor ideas, the links are in the OP.
Thanks again for making this feel less like shouting into the void and more like building something together. Seriously—your input is shaping this in ways I couldn't have done alone. 
P.S. If you're a parent, teacher, or just someone who's tried explaining Rust to a young learner: what's the one concept you wish had a better story? Drop it below or in the Discussion—I'm all ears.
jgh.rust@gmail.com also can mail me
Perhaps. That being said, no language is perfect.
Besides, good practices is not something a language can teach you, no matter how restrictive (and unfriendly). That's why it's interesting to have a language with a good choice of quality learning resources.
@huvaxstra, you tagged my last post as answer to your question, but I didn't give you any element of answer as per your conclusion, so I think you meant to tag someone else's post. 
Maybe I am strange. I am not saying I am a "GOOD" programmer. I have never been professional. Just program for myself. I am old now.
Back when I was just a child, I picked up my dads fortran book. He was taking a class to maybe change his career. He didn't seem too interested. I however read the book and was making programs to graph "*" astrix as a sin wave with spaces. I didn't even have a computer and did my own step through debugging on graph paper. Maybe nine or ten. Of course I gave up. Fortran was confusing. After that I did my math stuff by hand, looping etc with just flowcharts. I didn't have a text language to "help me think". Then maybe 13 or so I somehow enrolled myself in a class, when I showed up the teacher said it was for adults only. I had my paperwork so he gave me the first day as a chance. I had no problem picking up "Basic", scanned the book in class and was "good enough" by the end of the class that he let me stay. In that class I actually could touch a computer and enter my progams and get them to run, slowly. Not just do it in my head on paper. When I was about 15 or 16 I found K&R's book in a library and shifted to C but didn't have access to a computer or "c" compiler for a couple of years till I got to Junior College.
Anyway, I am not so smart. I was just lucky that I had access and interest to learning material at a young age. The simple concepts of programming are simple. A kid can do it if they are interested. If they are told to do it, that is another story. Of course the hard parts are hard and almost nobody, even those with degrees, have it all figured out. (Maybe Knuth)
Dark corners are fractal
There are huge differentce between 9 and 13 years. There are also pretty large individual variance, sure, but programming is typically understandable for 12-13 years old and not by 9-10 years old.