DEV Community: Shrouk Abozeid

Threading and Code Execution in Rails: Executor, Reloader, and Load Interlock

Shrouk Abozeid — Mon, 26 Oct 2026 15:42:14 +0000

Rails handles concurrency for us in many situations. But what happens when we create our own threads? How does Rails safely reload application code while other threads are running? And what does the Executor have to do with database connections and autoloading?

I recently explored these questions while reading the Rails 8 guides. Here are my notes, with examples to make the concepts easier to understand.

1. How Rails Handles Concurrency

Rails allows different operations to run concurrently.

For example, when using a threaded web server such as Puma, multiple HTTP requests can be processed simultaneously. Active Job can also execute multiple jobs concurrently, depending on the queue adapter and its configuration. Action Cable handles messages using threads as well.

Each thread manages its own unit of work, such as a controller instance or a job instance, but threads share the same process space.

This means they can access shared objects, including:

Ruby classes and modules.
Application configuration.
Global variables.
Other shared objects in memory.

Consider two requests arriving at the same time:

class UsersController < ApplicationController
  def show
    @user = User.find(params[:id])
  end
end

Each request gets its own controller instance, so the instance variable @user belongs to that particular instance.

However, both requests use the same User class.

This is usually fine, provided your application doesn't introduce unsafe shared state or modify shared objects in ways that cause race conditions.

Rails provides mechanisms to coordinate application execution with its internal systems. Two important ones are the Executor and the Reloader.

Let's understand why we need them.

2. The Rails Executor

The Executor separates application code from framework code.

Whenever Rails invokes application code through its framework entry points, it wraps that execution in the Executor.

The Executor has two callbacks:

to_run: Called before application code executes.
to_complete: Called after application code finishes.

Think of the Executor as a boundary around a unit of application work.

Framework invokes application code
               |
               v
        Executor starts
               |
               v
        to_run callbacks
               |
               v
       Application code
               |
               v
       to_complete callbacks
               |
               v
        Execution ends

What does the Executor actually do?

In a default Rails application, its callbacks help Rails:

Track which threads are in safe positions for autoloading and reloading.
Enable and disable the Active Record query cache.
Return acquired Active Record connections to the connection pool.
Constrain the lifetimes of internal caches.

Instead of making every component manage these responsibilities independently, Rails provides a common execution boundary.

This is particularly important when application code runs concurrently.

What if we create our own thread?

Rails knows how to wrap application code at its own entry points. But Ruby also lets us create threads directly.

For example:

Thread.new do
  user = User.find(1)
  puts user.name
end

Here, we're executing Rails application code inside a manually created Ruby thread.

That thread hasn't automatically been wrapped in the Rails Executor just because it was created inside a Rails application.

Why does this matter?

The code might access Active Record, reference autoloaded constants, or interact with other Rails-managed resources. Rails needs to coordinate those operations with its execution lifecycle.

The solution is straightforward:

Thread.new do
  Rails.application.executor.wrap do
    user = User.find(1)
    puts user.name
  end
end

Now the application code runs inside the Executor.

The important distinction is that the Executor doesn't create the thread. It manages the Rails execution lifecycle within the thread.

This also applies when using thread pools or concurrency libraries that execute application code on threads you manage.

What if we can't use `wrap`?

Rails also provides run! and complete! for situations where wrapping a block isn't practical.

Thread.new do
  execution_context = Rails.application.executor.run!

  begin
    # Execute application code here.
    user = User.find(1)
    puts user.name
  ensure
    execution_context.complete! if execution_context
  end
end

run! starts the Executor's execution context, while complete! finishes it.

The ensure clause ensures that completion is attempted even if the application code raises an exception.

For ordinary application code, prefer wrap because it handles the lifecycle for you.

One more detail: the Executor is re-entrant. If it's already active on the current thread, calling wrap again doesn't establish a second independent execution context.

However, each new thread needs its own Executor context when it executes Rails application code.

3. The Rails Reloader

The Executor manages the execution lifecycle, but it doesn't decide whether the application needs to reload its code.

That's where the Reloader comes in.

During development, Rails can reload application classes when their source files change. This lets us modify a model or controller without restarting the server.

For example, suppose we have this model:

class User < ApplicationRecord
  def greeting
    "Hello!"
  end
end

We change the method:

class User < ApplicationRecord
  def greeting
    "Hello from the updated code!"
  end
end

Rails needs to unload the old class and load the updated version.

But what happens if other threads are executing application code while the reload is happening?

Rails needs to coordinate the reload so that other threads don't continue executing against classes that have been unloaded.

The Reloader helps manage this process.

How do we use the Reloader?

It provides a similar block-based interface:

Rails.application.reloader.wrap do
  # Execute application code here.
end

Before entering the block, the Reloader checks whether the application needs to be reloaded.

If a reload is required, it waits until the reload can safely occur, performs it, and then continues with the application code.

The Reloader also invokes the Executor when one isn't already active on the current thread.

Therefore, you don't need to wrap the same code separately in both the Reloader and the Executor.

Executor vs. Reloader

Although they have similar interfaces, they serve different purposes.

Executor	Reloader
Manages the execution lifecycle.	Coordinates application code reloading.
Runs its execution callbacks.	Uses the Executor and coordinates reloading when necessary.
Suitable for application code executed in manually created threads.	Suitable for long-running, top-level processes that repeatedly invoke application code and need reload-aware execution.

For example, a long-running process might repeatedly invoke application code while running in development.

In that case, the Reloader can check for code changes before each unit of work.

However, only long-running, top-level processes should invoke the Reloader directly.

Why?

When a reload is required, the Reloader waits until other threads have completed their active Executor executions. Calling it from a child thread while its parent is waiting inside an Executor block can cause a deadlock.

For manually created child threads, use the Executor instead.

4. What Happens During a Reload?

To understand the Reloader more deeply, we need to look at class unloading.

When Rails reloads application code, it unloads autoloaded classes and modules so they can be loaded again.

The Reloader provides two additional callbacks for coordinating operations around this process:

before_class_unload
after_class_unload

These callbacks are useful when other components need to perform cleanup before classes are unloaded or take action afterward.

For example, Action Cable uses before_class_unload to disconnect existing WebSocket connections before application classes are unloaded.

The exact point at which class unloading happens relative to the Reloader's to_run and to_complete callbacks depends on the config.reload_classes_only_on_change setting.

The important point is that Rails coordinates unloading with application execution rather than allowing classes to be unloaded arbitrarily while other threads are using them.

5. How Rails Uses These Mechanisms

We don't usually need to wrap every controller action or background job ourselves.

Rails already integrates the Executor and Reloader into its framework entry points.

HTTP requests

ActionDispatch::Executor and ActionDispatch::Reloader are Rack middlewares responsible for wrapping requests in the appropriate execution lifecycle.

In a typical development configuration, the Reloader ensures that incoming requests use the latest application code when a reload is needed.

Active Job

Active Job wraps job executions with the Reloader.

This means that when a job is picked up from the queue, Rails can ensure it runs against the appropriate version of the application code.

Action Cable

Action Cable works a little differently because WebSocket connections are long-lived.

A connection is associated with an instance of a connection class. We can't simply reload the application independently for every incoming WebSocket message while keeping the same connection instance.

Instead, Action Cable wraps individual message handlers with the Executor.

When Rails needs to reload application code, Action Cable uses the Reloader's before_class_unload callback to disconnect its existing connections.

The clients can then reconnect automatically and communicate with the updated application code.

This approach allows Rails to reload application classes without requiring every WebSocket connection to close naturally first.

What about production?

The Reloader checks for file changes only when both config.enable_reloading and config.reload_classes_only_on_change are enabled.

These are the defaults in the development environment.

In production, reloading is disabled by default. When config.enable_reloading is false, the Reloader acts as a pass-through to the Executor.

The Executor still has important work to do, including coordinating Active Record connection management.

This is why the Executor remains relevant even when application code reloading is disabled.

6. The Load Interlock

So far, we've seen that Rails needs to coordinate application execution with class loading and unloading.

The Load Interlock is the mechanism that helps make autoloading and reloading safe in a multithreaded environment.

Let's look at the problem it solves.

Why can't two threads load the same class independently?

Suppose two threads encounter a constant that hasn't been loaded yet:

User

Rails needs to load the class definition from the appropriate file.

Imagine another thread tries to access User while that class definition is only partially evaluated.

That thread could observe an inconsistent state.

Similarly, unloading a class while another thread is executing code that uses it can cause problems.

The Load Interlock coordinates these operations.

It tracks threads that are:

Running application code.
Loading a class.
Unloading autoloaded constants.

Only one thread can perform a load or unload at a time, and these operations must wait until other threads have finished running application code.

This ensures that class loading and unloading happen at safe points.

What does the Executor have to do with it?

The Executor automatically acquires a running lock for the duration of its block.

When application code references a constant that needs to be autoloaded, Rails can transition to the appropriate loading state and then return to the running state.

Conceptually:

Executor starts
      |
      v
Acquire running lock
      |
      v
Execute application code
      |
      v
Constant needs autoloading?
      |
      v
Load the class safely
      |
      v
Return to running state
      |
      v
Executor completes

This coordination is particularly important in development, where application classes can be reloaded.

With the default production configuration, reloading is disabled and eager loading is enabled, so Rails doesn't need the Load Interlock for reloading. The Executor still performs its other responsibilities.

7. How `permit_concurrent_loads` Prevents Deadlocks

This is one of the more subtle parts of the guide.

The Executor holds the running lock while application code executes.

Now imagine one thread starts another thread and waits for it to finish.

