Posts tagged with "rails"

Hey folks, what’s up? I’ve been diving into Phoenix and Rails lately, and I wanted to share a casual rundown of what I’ve found.

Grab your favorite drink and let’s roll.

Why you might care

Both frameworks let you serve HTML, build APIs, and even add real time features. But they come from different worlds, so your choice really depends on what you value: performance, dev XP, community size…

12 points of comparison

1. Language

   • Rails runs on Ruby, which reads almost like English and is super beginner friendly.
   • Phoenix is built with Elixir, a functional language on the Erlang VM, so you get actor model concurrency by default.

2. Concurrency and performance

   • Phoenix rides on the BEAM VM, so handling thousands of sockets or long lived processes is a breeze.
   • Rails can scale too, but you’ll often set up extra threads, use a Puma cluster, or add gems like Sidekiq to match that level.

3. Productivity and dev experience

   • Rails is famous for being “batteries included”, like generators, built in conventions, scaffolding, etc. You can spin up a CRUD app in minutes.
   • Phoenix has generators too, but it’s more minimal. You might wire up things manually, but you’ll still be flying after a few files.

4. Templating and views

   • Rails ships with ERB, and the community also loves Haml or Slim.
   • Phoenix uses EEx, which feels a lot like ERB but leaner. Plus LiveView gives you reactive UIs with almost no JS.

5. Real time support

   • Phoenix Channels and LiveView are crazy powerful right out of the box.
   • Rails ActionCable works, but I’ve seen it get flaky under high load and it’s a bit less mature.

6. Ecosystem and community

   • Rails has been around for ages; there’s a gem for literally everything.
   • Elixir and Phoenix are newer, so fewer packages, but the community is tight and growing fast.

7. Database and migrations

   • ActiveRecord in Rails is super intuitive with its DSL and tons of extensions.
   • Ecto in Phoenix is also a DSL but functional; queries feel explicit and you get compile time checks.

8. Testing support

   • Rails defaults to minitest, and many devs opt for RSpec.
   • Phoenix uses ExUnit, which is simple, fast, and integrates nicely with testing Channels or LiveView features.

9. Learning curve

   • If you know OOP and Ruby syntax, Rails is a breeze.
   • Phoenix might feel odd at first if you’re new to functional programming, but once you learn pipes and pattern matching, you’ll love it.

10. Deployment and hosting

    • Rails goes on Heroku, AWS Elastic Beanstalk, Dokku… no sweat.
    • Phoenix apps compile to a BEAM release; you manage a node, but platforms like Gigalixir or Fly.io simplify it.

11. Scaling

    • Phoenix shines for real time heavy workloads, thanks to BEAM clustering.
    • Rails scales nicely for traditional web requests, but you might spin up more dynos or servers under load.

12. Hot code upgrades

    • BEAM lets you swap code on the fly for zero downtime if you know what you’re doing.
    • Rails can do phased restarts, but it’s not as seamless as a true hot upgrade.

Example code

Here’s a “Hello world” route in both:

# lib/my_app_web/router.ex
scope "/", MyAppWeb do
  pipe_through :browser
  get "/", PageController, :index
end

# lib/my_app_web/controllers/page_controller.ex
defmodule MyAppWeb.PageController do
  use MyAppWeb, :controller

  def index(conn, _params) do
    text(conn, "Hello from Phoenix")
  end
end

# config/routes.rb
Rails.application.routes.draw do
  root "pages#index"
end

# app/controllers/pages_controller.rb
class PagesController < ApplicationController
  def index
    render plain: "Hello from Rails"
  end
end

Wrap up

So yeah, Phoenix is your jam if you want blazing concurrency and real time magic.

Rails is perfect for rapid dev, huge libraries, and classic full stack CRUD apps.

Both rock, just pick the one that vibes with your team and project needs. Happy coding!

Hey there, fellow developers!

Today I want to talk about two popular web frameworks that continue to make waves in the development world: Ruby on Rails and Phoenix. If you're trying to decide between these two for your next project, this comparison might help you make that choice.

The Contenders

Ruby on Rails has been around since 2004 and revolutionized web development with its "convention over configuration" philosophy. It's built on Ruby and has matured into a stable, feature-rich framework with a massive community.

Phoenix is the newer kid on the block, built on Elixir (which runs on the Erlang VM). It first appeared in 2014 and has been gaining traction for its performance and scalability benefits.

Development Speed and Productivity

Rails is famous for getting projects off the ground quickly. Its generator commands, built-in testing, and vast library of gems mean you can set up a full-featured app in no time.

# Creating a new Rails app with a database and scaffolding
rails new my_blog
cd my_blog
rails generate scaffold Post title:string content:text
rails db:migrate

Phoenix also values developer productivity but has a slightly steeper learning curve if you're new to functional programming. That said, once you're comfortable with Elixir, Phoenix's generators are just as powerful.

