Panel: Elixir vs. Ruby

Ruby

Andrzej Krzywda

#functional-programming

#developer-experience-dx

#web-development

#scalability

Panel: Elixir vs. Ruby

by Andrzej Krzywda

In a detailed panel discussion titled "Elixir vs. Ruby" led by Andrzej Krzywda at the wroc_love.rb 2017 event, the speaker explores the fundamental differences and similarities between the Elixir and Ruby programming languages. While both languages may share some syntactic similarities, the speaker asserts that their semantics diverge significantly. The conversation addresses several key points regarding each language's ecosystem, including their use cases, community perceptions, and the motivations behind their development.

Key Points Discussed:

- Similarities and Differences: Elixir and Ruby are similar in syntax but fundamentally different in terms of their virtual machines, behaviors, and use cases. Elixir is designed with concurrency in mind, while Ruby focuses on developer happiness.

- Application Structure: The structure of Phoenix applications (built in Elixir) parallels regular Elixir applications, contrasting the Rails framework's control over application layout.

- Community Dynamics: There are distinctions between the Erlang and Elixir communities. Transitioning Ruby developers are finding appeal in Elixir due to its modern features, though misconceptions persist that Elixir is merely a refined version of Ruby.

- José Valim’s Contribution: Valim, originally from the Ruby community, developed Elixir to address gaps in the Ruby ecosystem concerning concurrency and developer experience. His intention was to enhance error messages and tooling, catering to developers.

- Erlang Compatibility: Elixir maintains compatibility with Erlang, ensuring stability and a seamless integration of features while introducing improvements like better tooling and support for metaprogramming.

- Performance and Scalability: The conversation highlights the performance benefits of using Elixir for scalable applications, particularly in contexts with high concurrency requirements, contrasting it with Ruby's capabilities.

- Simplicity and Readability: Elixir's approach to functional programming encourages clearer and more maintainable code, even if this results in a more verbose coding style.

- Refactoring: Refactoring practices differ significantly between Elixir and Ruby, with Elixir's functional paradigm enabling more straightforward alterations without side effects.

- Future Considerations: The discussion poses questions about the longevity of Elixir in the programming landscape, particularly in relation to Erlang and its evolution compared to languages like CoffeeScript.

Conclusion: The panel concludes that while Ruby emphasizes developer satisfaction, Elixir provides strengths in concurrency and a functional programming approach. Each community offers valuable perspectives, and ongoing exploration in both languages is essential for developers seeking to understand their motivations in the tech landscape.

00:00:12.519 I would say that in the first part, yes, Elixir and Ruby are similar, probably only in syntax. Everything else is completely different. Comparing these languages is challenging because the semantics vary widely.

00:00:23.599 The virtual machines, behaviors, and use cases for each language also differ significantly. The other part of the question regarded developers who write in Elixir but don't know how to write with Phoenix. I think this is much less of a concern because a Phoenix application is essentially an Elixir application.

00:00:41.120 When you build an application with Rails, Rails controls the structure and layout of your application, and you utilize the Rails CLI tools. However, when you build a Phoenix application, it functions just like any other Elixir application.

00:01:04.239 The layout is parallel to that of any other Elixir application, and the tools you use are consistent with those for any Elixir application. As for the Erlang community, would you say that it is separate from the Elixir community? Are they distinct, or do they just share the same VM?

00:01:37.320 There is indeed a level of separation between the two communities. There are many Ruby developers transitioning to Elixir. However, going back to our original question, I recently wrote a blog post on this subject, explaining that different features draw people to each language.

00:01:57.439 Those people who promote Elixir as a newer, better Ruby probably don't fully understand the differences. Elixir is a completely different environment and runtime designed for distinct purposes. It raises the question of whether Erlang developers created Elixir to take our jobs. However, it's worth noting that José Valim, a Ruby developer, created Elixir.

00:02:31.320 So what is the story behind it? José arrived in the Erlang community somehow and likely garnered some attention from other Erlang programmers. His journey likely stems from his background as a Rails team member, in which he worked on making Rails thread-safe.

00:03:17.080 Once he completed that, he sought alternatives for concurrency, feeling that the Ruby approach fell short. His exploration of different languages, including Erlang, introduced him to some valuable concepts.

