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.
