00:00:20.600
I've been working with Rails for a long time at various companies.
00:00:25.920
Similar to last year, I started writing this talk, but I ended up with way too much content.
00:00:31.859
As a result, I won't have much time to share about myself or my background, but you should know that I'm pretty cool.
00:00:38.640
If you're interested in learning more about me, you can follow me as CJohnRun on GitHub and Twitter.
00:00:44.460
I'm also on Mastodon.social, but I only have three followers, so I don’t often toot in public.
00:00:51.600
Like many of you, I hope I love Ruby on Rails. I love it even more than I did last year.
00:00:57.300
Who here loves Rails more than they did last year? It's such a great framework.
00:01:02.940
It's a web framework that lets me easily and safely express my thoughts without unnecessary fluff on top of a programming language that I still find extremely beautiful after 15 years.
00:01:08.820
Last year, around the time of RailsConf in Portland, I left my job at GitHub. After a brief misstep indicated by the crashing car, I now work at Jane Street, which is a tech-forward finance and trading company based in New York.
00:01:21.240
At Jane Street, I continue to work on developer tooling, just as I did at GitHub. It's pretty exciting because they have some of the best developer tooling I've ever seen, complete with robust systems for code review and deep editor integrations.
00:01:39.420
However, what they don’t have, sadly, is Ruby, and it follows that they also don’t have Rails. Jane Street writes nearly all their code in a fairly obscure programming language called OCaml.
00:02:03.840
I had never worked in OCaml, nor did I know anyone who had. Not many other companies or projects use OCaml, and to be honest, I stressed quite a bit before joining that I might be investing my time in a skill that wouldn't end up being transferable.
00:02:22.200
When you first join the company, they put you through a two-week onboarding for the language. They call it a 'boot camp,' and it's something you must attend. However, it's also something you will absolutely need.
00:02:39.060
OCaml has some features and patterns that just don't make sense if you haven’t been exposed to them before. Someone will walk over to you and probably reference Lambda calculus, and you'll probably make a confused face.
00:02:57.180
Then they will hand you a book called 'Types and Programming Languages.' It's pretty dense; they refer to it as 'TAPL' and usually say something like, 'Oh, it's a classic!' or 'It's not as complicated as it looks.'
00:03:14.940
This is clearly a company that has spent a lot of time thinking about what programming language they use and why they’re using it. The impressions left on me were that I need to keep an open mind and not just spend all my time talking about Ruby.
00:03:31.860
I also realized I needed to figure out what I didn’t know and how I could learn it. Lastly, given that Ruby and OCaml exist in such totally separate worlds, I began to consider what new tools I could gain that might apply elsewhere in my programming life.
00:03:44.580
In this talk, I'm going to go over some neat features from OCaml and show how they can be applied in Ruby. What I’m not going to do – and this is the thing I've seen other talks like this do – is try to convince you that OCaml is somehow better than Ruby.
00:03:56.220
As a spoiler, I don’t think it is better. In fact, I convinced my wife to name one of our kids Ruby, yet as of this talk, I have no kids named OCaml.
00:04:14.360
Rather, I hope to demonstrate that many of the things we see as features in OCaml are actually design patterns. With a little bit of work, we can adopt these patterns in Ruby as well.
00:04:29.600
To set a good foundation, let’s first go over some quick similarities and differences between these languages. The most obvious difference lies in the type system: Ruby has a dynamic type system while OCaml uses static typing.
00:04:42.720
For those of you who haven't programmed in a statically typed language, this means that the type of each variable is known before the code runs. Consider this example in Ruby: first, we define a variable called 'var' that holds the integer five.
00:04:54.840
Then, we redefine 'var' to now hold five but as a string, and we redefine it again to hold 'var' as a symbol. Finally, on the last line, we assign something from params to 'var', and now we don’t even know what type it is anymore.
00:05:12.120
It could be a string, an array, or a hash. We’ve all written code like this; it doesn’t feel weird to me but, what is the type of 'var'? The answer is it kind of depends on where you are in the execution.
00:05:29.940
Each line makes 'var' a different type. Thus, the type of the variable is only determinable at runtime. It’s relatively easy for me to write some code like this in Ruby.
00:05:55.500
Here I am calling the absolute function to get the absolute value of a string. We can all look at this code and know that it is probably wrong; in most codebases, 'abs' is not defined on strings.
00:06:06.900
If you do have 'abs' defined on strings in your codebase, please come find me because I want to hear about it. But that doesn't stop us from writing this code in Ruby and running it.
00:06:29.880
We won’t receive a no-method error until this part of the code is executed. By contrast, in a statically typed language like OCaml, types are always known. We tell the compiler the types of things through type annotations.
00:06:49.020
They are essentially code that declares the type of all the variables. For example, here’s a function called 'abs' that takes an integer called 'n' and returns another integer.
00:07:09.240
You can't change the types of variables in OCaml; if you attempt to do so, the program will simply refuse to compile. So here we're trying to define a variable that holds the integer five and redefine it to hold the integer five as a string, and we receive a compilation error.
00:07:30.000
Additionally, you can’t even write code that mixes up types. In this example, I'm trying to pass our 'abs' function a string instead of an integer, and the OCaml compiler catches that.
00:07:55.380
The language has a powerful type inference engine, which means you often don't have to explicitly write down these types. However, it’s crucial to say that every variable type is known before the code runs, as long as it compiles.
00:08:15.060
Another major difference between these languages is the programming style or paradigm. For some of you who might be relatively new to programming, the idea of programming styles might seem odd.
00:08:44.760
These programming styles are significant and were revolutionary in changing how code is written and reasoned about. Generally, the most common paradigms worth discussing are imperative, procedural, object-oriented, and functional.
00:09:09.420
There are certainly more, and there will be debates over the lines between these, but these are the main ones when talking about programming languages you might choose for an everyday project.
00:09:28.620
Imperative languages, like assembly and the original BASIC, execute statements in order with no functions, where any sharing just involves jumping from one part of the code to another, typically done with commands like 'jump' or 'go to.'
00:09:53.820
We can even implement this in Ruby using a library from Benjamin Bach written around 15 years ago that lets you define labels and navigate to them. In the example, we’re defining a loop that prints a string seven times.
00:10:09.419
Here we define a label called 'loop' and then jump to that label seven times. Languages like C organize imperative code into subroutines or functions, allowing better organization, isolating variables within the functions they were created in.
00:10:29.760
This also avoids the problem of jumping to a part of the code that is outside the scope of your program. Object-oriented languages like Ruby or Java organize behavior into objects and allow sending messages to those objects.
00:10:46.440
Instead of functions that take parameters, there’s an implicit parameter called 'self,' making it so we have to refer to these as methods instead of functions, but the same idea applies.
00:11:06.600
Functional languages like Haskell focus on functions as their primary organizational construct. Functions can be combined, passed to each other, can contain nested scopes, and can call themselves.
00:11:26.720
This is an example of functional-style patterns in Ruby, reflecting the different styles I've described before.
00:11:37.220
You might be thinking, "Hey, John, you said that Ruby is object-oriented, yet everything shown – all the code examples – are in Ruby." That's true, and it's because Ruby, as many of you know, is multi-paradigm.
00:12:03.744
It supports all these programming styles, though it excels at being object-oriented. In fact, most languages today are multi-paradigm; when a new feature comes out in one language, the others tend to adapt it.
00:12:18.780
OCaml is also multi-paradigm; the 'O' in OCaml actually stands for 'object,' referencing the object-oriented nature of the language. Still, it is decidedly focused on being functional.
00:12:32.700
In the same way that Rubyists rarely write recursive code, OCaml developers tend to completely ignore the object-oriented features.
00:12:51.480
Despite their differences, these languages share something crucial: they are both expressive and prioritize making developers happy.
00:13:16.740
Ruby makes developers happy by providing the flexibility to express their ideas as they see fit. For example, you could come up with various ways of writing the various code snippets shared earlier.
00:13:34.080
On the other hand, OCaml ensures that certain error-prone programming practices become impossible, reducing the uncertainties for developers when writing or modifying code.
00:13:53.160
Having worked in Ruby for so long, I tend to approach OCaml with Ruby 'glasses' on, aiming for module interfaces that sound like sentences. I'm meticulous about the separation of concerns for different parts of my app.
00:14:20.700
I spend a lot of time ensuring my code is testable; however, when I return to Ruby and work on Rails, I’ve noticed the absence of some features from OCaml that enhance my productivity and simplify refactoring.
00:14:44.760
So, I think about the lessons learned at work and how they can translate back to Ruby and Rails. Today, I’ll be covering three features from OCaml.
00:15:01.440
For each feature, I will explain what it is, how it works in OCaml, a similar approach we can adopt in Ruby, and how it might be applied in a standard Rails application.
00:15:18.600
I want to issue a slight word of warning: if you're sitting in your chair right now thinking, 'I already knew that there are static types and dynamic types; this talk is boring,' you should know that it starts light but ramps up quickly.
00:15:30.720
The pace gets quite fast, and if something doesn't quite make sense, consider revisiting the topic or experimenting with it yourself. Some concepts didn't click for me until the twentieth attempt.
00:15:48.720
With that warning behind us, let’s dive into our first topic, which is probably OCaml's most fun-sounding feature: functors.
00:16:06.960
In OCaml, there are basic value types—think strings, integers, maps, and arrays—and functions that take in some number of parameters and return something.
00:16:20.700
For example, we have a string called 's', an integer called 'i', and a function called 'add' which takes two integers and returns a third integer.
00:16:37.620
There are also modules, which are groupings of functions that hold similar values together. For instance, here’s a module encapsulating a car wash, containing functions like 'wash,' which takes a car as input, returns a message, and outputs the same car.
00:16:54.960
A crucial note: these are not classes—there are no instances of 'carwash.' It lacks state, meaning the values cannot change. The car wash is just a bucket for loosely collecting similar items.
00:17:10.800
Modules can be included within other modules in OCaml, just as they can be in Ruby. One of the primary ways we avoid duplicating code for similar features is to include modules within other modules.
00:17:29.640
For instance, I may have a module for blog posts and a separate module for wikis, and if both require short URLs, I could introduce a third module that contains these methods, sharing the relevant parts of their implementation.
00:17:52.680
Many times, when we summarize this type of module sharing, there are significant details about the behavior of individual classes—like blog posts and wiki entries—that need to be integrated into how short codings work.
00:18:06.060
For this, we might require a method named 'has_shortcode', which necessitates the prefix. We provide the blog post's prefix as 'post-' and the wiki entry's prefix as 'wiki-.' We do it this way because 'include' doesn’t accept arguments.
00:18:20.520
In Ruby, there are two typical ways to handle this. The first would be to define methods with commonly known names; you define them on the including class, and the module assumes those methods exist.
00:18:42.360
For instance, 'has_shortcode' could make an assumption that the including module has a method called 'shortcode_prefix' and, when using the module, we would have to define that requisite method.
00:19:01.680
The second way that you'll often see in Rails, but might not have noticed or considered is defining a method like 'has_shortcode.' This presents a nicer interface by allowing you to write one line, passing in the prefix directly.
00:19:30.480
In fact, some library authors will register a hook and include the module directly into 'ActiveRecord::Base', allowing one-line usage of the module you created.
00:19:57.300
The implementation normally looks similar to this: we modify the outer class to store the necessary attributes. In this case, 'has_shortcode' serves as an ActiveSupport concern, defining two class methods.
00:20:12.840
One method is 'shortcode_prefix' via an attr_reader and the other is 'has_shortcode,' which is used to introduce behavior into the model. The 'shortcode' implementation can then utilize the 'shortcode_prefix' method.
00:20:41.460
With this approach, the methods we define actually live on every model, even the ones that don’t utilize shortcodes. There are indeed ways to circumvent this issue, but most libraries do not pursue them.
00:21:09.360
For instance, if you look at ActiveRecord::Base, you might be surprised to see many methods present that you wouldn’t expect. None of this is the end of the world, but functors, as I’m about to describe, provide a potential third approach.
00:21:32.880
In OCaml, functors can be thought of as functions from one module to another. They allow you to pass specific details to a module, modifying its behavior at the moment of creation.
00:21:54.840
For example, here’s a definition for a functor that takes in a module called 'M' and returns a new module, where the property 'x' from the original module is incremented by 1.
00:22:12.360
Now, could we create a similar concept in Ruby? This talk would suck if I said no, so that’s what we’re going to try to implement.
00:22:28.440
What we aim for is a class called 'BlogPost,' which is where we want to include the methods. It should have methods resulting in a short URL.
00:22:42.960
We need to introduce something in the middle to hold the prefix that allows us to hook into the inclusion point. We can define a module method on 'has_shortcode' for this purpose.
00:22:59.640
We'll call that method 'make.' This way, it has access to the prefix since the prefix gets passed into it, and because of the way we'll invoke 'make,' we have the opportunity to return a new module instead of just the one being included.
00:23:15.840
Creating the new module is trivial with 'module.new,' inside of which, we can simply include the original module, thus creating a proxy module to define the prefix method between ourselves and 'has_shortcode'.
00:23:31.680
Next, we define methods on the proxy module for each of the passed-in arguments. By far, the simplest way to handle this is to use 'define_method.' In this case, we're defining a method called 'prefix'.
00:24:01.560
The 'prefix' method will return the prefix that is within scope from 'make,' and voilà—we've built something functional using this pattern!
00:24:21.960
This implementation also ensures that no instance variables are created on 'BlogPost,' and consequently, all classes that inherit from 'ActiveRecord::Base' that do not require this behavior avoid unnecessary extra methods.
00:24:37.920
While it's unfortunate that this code is highly specific to 'has_shortcode,' it doesn't have to remain that way. We can encapsulate the entire concept into a separate module called 'functor.'
00:24:56.520
This function will feature a 'make' method that works like the previous implementation, but will also define methods for all possible arguments, allowing a more general tool.
00:25:18.960
This will provide the same behavior to any module we define and you'll see that inside of the short URL method, we will have access to 'prefix,' which comes from the proxy module.
00:25:35.880
Additionally, we will still have access to 'id,' which comes from the base model. It’s also possible to use this implementation with a more traditional API—you could wrap it all to conceal the internals.
00:25:51.120
By doing this, we create a simple Rails API while maintaining the benefits provided by the functor.
00:26:06.600
At this stage, let’s transition to the second feature, which focuses on a language feature of OCaml known as variance. With this feature, you can define a value that can be in one of several different states.
00:26:27.240
A common example is color values: colors can typically be expressed in many different formats such as RGBA, RGB, hex, or by name.
00:26:43.920
However, how would we handle this in Ruby? Personally, I would create a Color class with factory methods for each individual color representation.
00:27:01.320
In this example, we have an initializer that only accepts RGBA colors, and we define factory methods that essentially map other color spaces onto RGBA, normalizing all incoming color data.
00:27:20.760
While this might be a reasonable solution, it diverges from the OCaml implementation, as we ultimately discard the user's input. If we need to maintain a user interface that reflects how users input color values, we must somehow store that information.
00:27:42.960
To solve this, we want to represent and store a color in any of these formats while also minimizing database complexity, ideally keeping all color information in a single database column.
00:28:06.720
We can modify the Color class to store both the details of the original input while determining the normalized color only when we actually need to color something.
00:28:25.560
For instance, when initializing, we would take the label that indicates how the information was stored and retain all input values.
00:28:43.800
Thus, we would implement two methods: one called 'to_rgba' to actually use the color in the interface, and another called 'to_hash' to serialize the data into the database.
00:29:07.680
In essence, this establishes how we can replicate the concept of variance in Ruby. A variant is essentially a label and the data associated with that label.
00:29:23.520
While it could be problematic that any value could theoretically be passed to the label, we could enforce stricter checking on this by making the constructor private.
00:29:36.960
Furthermore, we could encapsulate this entire pattern into a library that simplifies creating and using these variant types, allowing us to discard factory methods completely.
00:29:55.680
For example, we might want 'variant.create,' where we pass all valid labels for that variant type, and in return, we receive a new class.
00:30:14.760
Then, with this new class, we can call .new and pass it a label; if we attempt to create an instance with an invalid label, it should raise an exception.
00:30:37.740
The implementation consists of dynamically generating the new class within the create method, specifying what labels are valid.
00:30:51.600
Creating a new variant with this API will return a class that descends from a parent class for shared behavior purposes.
00:31:07.440
It’s important to note that because OCaml is statically typed, it can go further with these variance types; it supports a feature called pattern matching.
00:31:21.600
This allows for clear handling using switch statements; you can succinctly define various states that the variable can hold.
00:31:39.960
Moreover, the OCaml compiler checks that all possible cases are accounted for, so if the code doesn’t handle every potential status, it won’t compile.
00:31:55.560
In OCaml, the variable must have a type, so if we skip, for instance, the RGBA case, any output to that variable becomes undefined.
00:32:05.760
In Ruby, we could simply return nil, but nil is of a different type, thus breaking the invariant of having a known type.
00:32:20.520
Thus, we may not compile an OCaml program with a missing case without handling it explicitly.
00:32:38.160
In Ruby, we can't prevent code from compiling if a case is missing, but can we implement exhaustiveness checks to avoid such gaps?
00:32:58.920
The interface I’m envisioning is a method on all variant types within the 'P' class. This method will accept a hash where the keys represent the label to match and the values denote executed procs for those matching labels.
00:33:24.060
The implementation of 'match' is straightforward; it checks if any cases defined are not properly handled. If any are left unhandled, we'll raise a 'UnhandledMatchCase' error.
00:33:50.520
We’ll also handle the cases where a default is provided, bypassing the raise. We’ll need to raise an exception for unnecessary cases. With this interface, we can identify dead code.
00:34:02.520
Through this use of match statements, we cover our bases on variants by identifying points where specific values are called but not handled.
00:34:18.720
Now we’re going to discuss the last feature for today: monads. In the rapid pace of conversation, I must clarify something I previously misspoke on.
00:34:30.600
When I mentioned the wildcard case of a pattern match, I indicated that it couldn't return nil because nil differs from string types. However, in several statically typed languages, null isn't a type but a value.
00:34:51.240
In Java, for example, you see that null can manifest for any type; it's often synonymous with absence of value.
00:35:06.780
In OCaml, however, null simply doesn’t exist. The absence of null helps to avoid the perils of unintended consequences often associated with null checks.
00:35:20.280
The option monad solves the problem of needing a variable that can hold either a value or no value using the OCaml work with variants.
00:35:41.520
The shape of the option monad strictly comprises two states: either None or Some containing a value, where Some is the method for holding a defined value.
00:36:10.920
The most common way to unwrap these options is by using a match statement keying off whether the value is Some or None.
00:36:30.960
These options can be composed easily by chaining calls, ensuring that code executes smoothly until a None value is reached.
00:36:45.480
While Ruby provides similar functionality through if statements and the safe navigation operator, such constructs can lead to mistakes if the developer isn’t careful with null checks.
00:37:05.520
The option monad pattern emphasizes explicit handling of possibly null cases through 'bind' methods, propelling developers to account for values that could be absent.
00:37:21.840
If there’s a situation where ignoring null could result in serious errors, this is a beneficial pattern to adopt.
00:37:39.840
It’s also worthwhile to explore other common monads, as each embodies a design pattern that efficiently conveys information about dealing with API responses.
00:37:53.760
As we close, let's take a moment to reflect. It’s understandable if you feel overwhelmed; there's been a lot of content presented today.
00:38:14.760
We've moved from possibly not knowing OCaml existed to understanding its contrast with Ruby, to dissecting how to transfer these functionalities back into our Ruby community.
00:38:32.880
I hope to have impressed upon you that there is immense knowledge to gain. Many concepts that appear as language features are fundamentally design patterns.
00:38:46.680
In a language as syntactically flexible as Ruby, we can integrate these patterns seamlessly. So, I encourage you to explore functional languages, declarative languages, or any language that intrigues you.
00:39:08.760
Do so not because you're abandoning Ruby, but because diversifying your language skills can enrich your overall development proficiency.
00:39:23.520
By exploring these various programming paradigms, we can enhance the Ruby community and ensure that Ruby and Rails thrive for many more years to come.
00:39:40.560
Thank you for your attention; I hope you enjoyed the closing keynote!
