Talks
Ruby: The Challenges Ahead
Summarized using AI

Ruby: The Challenges Ahead

by Yehuda Katz

In this presentation titled "Ruby: The Challenges Ahead," Yehuda Katz addresses the current state and future direction of the Ruby programming language, drawing insights largely from its experiences alongside the Rails framework.

The talk begins with Katz discussing the increasing recognition Ruby has gained, primarily through its association with Rails. He emphasizes the need for Ruby to evolve beyond just being a tool for creating HTTP clients and testing libraries, advocating for a comprehensive development of the language that elevates it to a prominent status for serious project creation. Katz references Zed Shaw's view that Rails has somewhat hindered Ruby's broader potential and calls for a forward-thinking approach.

Key points from the discussion include:
- Evolution of Ruby's Use: Ruby has transitioned from primarily web development focus since the rise of Rails in 2004 to being employed in more complex applications, evidenced by tools like Chef.
- Concerns About Performance: Katz highlights performance issues faced by Ruby, particularly in high-performance environments. He insists that overlooking features like streaming support might lead to limitations for developers.
- Community Rationalization: The community often justifies the incomplete status of Ruby's libraries using the 80/20 rule, which needs reevaluation as more implementations emerge and Ruby broadens its application scope.
- Role of the Standard Library: The standard library is crucial for supporting various libraries, even if it is often criticized. Katz argues for its completeness over aesthetics, asserting stability in well-established libraries.
- Threading Challenges: Many Ruby libraries neglect proper threading mechanisms, which leads to complications in concurrent scenarios. Katz stresses the importance of libraries supporting robust threading to enhance performance.
- Library Maintenance: Katz calls for a commitment to maintaining existing libraries instead of creating redundant ones, arguing that this approach is vital for community success.
- Adopting Composition Over Inheritance: He encourages using composition as a robust design method to avoid fragility within code caused by improper inheritance practices.

Katz concludes that while the 80/20 rule has its benefits, it is essential for the Ruby community to focus on completing the remaining 20 percent of its library ecosystem. He urges his fellow developers to direct their efforts towards refining and expanding Ruby's offerings to ensure its growth and sustainability.

Overall, the presentation serves as a call to action for the Ruby community to prioritize the development of robust, complete libraries and frameworks that enhance Ruby's utility beyond its current capabilities.