# Creating a new Phoenix app with database support
mix phx.new my_blog
cd my_blog
mix phx.gen.html Content Post posts title:string content:text
mix ecto.migrate

Performance

This is where things get interesting:

Rails is plenty fast for most applications, but it's not known for raw performance. Ruby is an interpreted language, and while it's gotten faster over the years, it's not winning any speed competitions.

Phoenix absolutely shines here. Built on the Erlang VM, Phoenix can handle an enormous number of concurrent connections with minimal resources. Real-world benchmarks often show Phoenix handling 5-10x more requests per second than Rails on the same hardware.

Scalability

Rails scales horizontally well enough (adding more servers), but vertical scaling (adding more to one server) hits limits due to Ruby's concurrency model.

Phoenix/Elixir was built for distribution and fault tolerance. The Erlang VM was designed by telecom engineers who needed systems that never go down, even during upgrades. Phoenix inherits this robustness and can effortlessly spread across multiple cores and machines.

Real-time Features

Rails added ActionCable for WebSockets support, which works well for moderate real-time needs, but it's not Rails' strongest feature.

Phoenix has Channels, a robust real-time communication layer that's a core part of the framework rather than an add-on. Phoenix is famous for its benchmark where they handled 2 million WebSocket connections on a single (beefy) server.

Community and Ecosystem

Rails has a massive community with thousands of gems (libraries) for almost anything you could want. It's supported by major companies and has been battle-tested for nearly two decades.

Phoenix has a smaller but rapidly growing community. The ecosystem doesn't have the same breadth as Rails yet, but the quality of the libraries tends to be high.

Learning Curve

Rails is fairly easy to pick up, especially if you already know Ruby. Its conventions make sense once you understand them, and there are tons of tutorials available.

Phoenix requires learning Elixir first, which is a functional language. If you're coming from object-oriented programming, this shift in thinking can take time to adjust to. However, Elixir is known for its excellent documentation and friendly syntax.

Jobs and Market Demand

Rails still has a strong job market, especially in startups and established companies that adopted it during its heyday.

Phoenix jobs are fewer but growing. Companies that need high concurrency or real-time features are increasingly turning to Elixir and Phoenix.

Which Should You Choose?

Here's my take:

Choose Rails if:

• You need to build something quickly with a proven stack
• Your app has standard web app requirements
• You want easy hiring and a huge ecosystem of libraries
• You're already familiar with Ruby or similar OOP languages

Choose Phoenix if:

• Your app needs to handle high concurrency
• Real-time features are central to your application
• You're interested in functional programming
• You're building something that needs high reliability or fault tolerance

My Two Cents

Both frameworks are awesome in their own ways. Rails continues to evolve and remains a highly productive choice for web development. Phoenix represents where web development is heading, with built-in support for the real-time, highly-concurrent apps that are increasingly in demand.

In 2025, I think Rails is still the safer choice for most standard web applications, but Phoenix is the better technical choice for applications that need to scale massively or have significant real-time components.

One of the most significant improvements in Rails 8 is the enhanced parallel testing system that now comes enabled by default. This feature dramatically reduces test suite execution time with minimal configuration.

What Changed in Rails 8

In previous Rails versions, you had to explicitly opt into parallel testing by adding configuration to your test environment. Rails 8 flips this approach - parallel testing is now enabled out of the box, automatically detecting your system's CPU count and utilizing those resources efficiently.

How to Get the Most Out of It

Here's how to leverage this feature effectively:

# config/environments/test.rb
Rails.application.configure do
  # The default is now true, but you can specify the number of workers
  config.parallel_testing.workers = :number_of_processors # or set specific number
  
  # You can also configure specific worker counts for different test types
  config.parallel_testing.workers = {
    models: 4,
    controllers: 3,
    system: 2
  }
end

Managing Database Setup

With parallel testing, each worker needs its own database. Rails 8 automatically handles this with a new task:

bin/rails parallel:setup

This creates numbered databases for each worker (like myapp_test-1, myapp_test-2).

Dealing with Shared Resources

When tests run in parallel, be careful with shared resources. Rails 8 includes helpers to manage this:

class SomeTest < ActiveSupport::TestCase
  parallelize_with :processes do |worker|
    # Code that runs once per worker
    Setup.prepare_shared_resource_for_worker(worker)
  end
  
  test "something that uses isolated resources" do
    # This test can run in parallel
  end
end

When to Turn It Off

Some tests may not work well in parallel. For specific test files:

class ComplexSystemTest < ApplicationSystemTestCase
  # Disable parallelization for just this test class
  self.use_parallel = false
  
  test "a complex flow that shouldn't run in parallel" do
    # Test code here
  end
end

Enjoy the significantly faster test execution times with Rails 8's parallel testing defaults!