00:00:11.920
So, how many people here have seen DHHS's vlog in 15 minutes? You know, the screencast about starting a blog? Yeah, a lot of you! That was my first introduction to Ruby. I watched this video, and you know, I had been doing PHP and Perl and kind of all these other things. It felt like doing anything in those languages was just a lot of work, and there was a lot of duplication whenever I wanted to start something new. The idea that you could move quickly, that you could get started with something and just be off the ground without having to write any boilerplate, that was just amazing to me.
00:00:36.800
When I think about Ruby, I think about how it lets you move quickly, gets you up and running, and that’s really important. When you think about what Stripe is—right? We’re a payment API, and a lot of what we consider is how to make it possible for people to get started without very much work. Ultimately, that's how you get people into your community. As developers, we constantly see all this new technology and change, and if anything has a barrier to entry or requires work to get started, you're just not going to do it.
00:01:11.120
Unfortunately, over the years, I’ve watched as Ruby has had this great community behind it, filled with excited people, but that niche—the set of things that Ruby is really good for—has not been growing. In fact, it’s really shrinking. A good example to illustrate this is the choice we had back when Stripe was being started: we could choose between Python and Ruby. It felt like a rather arbitrary decision at the time, but Python seemed better at systems engineering, while Ruby felt better for web development. Both seemed to be on a trajectory towards immense popularity.
00:01:49.680
It’s hard to know which language to pick, and when you choose a language as a company, you’re making a bet on where you think it will be in five years. It’s not just about where it is now; it’s about where the best tools and best practices will be. Over the past few years, Python has really closed the gap. A lot of awesome web libraries have emerged in Python, and we’re seeing a similar story in Go. The way things used to work was that you could write a lot of code in Ruby. It’s fun to write because it’s easy, and you can get your business logic out. However, at some point, you may find yourself struggling to get Ruby to run fast, so you end up rewriting in C++ or a lower-level language.
00:02:33.920
Because C++ can be pretty miserable to write, you tend to put that off for as long as possible. With Go, it’s no longer painful. It may not be as productive as a higher-level language for most applications at the initial stage, but the size at which it finally makes sense to rewrite in a lower-level language is decreasing constantly. Similarly, if you’re doing pure web stuff, a lot of the new and innovative developments are happening with Node.js. You think about things like Meteor—while it’s not clear if Meteor will become the next Rails, it’s where a lot of the innovation is happening.
00:03:05.760
Here’s a graph that I found on modulecounts.com showing the number of Ruby gems, represented by the blue line, compared to the number of packages on npm, which is Node.js’s package manager. As you can see, there are still a lot more Ruby gems out there. We maintain our market share simply because we’ve been around for so long and have many contributors, but Node.js is rapidly growing. Pretty soon, we will hit that crossover point.
00:03:41.040
This is something we should all be thinking about and worrying about as members of the Ruby community. When people talk about improving Ruby, they generally focus on speeding up the interpreter or trying to increase efficiency, but I think they’re missing a broader point. In reality, there’s a small set of people who actually influence how the interpreter evolves, but everyone in this room has the power to influence the community itself. The community represents the collective action that we all take, so we all have a responsibility to consider what we can do to reverse this trend.
00:04:15.919
We should aim to grow the areas where Ruby is used and ensure we remain relevant in five to ten years. If you consider Perl, it serves as a cautionary tale. At one point, Perl ran about half the internet, but then it stagnated. Part of the problem was with Perl 6, a language that still hasn’t launched, while new languages like PHP emerged and began taking market share without Perl responding. In this talk, I’m going to present at least one possible way we could reverse the trend and shape Ruby into what we want it to be.
00:05:09.440
I’m aware that I might be wrong about some things, and I’m okay with that. The key takeaway I want to emphasize is that we should not just sit idly by. We must start a conversation about these problems, and this should be at the forefront of our minds. I'll be addressing specific examples to illustrate my points, but I don’t want to point fingers. Please note that some examples might be cherry-picked, and they should be considered in the context of the larger project they come from.
00:05:50.000
First, I believe we should try to expand the range of use cases for Ruby. We want to ensure that when you sit down to solve a problem, your first thought is to use Ruby for that. To do this, we need to identify where rapid development is happening today—what is exciting developers and getting them to build things? If you’re strategic, it’s not hard to create a library that others will build upon it, simply to provide the path of least resistance.
00:06:01.840
A good example is Bitcoin. If you look at GitHub and search for Bitcoin-related projects, you’ll see many repos coded in Python and JavaScript, but Ruby is lagging behind with only 177 repos. This indicates that there’s significant innovation happening in Bitcoin, with many developers eager to create solutions. If we created a great Bitcoin library in Ruby, it would likely lead more developers to start using Ruby.
00:06:59.920
Another fast-growing field is containerization. Technologies like LXC (Linux Containers) have improved over the past couple of years, prompting people to explore better ways to deploy applications and manage dependencies. Ruby has a strong presence in Docker—among languages, it has a plurality, excluding shell, which doesn’t really count. This indicates we’re in a good spot for containerization, and I could envision a future where Ruby becomes the default language used to interact with Docker.
00:08:17.920
Additionally, we should make it easier to build service-oriented architectures in Ruby. The common story is that a Rails or Ruby application starts small and grows, but it eventually becomes so large that changes result in cascading effects, making it hard to predict what will be affected by a given change. Look at Twitter: they had a monolithic architecture that became unsustainable, leading them to break things out and rewrite them in Scala. It’s unfortunate that the default way of building applications often leads to this situation.
00:09:03.840
We could change the paradigm so that developers are able to build things correctly from the beginning and not end up in that giant hole that forces them to rewrite in another language. Think of service-oriented architectures: the idea is to break down your application into different services that encapsulate functionalities. This allows developers to understand how each part works without needing to understand everything under the hood. It’s a cultural shift that requires a focus on long-term maintainability.
00:10:00.160
At Stripe, we’ve been working on something in this area by breaking out internal code into reusable libraries we've named 'chalk.' In the service-oriented architecture at Stripe, we provide a simple DSL for defining services. You can define your service interface, and it interacts seamlessly with a discovery system—essentially, making it easy to work with in a variety of situations.
00:10:48.560
In addition to improving service orientation, we need to invest in Bundler. I know that each of us has faced frustrating Bundler error messages, especially at large organizations where updates to gems necessitate running 'bundle install.' Bundler is a fantastic tool that surpasses any other package manager I've encountered, but we need to improve its user experience. Little frictions in user experience can affect how people perceive Ruby and its ecosystem.
00:11:38.320
The first focus should be on expanding the range of what Ruby is used for, developing more libraries that align with innovation. The second focus should be to catch up on what we are behind on—standardized practices for common tasks. Currently, Rails has some of this for web applications, but these practices cannot be applied outside of Rails, and that leaves many developers searching for answers.
00:12:05.199
Standardization can combat issues stemming from an ad hoc approach. For example, error handling can lead to bad practices if not standardized. Poor standardization can lead to weird bugs and sometimes frustrating issues that developers face, which may cause them to give up on the language altogether. Improving the standard practices would make it easier for developers to manage their Ruby applications and potentially lead to fewer frustrations.
00:12:52.640
We also need to stop monkey patching in Ruby. While some efforts have been made to introduce refinements, the underlying problems with monkey patching persist. Incompatible monkey patches can lead to unexpected behavior in the codebase, creating difficult debugging situations. You might encounter issues due to dependencies on specific behavior that can change between versions, resulting in unforeseen errors that can take hours to identify and fix.
00:13:50.240
Moreover, static analysis can help improve Ruby’s development process. Languages like Go have tools that offer strong static analysis capabilities, allowing you to inspect code and catch potential problems before they arise. Although Ruby is dynamically typed, there’s still room for improvement by offering tools that provide solid usage insights and coverage over commonly written code patterns.
00:14:40.239
The implicitness of Ruby is appealing for beginners because it allows for rapid development, but as applications grow more complex, this can present challenges. For longer-term projects, it can lead to major issues when developers realize they can’t adequately reason about their code. Writing code that is clear and easy to follow is crucial, especially when considering the longer lifespan of our applications. Security can also be tied back to how consumable the code is.
00:15:27.680
For example, Ruby on Rails used to allow YAML to be embedded within XML. While this may seem reasonable for certain scenarios, it can introduce complex security issues, as seen in a real-world exploit stemming from this feature. These types of scenarios highlight that a simpler, more concise interface is likely to lead to more secure applications. As we write libraries and frameworks, we should be mindful of not only providing robust functionality but also ensuring they remain comprehensible to users.
00:16:09.680
This principle ties into the idea of ownership over user security. We are responsible for the tools we create; therefore, we must ensure they are used safely. When security vulnerabilities arise, they can stem from design choices that inadvertently allow for incorrect usage. Our community has faced such challenges, and we need to recognize that by not taking ownership of our security practices, we risk creating a negative experience for users.
00:17:05.959
Going forward, I discussed what we can do to expand Ruby's horizons and catch up with what we are behind. However, it may be even more important to address the question of why Ruby should remain relevant in the long run. I believe Ruby possesses a unique dynamicism and power that many other languages lack. Its flexibility, particularly with blocks as a syntactic construct, allows developers to create robust and efficient code with less effort.
00:18:20.160
The question for the Ruby community going forward is: how do we cultivate this unique environment? We need to ensure that Ruby is considered for a broader range of tasks and remains exciting to developers. There are numerous possibilities available to us, and we should collectively explore innovative avenues to keep Ruby alive and thriving.
00:19:25.439
I hope this discussion has provided food for thought regarding how we can foster growth in our community, expand the avenues of Ruby usage, and keep our language relevant. Is the flexibility and expressiveness of Ruby something we want to preserve? If so, let's work together to convert these ideas into actions and decisions that will keep Ruby healthy for many years to come.
00:20:07.040
I appreciate your attention, and I’m happy to take any questions you may have as we dive deeper into this conversation. Thank you.
00:21:36.560
Do you want to take a question? Sure! Are there any questions for Greg?
00:22:10.720
You seem to be talking about how to ensure that Ruby wins over the long run. Why does Ruby have to win?
00:22:33.840
I don’t think Ruby absolutely has to win in terms of defining a single winner among programming languages. The reality is that there will always be alternatives. However, I want Ruby to endure and remain viable for the long term, not only for me personally, having invested time and effort into it but also for the community that appreciates its diverse features and capabilities.
00:23:07.960
Some specific points of investment for Ruby relate to its inherent strengths, such as the balance between functional and imperative programming, as well as the vibrant community that continues to empower strong growth. If Ruby were to fade away, it would mean the loss of a programming language that not only embodies great ideas but also achieves excitement and engagement among its users.
00:23:45.440
What about continuing to emphasize learning initiatives like Rails Girls, RailBridge, or G-School? There’s a real push right now for Ruby to be an introductory language that contributes to community growth and adoption. If Ruby gains more share in educational spaces, it will lead to sustainable growth.
00:24:55.680
I completely agree. Ruby is exceptionally beginner-friendly, and it’s essential to create a supportive learning environment that encourages newcomers. By leveraging those programs, we can motivate aspiring developers to learn Ruby, and this could facilitate a new generation that appreciates its simplicity and effectiveness for a range of applications.
00:25:56.560
Yes, I think Ruby’s current situation can be enhanced through the popularity of Rails, as people often associate the two. Ruby became a preferred choice alongside Rails, but we have to recognize that dependence solely on Rails will limit Ruby's scope over time. As new web frameworks come into play, we can't afford to have Ruby remain exclusively tied to Rails for growth.
00:26:24.720
The Ruby code idioms are valuable. The way we write code and execute test-driven development often set Ruby apart. Ruby offers substantial ease of development, allowing for quick and efficient testing, while Python’s structure may lead to a more rigid approach. In short, finding optimal frameworks within Ruby is vital to grow familiarity as well as competence.
00:27:36.560
Lastly, concerning gems and Node catching up rapidly, there could be a tipping point where Ruby gems meet critical mass. While we've addressed many conventional areas, I'm convinced there are still uncharted areas ripe for exploration. The wide variety of programming needs—much like innovation in other languages—ensures there will always be more room for our growth.
00:28:20.160
I'm glad that I could address some of your thoughts and provide insights on how Ruby can continue to thrive. I plan on sticking around, so please feel free to share more ideas or questions as we develop this conversation further.
00:29:08.320
Thank you all once again for your time. I look forward to our ongoing discussion and to exploring the potential of Ruby together.