00:03:58.360 One memorable statement from his talk was that he loved much about Erlang but also recognized things that were lacking. Elixir emerged as his attempt to fill those gaps by providing better error messages, an improved developer experience, and better tooling.

00:04:35.039 He aimed to replicate the Ruby experience, which he famously showcased by introducing a blog engine in just five minutes, highlighting the effectiveness of minimal code.

00:05:16.159 Elixir is built around the idea that development should primarily benefit developers rather than machines. While I don't want to speak on José's behalf, if you view his presentations, you'll notice he has three main goals for Elixir. The first goal is compatibility with Erlang, ensuring that existing features and capabilities remain accessible.

00:06:07.760 The second goal focuses on better tooling, which significantly enhances developer experience. I believe this is something deeply rooted in Ruby. Do you think the community is achieving this goal? From your perspective, how does the experience compare to Ruby?

00:06:27.680 In my opinion, yes, I would say so. However, that is subjective, and experiences may vary. Personally, I genuinely enjoy working with Elixir, and although you need to engage in a bit more groundwork with Elixir than in Ruby, this is by design.

00:06:51.400 Most likely, you'll find yourself writing somewhat more code compared to Ruby. Discussing the sentiments between Erlang and Elixir communities, I've observed a certain sentiment from the Erlang community toward Elixir. They are justified, pointing out that Erlang doesn't need fixing.

00:07:48.000 Part of the reason some developers might not favor Erlang or might feel indifferent is simply a reaction to its syntax, which can initially seem strange. The syntax is quite different and can feel inverted to those unfamiliar. Nonetheless, Erlang can produce very concise, precise, and arguably more readable code than Elixir.

00:08:48.880 We shouldn't claim that we are fixing Erlang. Don't you worry about the perception that Elixir could fade like CoffeeScript? Will Erlang keep evolving like JavaScript did, leaving Elixir in the dust?

00:09:27.840 I believe that the comparison is more akin to Java. JVM runs numerous languages, and the same applies to the Erlang VM, but it’s also slightly different. One of Elixir's primary goals is ensuring this compatibility.

00:10:03.000 All data types in Elixir and Erlang remain the same, which guarantees stability. CoffeeScript initially had the same promise, offering better syntax yet faded away as JavaScript improved with each version.

00:10:38.480 In my opinion, JavaScript’s enhancements were partly due to the pressure exerted by CoffeeScript, causing it to evolve rapidly. That, in turn, led to CoffeeScript’s decline.

00:11:38.920 I wonder if the same fate could potentially await Elixir, or if it will persist longer in the programming landscape. Presently, I don't see anything from the Erlang community that would jeopardize Elixir's compatibility with Erlang.

00:12:15.960 The OTP team at Ericsson is currently focused on making Erlang distribution more scalable. While it functions well for up to about 50 servers, anything above that tends to fail, as it wasn't originally designed for such large-scale operations.

00:12:57.720 Their efforts will allow Elixir developers to integrate new features seamlessly. The distinction between Elixir and Erlang is minimal; they are essentially the same language with differing syntax and standard libraries.

00:13:47.000 The biggest difference lies in the standard libraries, where Elixir's library is more coherent compared to Erlang's, which, after 20 years, has become a bit messy in places.

00:14:30.640 Another significant distinction is Elixir's support for macros and metaprogramming, which is relatively lacking in Erlang. Although Erlang programmers can perform these tasks, they often find the methods cumbersome.

00:15:03.400 Protocols and data polymorphism are also features missing in Erlang, and while achievable, they are not inherently part of Erlang. The Erlang community has been resistant to change, as they typically favor stability.

00:15:45.760 However, we're beginning to see features trickling back into Erlang from Elixir. In some respects, Elixir serves as a testing ground for ideas that may eventually be integrated back into Erlang.

00:16:37.360 During my exploration of the actor model, I noticed various implementations across different languages, including Ruby with Celluloid and Akka on JVM, which works with Java or Scala. When choosing a new language, I often feel I'm selecting the virtual machine rather than the language itself.

00:17:24.360 For example, I am more comfortable with the JVM, having first encountered it during my studies and later engaging with applications running on it. It feels natural for me.

00:18:12.880 However, I find Erlang's approach interesting and wonder when to switch between different VMs despite my familiarity with the JVM and Akka.

