In my last job I encountered my first Ruby/Rails codebase ever (mostly REST APIs but a few server-rendered views as well). Despite the initial chaotic impression of the codebase (it was a startup after all) with all the Rails magic on top, I really fell in love with the framework after a more experienced Rails dev introduced a few key conventions and helpful libraries to the codebase.
Out of those, I’d at least add the RuboCop [1] linter and the BetterSpecs [2] guidelines to this list. Both eliminated bikeshedding in the team and freed up brainpower to solve actual problems: the first one helps you learn intricacies of Ruby bit by bit right in the IDE and the latter one pushes you to write test in a specific style that’s easy to maintain and trust.
I am blown away by the suggestion to use factories over fixtures.
Factories are almost 100% responsible for excruciatingly slow test runs, since you have to rebuild the world every single test. Fixtures work perfectly fine and only need to be created once at the beginning of your test run.
For that matter, rspec itself is also a thoroughly unnecessary cargo-culted dependency when Ruby and Rails already bundle perfectly-serviceable, simple test frameworks.
Good luck with those very brittle specs. I have fixed so very many utterly broken tests due to poor spec maintenance mainly due to really poor fixtures. The problem with fixtures is that they do not complain when things go sideways whereas factories are built on top of actual living objects and thus can be validated.
You're generally trading speed for correctness in my experience. There is a time and place, of course, for this tradeoff, but we know how to parallelize specs and make test, in general, faster. Correctness is a whole different story.
If the number of teams developing on your monolith continue to grow, both you and parent will eventually come to the realization that there’s not a good fix for this in Rails. You’ll re-write your monolith into something that scales much better with organizational growth.
Using factories doesn't mean you need to persist everything to the DB on every test.
If you're using FactoryBot for example, you can use `build(:taco)` to instantiate a Taco without persisting it to the DB. If you use `create(:taco)` instead, then yes, the Taco will be saved to the DB, as well as all its associations (if any). This can of course bloat up your test execution time if you're doing this kind of instantiation + persistence on every test.
FactoryBot docs generally use `build` in their examples, as this should be the default build strategy used for most tests, while `create` should only be used on cases where you actually need to interact with the DB.
I love ruby having used it since before Rails, but it seems weirdly susceptible to the "with great power comes great responsibility" issue. Dynamically typed + the "don't disallow stupid things or you'll disallow clever things" mentality, maybe? Early adopters like _why who could actually handle it having a huge influence? Dunno.
I've worked with some devs who were not old battle-scarred greybeards who jumped on EVERY rspec feature because they were there and in a misguided attempt to DRY their test code well beyond reasonable limits.
So I feel you here.
But FactoryBot does allow fixture-like speeds with in-memory .build()'ing. Too few people use it, and too few have succumbed to a preponderance of tests being full-on integration style.
Ruby (and Rails, and rspec) all IMO require a lot more good guidance and wisdom on what NOT to use than other ecosystems I've used.
> For that matter, rspec itself is also a thoroughly unnecessary cargo-culted dependency when Ruby and Rails already bundle perfectly-serviceable, simple test frameworks
I think people developing professionally and working with large code bases, reach pretty fast all the limitations of minitest. IMO, Minitest is great to test small libs, but as soon as you need to refactor a lot of specs or use other stuff like Factories, then rspec is the tool. No cargo-culted. It is just the best and more complete option.
I have worked professionally with Rails since just after 1.0, on applications of every size.
The number of cases where applications sanely used features of rspec that couldn’t have been done equivalently and just as easily (and significantly less confusingly) with minitest-based tests are few and far between. And these are easily outnumbered 20:1 by insanely bad test suites that abuse rspec and thoroughly mock everything in their tests, resulting in tests that a) are so brittle they fail on any non-trivial refactor, and b) couldn’t possibly preemptively catch buggy behavior.
I have quite literally never worked on a Rails application that used minitest and which was forced to abandon it due to unmet needs.
I went all in on Rails a couple of years ago. Although the overall feature set is amazing, code discoverability has been a frustrating stumbling block from day one.
The "magic" (convention over configuration, autoloading, metaprogramming, etc) makes it difficult to know what methods are available to use. I end up over-relying on the official docs, which are of inconsistent quality. One example: api.rubyonrails.org lacks code examples, doesn't usually state what a given method returns, and many entries are outright blank.
Editor integration could help, but feels lackluster. With TypeScript in VS Code, hints come up as I write. I can hover anything to see its type, methods, and source code. With Rails, I can poorly approximate this behavior with a collection of half-functional community extensions, or I can buy and use the slow, bloated RubyMine IDE.
Rails enabled me to build my product, but my experience doesn't match the love I hear from other devs. I wish I knew how to make it click.
I went all in many years ago and then moved on several years ago (to different parts of the stack that I found more interesting), but here's my 2c FWIW.
The Rails Guides [1] are quite good (and much better than the API docs, even for the same topics). The "Getting Started" guide, in particular, was my first intro to Rails, and it's what convinced me to go all in — I built my entire prototype by just following along the guide, seeing what they were doing with their toy app, and then trying to whatever similar thing I needed in my app.
Coming from Python, the magic was distasteful to me, too. Rails adds a ton more magic on top — so, eventually, when I set aside Rails and just spent time with Ruby (writing scripts or what not), I realized I loved Ruby the language much more than Rails the framework (and all its baggage).
Stripping Rails down to its API-only mode (though it was a bit rough around the edges last I tried) got me closer to the Ruby of it all. Sinatra turned out to be a delightful little framework (though sadly I never got a chance to use it much). And, even though I've now moved on from Rails, I still like Ruby as a go-to scripting language — it makes it fun and easy to throw together a quick shell script or some data analysis, and it's very friendly to a functional programming style.
I guess what I'm saying is: You're not alone. Many people in the Rails community agree that there's a ton of hidden magic, sometimes too much [2]. But underneath it all is a delightful programming language.
I had exactly the same problem. Recently, with the help of ChatGPT (just free version). When I didnt know anything, I just asked. The result was pretty good.
I also wrote stupid code first in my own version, and copied + pasted to chatGPT, asked it to improve it, or rewrite in ruby on rails style. And wow!! The rewrote version even went with explanation.
This was my experience and I have commented it before. The magic/convention approach is the inferred part of Rails/Ruby culture. Where is the class definition? Well, where are you invoking initialization? This question leads to a question which hopefully leads to answer is hard to play by if you’re new or just trying to squash a simple request.
The whole just fire up an interactive session or rails console is probably the last thing I want to do but probably the only way to diagnose or figure out how things are truly working. What monkey patches are in the mix, what libs override methods I set, etc.
For me, Ruby is one of those programming languages that obviously takes a different programming approach and mindset that I don’t have. I don’t think Ruby is bad but I know it isn’t the tool that fits my skill set.
A good way to explore is getting an interactive session with something like pry and exploring what methods and attributes are available that way. It sounds clunky, but it's quite effective as you frequently get to play through the entire implementation once and it pairs extremely well with TDD.
I love ruby, and find it great to use pry and irb to explore and figure stuff out.
However, many times ruby libraries will use dynamic programming and method_missing to define methods on the fly… this makes it really hard to figure out what methods are actually available.
For that reason, I try to never use method missing to define core functionality in ruby, and hate when other gems do it.
The responsible thing when you use `method_missing` is to define `respond_to` to indicate whether an object responds to a particular method. This alleviates the "is a method available" issue because you can just ask the object "Do you respond to :method_I_want_to_call?", and it will correctly inform you it does or does not. This kind of discoverability is one of the things I miss when I'm working in Javascript/TS as I have been recently - sure you can check the .method_name property to see if it's a function and then execute it but it doesn't feel as nice.
E.g.
def method_missing(name, \*args)
if name =~ /^has_/
has(name, *args)
end
super
end
def respond_to(name)
if name =~ /^has_/
return true
end
super
end
I second this, when I was in Ruby land I used to regularly drop a binding.pry (later binding.irb) in the middle of some code i wanted to understand, and call things like `method` to see where an unrecognized method came from.
Pry is amazing for understanding code. IMO the most useful method is absolutely `some_object.methods`, but you can also improve the output a ton by always doing:
some_object.methods - {}.methods # or some other "parent" class/object
This does set subtraction to remove all the "core" object methods from your some_object methods, so you can see just what's unique about that object. For example, comparing one of my services with a parent Service class it inherits from:
instead of listing out the 187 methods that PaypalService has that it inherits from Service and every other parent object up the line, which is usually a surprisingly long ancestor list in any Ruby on Rails class (even POROs!).
There are a TON of useful methods like this that I'd recommend getting familiar with, which makes exploration and discovery of code incredibly fast and efficient. You can find them all with the same trick: by using `methods` on any method. :)
Thats a good point and nice to see that the rails community is starting to work to consider new engineers more. The whole JS and also PHP/Laravel ecosystem is doing this already since quite some time. Rails is still the best option imo when you want to be productive as a small team - but the learning resource don’t keep up with other frameworks/languages.
This is my biggest gripe. I am learning programmning as a hobby, I don't have much time in a day but like to allocate at least 1-2 hours to practice.
When deciding on the language to learn, I really really wanted to go with Ruby and then transition to Rails. But it seems like educational materials are currently lacking, most of the tutorials on YouTube are outdated.
When investing in eco-system, I never looked at the availability of jobs. But when comparing say JS/TS vs Ruby, there is clearly a viable route to learn it as a beginner.
The downside is that there is a lot of trash and low quality materials as well as inhibited complexity - but after some time its not such a problem to sift through the noise.
i find this critique interesting, because i believe the initial momentum behind rails was sparked by a video about how to create a blog using rails without any setup in just a few minutes.
An almost 20 year old demo from the creator really doesn't address the issue of community resources. Any application of minimal complexity needs to solve problems that demo doesn't begin to address, and beginners need access to resources to guide them in solving those problems.
Not to mention that Rails was the language-de-jour for most bootcamps between 2012 and 2017 or so. The problem was running into developers who only knew Rails, not finding ones that didn’t know it at all.
Some how nostalgic for those plain invert-colours buttons that rails used to have. Also DHH's iconic "whuups!" every 2 minutes is pretty funny to relive.
I think one of the things that sort of stopped rails from becoming mainstream was that when WebApps really took off everything switched to SPA apps. Now that's shifting back a bit (a good thing imo) as many people are starting to recognize the downsides of frontend apps. Next.js is basically one giant workaround for the shortcomings of spa apps.
Rails isn't mainstream? I'm of the opposite opinion - it's definitely in the Boring Technology† Club. It's well known that it's hard to find a more productive tech stack for building server side web apps.
Rails made Microsoft change its entire web strategy. It influenced so much. Rails is so mainstream that it doesn't get talked about like a hot new tech anymore. If you were a web developer in 2006~2016 it was still hot tech but kind of lost the plot IMO when they really started futzing around with the asset pipeline.
That’s fair, I guess I’m comparing it to how stable the controller and Active Model APIs have been. I wish Rails had taken a more hands off approach and let the frontend community plug in their own approaches to tooling instead of taking opinionated stances and then rolling them back after a while. I understand that Rails is “omakase” but I had to learn the frontend tooling, anyway, and the Rails versions are different enough to invalidate that learning.
Yes, i don't like to fight against the assets pipeline, but to be honest, I just went from Sprockets to Propshaft and never tried to use Webpacker.. you can even still use Sprockets with rails 7, so you could use the whole time, plain Sprockets and you would be doing fine.
Next.js isn’t one giant workaround for anything. People were building isomorphic SPAs using React long before Next was created. All Next.js did is to put it all together in a simple framework.
Some googling tells me that isomorphic SPA means the same page can be rendered server side or client side. Is that what it means to you? It's my first time encountering the term. If so ... people were doing that in react??
What alternatives would you propose? Usually when people are surprised by this, digging in reveals that they don’t really know what “client-side rendering” means.
It’s really a pity because nest.js is an awesome and very intuitive backend framework. Because it’s written on top of express, the real power comes from being able to drop down to the express layer anytime.
I always hear good things about Ruby on Rails, yet it remains relatively niche. I first heard about Ruby + Rails in 2013, and ten years later it seems to be just as niche. Loved by those who use it, but niche. Why does it continue to struggle in this way when more recent languages like Go are booming?
To write web app in golang and write mostly SQL by hand isn't that cool. Yes sometimes it is important, sometimes you should. But ActiveRecord is just a dream, that quite often people even forget how hard was the life before it.
That is debatable. Both GitHub and Hackyderm are large-scale Rails deployments, and both share a DevOps engineer (Nóva) who I've heard complaining about Ruby DevOps at least once. Twitter was forced to abandon Rails (being the poster child for Rails at the time).
(first, I am biased as I have worked with Ruby since 2007 and still enjoying it)
This is not a reply to you, but I decided a long time ago that I will not let this argument about scalability remain with response.
If you have already decided not to try Ruby on Rails or any Ruby framework, say so.
It is ok to have different preferences.
But this thing with Ruby needs to be more scalable is a very weak argument.
Here is why:
In the tech industry, it is not uncommon to come across companies that opt to rewrite their tech stack in a different language, often citing scalability as a reason. While this argument holds some merit, it's worth noting that scalability is a complex issue that affects all web frameworks, not just Ruby on Rails. Therefore, criticizing Ruby on Rails solely based on scalability may not be a strong argument when you take into consideration the idea that there are very big companies build with it.
- Ruby on Rails is scalable for 99.999% of all startups created with it. This 99.999% will die for any other reason but not because of their tech stack. Again the same can be said about any other web framework. Of course the 99.999% is just a made up number based on the fact that there are so few companies failing because of their tech stack scalability.
- Twitter and Github are maybe in the top 0.0001% of web apps when thinking about scale or usage. Hope you (the reader of this comment) will create a startup that will be so successful in terms of scale. But the chances are that with 99.999% confidence, you are not them, and the chances to create a product that will be like them are slim.
- The problems at scale are not only technological but also organizational.
> Ruby on Rails is scalable for 99.999% of all startups created with it.
You are right of course, but not for your stated reasons. Essentially RoR doesn't scale. RoR scalability is a meme, anything else scales much better. From node to PHP, they all can do much more on much less hardware. To achieve hyperscale with RoR you have to throw absurd hardware with layers upon layers of load balancers in front of it.
But I'd argue that it doesn't matter at all for a startup. Like you said most won't ever reach the point where they need such a thing. But they all benefit quite dearly from the excellent developer velocity provided by RoR.
I'm sorry, but if your answer is that Node and PHP are inherently more scalable than RoR then you've lost me already.
I've worked for three successful startups that started on PHP that couldn't scale the PHP code bases with their customer growth. All three rebuilt on Rails and are still in business and on Rails today.
Another startup where I'm very close with the founders they are on Node and they say the system is "a complete dumpster fire". They wish they had built on anything else.
The company I'm with now is primarily a giant Rails monolith and we have 100s of thousands of users connected at any given time. Our biggest bottleneck isn't Rails it's Postgres. We are dealing with billions of rows and Postgres isn't really even the problem. The problem is our data model wasn't designed in a way that would allow sharding/partitioning. Even this isn't an intractable problem. We create updated schemas, migrate, backfill. What we don't need to do is leave Rails "because it doesn't scale".
Most companies that moved off of Rails because of scalability either don't actually understand scalability or it was 15 years ago and they were on Rails 2 when it was still immature.
If you have a PHP application and have found that Ruby allowed you to scale or vice versa, it probably just means the skill level of the dev decision makers improved. There are a lot of gotchas and pot holes one can find themselves stumbling into that you really only have to start caring about once you are actually at the point where scale matters.
This I 100% agree with. The parent post was essentially that Rails doesn't scale and "everything else scales better".
Most battle tested languages and frameworks can be adequately scaled if you have the right devs. I think that a lot of the reason we see system rewrites due to scalability is more because startups tend to hire developers that like to "build new things fast" and those aren't necessarily the same as the developers that have already dealt with 1M+ users at petabyte scale.
Once you become that successful sometimes the solution is to bring in people that have solved these problems of scalability previously. This sometimes results in rewrites in whole or in part because their experience is on a different stack.
In one of the PHP to Rails (for scalability) projects I worked on I was contacted quite early in the process. I am a longtime friend with one of the business owners. The existing developers could not scale the product horizontally and were already on the largest instances available at the time so there was no more ability to scale vertically.
They had hired a new technical lead that had extensive experience scaling Rails, but most of the team only knew PHP. My team did both Rails and PHP consulting at the time and we were hired to speed up the rewrite in Rails while the PHP devs were doing a mix of trying to keep things running and learn Rails so they could support after the rewrite.
The first thing I did was review the existing PHP codebase. I then advised that they not switch to Rails because I firmly believed that in about 3 months the PHP version could be refactored to allow for adequate horizontal scalability. The full rewrite was expected to take a little over a year.
The owner agreed that my assessment was probably right, but he still opted for the rewrite because the new lead was competent at scalability and likely would have quit if they stayed on PHP.
The vast majority of “rails doesn’t scale” complaints come from amateurs that don’t understand sql. They blame rails when they write poor queries, do things like join or aggregate in the application, don’t understand indexing, etc…
Right, but I do believe that it is important to choose something that scales competently:
> most won't ever reach the point where they need such a thing
I considered covering this argument in my gp comment. What if your startup does grow to the scale where it becomes an issue? Do you suspend new user signups until you can do the rewrite? Or do you just let things keep spiraling, like GitHub? Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite).
> Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite).
How can this be true when we know that Shopify, Gitlab, Github and all others are using RoR.
Here is a more concrete scale[1]:
> We served 75.98 Million requests per minute to our commerce platform at peak. That’s 1.27 Million requests per second!
Is that a bit enough limit for you?
Here is more:
> We achieved 99.999+% uptime while averaging 3 Terabytes per minute of egress traffic across our infrastructure [2]
It is not debatable. Github does it, lot of companies deploy ruby on rails daily. Github has a huge codebase, and still rocks. Back in 2008, there weren't any better option, to be honest. I'm quite sure if github was written in go, it would be a nightmare too, specially from devops point of view.
The slowness is definitely a problem and it uses a lot of memory. I'm not sure, the term "scalable" is right though. It's slow at any scale, but AFAIK doesn't get much less efficient or develop other problems as it scales. Sure, you can write your app in a way where it doesn't scale, but there is nothing in Rails that makes that inherent.
I think Rails is a victim of its own success: many of the hot new Rails codebases from that time are now 10 year old monoliths. And those monoliths need incredible amounts of tests to compensate for the lack of compile-time type checking, Rails version upgrades are multi-month nightmares, and the object-oriented statefulness of the language means that complex load-bearing code can be extremely tricky to untangle.
There are certainly new compelling projects like Sorbet to add type checking, and the ecosystem itself is very mature, it's just that the average codebase is not going to live up the experience you might have with a brand new one.
Where, for example, in 2015 any SaaS or API would provide a gem (lib) to interact with it, today it's no longer the case. Modern PSPs, storage, search engines, etc almost all lack an official gem. Often lack even a third party one.
And where back in 2015 there were popular systems in Ruby outside of rails, all those are crumbling and/or gone. Jekyll is no longer the go-to static site manager, Chef and Puppet no longer the obvious devops tools. And Ruby is completely absent from emerging technology (AI, blockchain, WASM, data science, etc).
I'm afraid Ruby is becoming a legacy language and Rails' will be a legacy framework soon. Where the bulk of the Ruby jobs are to keep old stuff running and maintained. Afraid, because I'm still primarily Ruby developer.
I am not sure what sources are you using for news, but in 2023 Ruby is growing strong and faster than in other years.
There are new books written, new conferences organised, Hanami 2 is out, new organisation created by companies to support Rails docs and marketing, Phlex is a nice way to work with views, someone started to work again on Camping, someone else is working again on a new portof shoes.rb
More content is created everyday: see for example dev.to starting to have beginner articles. A very good sign.
now regarding your fear, what I can say is act like your fear is real and it will be in some way or another.
About that content: back in the days there were numerous podcasts about Ruby or Rails or both. That was when podcasts were hardly as omnipresent as they are today. There were newsletters, blogs, and every e-learning platform had many prime tutorials on rails.
Those aren't all gone. But in the grand scheme of things, Ruby, and Rails' have been relatively decimated. There now are about twice as much (web) devs as back when it started but Rails nor Ruby is hardly twice as big. It's been going strong, solid, flatline.
(disclaimer I am the curator of first and the maintainer of the second)
From where I am, things don't look the same as you are describing them:
1. https://newsletter.shortruby.com - it is younger than 1 year, but you can find a lot of new content there: new podcasts were released in the last 12 months, new conferences were organized, and new books were announced. When I say new = it means never done before, not new editions.
2. https://rubyandrails.info - while it is not a comprehensive directory, it has a lot of resources. Indeed the youtube courses section is empty, but that is due to my lack of time, not because they are missing
I don't have time to debate everything you wrote in the article, nor do I think I can change your mind.
I also don't know the future. Maybe you are right, maybe you are wrong. I choose to believe that Ruby is not dying and act like it: launch a newsletter, start to write a book, and prepare some more projects.
Thx for the FUD salt. Rails never left, and neither did sinatra. In fact, other frameworks came to play, like roda. Ruby is ok.
Sure, jekyll is no longer the new hotness, but I don't see a market shift towards a single tool. There's just the usual fragmentation. Hugo, next, none of them is consensual.
Ruby was one of the primary targets of wasi. It compiles to WASM since 3.2 officially, but work started more than a year ago. Ruby in the browser is possible.
Sure, not everyone is targeting Ruby. But I don't see new products targeting new stuff either. Seems that there are less oficial SDKs nowadays, usually targeting the top 3 tier 1. And that's fine, and means little about Ruby in the end.
I think it'll be more fragmented. For one, because major language gain more features and such start overlapping more. Making them easier to move between.
And secondly because we're now at that pendulum swing, where people realize that "write once run everywhere" has severe downsides, easily overcome by writing software in a language or framework that fits the usecases best.
The latter is easily seen in the common practice of splitting out the UI in webdev. And in using microservices. Rails stubbornly goes against this common practice (which isn't a value call, just an observation) and as such, places itself outside of what we commonly are used to .
The former is seen in e.g. typing or type hints being added everywhere, languages getting support for functional programming, generics, interfaces, class inheritance etc.
When you lack a type system which catches certain errors at compile-time, you need some other way of catching them. Unit tests are the typical solution.
Without compile-time type checking, every single line of code needs to be evaluated with a unit test to ensure there won't be any runtime syntax errors.
If you rename a function, type checking will catch that you rename all usages of it (or fail). With a type system to catch this, you must rely on more complete unit tests to catch anything you forget.
Types do not remove the need for unit tests, but they relieve some pressure from them.
I've been doing fulltime Rails dev for some 15+ years.
Rails (and Ruby) make tradeoffs, or just inherently have downsides that many newer frameworks, libraries and languages solve, or solve differently.
For me, the most prominent are Rubys' dynamic typing and Rails' black magic. But my biggest gripe is how Rails lacks a space for business logic. Sure, you can bolt something on yourself. Or just throw it all throughout the http, storage and rendering layer willi-nilli.
This has caused so many of the codebases i worked on, to be unmaintainable, untestable and therefore legacy that I can certainly blame it on the framework.
I've worked on many go, rust, typescript, php and ruby-no-rails systems to be ever more certain about this. Many frameworks lack this area, and almost all quickly degrade into spaghettis. I've come to like DDD, hexagonal and clean architecture for solving this. Most are perpendicular to Rails.
So, i'm certain that contributor to the lack of popularity of Rails is how hard it is to build maintainable, testable, clean projects in it.
I'd say it's a gradient. With Rails(ish) on one end, via, Nest.js and Laravel (DI), Hanami to Event Sourcing, CQRS or Hexagonal setups on the other
The latter, in my experience, is best. It's a "no framework" setup really. Where you organize code according to a "framework" that's no code, but architecture, conventions, rules, and design patterns. Where code reuse goes via libs, put aside behind abstractions.
I consider the question "what framework offers good architecture (for maintainability, DDD or business logic)" a somewhat wrong question because in it lies a strong opinion of what a framework is. And such frameworks are counter to what you want: you don't want these frameworks.
Phoenix (web framework for elixir) famously has the meme out there that “Phoenix is not your application”, with various articles etc explaining that the web interface should be a layer on top of the application code. They made a big deal of adding Contexts [1] as part of the scaffold which isn’t much more than a directory to put core app code.
> But my biggest gripe is how Rails lacks a space for business logic.
You can literally create a directory called app/my_actual_app and put all your business logic in there, Rails will even autoload it for you.
IMO it’s the sudden change from the “we’ll hold your hand every step of the way and offer tools and workflows for everything” web part (controllers, routing, ORM) to the “go and build your goddamn app” dealing with business logic. So many (especially new) devs try to stay in the cozy zone of having a nice name for everything at all costs, so they try to cram everything into “services” and “decorators” and “interactors” (yuck) and they’ll build business logic out of callbacks on ActiveRecord models and overload the poor things with dozens of “concerns” instead of, you know, going and building a goddamn Ruby app.
> One problem with fat models is that unless you are really disciplined in your code hygiene, they can tend towards an assortment of code smells
And I wholeheartedly agree. With the addition that "code hygiene" if not enforced or encouraged, is always one of the first victims under stress. And every (successful) project will see such stress.
With Rails you have to spend extra effort to keep doing "the right thing", whereas is should cost cost less effort to do that, and extra effort to "do the bad thing".
I think that the things that Ruby optimises for - mainly that code should be beautiful english prose - just aren't things that developers widely ended valuing.
I think that it's syntax, or what "beautiful ruby code" looks like, is significantly different from most other languages, making it more off putting to pick up or switch between.
You've got the wrong impression of what ruby optimizes for. It's not "mainly that code should be beautiful English prose" -- which I would venture the closest you'll get for that goal is AppleScript -- but rather, quoting Matz "Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby."
> Sometimes people jot down pseudo-code on paper. If that pseudo-code runs directly on their computers, it's best, isn't it?
I think this turns people away from Ruby (and is what Ruby people love about Ruby). I'm not a fan of Go, but people say they enjoy writing Go, which looks very different from Ruby.
But what DHH does/did with it for Rails is of a different order.
There, often, "beauty" is in the way. Hundreds (or thousands) of methods magically appearing from nowhere on a Record, by inflecting a database scheme runtime. Thats neat and all, but I'd very much rather just explicitly write getters and setters. It's not as if (with autocomplete) such things are a time sink.
Yes, RoR is a different and larger beast than Ruby. It also does not optimize "mainly that code should be beautiful English prose."
You can import the joyful drive of Ruby into your RoR codebases. I've worked on plenty of rails codebases that were a pleasure to work in. Far more than any other web framework I've worked with.
I consider e.g. 'scope' to just be (slightly harder to test and follow) over a class method.
I consider a concerns to be more complex and unexpected versions of a Module.
I consider "render @foo" to be just an incomprehensible version of the explicit "render_partial("the_name", ...)" And so on.
All of these have bitten me many times, oft in production even. Many of these caused me and my step debugger hours of wading though deep stacks of method-missing or runtime code definitions.
For me it's quite the opposite. It was the best way to build applications in the past when client side js was hard to use.
Many startups took advantage in creating apps fast with RoR.
Now that (especially with TypeScript) JS is good enough, browsers and JS engines improved a lot, I start to see less advantages in not using js/ts both for client and server.
I think it might be the proverbial fast boat in a narrow stream, the narrow stream being ruby the language.
It's not a mainstream one, and frankly the main reason to learn it in practice is rails. There's a big cold start problem there.
You have to convince people to like both the language and the framework at the same moment of decision, in addition to committing to learning both at once.
That's just always going to be more difficult than selling only a framework to people who either already know, or see more value in learning, a more mainstream language like JS, Python or Java.
I think this is the biggest reason it's remained niche.
It's a great tool for those that want to build CRUD apps quickly and get 99% of the things right. That speed comes from code re-use (mostly gems). Once you get experienced in rails, you primarily glue things together. It's fast, but does not feel rewarding.
> Once you get experienced in rails, you primarily glue things together
Both of these are equally true for most other languages with mature ecosystems. IMO the speed of Rails development reflects the speed of Ruby development in general. The standard library has everything, all kinds of little methods for all kinds of little things. Combine that with ActiveSupport extensions and you can do everything.
It's Active Record that makes rails code re-use especially unique. I don't know of any other framework where you can 1) be certain of the ORM 2) add database tables from a third party library 3) the whole experience not being cobbled together.
Laravel? Unsure exactly what you're meaning by #2, but Laravel's Eloquent is an Active Record-style ORM, and can act as a layer on top of most db tables I've used it on.
That's interesting. I remember having to defend my using ruby to other programmers around that time. I always loved it, and all the hate seemed to be centered around "it's too slow". No one ever brought up twitter being down, explicitly, that I can recall. Perhaps that's what they had in the back of their mind though? It's been a bit of a mystery to me why people passionately hate on ruby and IMO dismiss it out of hand. It's so nice to program with.
My impression (from years past) is that Ruby is what developers loved. It was my first “real” programming language and the reason I fell in love with coding. These days I’m mostly writing in JS and Node for work. Rails is the money-maker, but the philosophy of convention over configuration is why it really off IMO, and something that is both underrated and missing in the JS world.
IME you’re either a Rails Person or you’re not, and it’s hard to make either group understand why the other likes it. I also couldn’t understand why people would be okay with so much being hidden from them, or made in a way that removed the ability to reason about it externally, but my Rails colleagues just liked it and didn’t understand why I’d care.
If you know what Rails is doing then it isn’t hard to reason about. This comes with time/experience & reading Rails source.
Magic is a beautiful term for what Rails does, because just like a magician’s tricks, it’s possible to have a full understanding of what’s going on. It’s not as if Rails acts randomly.
Yes, that’s why I also wrote about the ability to reason about what it’s doing. You don’t have to search for a magician’s tricks if the intention is for you to be able to infer or intuit what they’re doing.
It’s magic when the only way to know is to be told. Which is, to me, a nonstarter for software.
Rails has always been fully open source. If you didn't understand something you simply looked at the Rails source code. At the time it came out most people were using .NET or Java which were largely closed source and PHP which was open source, but there were no real frameworks at that time. CodeIgniter and Cake came out in the couple of years following and were both immature in comparison.
> If you didn't understand something you simply looked at the Rails source code.
Okay, but what if instead a library was designed to be more reasonable and intuitive, such that you didn't need to dig through its source to understand what you needed? This is the problem with "magic".
> most people were using .NET or Java which were largely closed source and PHP
These are programming languages. Rails is a web framework.
1 point by fallingmeat 1 minute ago | next | edit | delete [–]
Why do similar articles or headlines seem to come up at the same time on front page? e.g. there is another article on Rails that happens to be front page right now that is seemingly otherwise unrelated (the other article is called The Rails Doctrine).
It’s always so odd when these type of posts pop up and I scroll through and see comments about how people love Ruby/Rails. Mainly because I can’t stand the language and framework. I absolutely hate any time I have to read through Ruby/Rails code or write something in it.
Agreed -- over the years working in many different languages and frameworks, I've found it most difficult to transfer experience and learnings to rails. Whereas in pretty much every other stack, I can trace through and read code to understand how the framework and library code and dependencies all work together, in a rails app, I have to read docs to grok magic. With all the metaprogramming, it is near impossible to just read code and get a sense of what all is happening in any reasonable amount of time.
Not OP, but I believe you're reading the wrong thing into that response.
For me, the responses are fascinating, because many of the things people seem to love about rails (and ruby) are the ones that I hate. It's not that you're not allowed to like those things, by all means feel free - I'm just perplexed.
Fwiw, I regularly use ruby for work (with and without rails) and I'm fairly competent with it. I just think it sucks.
Funny, it has the best, most complex syntax I have ever used.
I don't say this to be reductive. I believe there are two ways to approach a programming language: either from the formally-correct, highly-specified point of view; or from the communication and linguistics point of view. Ruby has a terrifying formal syntax precisely so that it can be extremely comfortable if you can get yourself to ignore the formality.
The flexibility fits my brain extremely well, and most of the time the theoretical syntactic complexity just isn't an issue.
i code in go these days. i have done perl and java and some others, started with c, did a bit of python along the way. ruby was always my favorite language. so expressive, so easy to be clear while being terse. i've spent months of my life shortening (my own) verbose ruby code. i switched to go only because of the execution speed and the compilation, a few years back the comparison was not even close. i don't know if i would like to go back to dynamic language... but i found ruby to be such a beautiful language.
p.s. this was big when i was leaving ruby: https://rubocop.org/ maybe there is a replacement now, but maybe it would have changed your view.
Many languages look similar, and familiarity feels simple. Ruby however has a lot of idioms fairly unique to the language, and what is different is mistaken for complexity.
I'd call promises in Javascript complex. A block is Ruby isn't complex, it's just weird if you're new to the language.
Worst maybe, you definitely don’t have to like it. Difficult to parse, maybe, some things can look similar to other things (blocks and Hashes), but complex from to POV of the programmer? Not really.
Out of those, I’d at least add the RuboCop [1] linter and the BetterSpecs [2] guidelines to this list. Both eliminated bikeshedding in the team and freed up brainpower to solve actual problems: the first one helps you learn intricacies of Ruby bit by bit right in the IDE and the latter one pushes you to write test in a specific style that’s easy to maintain and trust.
[1] https://github.com/rubocop/rubocop
[2] https://www.betterspecs.org/