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.