Rails.application.executor.wrap do
  thread = Thread.new do
    Rails.application.executor.wrap do
      User
    end
  end

  thread.join
end

Assume User hasn't been loaded yet.

Let's follow what happens.

The outer thread enters the Executor and acquires the running lock.
It creates a child thread.
The child thread enters its own Executor block.
The child tries to reference User, which needs to be autoloaded.
Loading User requires the other thread's application execution to finish.
But the outer thread is waiting for the child to finish using thread.join.
The outer thread is still inside its Executor block, holding the running lock.

Neither thread can make progress.

The outer thread is waiting for the child, while the child is waiting for the outer thread to stop running application code.

That's a deadlock.

The solution

Rails provides permit_concurrent_loads through the Load Interlock.

It allows a thread to release its running lock while waiting for another operation to complete, provided it won't reference any potentially autoloaded constants inside that block.

Here's the revised example:

Rails.application.executor.wrap do
  thread = Thread.new do
    Rails.application.executor.wrap do
      User
    end
  end

  ActiveSupport::Dependencies.interlock.permit_concurrent_loads do
    thread.join
  end
end

Now the outer thread releases its running lock while waiting for the child thread.

The child can acquire the loading lock, load User, and finish execution.

The outer thread then resumes.

Why must we be careful?

permit_concurrent_loads makes a specific promise: the calling thread won't dereference any potentially autoloaded constant inside the supplied block.

The safest approach is to keep the block as small as possible and place it directly around the blocking operation.

For example, wrapping thread.join is preferable to wrapping a large section of application logic.

Don't use this method as a general-purpose way to disable thread safety. It's intended for situations where a thread must wait for another operation that may need to autoload application code.

8. Practical Takeaways

Here are the rules I took away from reading the Rails guide.

Use the Executor when you create your own threads.

Thread.new do
  Rails.application.executor.wrap do
    # Rails application code
  end
end

This ensures that your code participates in Rails' execution lifecycle.

Use the Reloader only when you need reload-aware execution in a long-running, top-level process.

Rails.application.reloader.wrap do
  # Application code that should run with the latest code
end

Don't call it indiscriminately from child threads.

Understand that Rails already handles its own entry points.

Controller actions, Active Job executions, and Action Cable message handlers are integrated with these mechanisms. You generally don't need to wrap them manually.

Remember that disabling reloading doesn't make the Executor unnecessary.

The Executor still coordinates responsibilities such as Active Record connection management.

Be careful when combining threads, blocking operations, and autoloading.

A call to join, or another blocking operation inside an Executor block, can retain the running lock and cause a deadlock if another thread needs to autoload a constant.

In such cases, permit_concurrent_loads may help, provided you follow its requirements.

Conclusion

Rails makes concurrent application execution relatively straightforward, but it still needs to coordinate shared resources and application code loading.

The Executor provides a common boundary for running application code. The Reloader builds on that boundary to coordinate code reloading, while the Load Interlock helps ensure that classes are loaded and unloaded safely across threads.

Understanding these mechanisms helps explain why Rails automatically wraps its own entry points, why manually created threads need special attention, and why certain combinations of blocking operations and autoloading can cause deadlocks.

These are internal mechanisms that we don't usually need to think about during everyday Rails development. But understanding why they exist makes it much easier to write safe concurrent code when we need to go beyond the framework's default behavior.

These notes are based on the official Rails 8.0 guide, “Threading and Code Execution in Rails.”

The Rails Initialization Process: From bin/rails to a Running Server

Shrouk Abozeid — Tue, 20 Oct 2026 15:28:29 +0000

When you run bin/rails server, Rails doesn't immediately start accepting HTTP requests.

It first loads dependencies, resolves the command, prepares the server, loads your application configuration, runs initializers, and builds the Rack application.

Let's walk through it.

1. Launching Rails

`bin/rails`

The journey starts with the bin/rails executable:

#!/usr/bin/env ruby

APP_PATH = File.expand_path("../config/application", __dir__)

require_relative "../config/boot"
require "rails/commands"

The first line tells the operating system to execute the script using Ruby.

Next, Rails defines APP_PATH, which points to config/application.rb. This constant will be used later when Rails loads the application.

Then it requires two files:

config/boot.rb, to prepare the Ruby environment and dependencies.
rails/commands, to resolve and execute the requested Rails command.

Let's look at them one by one.

`config/boot.rb`

ENV["BUNDLE_GEMFILE"] ||= File.expand_path("../Gemfile", __dir__)

require "bundler/setup"
require "bootsnap/setup"

This file prepares the application's dependency environment.

First, BUNDLE_GEMFILE tells Bundler which Gemfile to use, unless it has already been configured.

Next, bundler/setup configures Ruby's load path so the application can load the gems declared in the Gemfile.

Finally, bootsnap/setup enables Bootsnap's caching mechanisms to help reduce startup time.

At this point, the dependencies are ready to be loaded.

2. Resolving the Rails command

`rails/commands.rb`

After booting the dependency environment, Rails loads rails/commands.rb.

A simplified version looks like this:

require "rails/command"

aliases = {
  "g"  => "generate",
  "d"  => "destroy",
  "c"  => "console",
  "s"  => "server",
  "db" => "dbconsole",
  "r"  => "runner",
  "t"  => "test"
}

command = ARGV.shift
command = aliases[command] || command

Rails::Command.invoke command, ARGV

ARGV contains the command-line arguments passed to the script.

For example, when you execute:

bin/rails server -p 3001

Rails extracts server as the command and leaves -p 3001 as the remaining arguments.

If you use the shorthand s, Rails expands it to server.

It then calls Rails::Command.invoke to find and execute the appropriate command.

`rails/command.rb`

The Rails::Command.invoke method looks up the requested command and executes it when a matching command is found.

If Rails cannot resolve the command, it can fall back to invoking a Rake task with the corresponding name.

For our example, Rails resolves server to Rails::Command::ServerCommand.

You can explore the implementation in the Rails command source code.

3. Preparing the server

The server command is responsible for preparing the environment and starting the server.

A simplified version of its perform method looks like this:

def perform
  extract_environment_option_from_argument
  set_application_directory!
  prepare_restart

  Rails::Server.new(server_options).tap do |server|
    require APP_PATH
    Dir.chdir(Rails.application.root)

    if server.serveable?
      print_boot_information(server.server, server.served_url)
      server.start
    end
  end
end

The exact implementation can vary between Rails versions, but the important steps are the same.

First, Rails processes the environment option and prepares the application directory and restart behavior.

Then it creates a Rails::Server instance using the configured server options. These can include the host, port, environment, PID file, and server adapter.

Notice the order: the server object is created before APP_PATH is required.

This ordering matters because the server setup needs to establish the selected environment before the application is loaded.

What is `Rails::Server`?

In modern Rails, Rails::Server inherits from Rackup::Server.

Rackup provides the interface for running Rack applications, while Rails adds application-specific behavior around it.

The server object prepares the server configuration, but this doesn't mean that the Rails application has already completed initialization.

That happens in the next part of the process.

4. Loading the application configuration

When Rails executes:

require APP_PATH

it loads your application's config/application.rb.

A typical Rails application contains something similar to:

require_relative "boot"
require "rails/all"

Bundler.require(*Rails.groups)

module MyApp
  class Application < Rails::Application
    # Application configuration
  end
end

The actual file depends on your application and Rails version.

Let's break down the important parts.

Loading `rails/all`

require "rails/all"

This loads the standard Rails frameworks, including Active Record, Action Controller, Action View, and other framework components.

Applications can choose a more selective set of frameworks, so the exact set depends on how the application was created and configured.

Defining `Rails::Application`

module MyApp
  class Application < Rails::Application
    # Application configuration
  end
end

This defines your application class and its configuration.

For example, this is where you might configure time zones, autoload paths, middleware, generators, or other application settings.

However, defining the application class is not the same as fully initializing the application.

Rails still needs to execute the initialization process.

5. Building the Rack application

Now we reach Rails::Server#start.

The server startup process prepares runtime resources, handles development caching where applicable, configures logging, and delegates to Rackup to load and run the application.

For a standard Rails application, the Rack configuration file is config.ru:

require_relative "config/environment"

run Rails.application

This file is the bridge between Rack and Rails.

Rackup uses Rack::Builder to evaluate the configuration file and build the Rack application.

The first line loads config/environment.rb.

Let's follow that call.

6. Initializing Rails

`config/environment.rb`

A standard Rails environment file looks like this:

require_relative "application"

Rails.application.initialize!

The first line ensures the application configuration has been loaded.

The second line triggers the actual initialization process.

This is an important distinction:

config/application.rb defines the application; Rails.application.initialize! initializes it.

The initialization process is implemented through Rails' initializer infrastructure.

`rails/all.rb` and the Railties

When config/application.rb requires rails/all, Rails loads the framework components and their Railties.

A Railtie is an integration point that allows a framework or library to participate in Rails initialization and configuration.

Rails uses these integrations to register initializers, configure middleware, prepare framework components, and coordinate startup.

Running initializers

The initialize! method calls run_initializers, which executes the registered initializers in dependency order.

The initializers are organized into three broad groups:

Bootstrap initializers: prepare the application and its environment.
Railtie initializers: configure and integrate Rails frameworks, engines, and application-level behavior.
Finisher initializers: perform later initialization work and finalize the application setup.

The ordering matters because some initializers depend on work completed by earlier ones.

For example, a framework may need its configuration to be loaded before another initializer uses it.

Application-specific initializers in config/initializers also participate in this process.

Once initialization finishes, Rails.application is ready to serve as the application object passed to Rack.

7. From `Rails.application` to the HTTP server

Remember this line in config.ru?

