Ruby has a beautiful and dangerous relationship with its data structures. Beautiful because Array and Hash are so good, so ergonomic, so well-designed that you can build almost anything with just those two. Dangerous because that ergonomics hides what's actually happening. When you call array.include?(x), Ruby walks the entire array. O(n). When you call hash[key], Ruby computes a hash, finds a bucket, handles collisions. O(1) amortized. You've been making algorithmic decisions every time you chose between an Array and a Hash, you just didn't have the vocabulary.
This module pulls back the curtain. You'll learn that a Ruby Array is a dynamic array — it allocates extra memory, doubles in size when full, copies elements on resize. You'll learn that a Ruby Hash is an open-addressing hash table (since Ruby 2.4) with a specific collision resolution strategy. You'll learn that Set in Ruby is literally just a Hash where the values are true. None of this changes how you use Ruby. All of it changes how you think about what Ruby is doing when you use it.
The linked list section will feel academic, and honestly, it partly is. You'll almost never use a linked list in production Ruby code. But linked lists teach you something arrays can't: pointer-based thinking. The idea that data doesn't have to live in contiguous memory, that nodes can point to other nodes, that you can restructure a data layout by changing references instead of moving data — this is the conceptual foundation for trees, graphs, and every complex data structure that follows. Linked lists are training wheels for your brain. Respect them even when they feel trivial.
Conclusion #
By the end of this module, you'll look at Ruby's standard library differently. Not with suspicion, but with understanding. You'll know why Array#push is O(1) amortized but Array#unshift is O(n). You'll know why Hash lookups are fast and why order preservation was a big deal when Ruby added it. You'll stop treating data structures as black boxes and start treating them as engineering decisions with tradeoffs. That shift in perspective is worth more than any specific implementation you write here.
Predictions #
-
The moment you understand how a hash table actually works — hashing, buckets, collision resolution — will feel like finding out how a magic trick is done. Impressive in a different way.
-
Stacks and queues will feel too simple. Then you'll hit a problem that's trivially solvable with a stack and impossible without one, and you'll get it.
-
You'll start noticing data structure choices in Rails source code. ActionDispatch uses stacks. ActiveRecord query building uses trees. Once you see it, you can't unsee it.