00:00:21.039 So, I'm going to be talking about a combination of down-to-earth and high-level concepts, and hopefully that will resonate with everyone here.
00:00:26.080 What I really want to discuss today is the current state of Ruby and where I see it needing to go. We are at a critical point in Ruby's development.
00:00:41.040 Ruby has received a lot of recognition, particularly through Rails. However, I feel as if we've reached a point where it's no longer sufficient to just keep creating more HTTP clients or writing yet another testing library.
00:00:52.719 I believe we are outgrowing that phase, and we need to shift our focus towards completeness and fully developing the language. If we fail to do that, Ruby risks becoming just a scripting language used to interact with the JVM or C, where serious software development is not the primary focus.
00:01:18.400 In my opinion, it matters a great deal to elevate Ruby to the status of a language that people use to create significant projects.
00:01:36.240 I partially agree with what Zed said, that Rails has somewhat held the language back. So, today, I want to discuss how I see Ruby progressing alongside Rails.
00:01:42.159 I see two key forces at play. On one hand, JRuby's popularity provides us the opportunity to exist as a scripting language on the JVM, but I don't want that to be our sole identity.
00:02:06.479 I want to highlight some important aspects of Ruby's development. While I could spend the entire talk on this, I'll just touch on a few major points. Ruby was developed over several years, largely by a community in Japan and later expanded globally, leading to the creation of a standard library.
00:02:29.200 When Rails emerged in 2004, it dominated the Ruby landscape, focusing primarily on web development and the 80/20 productivity rule. A lot of libraries developed during this period were indeed excellent, but as we entered 2009, we started seeing Ruby used in more serious applications like Chef.
00:02:54.480 What started happening was that people began to notice performance deficiencies, especially when trying to develop high-performance web servers. Many developers claim that it's not a big deal, but those who do care are the ones building software that will end up impacting many others.
00:03:08.160 For instance, if someone says that streaming support is not necessary, it implies that a handful of developers might miss implementing crucial features. This was brought to light when Wes worked on the HTTP library since the existing one was inadequate.
00:03:25.920 There's a prevalent issue within the Ruby community, where we often rationalize the lack of completeness by adhering to the 80/20 rule. I categorize our evolution into four phases, but it's unclear where we're heading with this growing-up phase. However, there's been a noticeable shift in the way we communicate about Ruby in recent years.
00:03:44.480 As more implementations gain traction and Ruby is being utilized for more than just web-based applications, establishing what constitutes the '80 percent' becomes challenging.
00:04:05.600 Regarding the standard library, it serves as a foundational element for many libraries. Despite its criticisms, it is essential. If you examine a dependency graph of Ruby, you'll find that most popular libraries rely on it in some way.
00:04:20.480 When people argue that certain standard libraries are obsolete, it's often merely due to preference over API design, rather than performance or capability. The main goal of the standard library isn't to provide the most aesthetically pleasing APIs, but to be comprehensive. Even though it doesn't always deliver perfection, the primary goal is completeness.
00:04:57.560 Take libraries like Net::HTTP or REXML, for example; despite being at times slow, they are robustly designed. A significant concern, however, is that many libraries created during the Rails era neglect the complexities of threading scenarios.
00:05:14.800 Given that most Ruby web servers do not offer effective thread support—aside from JRuby servers—in many configurations, one might enable threading in a Rails app on Passenger, but they miss out on true multi-threaded behavior.
00:05:35.200 The Unicorn and Passenger advocates might claim that this isn't an issue, but the absence of viable alternatives for MRI with thread support limits developers' ability to assess whether threading would benefit their applications.
00:06:03.119 Additionally, the early years of Ruby's standard library development considered various scenarios effectively, unlike many libraries built today, which often ignore threading.
00:06:14.800 The landscape poses real challenges, particularly for developers trying to build robust protocols. For example, some argue that if a library hasn't seen recent updates, it might be outdated. I hold the opposite view: an unupdated library may indicate stability.
00:06:34.040 Often, the libraries that were created prior to the widespread adoption of idiomatic Ruby may house much of the code we still value today. It's worth noting that Ruby's early protocols were unique and were built using conventions from a decade ago.
00:06:49.520 In my view, well-crafted implementations of established protocols are more valuable than continually updated, but less robust, libraries.
00:07:14.560 This leads us to questions about the stagnation of the standard library. There have been discussions about cleaning up the Ruby ecosystem, and while some paths offer greater potential for improvement, it is essential to evaluate the value we carry from previous libraries. Old doesn’t mean ineffective.
00:07:32.920 We can't expect rapid changes in libraries that are fundamentally reliable, as their stability is essential for broader usage. I believe it is critically important to focus on robustness.
00:07:49.360 Next, I'd like to discuss Rails—specifically its place as a kind of standard library. Rails itself tends to follow sound principles, making it robust and comprehensive in design.
00:08:06.240 Yet, Rails also harbors quirks driven by necessity, with specific code behavior that might perplex developers falling into their use. These eccentricities do serve a purpose; for example, Rails handles ETags uniquely yet securely in ways that prevent vulnerabilities.
00:08:24.560 Rails successfully addresses numerous challenges within the ecosystem, but its gems frequently stray from the robustness seen in the Rails core. Consequently, gems often lack the same stability as Rails itself.
00:08:41.080 While Rails gems should be robust in scope, some instead perform only narrowly defined tasks, which can be valid, but don't contribute to the same overarching quality.
00:09:00.080 Collaborative development among Ruby community members often leads to the 'many solutions for the same problem' scenario, where libraries provide minimal value apart from solving the most basic needs.
00:09:16.000 An expectation of high library churn can indicate a healthy ecosystem, especially for plugins. But if there’s over-reliance on single-threaded operation for libraries within Rails—originally a model for 80/20 rule—that causes issues when performance needs began to escalate.
00:09:34.560 When we utilize libraries in scenarios involving concurrent requests, such as simultaneously making HTTP calls, the absence of strong threading support becomes more pronounced.
00:09:54.240 Many libraries have ignored threading implications, resulting in severe complications down the line.
00:10:11.120 A concerning trend manifests when developers rely too heavily on simplistic solutions, often through their creative exploitation of Ruby's dynamic properties.
00:10:30.080 This repeated tendency can lead to unsustainable code patterns, especially when extensibility does not factor in a broader framework of development.
00:10:47.040 To illustrate my point, let me provide a quick example of a common issue developers encounter when bypassing SSL certificate verification in code.
00:11:01.680 This practice prompts issues since users are instructed to manipulate Ruby's constants improperly. Instead, solutions should acknowledge the need for secure verification and seek proper implementation.
00:11:21.040 On the same note, we often see reckless usage of threading techniques. For example, reusing sockets improperly can lead to network handle corruption when making simultaneous requests in Ruby.
00:11:34.720 Such patterns highlight the importance of understanding Ruby's threading mechanics and why using thread-local storage incorrectly can create substantial risks of conflicts.
00:12:00.160 Many languages utilize pools rather than trying to implement threading patterns in complex ways, evident through server architectures like connection pools used in Rails.
00:12:17.520 Coding patterns meant to optimize socket usage don’t provide a resolution. I encourage writing libraries that employ pooling techniques to avoid common threading problems.
00:12:31.440 There’s a wider issue at stake with inheritance overcomposition. While inheriting for functionality's sake might seem attractive, it often leads to fragility in code.
00:12:47.880 Fragile base class problems arise when superclass methods fail to account for their subclasses adequately, causing breakdowns as new methods get added in future Ruby versions.
00:12:59.840 One resolution is leveraging composition rather than inheritance, providing clean interfaces that help mitigate fragility in library design.
00:13:16.640 Regularly, we'll encounter various limitations within the Ruby ecosystem; however, through concerted efforts, we can improve upon established library behaviors.
00:13:34.080 For many developers, this discussion centers on finishing incomplete libraries. Creating new libraries without adequate assessment versus existing solutions falls into nihilism.
00:13:55.760 To move away from this, we must commit to maintaining libraries, avoiding running into dead ends or duplicative efforts across the community.
00:14:13.600 As a community, we must share in development efforts and do our best to streamline protocol designs striving to involve strong collaboration.
00:14:29.680 We currently face the choice between expanding slow VMs with faster C extensions or fast VMs with a more constrained environment. This directly affects our programming model.
00:14:49.680 To sum up, while the 80/20 rule certainly has its merits in terms of enhancing productivity, it is crucial to bring the ecosystem up to speed on completing the final 20 percent.
00:15:05.679 It’s time for Ruby to complete its depth of library offerings while refining its operational philosophies to ensure sustained growth moving forward.
Explore all talks recorded at MountainWest RubyConf 2011
+14