run Rails.application

It tells Rack to use the Rails application as the Rack endpoint.

Rack builds the middleware application, and incoming requests pass through the configured middleware stack before reaching Rails' request-handling components.

The request eventually reaches the router and the relevant controller, depending on the application and request.

Meanwhile, Rackup starts the configured server adapter—typically Puma—which listens for HTTP connections and dispatches requests to the Rack application.

So there are two related but different responsibilities:

Rails initializes the application and prepares request-handling behavior.
Rackup and the server adapter provide the interface that runs the application and accepts HTTP requests.

That separation is one of the reasons Rails can run on different compatible Rack server implementations.

The complete flow

Here is the sequence in simplified form:

bin/rails
   |
   v
config/boot.rb
   |
   v
rails/commands.rb
   |
   v
Rails::Command.invoke
   |
   v
ServerCommand
   |
   v
Rails::Server
   |
   v
config/application.rb
   |
   v
server.start
   |
   v
Rackup loads config.ru
   |
   v
config/environment.rb
   |
   v
Rails.application.initialize!
   |
   v
Initializers run
   |
   v
run Rails.application
   |
   v
Rack middleware + server adapter
   |
   v
The application is serving requests

The diagram is a conceptual overview rather than a complete call stack. Some steps invoke other setup routines, and the exact implementation can vary by Rails and Rackup version.

Final thoughts

Tracing Rails initialization helped me understand that starting a Rails server is not one operation. It's a sequence of responsibilities shared between the Rails command system, application configuration, the initializer infrastructure, Rack, and the server adapter.

If you want to explore the implementation further, the official Rails initialization guide is an excellent place to continue.

Understanding this flow is especially useful when debugging boot errors, investigating initializer order, or figuring out where a configuration change takes effect.

Learning Go as a Ruby Developer #7: Finally Understanding Pointers

Shrouk Abozeid — Tue, 06 Oct 2026 15:30:00 +0000

Pointers were probably one of the concepts I was most curious about when I started learning Go.

Coming from Ruby, I don't normally think about memory addresses or explicitly passing references around.

In Go, pointers are much more visible.

At first, they looked like one of those concepts I remembered from C++ and hoped I wouldn't have to think about again.

But once I understood what they actually represent, they became much less scary.

So What Is a Pointer?

A pointer is a value that stores the memory address of another value.

For example:

age := 30

pointer := &age

The & operator gives us the address of age.

So instead of:

age

which represents the value:

we have:

pointer

which represents the address where 30 is stored.

Getting the Value Back

If we have a pointer, we can use * to get the value stored at that address.

age := 30

pointer := &age

fmt.Println(pointer)
fmt.Println(*pointer)

The first Println gives us the memory address.

The second gives us:

because *pointer means:

Go to the address stored in pointer and give me the value there.

This is called dereferencing.

So we have two operators to remember:

& → get the address
* → get the value at that address

Changing a Value Through a Pointer

This is where pointers become really useful.

age := 30

pointer := &age

*pointer = 31

fmt.Println(age)

The result is:

We didn't directly change age.

We changed the value at the address stored in pointer.

Since pointer points to age, the original value changes.

Pointers with Functions

This becomes especially useful when passing values to functions.

Consider this function:

func changeAge(age int) {
    age = 31
}

If we do:

age := 30

changeAge(age)

fmt.Println(age)

the value is still:

That's because the function receives a copy of the value.

If we want the function to modify the original value, we can pass a pointer:

func changeAge(age *int) {
    *age = 31
}

Then:

age := 30

changeAge(&age)

fmt.Println(age)

Now the result is:

We pass the address:

&age

and inside the function we dereference it:

*age

This Is Where Ruby Feels Very Different

In Ruby, I don't normally have to think about passing a memory address.

For example:

def change_name(user)
  user.name = "Alice"
end

If user is an object, the method can modify that object.

Ruby handles the object references for me.

Go makes the relationship much more explicit.

I have to decide whether I'm passing the value itself:

func changeAge(age int)

or a pointer to the value:

func changeAge(age *int)

That distinction matters.

Pointers and Structs

Pointers become especially common when working with structs.

Let's use the Person struct from the previous article:

type Person struct {
    Name string
    Age  int
}

We can create a pointer to a Person:

person := &Person{
    Name: "Alice",
    Age:  30,
}

Now person is a pointer to a Person.

We can still access its fields directly:

fmt.Println(person.Name)

Go automatically dereferences the pointer when accessing the field.

So:

person.Name

is effectively shorthand for:

(*person).Name

This is a nice convenience because we don't have to write * every time we access a field.

Pointer Receivers

This also connects to something we saw in Part 3: methods.

Remember that Go methods can have a receiver:

func (p Person) SayHello() {
    fmt.Println("Hello", p.Name)
}

This is a value receiver.

The method receives a copy of the Person.

If we want the method to modify the original Person, we can use a pointer receiver:

func (p *Person) Rename(name string) {
    p.Name = name
}

Now:

person := Person{
    Name: "Alice",
    Age:  30,
}

person.Rename("Bob")

fmt.Println(person.Name)

prints:

Bob

The pointer receiver allows the method to modify the original value.

Value Receiver vs Pointer Receiver

This distinction is important:

func (p Person) Rename(name string)

means the method receives a copy.

While:

func (p *Person) Rename(name string)

means the method receives a pointer to the original value.

Coming from Ruby, this is one of those things I don't normally have to think about.

In Ruby, I can simply mutate the object:

def rename(person)
  person.name = "Bob"
end

Go makes the decision more explicit.

Go vs Ruby

Concept	Go	Ruby
Reference to a value	Pointer	Object reference handled by Ruby
Get address	`&value`	No equivalent syntax
Dereference	`*pointer`	No explicit dereference
Modify through reference	`*pointer = value`	Mutate the object directly
Pointer receiver	`func (p *Person)`	No equivalent
Value receiver	`func (p Person)`	No direct equivalent
Memory address	Explicitly accessible through pointers	Normally hidden

What Surprised Me

The syntax wasn't actually the hardest part.

It was changing the way I think about values.

In Ruby, I can mostly think:

"I have an object."

In Go, I sometimes have to ask:

"Do I have the value, or do I have a pointer to the value?"

That distinction affects how data is passed to functions and how methods can modify it.

Once I started thinking about a pointer as simply:

"A value that tells me where another value lives"

the concept became much easier.

The Main Idea

I initially thought pointers were going to be one of the most complicated parts of learning Go.

They're definitely more visible than they are in Ruby, but the basic idea is pretty simple:

& → give me the address
* → give me the value at that address

And when working with structs:

person := &Person{}

means:

person points to a Person.

While:

func (p *Person)

means:

this method works with a pointer to the original Person.

As a Ruby developer, I probably won't need to think about memory addresses every day.

But understanding pointers gives me a better picture of what's actually happening when Go passes values around.

And that's becoming one of my favorite parts of learning Go:

Ruby lets me stay comfortably high-level.

Go occasionally makes me look under the hood.

Learning Go as a Ruby Developer #6: Living Without Classes

Shrouk Abozeid — Fri, 04 Sep 2026 14:44:56 +0000

One of the questions I had while learning Go was:

If Go doesn't have classes, where do I put my data?

In Ruby, I'm used to creating a class and defining its attributes and behavior there:

class User
  attr_accessor :name, :age

  def initialize(name, age)
    @name = name
    @age = age
  end
end

user = User.new("Alice", 30)

Go doesn't have classes.

Instead, one of the building blocks it gives us is the struct.

A struct is a collection of fields that allows us to group related data together.

Structs in Go

A struct is defined using the struct keyword:

type Person struct {
    Name string
    Age  int
}

Here we're defining a type called Person with two fields:

Name, which is a string
Age, which is an int

We can then create a value of that type.

person := Person{
    Name: "Alice",
    Age:  30,
}

And access its fields using .:

fmt.Println(person.Name)
fmt.Println(person.Age)

This feels quite similar to accessing attributes on a Ruby object:

person.name
person.age

But the underlying idea is different.

Creating Struct Values

There are several ways to initialize a struct.

The first is to provide the values in the same order as the fields:

person := Person{"Alice", 30}

We can also explicitly specify the field names:

person := Person{
    Name: "Alice",
    Age:  30,
}

This second form is easier to understand, especially when a struct has many fields.

We can also initialize only some fields:

person := Person{
    Name: "Alice",
}

The fields we don't specify receive their zero value.

So Age would be:

We can even create an empty struct:

person := Person{}

In that case, all fields get their respective zero values.

This connects nicely with what we saw in Part 2 when talking about zero values.

Structs and Pointers

Structs can also be used with pointers.

For example:

person := &Person{
    Name: "Alice",
    Age:  30,
}

Now person is a pointer to a Person.

We can still access the fields directly:

fmt.Println(person.Name)

Go allows this as a convenient shorthand for dereferencing the pointer first.

Conceptually, this:

person.Name

is an easier way of working with:

(*person).Name

This was another place where Go reminded me of C++.

As a Ruby developer, pointers aren't something I normally think about when working with objects.

In Go, understanding whether you're working with a value or a pointer becomes much more important.

Creating Your Own Types

Go also allows us to create a new named type based on another type.

The syntax is:

type <typename> <datatype>

For example:

type Banana int

Now Banana is its own type based on int.

We can declare a variable using it:

var myBanana Banana = 50

This might look unnecessary at first.

Why create Banana if it's basically an int?

The important idea is that we're giving a type a specific meaning.

Instead of having an application full of anonymous int values, we can create named types that communicate what those values represent.

Ruby's Approach

Ruby is dynamically typed, so we normally don't create separate primitive-based types in the same way.