00:18:57.680 From a developer's viewpoint, my skills have taken years to develop in Ruby. I prefer focusing on business logic rather than the implementation details of websockets or managing a million connections, which Erlang excels at.

00:19:39.200 For instance, if I were to develop an application similar to Slack, scaling would be a simple matter due to the cost per user per month, making it less of an issue.

00:20:21.520 Conversely, WhatsApp operates on a different business model where each connection increases operational costs.

00:20:56.439 Hence, the choice to utilize Erlang for projects focused on handling numerous connections without incurring excessive costs would be rational.

00:21:32.840 Comparatively, the notion of whether scaling is relevant to everyone is subjective. Throughout my experience running a Ruby shop for 10 years, I've only encountered one project that would have benefitted greatly from enhanced scalability.

00:22:18.480 There might have been several high-traffic projects, but in the end, I believe in the business perspective that's influenced my focus—ensuring client satisfaction and delivering software that works.

00:23:19.352 I also understand other developers may see the need for more scalable solutions depending on their projects. This does highlight some of the limitations developers face regarding dependencies on towering infrastructures.

00:23:55.680 In those cases, we would have used different stacks. For example, a major commenting widget for high-traffic websites might be a better fit for technology other than Ruby, as it would ensure the efficiency needed for handling spikes in usage.

00:24:56.600 I haven't worked with Akka much but understand that with Akka, it is crucial not to block your threads as doing so could create problems. In contrast, the Erlang VM functions with built-in primitives for actor concurrency, inherently avoiding any blocking issues.

00:26:04.440 The design of the Erlang VM ensures progress in your program regardless of blocking within a process. Therefore, using the Erlang VM has advantages in managing concurrency.

00:26:59.520 For instance, persistent WebSocket connections and game server functionality are being developed in Elixir, opening up new avenues that Ruby developers haven't extensively explored. Elixir has gained ground not just in web development but also in these unexplored areas.

00:27:50.960 Joe Armstrong, one of the co-creators of Erlang, once stated that in many languages, you write a web server that handles a million connections, whereas in Erlang and Elixir, you essentially have a million web servers each handling a single connection.

00:28:51.120 This underscores the simplicity of software architecture in these languages. While many are drawn to Elixir for various reasons, from performance to other features being marketed, I believe the core aspect that keeps developers using Elixir is the software's simplicity.

00:29:41.680 Elixir provides a clearer path to understanding the software being built. While performance can be an enticing factor, and hot code loading offers unique benefits—although it's complex to implement—simplicity in building maintainable software is of utmost importance.

00:30:30.680 Concerning differences between building applications in Ruby vs. Elixir, I believe that while both provide potential benefits, Elixir focuses on following patterns that lend themselves to functional programming.

00:31:26.640 This distinction makes Elixir appealing as developers lean towards solutions that facilitate handling concurrency and functional programming practices while maintaining read-friendly code.

00:32:47.840 There's also a vast gap in how we perceive and execute refactoring in Elixir compared to Ruby. Its functional paradigm often results in code that’s less cumbersome and easier to maintain.

00:33:32.240 Refactoring in Elixir involves straightforwardly moving functions without worrying about side effects due to the lack of mutable state within the code.

00:34:19.520 The vocabulary in Elixir may seem more verbose, which can lead to larger codebases, but this verbosity can enhance clarity in the long run.

00:35:01.120 In conclusion, while developer happiness and productivity remain key tenets in the Ruby ecosystem, Elixir is carving its niche by providing an environment where concurrency and functional programming reign.

00:35:50.680 The scalability discussions occurring today highlight that there are many paths for developers. As the Ruby community continues to evolve, there is potential for Elixir to provide an alternative philosophy that emphasizes different strengths.

00:36:19.280 The final take-home message is that each community offers unique perspectives on development. It's important for developers to understand their motivations, whether it's market-driven or curiosity in exploration, as both can lead to fruitful endeavors.

00:37:07.840 Thank you for engaging in this discussion today. I'm eager to see what innovations the future holds for both Ruby and Elixir communities.

00:37:29.580 Let's take a brief break before our next talk and explore the exciting topics that remain on our agenda.

Andrzej Krzywda

@andrzejkrzywda

wroclove.rb 2017