Python Feel “Hot” While Ruby on Rails Feels “Dead”

 

Why Does Python Feel “Hot” While Ruby on Rails Feels “Dead”?

If you’ve been following tech trends, you’ve probably noticed something: Python is everywhere — data science, AI, automation, scripting, backend development. Meanwhile, people often say “Rails is dead”.

But is that really true? Let’s explore why Python seems to dominate the conversation while Rails quietly powers some of the biggest apps in the world.

---

🚀 Python: The Language of the Hype Cycle

Python’s growth story is incredible. Here’s why it feels “hot”:

• AI & Machine Learning: Libraries like TensorFlow, PyTorch, Pandas, and NumPy made Python the default for AI research, startups, and now Generative AI.

• Universities & Education: Python is taught as the first programming language in most schools, creating a constant pipeline of new developers.

• Multiple Domains: Web apps (Django, Flask, FastAPI), scripting, DevOps, data engineering, AI — Python is everywhere.

👉 Python isn’t just a language anymore, it’s an ecosystem that touches every part of the industry.

---

🌐 Ruby on Rails: The Specialist

Ruby on Rails, on the other hand, stayed focused: web development.

• It’s still one of the fastest ways to build SaaS, marketplaces, and e-commerce platforms.

• Rails apps power Shopify, GitHub, Basecamp, Hey.com, Airbnb (early years) and countless startups.

• Rails developers can build production-grade apps in weeks, not months.

👉 Rails chose depth over breadth — it’s not everywhere, but it’s very strong where it plays.

---

💼 Market Trends: Jobs and Perception

Why does it feel like Python = opportunity, and Rails = old news?

• Python jobs exploded because of AI/ML hype and funding.

• Rails jobs are concentrated in SaaS companies and established businesses.

• Startups today often default to Node.js + React (because of frontend dominance) or Python + FastAPI (because of AI integration).

👉 This creates the perception that Rails is dead — but in reality, it’s just not riding the AI hype wave.

---

📣 Community Energy

Another key difference:

• Python community is academic, research-heavy, and hype-driven → always publishing papers, open-source models, tools.

• Rails community is pragmatic, product-driven, and quieter → people are busy building businesses with Rails.

👉 Rails lacks the buzz, but not the impact.

---

🔥 Rails 8: The Quiet Comeback

Rails 8 proves the framework is far from dead:

• Kamal → built-in Docker-based deployment (no PaaS required).

• Solid Queue → native job system (no Redis needed).

• Solid Cache → built-in caching with ActiveRecord.

• Propshaft → modern replacement for Sprockets.

Rails is positioning itself as:

“The fastest way for small teams to go from idea → production without DevOps headaches.”

That’s powerful.

---

🎯 Final Thoughts

So why does Python feel hot while Rails feels dead?

• Python = hype, breadth, and AI-driven growth.

• Rails = stability, productivity, and shipping production apps fast.

Rails isn’t dead — it’s just mature and stable. It doesn’t chase every hype cycle, but it quietly powers some of the most important apps on the internet.

👉 If you want to build the next AI model, Python is a great choice.
👉 If you want to build the SaaS product that monetizes it, Rails is still one of the best bets.

New Feature in Ruby on Rails 8

 

What’s New in Ruby on Rails 8?

Ruby on Rails has always been about developer happiness and productivity. With the release of Rails 8, the framework takes another giant leap forward, making it easier than ever to build, deploy, and scale modern web applications.

In this post, we’ll explore the most exciting new features in Rails 8 and why it matters for developers and businesses.

---

🌟 1. Built-in Deployment with Kamal (No PaaS Needed)

Traditionally, deploying Rails apps required third-party services like Heroku or custom DevOps pipelines. Rails 8 changes this with Kamal (formerly “MRSK”), a first-class deployment tool included in Rails.

• 🚀 Deploy Rails apps to any cloud or VPS (AWS, GCP, DigitalOcean, etc.).

• 🐳 Uses Docker under the hood for consistent environments.

• 🔄 Rollbacks and zero-downtime deploys out-of-the-box.

👉 This means you can go from development to production without needing a PaaS provider.

---

🌟 2. Propshaft: The Next-Gen Asset Pipeline

Rails 8 introduces Propshaft, a modern replacement for Sprockets.

• Simpler, faster, and more reliable.

• Designed for modern JS & CSS tooling (ESBuild, Vite, Tailwind).

• No more config-heavy asset management headaches.

👉 With Propshaft, assets are leaner and the pipeline plays nicely with today’s frontend workflows.

---

🌟 3. Solid Queue: Built-in Background Jobs

Rails has had Active Job for years, but you still needed a backend like Sidekiq or Resque. Rails 8 introduces Solid Queue — a native, database-backed job queue system.

• 📦 No Redis required — works with just your database.