For example:

age = 30

The variable simply references an Integer.

If we want to represent something like a person, we'd typically create a class:

class Person
  attr_accessor :name, :age
end

Go separates these concepts.

A struct gives us a way to group fields:

type Person struct {
    Name string
    Age  int
}

And a custom type gives us a way to define a new named type:

type Banana int

There doesn't need to be a class involved.

Struct vs Ruby Class

This is where I initially had to change my mental model.

A Ruby class usually combines data and behavior.

class Person
  def initialize(name)
    @name = name
  end

  def say_hello
    puts "Hello #{@name}"
  end
end

A Go struct, on the other hand, primarily describes the data:

type Person struct {
    Name string
}

And later, behavior can be associated with the type using methods.

For example:

func (p Person) SayHello() {
    fmt.Println("Hello", p.Name)
}

Then:

person := Person{Name: "Alice"}

person.SayHello()

We'll look at methods more closely when we continue exploring how Go handles behavior without classes.

Go vs Ruby

Concept	Go	Ruby
Group related data	`struct`	`class`, `Struct`, etc.
Define a struct	`type Person struct { ... }`	`class Person`
Access fields	`person.Name`	`person.name`
Initialize	`Person{Name: "Alice"}`	`Person.new("Alice")`
Missing fields	Get zero value	Depends on initialization
Empty value	`Person{}`	`Person.new`
Pointer to value	`&Person{...}`	No explicit pointer syntax
Custom type	`type Banana int`	No direct equivalent in the same type-system sense

Main idea

Go doesn't really ask you to think in terms of classes first.

Instead, you can start with the data:

type Person struct {
    Name string
    Age  int
}

And that's it.

No constructor is required just to create a value.

No inheritance is involved.

No class hierarchy is necessary.

You simply define the type and create values from it.

But TBH I still like Ruby's object model.

When working on a Rails application, classes provide a natural place for models, services, and domain behavior.

Learning Go as a Ruby Developer #5: Strings and formatting

Shrouk Abozeid — Mon, 17 Aug 2026 14:24:35 +0000

A Go string is essentially a sequence of bytes.

That sounds like a small implementation detail, but once you start dealing with UTF-8 and Unicode, it becomes important to understand what's actually happening.

Strings in Go

A basic Go string looks familiar:

message := "Hello World"

fmt.Println(message)

Strings can use double quotes:

message := "Hello \t World"

Or backticks:

message := `Hello \t World`

And these two behave differently.

With double quotes, escape sequences are interpreted:

fmt.Println("Hello \t World")

The \t becomes a tab.

With backticks, the contents are treated as a raw string literal:

fmt.Println(`Hello \t World`)

Here, \t remains part of the string.

This is useful when you want the contents of a string to be interpreted literally.

A String Is a Sequence of Bytes

Consider:

str := "Hello You!"

We can convert the string to a byte slice:

bytes := []byte(str)

Then print both:

fmt.Printf("%v\n", str)
fmt.Printf("%v\n", bytes)

The output looks like:

Hello You!
[72 101 108 108 111 32 89 111 117 33]

Those numbers represent the individual bytes that make up the string.

For example, the first character:

is represented by the byte:

So when Go says a string is a sequence of bytes, this isn't just an abstract definition.

We can actually see those bytes.

So Where Does UTF-8 Come In?

Computers ultimately store data as binary.

That means we need a way to represent text as numbers that computers can store.

That's where character encodings come in.

UTF-8 stands for:

Unicode Transformation Format – 8-bit

It provides a way to encode Unicode characters using between 1 and 4 bytes per character.

This allows the same encoding to represent characters from many different writing systems.

For example, simple ASCII characters such as:

A
B
C

can be represented using a single byte.

Other Unicode characters can require multiple bytes.

And this is where the distinction between characters and bytes becomes important.

Bytes Are Not Characters

Consider this:

str := "Hello"

Each character in this particular string can be represented by one byte.

But that doesn't mean every character is one byte.

For example, Unicode contains characters that require multiple bytes when encoded as UTF-8.

So if we're dealing with text outside the ASCII range, we can't simply assume:

1 character = 1 byte

This is one of those details I rarely think about when writing normal Ruby application code.

Go makes the underlying representation much more visible.

Ruby Comparison

Ruby also lets us inspect the bytes of a string.

str = "Hello You!"

str.bytes

This gives us the byte values making up the string.

So the underlying concept isn't completely foreign to Ruby.

The difference is that Go's type system and standard library make this distinction much more explicit.

That mental model becomes particularly useful when working with files, network protocols, encodings, and other low-level operations.

Formatting with `fmt`

Another part of my notes that I found useful was Go's fmt package.

It provides formatted output similar to Ruby's printf.

For example:

name := "Alice"
age := 30

fmt.Printf("Name: %s, Age: %d\n", name, age)

The % symbols are called format verbs.

They tell fmt how to format the value.

`%v` — Print the Value

When you're not particularly concerned about the exact formatting, %v is useful.

name := "Alice"

fmt.Printf("%v\n", name)

It prints the value using its default format.

This is one of the formatting verbs I expect to use frequently.

`%T` — Print the Type

One I particularly like while learning Go is %T.

age := 30

fmt.Printf("%T\n", age)

This prints the type of the value.

For example:

int

Coming from Ruby, this reminds me of:

puts age.class

Both are useful when you're trying to understand what you're actually working with.

Formatting Numbers

Go also provides formatting verbs for different number representations.

For example:

number := 42

fmt.Printf("%d\n", number)
fmt.Printf("%b\n", number)
fmt.Printf("%o\n", number)
fmt.Printf("%x\n", number)
fmt.Printf("%X\n", number)

These represent the number in:

%d — decimal
%b — binary
%o — octal
%x — hexadecimal using lowercase letters
%X — hexadecimal using uppercase letters

So:

can be represented as:

in binary.

Characters and Unicode Formatting

Go also provides formatting verbs for characters and Unicode values.

For example:

fmt.Printf("%c\n", 65)

prints:

because 65 corresponds to the Unicode code point for A.

There's also %q for quoted character/string representations.

And %#U can be used to display a Unicode code point in Go syntax.

These formatting options become particularly useful when you're debugging text and encoding-related issues.

Go vs Ruby

Here's how some of these concepts compare.

Concept	Go	Ruby
String	Sequence of bytes	`String` object
String literal	`"Hello"`	`"Hello"`
Raw string	`Hello`	`%q{Hello}` / other forms
Inspect bytes	`[]byte(str)`	`str.bytes`
Print	`fmt.Println`	`puts`
Formatted output	`fmt.Printf`	`printf`
Print type	`%T`	`.class`
Default formatting	`%v`	`puts` / interpolation
Decimal	`%d`	`printf("%d", n)`
Binary	`%b`	`printf("%b", n)`
Hexadecimal	`%x` / `%X`	`printf("%x", n)`
Character	`%c`	`chr` / formatting

When you're working with files, network communication, binary data, or encoding problems, understanding that you're ultimately dealing with bytes becomes extremely valuable.

And this is another recurring theme in my Go journey:

Ruby often lets me forget what's happening underneath.

Go occasionally makes me look underneath the hood.

And sometimes, that's exactly what I need to become a better developer.

Learning Go as a Ruby Developer #4: What can we do with a single "for"

Shrouk Abozeid — Fri, 07 Aug 2026 16:32:53 +0000

So loops in ruby has several ways to implement

10.times do |i|
  puts i
end
while condition
  # ...
end
users.each do |user|
  # ...
end
until finished
  # ...
end

Go looks at all of this and basically says:

We only need one loop.

That loop is for.

Before getting into loops, though, let's look at conditions.

Conditions in Go

Go has the familiar if, else if, and else.

if age >= 18 {
    fmt.Println("Adult")
} else {
    fmt.Println("Minor")
}

The syntax is pretty close to Ruby, but there is one important difference.

Go does not use end.

Ruby:

if age >= 18
  puts "Adult"
else
  puts "Minor"
end

Go uses curly braces to define the block:

if age >= 18 {
    fmt.Println("Adult")
} else {
    fmt.Println("Minor")
}

Coming from Ruby, I had to get used to seeing {} everywhere.

Boolean Operators

The familiar operators are there:

if !active {
    // not active
}

if age == 18 {
    // exactly 18
}

And for inequality:

if age != 18 {
    // not 18
}

So the basic logic isn't particularly difficult to transition to.

It's mostly the syntax that's different.

now going back to loops

The `for` Loop

Go has only one looping construct:

for

The traditional form looks like this:

for init; condition; post {
    // code
}

For example:

for i := 0; i < 10; i++ {
    fmt.Println(i)
}

There are three parts:

Initialization — runs before the first iteration
Condition — checked before every iteration
Post statement — runs after every iteration

This is very similar to the traditional C-style loop.

And this is where my C++ nostalgia started showing up.

Go doesn't have separate times, while, or until loops.

Instead, you use for.

for i := 0; i < 10; i++ {
    fmt.Println(i)
}

One keyword, several forms.

The While-Like `for`

What if we don't need the initialization and post statements?

No problem.

x := 1

for x < 10 {
    fmt.Println(x)
    x++
}

This behaves like a while loop.

In other words:

for condition {
    // ...
}

is Go's version of:

while condition
  # ...
end

This is one of those examples where Go's simplicity starts making more sense.

Instead of introducing another keyword for while, Go reuses for.

Infinite Loops

You can even remove the condition completely:

for {
    // keep going
}

This creates an infinite loop.

Of course, you'll usually want some way to escape it.

That's where break comes in.

x := 1

