Stop telling developers what to use.
You've seen the sites. "Just fucking use HTML." "Just fucking use React." "Just fucking use Rails." Everyone's got an opinion. Everyone's got the answer. Everyone knows exactly what you should be building with.
Here's the thing: they're all right, and they're all wrong.
And that's the whole point.
Let's talk about what "right" and "wrong" actually mean in programming.
If you're trying to hammer in a nail, a sledgehammer is probably the wrong tool. Doesn't mean a sledgehammer is bad. Doesn't mean sledgehammers suck. It just means it's the wrong tool for that job.
Right and wrong aren't absolute truths handed down from the programming gods. They're contextual. They're situational. They're about fit.
The person screaming "just fucking use X" isn't giving you wisdom. They're giving you their preferences dressed up as universal truth.
"The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities." — Edsger Dijkstra
When all you have is a hammer, everything looks like a nail.
That's what happens when you listen to the "just fucking use X" crowd. You end up with one tool. One perspective. One answer to every problem.
That's not engineering. That's religion.
Good developers have lots of tools. They understand the tradeoffs. They make informed decisions based on:
Notice that last one? Your preferences matter. Your values matter. What you enjoy working with, what makes you productive, what brings you joy in your craft. That's not weakness. That's wisdom.
Here's what I've learned from teaching thousands of people to code:
Programming is not about Ruby or Java or JavaScript or C#. Programming is about abstraction, semantics, encapsulation, logic, interface, and more. Those ideas are expressed in every programming language.
Just like poetry is not about Italian or English or German. Poetry is about rhyme, meter, imagery, metaphor, rhythm, form. Universal concepts that any language can express.
The danger is that if you're taught your first language in the spirit of "this is all you need to know to get a job," you'll never learn to recognize those universal concepts. You'll miss the forest for the trees. And tragically, you'll miss all the beauty and elegance there is to code.
No programmer worth their salt defines themselves as solely a Ruby programmer or a PHP programmer. We are programmers. Programming languages are just our tools. We adapt our toolset to different circumstances and problems.
Here's what you shouldn't base your decisions on:
Technology choices aren't fashion. You don't need to be on-trend. You need to ship software that works, that you can maintain, and that solves real problems for real people.
The hot new framework will be old news in 18 months. Your codebase will still be there, needing maintenance, long after the hype cycle moves on.
Choose tools you understand. Choose tools that fit. Choose tools you actually want to work with.
Matz, the inventor of Ruby, was asked once at a conference why he would design a language with so many ways to do the same thing. His answer speaks to something deeper than programming:
"I want to make Ruby users free. I want to give them the freedom to choose. People are different."
What's "right" for one person might not be "right" for another, and neither are wrong. They are just different, and they should be allowed to be different without judgment.
I believe in that value in life, from religious freedom to marriage equality to political affiliation. And certainly in code.
The "just fucking use X" crowd doesn't believe in freedom. They believe in conformity. They want you to choose what they chose so they can feel validated in their decision.
Don't give them that power.
When is your favorite tool actually too much?
You're building a landing page. Some text, some images, maybe a contact form.
You don't need React. You don't need Vue. You don't need Svelte. You don't need a build step, a bundler, a node_modules folder with 47,000 dependencies.
You need HTML. Maybe some CSS. Maybe a sprinkle of vanilla JS if you're feeling fancy.
Every line of JavaScript you add is a line you have to maintain. Every dependency is a potential security vulnerability. Every abstraction is complexity you're signing up for.
Use JavaScript when you need JavaScript. When you're building genuinely interactive applications. When you're managing complex state. When vanilla DOM manipulation becomes a nightmare.
Don't use it because someone told you HTML is for dinosaurs.
React is a fine library. It solves real problems. It's battle-tested at scale.
It's also massive overkill for most websites.
If you're building a blog, a marketing site, a small business website, a portfolio, a documentation site... you probably don't need React. You definitely don't need a single-page application architecture.
You need fast page loads. You need content that search engines can read. You need something you can update without rebuilding the entire frontend.
Use React when you're building applications, not websites. When you have genuinely complex UI state. When you have a team that knows React and can maintain it.
Don't use it because it's what everyone else is using.
You're building a web app. A CRUD application. A SaaS product.
You don't need C++. You don't need to manage memory manually. You don't need compilation times measured in coffee breaks.
C++ is for systems programming. Game engines. Operating systems. High-frequency trading. Places where every microsecond matters and you need to squeeze every ounce of performance from the hardware.
99% of software doesn't need that. 99% of software needs to be built quickly, maintained easily, and changed frequently.
Use C++ when performance is genuinely critical. When you're writing code that runs millions of times per second. When garbage collection pauses are unacceptable.
Don't use it because you want to feel like a "real" programmer.
You're building a startup MVP. You need to move fast, iterate quickly, change direction when you learn something new.
Go is great for infrastructure. Great for tools that need to be fast and compiled to a single binary. Great for systems that handle massive concurrency.
But Go's rigidity, its verbosity, its explicit error handling everywhere... that's friction when you're trying to move fast. That's ceremony when you need flexibility.
Use Go when you need Go's strengths. Fast compilation. Easy deployment. Excellent concurrency primitives.
Don't use it because Google uses it.
No, wait. Actually...
Rails is almost never overkill.
Look, I'm biased. I've been writing Rails for a long time. I've taught thousands of people to code with Ruby and Rails. So take this with whatever grain of salt you want.
But here's the thing: Rails is designed for exactly the kind of software most of us are building. Web applications. SaaS products. Internal tools. APIs. E-commerce platforms.
It's batteries-included. Conventions over configuration. Everything you need, right there, working together out of the box.
Is it the fastest runtime? No. Is it the most cutting-edge technology? No. Does it get the job done, reliably, maintainably, enjoyably? Yes.
Sometimes the right tool is the boring tool. The proven tool. The tool that lets you focus on your actual business logic instead of gluing together seventeen microservices.
Rails is a sledgehammer, sure. But most software problems? They're nails.
It's not.
The goal of Ruby is to make programmers happy. Matz started out to make a programming language that would make him happy, and as a side effect it's made many, many programmers happy.
As far as I know, the only programming language in history invented for your happiness is Ruby. The Ruby language values you, the programmer, over the machine.
Is it the fastest language? No. Do you need it to be? Almost certainly not.
The time you save writing clear, maintainable, enjoyable code pays for itself a thousand times over. Your server costs are rounding errors compared to your developer salaries. Optimize for humans first.
Use Ruby when you want to enjoy programming. When you want code that reads like prose. When you care about craftsmanship and beauty in software.
Which should be always.
The most important thing for any programmer to learn, regardless of language, is to fall deeply and profoundly in love with code.
Programming is an art. Just like poetry or dance or music, the particular style or language of expression is of little importance to the art itself. What matters is learning to recognize the abstract truth in the craft.
The joy of programming does not hide in the technical implementations of one language or another. It is found in the wonder of the medium itself, in what Ada Lovelace called "the science of operations."
Learning to code without learning to recognize that beauty is tragic.
Don't let some angry person on the internet rob you of that joy by making you feel like you chose wrong.
There is no wrong. There is only different.
Here's what you should actually do:
Don't be a one-trick pony. Understand different paradigms, different tradeoffs, different approaches.
Before picking a tool, make sure you actually understand what you're building. Most architecture astronauts crash because they're solving imaginary problems.
What does your team know? What can you maintain? What fits your timeline? What brings you joy?
Not the choice Twitter told you to make. Not the choice that blog post demanded. Your choice, based on your values, your situation, your informed judgment.
Every technology choice has tradeoffs. Accept them. Don't complain that your hammer isn't good at turning screws.
All that said...
If you're still not sure where to start, you could do a lot worse than Ruby and Rails. Just saying.
They're tools designed for people who want to build things and have fun doing it. Tools that prioritize programmer happiness. Tools that have been shipping production software for twenty years.
Rubyists pioneered rapid development frameworks. Rails was the first major framework to embrace REST. Rubyists thought SVN sucked and built GitHub. They thought hosting sucked and built Heroku. They've started GitHub, Twitch, Twilio, Airbnb, Shopify, and more.
For such a "niche" language, the impact and influence of Ruby is incredible. And it's not a coincidence. The Ruby tool wants you to be happy, and when we are happy we can play and explore. The Ruby tool wants you to value expression and communicate purely. The Ruby tool wants you to be different and make the language your own.
Not because someone yelled at you to use it.
Because it's a genuinely good tool that respects your time and intelligence.
But hey, that's just my opinion.
Make your own choice.