• ✅ Great for small to medium apps that don’t need a dedicated queue.

• 🔄 Still works with external job processors if you want.

👉 Background processing is now easier to set up and manage in any Rails app.

---

🌟 4. Solid Cache: Smarter Caching with Active Record

Caching has been supercharged in Rails 8 with Solid Cache:

• Stores cache entries directly in the database.

• Works well with horizontal scaling (multiple servers).

• Provides visibility and management through ActiveRecord.

👉 Caching is now simpler and more reliable without needing extra infrastructure.

---

🌟 5. Rails Defaults 8.0

Every major release updates Rails defaults to modern best practices. In Rails 8, new apps come pre-configured with:

• Latest security defaults.

• Zeitwerk mode as the standard.

• Propshaft instead of Sprockets.

• Optimized configs for production-ready apps.

👉 Less time tweaking configs, more time building features.

---

🌟 6. General Improvements & Enhancements

• Action Mailer improvements → better async delivery.

• Stronger ActiveRecord performance optimizations.

• Better support for Hotwire & Turbo out of the box.

• Minor DX (developer experience) improvements across generators, configs, and logs.

---

🎯 Why Rails 8 Matters

Rails 8 isn’t just an upgrade — it’s a statement:

• Developers get full-stack power without extra tools.

• Small teams can ship production apps without DevOps complexity.

• Rails remains one of the fastest ways to build modern web apps.

With Kamal, Propshaft, Solid Queue, and Solid Cache, Rails 8 gives developers the full power of a modern framework + deployment + infrastructure in one package.

---

✅ Final Thoughts

Rails 8 is all about simplicity, productivity, and independence. It removes external dependencies, makes deployment first-class, and improves the developer experience.

If you’re starting a new project, Rails 8.0.2.1 (latest stable) is the version you should be using. And if you’re on Rails 7, now’s the perfect time to plan an upgrade.

💡 In short: Rails 8 makes it easier than ever to go from idea → production with minimal friction.

Using GenAI in Ruby on Rails

 

🧠 What is GenAI?

Generative AI (GenAI) refers to AI systems that can generate content — like text, images, code, or even audio — rather than just analyzing or classifying data. Popular examples include ChatGPT, DALL·E, and Stable Diffusion.

In a Ruby on Rails project, you can use GenAI to:

• Build chatbots for customer support.

• Generate product descriptions or blog posts dynamically.

• Enhance search features with natural language understanding.

• Create summaries of long documents.

• Automate email replies or notifications.

---

⚙️ Using GenAI in Ruby on Rails

The most common way is to connect Rails with OpenAI’s API (or other GenAI providers like Anthropic, Cohere, Stability AI).

Example: Text Generation with OpenAI (GPT-4o-mini)

# app/services/genai_service.rb
require "openai"

class GenaiService
  def initialize
    @client = OpenAI::Client.new(access_token: Rails.application.credentials.dig(:openai, :api_key))
  end

  def generate_text(prompt)
    response = @client.chat(
      parameters: {
        model: "gpt-4o-mini",
        messages: [{ role: "user", content: prompt }],
        temperature: 0.7
      }
    )
    response.dig("choices", 0, "message", "content")
  end
end

Usage in a controller:

class GenaiController < ApplicationController
  def create
    prompt = params[:prompt]
    ai = GenaiService.new
    render json: { result: ai.generate_text(prompt) }
  end
end

---

Example: Image Generation with DALL·E

def generate_image(prompt)
  response = @client.images.generate(
    parameters: {
      prompt: prompt,
      size: "512x512"
    }
  )
  response.dig("data", 0, "url")
end

---

🚀 Benefits of GenAI in Rails Apps

✅ Saves time by automating repetitive tasks.
✅ Improves user experience with natural conversations.
✅ Personalizes content for users.
✅ Adds innovative features that differentiate your app.

Integrating OpenAI with Ruby on Rails

 

Integrating OpenAI with Ruby on Rails: A Step-by-Step Guide

Artificial Intelligence is transforming how modern web applications are built, and OpenAI’s models can be seamlessly integrated into your Ruby on Rails projects to add natural language processing, chatbots, content generation, and more. In this guide, we’ll walk through how to set up OpenAI in a Rails application.

---

🔧 Step 1: Add the OpenAI Gem

First, install the ruby-openai gem. This gem provides a simple wrapper around OpenAI’s API.

# Gemfile
gem "ruby-openai"

Run:

bundle install

---

🔑 Step 2: Configure API Key

Set your OpenAI API key as an environment variable (best practice is to use dotenv-rails or Rails credentials).

export OPENAI_ACCESS_TOKEN="your_api_key_here"

Or inside Rails credentials:

EDITOR="nano" bin/rails credentials:edit

openai:
  api_key: your_api_key_here

---

💻 Step 3: Initialize OpenAI Client