for {
    if x > 9 {
        break
    }

    fmt.Println(x)
    x++
}

The loop keeps running until the break statement is reached.

Ruby has a similar concept:

x = 1

loop do
  break if x > 9

  puts x
  x += 1
end

Again, Go doesn't need a separate loop construct.

for handles it.

`break` and `continue`

Go also provides the familiar break and continue keywords.

`break`

break exits the loop completely.

for i := 0; i < 10; i++ {
    if i == 5 {
        break
    }

    fmt.Println(i)
}

The loop stops when i reaches 5.

`continue`

continue skips the remaining code in the current iteration and moves to the next one.

for i := 0; i < 10; i++ {
    if i%2 == 0 {
        continue
    }

    fmt.Println(i)
}

This skips even numbers and prints the odd ones.

Ruby has the same concepts:

10.times do |i|
  next if i.even?

  puts i
end

Ruby uses next where Go uses continue.

`range`: The Go Way to Iterate Over Collections

The for loop becomes even more interesting when combined with range.

The range form allows you to iterate over collections such as:

arrays
slices
strings
maps
channels

For example:

names := []string{"Alice", "Bob", "Charlie"}

for index, name := range names {
    fmt.Println(index, name)
}

This gives us both the index and the value.

The output would look conceptually like:

0 Alice
1 Bob
2 Charlie

Comparing `range` with Ruby

In Ruby, I'd probably write:

names = ["Alice", "Bob", "Charlie"]

names.each_with_index do |name, index|
  puts "#{index} #{name}"
end

Or, if I don't need the index:

names.each do |name|
  puts name
end

In Go, range handles both cases.

for index, name := range names {
    fmt.Println(index, name)
}

And if I only care about the value, I can ignore the index:

for _, name := range names {
    fmt.Println(name)
}

The _ tells Go that I intentionally don't need that value.

Switch Statements

Go also has switch for conditional logic.

A simple switch looks like this:

switch name {
case "Moneypenny":
    fmt.Println("Miss Moneypenny")
case "Bond":
    fmt.Println("Bond, James Bond")
case "Q":
    fmt.Println("This is Q")
default:
    fmt.Println("Unknown")
}

Unlike Ruby's case, Go doesn't require an end.

Ruby:

case name
when "Moneypenny"
  puts "Miss Moneypenny"
when "Bond"
  puts "Bond, James Bond"
when "Q"
  puts "This is Q"
else
  puts "Unknown"
end

But there is another interesting form of Go's switch.

Switch Without an Expression

You can leave the value out completely:

switch {
case age < 18:
    fmt.Println("Minor")
case age >= 18:
    fmt.Println("Adult")
}

Each case is essentially a condition.

This can be useful when you have several related conditions.

Ruby's case can also be used for conditional expressions, although the syntax and matching behavior are different.

Multiple Values in a Case

A Go case can match multiple values:

switch name {
case "Moneypenny", "Bond", "Dr No":
    fmt.Println("Secret agent")
default:
    fmt.Println("Unknown")
}

This means we don't need separate cases for every value when they should produce the same result.

`fallthrough`

One thing that caught my attention was fallthrough.

Normally, once a Go switch finds a matching case, it stops.

switch {
case true:
    fmt.Println("first")
case true:
    fmt.Println("second")
}

Only the first case runs.

If you explicitly use fallthrough:

switch {
case true:
    fmt.Println("first")
    fallthrough

case true:
    fmt.Println("second")

case true:
    fmt.Println("third")
}

The first and second cases run, but the third does not.

This is different from the behavior many people might expect from C-style switch statements, where falling through can happen unless you explicitly stop it.

Go makes the behavior explicit with fallthrough.

Go vs Ruby: Control Flow

Here's how the two languages compare.

Concept	Go	Ruby
Condition	`if` / `else`	`if` / `else`
Not	`!`	`!`
Equality	`==`	`==`
Inequality	`!=`	`!=`
Main loop	`for`	Multiple constructs
While loop	`for condition`	`while condition`
Infinite loop	`for {}`	`loop do`
Iterate collection	`for ... range`	`.each`
Skip iteration	`continue`	`next`
Exit loop	`break`	`break`
Switch	`switch`	`case`
Multiple switch values	`case "a", "b"`	`when "a", "b"`

Neither approach is necessarily better.

They're just optimizing for different things.

Design Patterns in Ruby #5: Abstract Factory Pattern

Shrouk Abozeid — Wed, 05 Aug 2026 16:02:00 +0000

In the previous article, we explored the Factory Method pattern and saw how it delegates object creation to subclasses.

But what if your application doesn't need to create just one object?

What if it needs an entire family of related objects that are designed to work together?

That's exactly the problem the Abstract Factory pattern solves.

The Problem

Imagine you're building an e-commerce application that supports multiple payment providers.

Your application currently integrates with:

Stripe
PayPal

For each payment provider, you need several related objects:

A Payment processor
A Refund processor
A Customer service

For Stripe, those objects might be:

StripePayment
StripeRefund
StripeCustomer

For PayPal:

PayPalPayment
PayPalRefund
PayPalCustomer

If you instantiate each object manually, your code quickly becomes filled with conditionals:

if provider == :stripe
  payment = StripePayment.new
  refund  = StripeRefund.new
  customer = StripeCustomer.new
else
  payment = PayPalPayment.new
  refund  = PayPalRefund.new
  customer = PayPalCustomer.new
end

The problem isn't creating a single object anymore.

It's ensuring that all related objects come from the same payment provider.

The client shouldn't accidentally create a StripePayment with a PayPalRefund.

Abstract Factory

The Gang of Four defines Abstract Factory as:

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Instead of asking for individual objects, the client asks a factory to provide an entire family.

StripeFactory
 ├── Payment
 ├── Refund
 └── Customer

PayPalFactory
 ├── Payment
 ├── Refund
 └── Customer

The client never knows which concrete classes it's using.

It only communicates with the factory interface.

Structure

The pattern consists of five participants.

Abstract Factory

Defines the interface for creating every product in the family.

create_payment
create_refund
create_customer

Concrete Factory

Implements the Abstract Factory.

Each concrete factory creates one complete product family.

Examples:

StripeFactory
PayPalFactory

Abstract Product

Defines the common interface shared by each product.

Examples:

Payment
Refund
Customer

Concrete Products

The concrete implementations belonging to a specific family.

StripePayment
StripeRefund
StripeCustomer

PayPalPayment
PayPalRefund
PayPalCustomer

Client

The client depends only on the Abstract Factory.

At runtime, it receives whichever concrete factory is needed.

This completely decouples the client from concrete implementations.

Ruby Example

Products

class StripePayment
  def process(amount)
    puts "Charging $#{amount} with Stripe"
  end
end

class StripeRefund
  def process(transaction_id)
    puts "Refunding #{transaction_id} through Stripe"
  end
end

class StripeCustomer
  def create(name)
    puts "Creating Stripe customer: #{name}"
  end
end

class PayPalPayment
  def process(amount)
    puts "Charging $#{amount} with PayPal"
  end
end

class PayPalRefund
  def process(transaction_id)
    puts "Refunding #{transaction_id} through PayPal"
  end
end

class PayPalCustomer
  def create(name)
    puts "Creating PayPal customer: #{name}"
  end
end

Abstract Factory

class PaymentProviderFactory
  def create_payment
    raise NotImplementedError
  end

  def create_refund
    raise NotImplementedError
  end

  def create_customer
    raise NotImplementedError
  end
end

Concrete Factories

class StripeFactory < PaymentProviderFactory
  def create_payment
    StripePayment.new
  end

  def create_refund
    StripeRefund.new
  end

  def create_customer
    StripeCustomer.new
  end
end

class PayPalFactory < PaymentProviderFactory
  def create_payment
    PayPalPayment.new
  end

  def create_refund
    PayPalRefund.new
  end

  def create_customer
    PayPalCustomer.new
  end
end

Client

class CheckoutService
  def initialize(factory)
    @factory = factory
  end

  def checkout(customer_name, amount)
    customer = @factory.create_customer
    payment = @factory.create_payment

    customer.create(customer_name)
    payment.process(amount)
  end

  def refund(transaction_id)
    refund = @factory.create_refund
    refund.process(transaction_id)
  end
end

Using the client:

factory = StripeFactory.new
checkout = CheckoutService.new(factory)

checkout.checkout("Alice", 100)
checkout.refund("txn_123")

Switching to PayPal requires changing only one line:

factory = PayPalFactory.new
checkout = CheckoutService.new(factory)

The rest of the application remains unchanged.

Notice that CheckoutService never references StripePayment, PayPalPayment, or any other concrete implementation.

It only communicates with the Abstract Factory.

Factory Method vs Abstract Factory

Although both patterns deal with object creation, they solve different problems.

Factory Method	Abstract Factory
Creates one product	Creates a family of related products
Uses inheritance	Uses object composition
Subclasses decide what to create	A factory object decides which family to create
Best when object creation varies	Best when entire product families vary

Another way to think about it:

Factory Method asks:

Which object should I create?

Abstract Factory asks:

Which family of objects should I create?

Adding New Products vs New Families

Suppose our payment providers now support webhooks.

We need another product:

create_webhook

With Abstract Factory, the abstract factory interface must change.

class PaymentProviderFactory
  def create_payment; end
  def create_refund; end
  def create_customer; end
  def create_webhook; end
end

Every concrete factory (StripeFactory, PayPalFactory, etc.) must also implement create_webhook.

On the other hand, if you add a completely new payment provider—say Adyen—you simply introduce a new concrete factory:

AdyenFactory
 ├── AdyenPayment
 ├── AdyenRefund
 ├── AdyenCustomer

