Exercise 2: Why Ruby Compares to Python, Not a Unique Rails Story — Possible Solution
====================================================================

WHY RUBY HAS NO substr()-VS-mb_substr()-STYLE SPLIT
------------------------------
Per this chapter, Ruby's String class carries its own encoding metadata and every core string method - length, [], slice, each_char - operates on characters in that encoding rather than on raw bytes. There's no separate byte-oriented string function family in Ruby that could accidentally be reached for instead of a safe one, because the default behavior is already character-safe.

WHY THIS CHAPTER COMPARES RUBY TO PYTHON RATHER THAN TREATING IT AS UNIQUELY RAILS-SPECIFIC
------------------------------
Per this chapter, Python 3's own str type is Unicode-code-point-aware by design, the exact same underlying reason Django's own Chapter 7 never needed to discuss string-slicing safety at all. Since Ruby and Python 3 share this same design choice, framing Ruby's safety as a uniquely Rails-specific finding would be inaccurate - it's really a language-level trait Ruby shares with Python, genuinely different from PHP's own raw-byte string behavior, which is what actually created a real risk for the Laravel rebuild course specifically.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that Ruby's core string methods are character-aware by design, and correctly explains why this chapter frames the finding as a similarity to Python rather than a unique Rails achievement, since Python 3 shares the identical underlying design trait.