Create a service file for handling OpenAI requests, for example:

# app/services/openai_service.rb
require "openai"

class OpenaiService
  def initialize
    @client = OpenAI::Client.new(access_token: Rails.application.credentials.dig(:openai, :api_key))
  end

  def chat(prompt)
    response = @client.chat(
      parameters: {
        model: "gpt-4o-mini",
        messages: [{ role: "user", content: prompt }],
        temperature: 0.7
      }
    )
    response.dig("choices", 0, "message", "content")
  end
end

---

🚀 Step 4: Use OpenAI in a Controller

Example controller to call the service:

# app/controllers/ai_controller.rb
class AiController < ApplicationController
  def generate
    prompt = params[:prompt]
    ai_service = OpenaiService.new
    @response = ai_service.chat(prompt)

    render json: { response: @response }
  end
end

And add a route:

# config/routes.rb
post "ai/generate", to: "ai#generate"

---

🌐 Step 5: Test the Endpoint

Send a POST request with a prompt:

curl -X POST http://localhost:3000/ai/generate \
  -H "Content-Type: application/json" \
  -d '{"prompt":"Explain Ruby on Rails in simple terms."}'

Response:

{
  "response": "Ruby on Rails is a web framework that helps developers build web apps quickly..."
}

---

📊 Possible Use Cases in Rails

• Customer support chatbots

• Blog/content generation

• Code suggestions in developer tools

• Semantic search & recommendations

• Automating routine text tasks

---

✅ Final Thoughts

Integrating OpenAI with Ruby on Rails is straightforward using the ruby-openai gem. By following the steps above, you can add powerful AI-driven features to your Rails app and create a more interactive, intelligent experience for users.

datepicker with nested form field

Indeed, you will have to retrigger the datepicker plugin. You are probably doing something like

$('datepicker').some_function_to_do_your_datepicker_styling();

But of course, the dynamically added elements are not yet in the DOM.

So do something like:

$('form').on('cocoon:after-insert', function() {
  /* apply datepicker styling */ 
});

Intro to Docker for Developers: How to Run your Rails App on Docker

Docker in a Nutshell First of all what is Docker? Let’s chew on the Wikipedia definition to start: 

“Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux.[2] Docker uses resource isolation features of the Linux kernel such ascgroups and kernel namespaces to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.[3]”

From a developer perspective Docker promises us the opportunity to forget about the “it works in my local environment but not in production” problem as well as the “it works on my Ubuntu machine but not on my buddy’s Mac three feet away” scenario. 

Now, with the magic of a definition file, it is super easy to port an app between environments: from local to lab, and later to production. Docker is incredibly fast and thanks to the use of some linux kernel features like namespaces, we have isolation for filesystem, networks and processes. 


This consistency is an incredible opportunity for developers, but it’s an especially big win for our users: with Docker we can reduce highly disruptive “environmental issues” to almost zero percent. 

Did I just say the word disruptive? Oh right, container revolution, blah blah. :)

Step #1: Prepare Your Infrastructure / Server Environment

Let’s “dockerize” a basic Rails app.This is what the app looks like. It was created using “Rails new Rails-App” (if you don’t have Rails you can just follow the installation instructions here) 

First, you need to have Docker running. To do so, you can just check the docker documentation, which is really quite easy to follow. Choose your platform, follow the instructions, and voilà! 

Once installed, check that the Docker daemon is running properly by typing:

$ docker -v

Docker version 1.7.0, build 0baf609 (this will probably change based on the installation type/platform you have chosen)

Step #2: Build Your Image

Next up we need to build our Rails image. Docker uses a definition file to describe what the environment will contain. Usually it’s named Dockerfile (you can use a different name also), so for simplicity let’s create a file in our app directory called “Dockerfile” and add a few lines in there (gist):

# Base image FROM ruby:latest 

ENV HOME /home/rails/webapp 

# Install PGsql dependencies and js engine 

RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs 

WORKDIR $HOME 

# Install gems 

ADD Gemfile* $HOME/ 

RUN bundle install 

# Add the app code 

ADD . $HOME 

# Default command 