The existing factories remain unchanged.

That's why people often say:

Factory Method is open to new creators.
Abstract Factory is open to new product families.

Where You'll See It in Rails

Although Rails doesn't explicitly label it as the Abstract Factory pattern, the idea appears in several places.

Active Storage

Depending on your configuration, Rails creates a family of storage-related objects for:

Local Disk
Amazon S3
Google Cloud Storage
Azure Blob Storage

Your application interacts with a common interface while Rails supplies the correct implementation behind the scenes.

When Should You Use It?

Use Abstract Factory when:

Your application works with multiple product families.
Objects within a family should always be used together.
You want to switch implementations through configuration.
You want to isolate your application from concrete classes.

Avoid it when you only need to create a single object. In that case, Factory Method or even a Simple Factory is usually a better fit.

Key Takeaways

The Factory Method pattern creates one object and relies on inheritance to determine which concrete product to instantiate.

The Abstract Factory pattern creates families of related objects and relies on composition to swap entire implementations at runtime.

A simple rule to remember is:

Factory Method answers: Which object should I create?

Abstract Factory answers: Which family of objects should I create?

for a full example in ruby check this https://github.com/ShroukAbozeid/design-pattern/tree/main/factory/abstract_factory

Design Patterns in Ruby #4: Simple Factory vs Factory Method

Shrouk Abozeid — Tue, 04 Aug 2026 15:00:00 +0000

When building applications, creating an object is rarely as simple as calling User.new.

Different objects may require different initialization logic, validation, external API calls, or configuration. If every class is responsible for deciding what object to create, this logic quickly becomes scattered throughout the codebase.

Factory patterns solve this problem by separating object creation from object usage, making the code easier to maintain and extend.

Let's look at the two most common approaches: Simple Factory and Factory Method.

Simple Factory

it is not actually a design pattern by the book but it is commonly used.

it has a very basic idea of encapsulating the objects creation from it’s usage

it has a class ‘Simple Factory’ that contains the logic of creating objects , that factory is used in a “client” to create the objects then use it

Instead of allowing clients to instantiate objects directly, a single factory class becomes responsible for deciding which object should be created.

Structure

A Simple Factory consists of:

A factory class that contains all the object creation logic.
A single factory method that returns different objects based on some condition.
A client that uses the factory instead of creating objects directly.

a naive implementation of simple factory in ruby

class UserSimpleFactory
  def self.create_user(type, user_args)
    case type
    when 'admin'
      Admin.create(name: user_args[:name], email: user_args[:email], password: user_args[:password])
    when 'customer'
      Customer.create(name: user_args[:name], email: user_args[:email], password: user_args[:password])
    when 'guest'
      Guest.create(name: user_args[:name], country: user_args[:country])
   else
     raise 'INVALID_TYPE'
   end
  end
end

class RegisterHandler
  def create_user(params)
    user = UserSimpleFactory.create_user(params[:type], params[:user])
  end

  def register(params)
    user = create_user(params)
    "Hello #{user.name}"
  end
end

Advantages

Centralizes object creation.
Keeps clients from depending on concrete classes.
Easy to understand and implement.

The Problem

This works well while you only have a few product types.

However, every time a new user type is introduced, the factory needs another when branch.

Eventually the factory becomes a large conditional statement responsible for creating every possible object.

This violates the Open/Closed Principle because adding a new product requires modifying an existing class.

at that time you might think to extract parts of this method into different classes and voilà you get a factory method pattern

Factory Method

The Gang of Four defines Factory Method as:

Define an interface for creating an object, but let subclasses decide which class to instantiate.

this pattern lets a class defer instantiation to subclass. and encapsulates the instantation of concrete types

The parent class defines the workflow, while each subclass decides which concrete object should be created.

This removes the need for long case statements and replaces them with polymorphism.

Structure

Abstract creator : it gives you an interface with method(THE factory method) to create object(product), any other method on this class operates on the object returned by the factory method
Concrete creator : is a subclass that implement the factory method
Abstract product; interface(parent) of all products that different concrete creators return
Concrete product must implement the same interface so that the factories can refere to the interface not the concrete classes

this pattern decouples the implementation of the product from its use

class RegisterHandler
  def create_user(user_args)
    raise NotImplementedError
  end

  def register(params)
    user = create_user(params)
    "Hello #{user.name}"
  end
end

class AdminRegister < RegisterHandler
  def create_user(user_args)
    Admin.create(name: user_args[:name], email: user_args[:email], password: user_args[:password])
  end
end

class CustomerRegister < RegisterHandler
  def create_user(user_args)
    Customer.create(name: user_args[:name], email: user_args[:email], password: user_args[:password])
  end
end

class GuestRegister < RegisterHandler
  def create_user(user_args)
    Guest.create(name: user_args[:name], country: user_args[:country])
  end
end

Notice that the register method is implemented only once.

The only thing subclasses customize is how the user is created.

The registration workflow remains unchanged regardless of the user type.

Advantages

Eliminates large conditional statements.
Follows the Open/Closed Principle.
Makes it easy to introduce new product types.
Uses polymorphism instead of branching logic.
Keeps creation logic isolated inside dedicated creator classes.

The trade-off is that it introduces more classes, which can feel unnecessary for small applications.

Did you know that Rails framework is full of Factory patterns? 👀

Example: Action Mailer

Every mailer inherits from ApplicationMailer

When you define

class UserMailer < ApplicationMailer
  def welcome(user)
    mail(to:user.email)
  end
end

The framework handles the workflow of building and delivering an email.

Your subclass supplies the message-specific details.

Example: Active Job adapters

You write:

class SendEmailJob < ApplicationJob
end

Then configure:

config.active_job.queue_adapter = :solid_queue

config.active_job.queue_adapter = :sidekiq

Each adapter creates its own queue implementation.

Rails defines the workflow.

The adapter subclasses provide the implementation

Key Takeaways

A Simple Factory centralizes object creation using conditional logic. It's a pragmatic solution for smaller applications but becomes harder to maintain as the number of products grows.

Factory Method takes a different approach by replacing those conditionals with polymorphism. Instead of modifying one factory every time a new product is added, you create a new creator class that knows how to build that product.

A good rule of thumb is this:

If your factory keeps getting longer every time you introduce a new product, it's probably time to replace it with Factory Method.

for a full example in ruby check this https://github.com/ShroukAbozeid/design-pattern/tree/main/factory

Snehal Ahire - Rails Under a Microscope: Summarized with AI

Shrouk Abozeid — Wed, 29 Jul 2026 13:12:23 +0000

Sometimes I'm lazy to talk notes myself(which ofcourse is better) but instead of not talking notes at all i let ai summarize what i just watched to make sure i didn't drop anything.

in this video Snehal Talks about performance problems that developers can face in large scale application and what could be some of the causes.

So here is her talk in points :D

Rails Performance Challenges

Performance issues in Rails applications, such as slow listing pages, delayed search queries, and long-running Sidekiq batches, cause significant frustration for both users and developers.
Persistent performance bottlenecks lead to increased infrastructure costs and delays in feature development, making performance optimization a necessity for application survival.
While developers may be tempted to rewrite slow Rails applications in languages like Rust or Go, such rewrites are often risky and costly; instead, applications should be analyzed to identify specific bottlenecks.

Data Retrieval Optimization

Code that appears innocent in the early stages of an application can evolve into a performance bottleneck as the system scales over many years.
Common performance issues in mature applications include memory bloat, memory leaks, and inefficient database queries.
Fetching unnecessary data, such as loading all columns when only a few are needed, is inefficient and becomes increasingly problematic as the number of rows grows into the millions.
Developers should optimize data retrieval by selecting only the specific columns required for the task.

Pagination Strategies

Standard pagination using offset is suitable for small datasets but becomes inefficient for large databases because the system must scan and discard all preceding records to reach the requested page.
Keyset pagination is a more efficient alternative for large datasets because it fetches only the required data without scanning and discarding previous records.
Keyset pagination is index-friendly, leveraging indexed columns like ID or created_at to provide consistent performance regardless of how deep into the dataset the user navigates.
Keyset pagination is an effective strategy for features like "Load More" or infinite scrolls because it uses pointers from the last row of a previous page to start the next query, though it prevents direct navigation to specific page numbers.

Query and Caching Best Practices

To prevent N+1 queries, Rails 7 and later versions offer strict loading features that can be used during development to avoid accidental performance issues.
Caching should only be implemented when the value of recomputing data exceeds the costs associated with cache maintenance and invalidation, as improper caching can negatively impact performance.

Memory Management and Heap Fragmentation

Memory bloat occurs when there is a significant discrepancy between the actual size of live objects in an application and the Resident Set Size (RSS) reported by the system.
The Memory Profiler gem is a tool used to diagnose memory issues by identifying memory allocations and retained objects, categorized by gem, location, class, or specific line of code.
Memory consumption in Ruby is often driven by arrays, strings, and hashes, which are dynamic allocations stored in the heap, while static functions are managed in the stack.
Ruby manages heap memory by dividing pages into multiple slots; when a new object is created, Ruby searches for a free slot within these pages.
When a page is full, Ruby requests additional pages from the system allocator—such as Malloc or Jemalloc—rather than communicating directly with the operating system.
Heap fragmentation occurs when the garbage collector frees objects, leaving non-adjacent holes in memory that are too small or poorly positioned to accommodate new object allocations.
Because Ruby cannot utilize these non-adjacent free slots, it is forced to request more pages from the system allocator, leading to an increase in total memory usage despite the presence of free space.

Allocator and Garbage Collection Dynamics

Allocator fragmentation also occurs when the system allocator cannot merge non-adjacent memory blocks, a problem that can be mitigated in multi-threaded environments like Sidekiq by configuring Malloc Arena Max to two or four.
Increased numbers of arenas contribute to higher levels of memory fragmentation.
Locators retain memory and maintain caches of different block sizes to facilitate instant future allocations.
Garbage collectors do not immediately return memory to the system, instead retaining it for future use, which keeps process memory usage high even when objects are no longer needed.
Configuring the heap growth factor can help manage fragmentation, as a higher factor results in less fragmentation.
Ruby 3.2 introduced variable width allocation, which manages slots through size pools rather than statically to reduce memory bloat and fragmentation, though its effectiveness depends on code support.
Memory bloat is primarily caused by heap fragmentation, allocator fragmentation, allocators reserving extra memory, and the garbage collector holding onto memory.
Resident Set Size (RSS) refers to the amount of RAM a specific process uses.

Memory Optimization Techniques

Loading large datasets into an array can be optimized by using batches with configurable batch sizes instead of loading all records at once.
Converting large datasets to JSON within Ruby consumes significant memory; offloading this process to the database using functions like row_to_json or json_agg is more efficient.
Reading large CSV files should be done line-by-line or using foreach rather than loading millions of rows into memory at once.
Creating temporary objects inside loops, such as date objects, leads to excessive memory usage over millions of iterations; these objects should be created once before the loop and reused, ideally using freeze.
Using include? on arrays inside loops creates new arrays in every iteration, which can be avoided by using a Set for faster retrieval and freezing the collection.

Bulk Operations and Database Efficiency

The destroy method loads all associations into memory, whereas delete_all performs a single operation without callbacks or associations, though it requires manual handling of child records to avoid orphaned objects.
Per-record updates can trigger N+1 query issues and high memory usage; bulk operations like upsert, update_all, or upsert_all are more efficient alternatives.
Inserting rows one by one for associations, such as orders and line items, creates memory overhead when processing multiple rows.
Bulk queries can be optimized by using insert or upsert operations instead of individual queries.
Memory bloat issues can be addressed by utilizing batches, reusing data, and freezing objects to prevent redundant object creation.

Identifying and Resolving Memory Leaks

A gradual, steady increase in memory usage over time often indicates a memory leak, even if restarting the process temporarily resolves the symptoms.
Symptoms of a memory leak include a steadily growing Resident Set Size (RSS) that does not decrease after Sidekiq jobs, a heap of objects that are never deallocated, and frequent garbage collection (GC) pauses as the system struggles to clean up unreleased objects.
Unbounded in-memory objects, such as those stored in class or global variables, can cause memory leaks because the garbage collector cannot release them as long as they remain referenced.
Replacing class or global variables with local methods allows the garbage collector to automatically free memory after the data is used.
Closures can lead to memory leaks if they capture large objects rather than specific values, as the captured variables are not released.
Passing only the specific data required, such as a calculated size rather than an entire array, prevents unnecessary memory retention.
Implementing these memory optimizations resulted in a 42% reduction in memory usage (from 788 MB to 459 MB) and an 80% reduction in the number of objects (from 11 million to 2 million), while performance time improved from 2 minutes to between 10 and 20 seconds.

Database Query Tuning and Indexing

Database query performance can be analyzed and tuned using the EXPLAIN ANALYZE command in PostgreSQL.
Adding specific conditions to a query can shift the execution plan from a slow parallel sequential scan to a significantly faster index scan, as demonstrated by a reduction in execution time from 2,800 milliseconds to 0.7 milliseconds.
Partial indexes are effective only when queries include the specific index conditions, and neglecting these details can lead to high execution times.
Small, neglected features or individual application problems can cause significant performance degradation across an entire system.
Materialized views in Postgres serve as physical tables that store computed data, offering an alternative to complex joins across multiple tables or the complications of using read replicas.
Postgres features such as TS vectors combined with GIN indexes allow for efficient searching across multiple columns by creating a vector for direct querying.

Scaling and Infrastructure Management

Sidekiq can be autoscaled using latency-based queuing, which organizes tasks into multiple queues based on their latency requirements.
Specialized GIN indexes, which support various operators, can be utilized to achieve faster retrieval speeds for JSON columns.

Performance Culture and Workflow Integration

Performance optimization should begin with **profiling and measurement **rather than relying on intuition to identify bottlenecks.
Database capabilities, including indexes, aggregations, and bulk operations, should be leveraged for heavy tasks rather than attempting to reinvent these processes.
Identifying data patterns and understanding how data is derived and processed is essential, as even minor inefficiencies accumulate at scale.
Performance management is a collaborative responsibility that should be shared across the entire team.
P*erformance should be integrated into the development workflow* by setting budgets and monitoring metrics throughout the design, build, and shipping phases, rather than treating it as an afterthought.
Addressing performance issues requires a continuous, multi-faceted approach rather than a one-time fix or a complete rewrite of the application in a different language.

Thanks Snehal for an interesting talk and a great presentation, if you know her profile tag her for credits

Learning Go as a Ruby Developer #3: Functions, Methods, and Why Go Doesn't Have Classes

Shrouk Abozeid — Mon, 27 Jul 2026 14:59:31 +0000

One of the biggest mindset shifts I've had while learning Go came when I reached functions and methods.

As a Ruby developer, almost everything revolves around objects. Every piece of behavior belongs to a class, and every function is really just a method attached to an object.

Go takes a different approach.

Functions exist independently, and methods are simply functions with a receiver. There are no classes, no inheritance, but still writing object-oriented code.

Let's see how Go approaches behavior compared to Ruby.

Why This Felt Strange Coming from Ruby

In Ruby, we rarely think about standalone functions because they don't really exist.

Everything is an object.

class Calculator
  def add(a, b)
    a + b
  end
end

calculator = Calculator.new
calculator.add(2, 3)

Want behavior?

Create a class.

Need reusable logic?

Another class or a module.

Go starts from a much simpler place.

Most behavior begins as just... a function.

Functions in Go

Functions are declared using the func keyword.

func add(a int, b int) int {
    return a + b
}

The syntax may look unusual at first, especially if you've spent years writing Ruby.

Instead of writing the return type first, Go places it after the parameter list.

Calling the function is exactly what you'd expect.

result := add(2, 3)

Grouping Parameters

Go lets you group parameters that share the same type.

Instead of writing:

func add(a int, b int) int

you can write:

func add(a, b int) int {
    return a + b
}

It's a small feature, but it keeps function declarations much cleaner.

Returning Multiple Values

func divide(a, b int) (int, int) {
    return a / b, a % b
}

Then you can capture both results.

quotient, remainder := divide(10, 3)

Coming from Ruby, this felt familiar because Ruby also supports multiple assignment.

def divide(a, b)
  [a / b, a % b]
end

quotient, remainder = divide(10, 3)

The difference is that in Ruby we're really returning an array, while in Go multiple return values are part of the language itself.

Named Return Values

One feature I wasn't expecting was named return values.

Instead of writing:

func sum(a, b int) int {
    return a + b
}

you can write:

func sum(a, b int) (result int) {
    result = a + b
    return
}

Notice the bare return.

Because result was named in the function signature, Go automatically returns it.

This is called a naked return.

Anonymous Functions

Go also supports anonymous functions.

You can assign them to variables.

greet := func(name string) {
    fmt.Println("Hello", name)
}

Or execute them immediately.

func() {
    fmt.Println("Running immediately")
}()

This reminded me a lot of Ruby blocks and lambdas.

greet = ->(name) { puts "Hello #{name}" }

greet.call("Alice")

Although the syntax is different, the concept feels familiar.

Variadic Functions

Sometimes you don't know how many arguments a function should accept.

Go solves this using variadic parameters.

func printNumbers(numbers ...int) {
}

The ... tells Go to collect all arguments into a slice.

Ruby has something very similar.

def print_numbers(*numbers)
end

This was one of the easiest concepts for me to understand because the two languages approach it almost the same way.

So Where Are the Classes?

This was the question I kept asking while reading through the documentation.

If Go doesn't have classes...

Where do methods live?

The answer surprised me.

Methods belong to types, not classes.

Methods in Go

A method is simply a function with a receiver.

type Person struct {
    Name string
}

func (p Person) SayHello() {
    fmt.Println("Hello,", p.Name)
}

Now we can call it like this.

person := Person{Name: "Alice"}
person.SayHello()

The syntax felt unusual at first.

Instead of defining the method inside the type like Ruby does, the receiver appears before the method name.

func (receiver Type) MethodName() {
}

Value Receivers

By default, methods receive a copy of the value.

func (p Person) Rename(name string) {
    p.Name = name
}

Changing p.Name only changes the copy.

The original object stays exactly the same.

This is called a value receiver.

Pointer Receivers

If you want to modify the original value, you use a pointer receiver.

func (p *Person) Rename(name string) {
    p.Name = name
}

Now changes affect the original struct.

This distinction between value and pointer receivers was one of the first places where Go reminded me of C++.

Ruby developers usually don't think about this because objects are already passed around by reference-like semantics.

Go asks you to decide whether you're working with a copy or the original value.

Side-by-Side Comparison

Go	Ruby
Standalone functions	Everything is a method
`func` keyword	`def` keyword
Multiple return values	Usually arrays or multiple assignment
Anonymous functions	Lambdas and Procs
Variadic parameters (`...`)	Splat operator (`*`)
Methods attached to types	Methods defined inside classes
Value receivers	Objects usually mutated directly
Pointer receivers	Reference-like object semantics

Thoughts

Ruby's object model is incredibly elegant.

Everything feels consistent because everything is an object.

Go takes a more lightweight approach.