CMD ["rails", "server", "--binding", "0.0.0.0”]

Okay...so what’s a “Docker image” for real? 

An image is a read-only template that Docker uses to run your code through a container. It contains a complete environment definition: it has the OS binaries, libraries, dependencies and all the applications that you need to run your code or application. All the magic is stuffed into it, so pay attention! 

Images contain layers (I won’t explain much about them here, since it’s a big topic that requires its own blog post). Every instruction creates a new layer in the filesystem. And thanks to the use of a union filesystem, those layers are “combined” into a single filesystem. Neat and tidy. 

An image can be built and pushed into a registry, like Docker Hub, or Quay.io (or even a custom one), just like you would do with GitHub. You can even have public or private repositories, so others can leverage your image / template, or you can re-use for other purposes.

Digging into your Dockerfile

To help us understand how this all works, let’s examine our freshly baked Rails Dockerfile.

FROM ruby:latest - This is the first instruction you have to have in your Dockerfile, with this instruction we are defining the base image. In our case, it will use this base image https://registry.hub.docker.com/u/library/ruby/, which actually has an interesting hierarchy:

• 
  
• Ruby is based on buildpack-deps:jessie which is based on buildpack-deps:jessie-scm which is based on buildpack-deps:jessie-curl, which is finally (!) based on debian:jessie.
• 
  
• As you can see, between images there exist some kind of “inheritance” concept where you can “extend” your images from others. It’s a great thing since you can build your environments based on trusted/stable (if you find them! and still be careful) images.

ENV HOME /home/rails/webapp - Just defining an environment variable.

RUN apt-get update -qq && apt-get install -y build-essential nodejs

• The RUN instruction executes a command in the docker container. So the “apt-get …” command will update the OS packages list and will install some libraries among nodejs.

WORKDIR $HOME - The WORKDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions.

ADD Gemfile* $HOME

/RUN bundle install

• 
  
• Copy all the gem files definitions into the filesystem in the container and execute the command to install the gems. (I’ll explain why I’m doing this, in the next “Using Cache in Docker” post :) )

ADD . $HOME - Copy all the website files into the container.

CMD ["rails", "server", "--binding", "0.0.0.0"] - Specify the default command for when the container runs.

Step #3 - Build and Run Your Web App

Now that we have a better idea of our Dockerfile, let’s get our hands dirty! We need to build and run the web app:

$ docker build -t ruby-app .

Since we don’t have a Ruby image downloaded yet, it will pull the latest from Docker Hub and then run all the instructions from the Dockerfile. You should end up with something like this:

Later we can check the image using:

$ docker images

Let’s create a container and run the app.

$ docker run -d -p 3000:3000 rails-app

The command above will create a docker container using the “ruby-app” image you created in Step #2. The “-d” flag tells docker daemon to run this container in “daemon mode”.

Remember our CMD instruction in the Dockerfile? Well that is what’s running in the container “rails server --binding 0.0.0.0”

You can just open your browser at: http://localhost:3000 or you can get the container IP:

docker inspect 8f4fec2497f5 | grep IPAddress

(you can also run docker inspect --format '{{.NetworkSettings.IPAddress}}' 8f4fec2497f5 )

In my case it is: "IPAddress": "172.17.0.2"

So, just open the browser and point it to http://172.17.0.2:3000 and you will see the rails app running :)

One last interesting command about the run command we used is the -p flag.

docker run -d -p 3000:3000 ruby-app

When using the -p flag docker let us choose a port binding between the host and the container. Without this flag we could get into the rails app from outside the container. We could even choose a different port like: 

docker run -d -p 5000:3000 ruby-app

Or let docker choose a random port like

docker run -d -p 3000 ruby-app

To see what port docker has chosen, we can run “docker ps”

Or let docker choose a random port like docker run -d -p 3000 ruby-app To see what port docker has chosen, we can run “docker ps”

And in the port column you will see that the assigned port is 32769.

Also you could do:

$docker port 284bb5e37f44

Result: 3000/tcp -> 0.0.0.0:32769

And in the port column you will see that the assigned port is 32769. Also you could do: $docker port 284bb5e37f44 Result: 3000/tcp -> 0.0.0.0:32769

Using MongoDB With Ruby On Rails 5

In this post I am going to walk you through installing Ruby on Rails 5 using rbenv and use the Mongoid MongoDB driver for Ruby. MongoDB is a fantastic NoSQL database that is incredibly scalable and fast which makes a good combo with Rails. We will be using Linux Ubuntu 16.04 with MongoDB and Rails already installed.

Create a Rails App (Without Active Record)

rails new myapp --skip-active-record

Using the –skip-active-record option will create the app without the database.yml config file. We will use a mongoid config file instead. This will also prevent using the sqlite gem. We will add the Mongoid gem below

Edit Gemfile

Add the following to your Gemfile

gem 'mongoid', '~> 5.1.0'

Generate Mongoid Config File

rails g mongoid:config

This will create config/mongoid.yml

Thats It! you should now be able to run “rails s” and use MongoDB

rails g scaffold post title body author created

Now visit “http://localhost:3000/posts” and you should have CRUD functionality using MongoDB

If you did NOT use the “–skip-active-record”

Remove Gem “sqlite” from the Gemfile

Delete the database.yml file

Go to config/application.rb and remove “require rails/all” and replace with…


require "action_controller/railtie"
require "action_mailer/railtie"
require "rails/test_unit/railtie"

Comment out any line that has “active_record” in it in the following files

/config/development.rb
/config/production.rb
/config/initializers/new_framework_defaults.rb