Instead of encouraging you to wrap every behavior inside a class, it asks a simple question:

Does this really need to belong to a type?

Sometimes the answer is yes—a method makes sense.

Other times, a standalone function is perfectly fine.

Go is trying to remove the parts it considers unnecessary while keeping the parts that are genuinely useful.

This has been one of the most interesting lessons so far in my Go journey, what about you?

Learning Go as a Ruby Developer # 2: Variables, Constants, and Why Go Doesn't Trust You

Shrouk Abozeid — Sat, 25 Jul 2026 14:20:50 +0000

One of the first differences I noticed when learning Go was how seriously it takes types.

Coming from Ruby. I rarely think about their types because Ruby figures everything out at runtime.

Go has a very different philosophy.

It wants to know exactly what every variable is, and if it doesn't know, it'll ask you to be explicit.

Why This Felt Strange Coming from Ruby

In Ruby, creating variables couldn't be easier.

name = "Alice"
age = 30
admin = true

Ruby decides the type at runtime.

Later I can even do something like this:

value = 10
value = "hello"
value = [1, 2, 3]

The same variable can hold completely different kinds of objects throughout the program.

Go doesn't allow that.

Once a variable has a type, that type is fixed.

Declaring Variables in Go

The most explicit way to declare a variable is by specifying its type.

var age int = 30
var name string = "Alice"
var admin bool = true

This is checked during compilation, long before your program ever runs.

If you later try to assign a different type, the compiler will stop you immediately.

This felt a bit strict—but it also means many bugs are caught before the program starts.

Type Inference

Fortunately, Go doesn't always require you to write the type yourself.

It can often infer it.

var admin = false

Go knows this is a bool.

Likewise:

var message = "Hello World"

becomes a string.

Short Variable Declaration

Inside functions, Go provides an even shorter syntax.

message := "Hello World"
count := 10

The := operator both declares the variable and lets Go infer its type.

If you're writing local variables, you'll probably use this style most of the time.

One thing I learned from my notes is that this syntax can only be used inside functions.

Declaring Multiple Variables

Go also makes it easy to declare multiple variables.

var x, y, z int = 12, 15, 10

or with inferred types:

var a, b, c = "hi", 30, true

For larger groups, Go encourages this style:

var (
    host string = "localhost"
    port int = 8080
    debug bool = true
)

Constants

Constants are declared using const.

const MaxUsers = 100

You can also group them.

const (
    Enabled = true
    Pi = 3.14
)

Unlike variables, constants cannot be changed after they're declared.

Ruby has constants too:

MAX_USERS = 100

But every Ruby developer knows the truth...

Ruby will happily let you change it.

MAX_USERS = 200

You'll get a warning, not an error.

Go, on the other hand, simply refuses.

Zero Values

If you declare a variable without assigning anything, Go automatically initializes it.

var age int
var active bool
var name string

The values become:

Type	Zero Value
int	0
float64	0.0
bool	false
string	""

Coming from Ruby, I expected something similar to nil.

Instead, Go gives every type a sensible default.

That design avoids a lot of unnecessary initialization code.

Type Conversion

Another thing that immediately stood out was that Go doesn't automatically convert between types.

Suppose we have:

var i int = 45

Converting it to a floating-point number requires an explicit conversion.

var f float64 = float64(i)

Likewise:

var u uint = uint(f)

Every conversion must be intentional.

Ruby is much more forgiving.

number = "45"

number.to_i
number.to_f

And in many cases Ruby performs conversions automatically for you.

Go deliberately avoids this.

Creating Values with `make`

One line in my notes that initially confused me was this:

numbers := make([]int, 3)

Unlike arrays in many languages, make creates and initializes certain built-in data structures.

In this example, it creates a slice with a length of three.

I'll dive much deeper into slices later in the series, but for now it's enough to know that make is commonly used when creating slices, maps, and channels.

So to conclude:

Changing a type?

Be explicit.

Creating a variable?

Be explicit—or let the compiler infer it.

Converting numbers?

Be explicit.

At first it felt like the language didn't trust me :D

Now I think it's more accurate to say Go doesn't trust assumptions.

Instead of guessing what I meant, it asks me to say exactly what I want.

Ruby optimizes for flexibility.
Go optimizes for correctness.

Learning Go as a Ruby Developer # 1: How Go Programs Actually Run

Shrouk Abozeid — Tue, 14 Jul 2026 15:00:00 +0000

Recently I started learning Go, and one of the first things I noticed was how much it reminded me of C++.
I haven't touched C++ since college, so Go gives me a weird sense of nostalgia :D

As a Ruby developer, I'm used to writing code and simply executing it.
Go, however, has a much stronger notion of what a program actually is and how it starts running.

In this article, I want to explore how a Go program is structured and compare it with how we typically think about programs in Ruby

Why This Felt Strange Coming from Ruby

In Ruby, writing a program is straightforward:

puts "Hello World"

Save it as hello.rb and run:

ruby hello.rb

There's no special package declaration, no imports required for basic programs, and no designated entry point function.

Go takes a very different approach.

Every executable Go program follows a specific structure, and understanding this structure is one of the first steps to becoming comfortable with the language.

How Go Programs Are Structured

A typical Go file looks like this:

package main
import (
 "fmt" 
) 

func main() {
 fmt.Println("Hello World")
}

There are three important pieces here:

1. Package Declaration

Every Go file begins with a package declaration:

package main
Packages are Go's mechanism for organizing code.

If you want to build an executable application, the package must be named main.

2. Imports

Go requires explicit imports:

import (
    "fmt"
)

The compiler will actually complain if you import something you don't use.

As a Ruby developer, this felt unusual because Ruby happily allows unused
requires:

require 'json'
require 'csv'

puts "Hello"

Go prefers keeping dependencies explicit and clean.

3. The main Function

Every executable Go program starts execution in:

func main() {
}

The mainfunction:

accepts no arguments
returns no values
acts as the application's entry point

When main() finishes, the program exits.

How Program Execution Works

According to the Go specification, a complete program consists of:

one package named main
all packages imported by main
all transitive dependencies

Program execution happens in two stages:

Initialize packages
Execute main()

Once main()returns, the program terminates.

Running vs Building Programs

Go provides two common ways to execute code.

Run directly

go run hello.go

This compiles and runs the program immediately.

Build an executable

go build hello.go
./hello

This creates a standalone binary.

In Ruby: applications are distributed as source code and interpreted at runtime.

Coming from Rails, where so much setup happens automatically, Go feels so explicit.

At the same time, that explicitness means you have to think about things that Ruby usually hides from you.

while Ruby optimizes for developer happiness and speed of iteration, Go forces me to understand what's actually happening.

What about you? do you use Ruby or Go, or both ? and how was the transition for you ?

DEV Community: Shrouk Abozeid

Threading and Code Execution in Rails: Executor, Reloader, and Load Interlock

1. How Rails Handles Concurrency

2. The Rails Executor

What does the Executor actually do?

What if we create our own thread?

What if we can't use wrap?

3. The Rails Reloader

How do we use the Reloader?

Executor vs. Reloader

4. What Happens During a Reload?

5. How Rails Uses These Mechanisms

HTTP requests

Active Job

Action Cable

What about production?

6. The Load Interlock

Why can't two threads load the same class independently?

What does the Executor have to do with it?

7. How permit_concurrent_loads Prevents Deadlocks

The solution

Why must we be careful?

8. Practical Takeaways

Conclusion

The Rails Initialization Process: From bin/rails to a Running Server

1. Launching Rails

bin/rails

config/boot.rb

2. Resolving the Rails command

rails/commands.rb

rails/command.rb

3. Preparing the server

What is Rails::Server?

4. Loading the application configuration

Loading rails/all

Defining Rails::Application

5. Building the Rack application

6. Initializing Rails

config/environment.rb

rails/all.rb and the Railties

Running initializers

7. From Rails.application to the HTTP server

The complete flow

Final thoughts

Learning Go as a Ruby Developer #7: Finally Understanding Pointers

So What Is a Pointer?

Getting the Value Back

Changing a Value Through a Pointer

Pointers with Functions

This Is Where Ruby Feels Very Different

Pointers and Structs

Pointer Receivers

Value Receiver vs Pointer Receiver

Go vs Ruby

What Surprised Me

The Main Idea

Learning Go as a Ruby Developer #6: Living Without Classes

Structs in Go

Creating Struct Values

Structs and Pointers

Creating Your Own Types

Ruby's Approach

Struct vs Ruby Class

Go vs Ruby

Main idea

Learning Go as a Ruby Developer #5: Strings and formatting

Strings in Go

A String Is a Sequence of Bytes

So Where Does UTF-8 Come In?

Bytes Are Not Characters

Ruby Comparison

Formatting with fmt

%v — Print the Value

%T — Print the Type

Formatting Numbers

Characters and Unicode Formatting

Go vs Ruby

Learning Go as a Ruby Developer #4: What can we do with a single "for"

Conditions in Go

Boolean Operators

What if we can't use `wrap`?

7. How `permit_concurrent_loads` Prevents Deadlocks

`bin/rails`

`config/boot.rb`

`rails/commands.rb`

`rails/command.rb`

What is `Rails::Server`?

Loading `rails/all`

Defining `Rails::Application`

`config/environment.rb`

`rails/all.rb` and the Railties

7. From `Rails.application` to the HTTP server

Formatting with `fmt`

`%v` — Print the Value

`%T` — Print the Type

The `for` Loop

The While-Like `for`

`break` and `continue`

`break`

`continue`

`range`: The Go Way to Iterate Over Collections

Comparing `range` with Ruby

`fallthrough`