My time with Rails is up - lreeves
======
vinceguidry
> Now, this line of code is not simple, it’s easy to write it, but the code is
> extremely complicated under the hood because:

Every time I hear someone complain about Rails, I ask myself if this person is
really just complaining about how complex web dev is. I've never seen a
complaint that passed this smell test.

Yes, Rails abstracts over a veritable shit-ton of complicated domains. The
problem is, that complexity isn't going to go away if you decide not to use
those abstractions. Every single one of that laundry-list of things that
ActiveRecord::Base.create does will have to be implemented again, by you,
badly, if you choose to roll your own.

It boggles my mind why developers don't take the web seriously as a domain,
like it's not real coding or something. It's the worst instance of bike-
shedding I've ever seen.

Rails isn't perfect, by any means. But Rails is not a black box, it's all free
software. You are more than free to re-implement anything Rails does yourself
and release it as a gem. Modularity and flexibility are built right in. It
seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.

~~~
awesomepantsm
Try setting up rails dev on a windows environment and get back to me.

~~~
Retr0spectrum
I think the majority of webdev tools are pretty tedious to set up on Windows
without cygwin etc.

~~~
Marazan
Flask is no problem, Django is child's play to setup.

~~~
true_religion
I feel like that's because someone put a lot of time and effort into making
Python's core library play nice on Windows, and Pythonistas tend to interact
with the OS/network only through core library functions.

To contrast, Elixir runs on Windows. However, it may be hard to get all your
projects up and running due to various baked in concerns where they were
written to support Unix-like systems only.

------
matt4077
If any of the frameworks glorified on HN were subject to the same scrutiny as
Rails, Github would need a suicide hotline.

I've recently had the pleasure of working on a new, medium-sized node/react
project. Now I was new to a lot of the technology, but I've learned a few and
would think I have some experience.

It probably took me a week to get webpack running the way I wanted. The
documentation is an atrocious mix of stuff that is outdated (older than 6
months) and stuff that's too new (webpack 2.0) without any indication as to
the validity. There're six different ways to get hot reloading/replacement to
work, with similar problems. The configuration's syntax is heavily influenced
by brainfuck with a /\w/[{\\[]/s thrown in for good measure. As a soothing
measure, webpack doesn't complain about anything but parse errors with the
configuration. The version I was using came with 12 different options to
render source maps, none of which worked in chrome (since fixed).

And that's just the linker. I actually had presets to search for, i. e.
["express.js" from:<date-of-last-stable-release> to:<date-of-following-
alpha/beta-release>]. node_modules once managed to consume 4TB of hd space
(someone managed to create a circular dependency) and even in regular use gets
to the point where I'm looking for the elasticsearch plugin for ls *<x>. If
you have checkouts of several versions or projects, each one will have it's
own version of left_pad & friends at around 230MB (just checked with a clean
install of mxstbr/react-boilerplate) with no way of deduplication.

I enjoy playing with new technology (currently elm & swift) but I know that
it's time "joyfully wasted" right now and don't try to justify it. There's no
amount of type-safety bugs that could cost as much time as a new framework's
kinks.

~~~
BurningFrog
The most used frameworks are always the most complained about.

It's an easy mistake to think that means they're the worst.

~~~
rtpg
While that's true, why don't we see this sort of stuff with Django or Flask?

Of course we see people complain about these tools, but my impression is that
people who end up leaving those communities are rarely because of community
issues (more like "I'm going to do some Go instead"-style things)

Surely something is different. It's not like Django is unused...

~~~
goldbrick
Rails is at least an order of magnitude more widespread than
Django/Laravel/any of its imitators. If you take a swing at any of the follow-
ons, its proponents will invariably say it's just doing what Rails does. Try
to imagine a "Why Django sucks" flamepost garnering anywhere near the
attention that the same does for Rails... yeah, won't happen.

~~~
uptownJimmy
Rails is several percentage points more widespread than Django, but far from
any order of magnitude.

------
pmontra
I used Rails mostly for small or medium sized projects, one or two developers
teams, all of us freelancers. It's the perfect tool for this kind of work. We
can deliver quickly, send invoices, move on to something else or come back
later to add features.

Do projects get complicated? Yes, some of then. Mainly because most customers
pay for features and not for refactoring or design, which they don't
understand (remember, no in house technical staff). Try to sell them a new
page with attached the price of a major refactoring... good luck with that. So
sometimes features get kludged together because of budget constraints. I have
projects with suboptimal UX (understatement) because they rationally decide to
make tradeoffs between usability and costs. It's their privilege. I bet this
would happen with any language or framework. Your customers could be more long
sighted than mines, I hope they are.

So, would I move away from Ruby and from Rails? Yes, when customers won't like
starting a project with Rails anymore. This means that other tools don't have
to cost them more. Do I care about Rails architectural shortcomings? A little,
but I appreciate its shortcuts more. They work well in my projects.

~~~
erikpukinskis
This is my takeaway from Rails. Good default for your 1.0. Frankly, I would
probably use Rails even if I was starting a startup. It's easy to hire, easy
to talk about. Heck you will often find graphic designers who have played with
Rails.

Choosing Rails will definitely lead to problems in the long run, but at least
they are well understood problems. You're going to do an in-flight replacement
of your 1.0 eventually anyway. You just need one grayhair on the team to steer
the younglings away from the worst abuses and you'll have a stable, if clunky,
platform to build on. It's the definition of mitigating risk.

Java and C# are of course equally boring, but I think the fact that Rails is
culturally open source provides a huge benefit over them.

JavaScript, Go, Haskell, etc are arguably better if you really understand
them, but they're research projects. Lots of great pieces of code, but the
story of how to use them together is still being written. I would use one of
them if my intention was to hire slow and keep my dev team fewer than ~30
people in the long term.

~~~
hiphipjorge
What you're missing (at least with Node.js/Javascript) is that Node does not
aim to be Rails. Node doesn't aim to have one correct way of doing one thing
as Rails often does. Yes, there are best practices, but Node aims to give the
developer the freedom to do things as they need to.

The result of this is that, yes, development of your standard CRUD app is
probably not as fast as it would be with Rails. Also, moving from project to
project is not as easy as it would be with Rails. But the advantage is that,
if you have good developers who are good at architecting (a big if), you
architecture will better reflect the problem at hand.

~~~
matwood
> The result of this is that, yes, development of your standard CRUD app is
> probably not as fast as it would be with Rails. Also, moving from project to
> project is not as easy as it would be with Rails. But the advantage is that,
> if you have good developers who are good at architecting (a big if), you
> architecture will better reflect the problem at hand.

And if you just want something to work quickly, Rails wins. JS encourages
developers to spend days and weeks on picking each part of a framework for an
MVP that may go nowhere. Rails is no longer the new shiny and it has moved
into the 'get shit done' category of developer tools.

------
orthoganol
I can't take his opinions too seriously because his 3 central gripes, which he
wrote extensively about, boil down to:

1) Too much complexity is hidden by simple interfaces

Those simple interfaces make programming enjoyable and don't break, so...

2) Your app logic is going to be too tightly coupled to core Rails features
like AR, helpers, controllers ("your app is Rails")

Yes, you are in fact using the features of Rails when you use Rails. Is this
actually a problem?

3) ActiveSupport. "No actual solutions, no solid abstractions, just nasty
workarounds"

ActiveSupport has saved me bajillions of hours and never broke anything for
clients. I wasn't aware it was such a flawed library, if it is?

Rails is maximized for developer happiness by, among other things, making
things simple (yes, which to a large extent means hiding complexity), giving
you a bunch of Omikase core features that you can in fact use, and gives you a
lot of sugary methods for handling things that are tedious. I understand
people wanting to try other things and leave Rails, no problem with that, but
his stated reasons reveal a lot more about him than about Rails.

~~~
philwelch
> Those simple interfaces make programming enjoyable and don't break, so...

If they don't break for you, then use Rails. I find that they break _all the
time_.

Hint: What does "validates: :unique" actually do?

~~~
gkop
There an info box calling this out in the Rails Guide for Validations.

~~~
philwelch
I don't see an info box for the issue I'm thinking of. Are you thinking of the
case sensitivity issue?

[http://guides.rubyonrails.org/active_record_validations.html...](http://guides.rubyonrails.org/active_record_validations.html#uniqueness)

The expectation is that "validates :field, uniqueness: true" would validate
that the value of the indicated field is unique among all rows in the table.
However, this abstraction breaks spectacularly. Any web application, even a
Rails app, is usually run over multiple processes, often on multiple different
hosts. Uniqueness validation does a non-atomic check and set, which is a known
race condition in this kind of environment. The guide does say:

> ...it may happen that two different database connections create two records
> with the same value for a column that you intend to be unique. To avoid
> that, you must create a unique index on both columns in your database.

But what actually happens when we do this? The race condition where you would
otherwise get non-unique values inserted into a column of unique values is
instead a race condition where a database adapter throws a generic exception
for "the DB complained" with an error message about a failed constraint, and
your site throws a 500. Your only recourse is to capture an overly generic
class of exception that's thrown by e.g. the MySQL adapter, pattern-match the
exception text for a magic string like "uniqueness constraint failed"
depending upon which DB you're using, and write your own custom code to
recover from that.

That's right: Rails has adapters for MySQL, PostgreSQL, etc, but "adapting"
different SQL variants to ActiveRecord doesn't go as far as turning constraint
failures, lock wait timeouts, etc. into generic, application-intelligible
exception classes. The entire point of ActiveRecord is that your application
code should be portable between SQL variants--hell, it shouldn't even have to
_know_ what SQL variant it runs on!--but between having to write your own SQL
for any use case other than "let's deal with a result set as an array of
ActiveRecord objects" and this nonsense, no real-world Rails application
achieves this.

In other words, something that Rails pretends happens in one line of code does
not actually happen at all, and to make it actually happen, you have to write
a whole bunch of code that has to resort to string-matching a bucket exception
class for "the DB complained" for the specific exception text that your
particular DB engine throws. This is probably the worst example, but it's
illustrative. Rails provides the illusion of simple interfaces and enjoyable
programming. After working in Rails for just a few years, though, the illusion
has vanished for me and I spend far too much time asking questions like "how
the fuck did THAT get set to nil?" and "what does does it take to turn this
multiline string of raw SQL into objects I can actually use?".

Honestly, I don't want to come across as too harsh. The sad truth is that
nothing is perfect, and if you focus on the imperfections, all software pretty
much just sucks. But Rails actually tries to convince you that it doesn't
suck, that it abstracts away the complexity for you, and that you don't have
to worry about it yourself, leaving you ill-prepared for the reality that it's
still there and you do have to worry about it.

~~~
Olap84
So given your rant, does any ORM cater for this condition better?

Does any web framework manage these? Given two almost identical requests that
cause a race condition most frameworks fall down in my experience.

~~~
philwelch
There are some ORM's where you define the schema in the application code and
it alters the DB schema on the fly, but that seems dangerous, too.

What I would do, given Rails' existing framework of "programmatically discover
the table schema and magically generate logic from it", is set it up so that
it observes uniqueness constraints and programmatically adds the validation
when found. Also, the adapters should interpret server error messages, throw a
custom exception class for "uniqueness constraint failed", and ActiveRecord
should catch this exception class and turn it into a failed validation when
you attempt to save a record.

If that's too much work, just be fucking honest, remove the uniqueness
validation (because it's completely useless), and be upfront with us that we
have to roll our own solution for it.

------
tptacek
_This is how Rails works, classic example:_

    
    
        User.create(params[:user])
    

_You see a simple line of code, and you can immediately say (assuming you know
User is an AR model) what it’s doing. The problem here is that people confuse
simplicity with convenience. It’s convenient (aka “easy”) to write this in
your controller and get the job done, right?_

 _Now, this line of code is not simple, it’s easy to write it, but the code is
extremely complicated under the hood because:_

 _\- params must often go through db-specific coercions_

 _\- params must be validated_

 _\- params might be changed through callbacks, including external systems
causing side-effects_

 _\- invalid state results in setting error messages, which depends on
external system (i.e. I18n)_

 _\- valid params must be set as object’s state, potentially setting up
associated objects too_

 _\- a single object or an entire object graph must be stored in the database_

 _This lacks basic separation of concerns, which is always damaging for any
complex project. It increases coupling and makes it harder to change and
extend code._

This feels like the core of the argument of the whole post. It does not seem
correct. In isolation, the call to User#create seems magical. But there's not
enough context here to criticize it. We don't know enough to say whether
there's inadequate separation of concerns.

No matter how we handle "users", we are going to need to do all 6 things in
the list the author presented. No matter how we structure those 6 things,
there is going to be a single entrypoint function that kicks them off --- _end
users_ won't be pushing 6 different buttons to drive them. So: what's the
better design here?

~~~
oneloop
Just to point out that all those objections could be made about Django as
well.

~~~
cname
In Django, the validation & type coercion would typically happen in a Form
object (or, if you're using Django REST Framework, a Serializer). That step at
least is outside of the ORM and seems much more explicit to me.

Also, in Django models are explicitly defined. There's no ActiveRecord magic
of reading the database to define the model. Which is not to say that AR's
approach is bad or wrong, but it is pretty significantly different from
Django.

~~~
draw_down
"Explicit is better than implicit"

------
matt4077
I can't grasp the hostile attitude towards rails at HN. Even agreeing with
(some) of the criticism, I'm deeply thankful to Rails, DHH and everyone else
involved.

Because before rails 1.0, I worked in php.

Many people may actually be too young to remember, but the jump from php and
anything else that was state-of-the-art at the time to rails was without doubt
the biggest leap web development ever took.

The most meaningful advances actually weren't just technical but social. It
would've been possible to write an excellent webapp before rails, but just
about nobody ever did. The opinionated nature of Rails many are complaining
about today was a revolution because it taught everyone using it good
architecture. You can nitpick about any one of those opinions, sure. But back
then it was common to join a project with >100kloc with directories containing
password.php, passwprds.php, pass.v3-old.inc, large_image.head.2002-v1.jpg &
employees.xls. The quality of almost any rails project I have seen is, in
comparison, excellent. It'd say a new team member on a rails project was
productive in less than a third of the time it took in non-rails projects at
the time.

So, to anyone complaining: I'm pretty sure that looking into any of your
strongest held believes on web dev, you'll discover that rails had significant
influence in creating them in the first place. To do something like that,
pretty much as just one guy on the beginning, should afford someone a certain
amount of respect.

~~~
mattmcknight
Same, but coming from the hell of Java web applications. They had the opposite
problem, too much architecture.

~~~
heartbreak
Which is funny, because that's what exactly what the OP wants from Rails.

~~~
mattmcknight
I see it more as he wants Data Mapper to be as easy as Active Record. Just
from a pure patterns perspective, it never will be, because Data Mapper has
one additional level of complexity.

------
cynusx
I think rails has plateaud in terms of improvements. The article is pointing
out the tight coupling of activerecord with business logic which is the
consequence of a belief that I strongly disagree with in the rails community.
'fat models, skinny controllers' has caused a lot of mayhem as minor database
updates (or update intention) triggers a cascade of actions.

This behaviour is counter to the model2 MVC implementation that rails is using
as controllers should really be in charge of coordinating (helped by
specialized classes if need be).

The author correctly points out that the way rails deals with views is painful
however rails views are not tied to the model at all, they are tied to
controllers and this can be modified if need be.

I personally maintain an approach of tying dedicated ruby classes to view
files (e.g. SidebarComponent) and compose the view in the controller using a
chain of these classes. This approach is much more object-oriented and avoids
the weird pass-along view-hierarchies that many rails projects have.

There are much things to improve about rails but the project doesn't seem to
absorb more object-oriented approaches over time and is tilted heavily towards
DSL's for everything and doesn't value creating a more specialized class
hierarchy to encapsulate more complexity.

I don't see a need to move away from Rails yet though as you can easily work
inside the framework in a more Object-oriented approach. I guess you can
characterize my approach as skinny models, skinny controllers, fat business
logic objects and every partial is powered by a view object.

~~~
askyourmother
Improvements are a strong word, I thought they were still playing whack a mole
on the numerous Rails RCE security issues.

------
clessg
I too have stopped using Rails. To other Rails refugees, I highly recommend
the up-and-coming Phoenix Framework for the Elixir language:
[http://www.phoenixframework.org/](http://www.phoenixframework.org/).

Simple as in simple, fast, productive, beautiful Ruby-like syntax. Favors a
functional and immutable workflow over object-oriented and mutable spaghetti
code.

~~~
danenania
How's the community and library ecosystem looking in Elixir/Phoenix?

It sounds great in principle. I'd love to move from Rails toward something
more functionally-inspired, but I worry that lack of libraries and google
results is going to be a net productivity killer over the Rails + evolving
into micro-services approach.

~~~
brightball
[https://github.com/h4cc/awesome-elixir](https://github.com/h4cc/awesome-
elixir)

~~~
danenania
Thanks! Great list.

------
Locke
Nostalgia warning: I also grew frustrated with Rails / ActiveRecord and jumped
to Merb / DataMapper with excitement. Perhaps it will sound like a small
thing, but I remember feeling especially frustrated that every ActiveRecord
model became such via inheritance. This drove me crazy:

    
    
        class User < ActiveRecord::Base
    

Why should my `User` extend from `ActiveRecord::Base`? Is a User of my app
also an ActiveRecord::Base? What is an ActiveRecord::Base anyway?

So, when DataMapper came along and favored composition over inheritance I was
sold.

However, my experience with DataMapper was that it didn't have the stability
of ActiveRecord, nor did it reach feature parity.

And, then Rails killed Merb. At the time I thought it was a tragedy. The
competition Merb provided _did_ improve Rails, it would have been nice if that
competition had been longer term, though. On the flipside, I wonder if there
would have been enough community to support two large Ruby web frameworks.

In the end I made peace with Rails and ActiveRecord (and, believe it or not,
even ActiveSupport!). I don't have great love for Rails, but it is a powerful
tool, so I accept it for what it is.

That said, I think the author's criticisms are well stated and hopefully there
will be some influence on the future direction of Rails, etc, and the way devs
approach Rails.

~~~
barrkel
Having used many different ORMs that let you think that your business models
could just gain persistence with a little sprinking of automagic, I far prefer
the non-object-orientation of ActiveRecord.

Databases aren't object-oriented. Thinking of them with an is-a, LSP etc.
mindset is a recipe for pain down the road. Databases are containers for
facts: a means of storing, finding, synthesizing and manipulating facts. Your
User class isn't a user of your application; IMO it's wrong to think of it as
an object, because it could just be a slice of the User's facts (e.g. a subset
of the columns).

I'm not a big fan of object orientation any more, and I like my databases to
be stores of facts. The data in the database is primary; code in the
application is secondary. Persistence isn't something I add to my benighted
objects to let them be reanimated by query; persistence is what lets me
briefly get a handy representation of a tuple locally.

To my mind, ActiveRecord models are little more than hashes with a nicer
syntax. I don't need them to be much more; I don't want them to be much more.
You can try and add methods and make them smaller, but coordinating the
manipulation of facts is problematic in a transactional world, and the
responsibilities aren't clear either. Object orientation is predicated on the
idea of message sends and hidden state; tables have explicit state and no
behaviour. Not a good match.

~~~
spacemanmatt
Honestly, I feel like OO has been a net harm to the practice. It is a useful
code reuse pattern but I feel like it has gotten far too much play.

------
jon-wood
I'm somewhat split on the author's opinion here. I also picked up Rails back
in the day (I think the first version I installed was 0.8), and I have a bit
of a love/hate relationship with it.

As a framework for building comventional HTML templated database backed
websites I still think it's near unbeatable, especially with the addition of a
few common gems. However it so often gets shoehorned into other places - API
backends, rich client apps, and massive systems. Places where the Rails
conventions rapidly go from everything falling into place to getting in the
way and needing to be worked around, or heavily tuned.

I completely agree that ActiveRecord is the core of why big Rails applications
are complex to work with and often exhibit disproportionally poor performance.
It doesn't lend itself well to composition, and results in data persistence
being intertwined with business logic. That's fine for early prototypes, and
in all honesty will get you to market quickly, but it makes extracting the
concepts you discover during development into a coherant API much more complex
than I'd like.

These days I still use Rails for the aforementioned HTML generating web
applications, but it's often acting as an API client to systems built on top
of a Grape based backend, with an API built around service objects and a
simple data access later.

~~~
keithwhor
Interesting you bring up the point about API backends. I'm the author of Nodal
[1], with the goal of bringing the best design patterns and practices from
Rails and Django to the world of Node, _focused completely on building a
decoupled API layer_. There is no view / template logic at all.

The project is very lightweight right now (benefits of being a young project
with a sole full-time contributor), but I'd be interested to hear your
feedback as to what you think is or isn't necessary for continued development.
:)

[1] [http://github.com/keithwhor/nodal](http://github.com/keithwhor/nodal)

~~~
jon-wood
Interesting, I think I came across Nodal while evaluating options for a side
project a while back. Having just taken another look the big thing that seemed
to be missing was something to serialize objects to JSON, although that may be
because serializing objects is so trivial on JavaScript anyway. There also
didn't seem to be much documentation about the operational side of things,
most glaring was nothing being said about how the scheduler actually schedules
jobs and ensures they get run.

~~~
keithwhor
Scheduler is actually still a WIP. I've changed the core around significantly
in the last few releases, which has changed how the scheduler operates. That's
why there's not much around it. ;)

We serialize models to JSON automatically in the response layer, and all
models have a `.toObject()` method that takes an optional interface (which
keys to actually serialize).

There is full API documentation but I still have a _lot_ of work to do
creating more fleshed-out tutorials. :)

~~~
jon-wood
The issue I have with just having a toObject or to_json method is that context
is everything when serialising. Different access levels, different client
types, and just different parts of an API call for different ways of sending
data to end users.

~~~
keithwhor
Which is why you very clearly specify the _interface_ whenever .toObject is
called (which fields are exposed). By default, everything is included, but you
have complete granular control. It's what allows us to do things like have
full GraphQL support. :)

[http://graphql.nodaljs.com/](http://graphql.nodaljs.com/)

------
Doctor_Fegg
I read this with a lot of head-nodding but also a great sense of sadness.

I agree with pretty much every brickbat hurled at Rails in this article,
except for one thing:

> Both projects were ultimately killed by Rails as Merb was “merged” into
> Rails, what turned out to be a major Rails refactor for its 3.0 version.
> DataMapper lost its community attention and without much support, it never
> evolved as it could if Merb was not “merged” into Rails.

DataMapper wasn't killed by Rails absorbing Merb. DataMapper was killed by
"Things You Should Never Do, Part I":

> "They did it by making the single worst strategic mistake that any software
> company can make: They decided to rewrite the code from scratch."

([http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html))

DataMapper 2 was insanely ambitious, and true enough, it was never finished. A
core subset was salvaged as ROM (Ruby Object Mapper), which has a certain
artisan purity but is a long way from hitting the readable/understandable
sweet spot that DataMapper originally had. But DataMapper 1 was abandoned by
its developers. Pull requests languished and there weren't even any
maintenance releases. I idled in the DataMapper IRC channel for a while and
pretty much every query was answered with "don't bother, wait for DM 2".
Unsurprisingly, people switched to ActiveRecord instead.

I still use DataMapper. I use it in my own framework, which is plaintively
simple compared to Rails and no doubt makes a load of mistakes, but they're
the mistakes I've chosen to make (which, as per DHH, is "opinionated"
software). I would love DataMapper to be, if not revived, at least slightly
maintained. There is life outside Rails, but you have to want it.

~~~
ssmoot
You nailed it. HABTM just never worked, and there was little interest in
making it work. Since I handed out commit-access like candy, the majority of
contributions were to endlessly refactor. Or do things like letting you treat
a CSV file as a database. And HABTM still didn't work.

I didn't know how to put the genie back in the bottle. I didn't have the same
problems that prompted me to create DM in the first place anymore (and by that
point, I wasn't sure that porting a large Java Pattern to Ruby was even a good
idea considering what I'd learned in the process about method dispatch
performance in Ruby) and I was burned out on maintenance. So I handed over the
keys and the rest is history.

I messed up. :-)

Today I'm happily writing apps with akka-http and think O/R Mappers are a
fundamentally flawed idea. It's like trying to build a truck to move a few
yards of dirt 100 feet. It'll never pay off. And I think even "users" would
probably find that the hours they put into learning and using the tool will
never get ahead of the performance, simplicity and linear scaling of effort
they'd have had with a simpler solution.

So these days I'm much more likely to write this in Scala:

    
    
      val limit = 10.0
    
      sql"SELECT name FROM coffees WHERE price < $limit".as[String]
    

Than anything else. You will never find an O/RM that's faster, simpler or
easier to write and maintain than that.

Plus Contextual Validations in the O/RM is just a bad idea. Even if they do
appear in the PoEAA. First-class-Form objects and deserialization/validation
at the app boundaries may not be a new idea, but it's the right one. (IMO)

~~~
solnic
Hey Sam, great to see you commenting on this :) I started contributing to DM
when Dan was already in charge but I was a DM user when you were still working
on it.

Anyhow, you made really good points here. I've worked on ORMs for a couple of
years before I concluded the same - NOT WORTH THE EFFORT.

My approach with rom-rb is functional, as in this project works more like
persistence libs in functional languages, rather than an O/R mapper. I removed
the whole idea of mutable objects and managing their state using UoW etc. This
simplified the stack a lot, and despite a complete lack of any performance-
related tweaks rom-rb is already faster than ActiveRecord.

I also agree with your opinion re validations. I removed this concept from
rom-rb as well and built a standalone validation library instead. This works
very well.

Cheers!

~~~
ssmoot
I think I'd blocked out the pain of dealing with mutable strings. :-)

We were a pretty enthusiastic bunch back in the day. Glad to hear you're still
pushing things forward.

------
brightball
The thing that has blown my mind about Elixir and Phoenix is how it gets
everything right. It's the clear migration path from Rails.

~~~
pmontra
Phoenix is very Rails like in the way it makes developers work and very un-
Erlang. I mean: Phoenix apps are monoliths and not loose collectives of
processes with an explicit http process.

Check "Phoenix is not Your Application" at
[http://www.elixirconf.eu/](http://www.elixirconf.eu/)

It starts with the right claim but it ends with workers inside Phoenix.
Instead the router and the http server should be at the same level of the
other workers. Actually, they shoul be much less important, an implementation
detail.

~~~
chrismccord
A new phoenix application is not a monolith. The `phoenix.new` generator
generates a regular _Elixir_ application for you that sets up a default
Endpoint worker in your supervision tree, as well as a web directory to put
phoenix related files (routers, controllers, etc). wrt to collective process,
we add `worker(MyApp.Endpoint, [])` into your supervision tree, so we do
exactly what you are wanting. Building a Phoenix application is building an
Elixir application, not the other way around. Your phoenix dependency and
related workers are just one component to your larger Elixir/OTP
infrastructure. Note: Lance Halvorsen, who gave the "Phoenix is not your App"
talk, is on the Phoenix core team. We have been pushing these ideas since the
beginning and as Lance I and laid out in our ElixirConfEU talks, we're taking
a stronger stance on isolation with upcoming changes to guides and phoenix
resource generators.

~~~
pmontra
Understood but to make me clear: I'd like to see Phoenix as part of an
umbrella application and not it starting other applications as its workers. It
should be a peer among peers and not the boss. However, as Rails demonstrated,
the current approach is very convenient so I can hardly criticize it too much
at this stage of Phoenix adoption. I think it helps the onboarding to the
platform.

~~~
chrismccord
Phoenix v1.3 is adding an `--umbrella` flag to the `phoenix.new` generator for
first-class umbrella support out of the box. In the Phoenix book we also have
the reader breakout their application in an umbrella for the domain bits and a
web app for the phoenix bits. Umbrellas have been a little underserved in the
community so far, but stay tuned for future improvements around this.

~~~
pmontra
Great news, thanks!

------
adamors
I have 2 main concerns going forward with any Rails alternative (ie.
Trailblazer and the like): community support and jobs.

I have no idea how big the community behind each library/framework is and
honestly I don't have the time to properly test-drive multiple and research
the health of their respective ecosystems. With Rails I can rely on 10-15 gems
that can help me with 80% of my projects. Perhaps I overestimate my reliance
on 3rd party code, but that leaves me with my second issue.

Ruby jobs are de facto Rails jobs. I have weekly email newsletters set up for
Ruby jobs and in the last 3+ years only a handful were Sinatra/Rack based. It
would be interesting to see a reliable source of non-Rails Ruby jobs out
there.

~~~
chucksmash
At some point you'll be in a position to decide which tech stack a company
should use. I suspect you'll find there's a bit of a chicken and egg problem
here - you'll want access to the largest pool of good candidates possible so
you will also be disincentived from straying from the well worn path.

Even if you grant that good programmers can pick up new languages or
frameworks easily (which I'm not entirely convinced of - there is a wide gulf
between "can follow the tutorial" and "successfully used in anger"), you'll
incur a penalty in velocity while all your new hires learn Framework X.

Anecdotal example of the perils of going off the beaten path: I often see a
job advert on StackO for a company looking for Python/Django guys. When you
click through to the job description, they are actually using Perl/Dancer. Not
that there's anything wrong with that, but for me personally that's a deal
breaker. I have no interest in investing the time to become proficient on that
particular stack.

~~~
pessimizer
> Even if you grant that good programmers can pick up new languages or
> frameworks easily (which I'm not entirely convinced of - there is a wide
> gulf between "can follow the tutorial" and "successfully used in anger"),
> you'll incur a penalty in velocity while all your new hires learn Framework
> X.

I think the question is more "Does what we're doing require good programmers,
or can we get by with shitty ones?" More often than not, you're not doing
anything special, and you want to pick a platform that the cheapest, most
common programmers out there can add features in a non-disastrous amount of
time (different depending on industry + your competition), and not generate
enough technical debt to collapse everything before the next rewrite/upgrade
cycle.

------
captain_crabs
I'm a full-time Rails developer, and I've run into the exact pains that he's
talking about. By and large, I've fought with ridiculous things as projects
grew, and run into extremely 'magical' bugs. It's frustrating as hell. But
I've found the way through them is actually to lean into ActiveRecord, not
away from it.

When it really boils down to it, ActiveRecord is a perfect pattern to deal
with the "submit a form, validate it, run some logic, return the results"
round-trip that's the core experience of web applications. Do you have
validated data you need to do really complex logic on? Sweet. Send it on over
to some PORO's. Have a complex query that isn't easy to cache? Nice!
ActiveRecord will get out of your way. What's really hard is figuring out how
to frame the problem in a way that makes Rails a great solution for it. This
part is really really hard, I think in a lot of ways akin to art (and by 'art'
I don't mean some deeper honor or aesthetic - just that there's no guidance),
since the principles and patterns actually come from your domain and not
somewhere else. And the developers I know who really hate the way Rails does
something, especially ActiveRecord, are huge on applying patterns.

When I've taken the time to think through how to structure, really deeply, the
applications are a pleasure to change and modify even when I come back much
later. And for me, the proof is in the pudding: those aforementioned other
developers who hate ActiveRecord don't complain! They'll see it, give a small
'huh,' then go do what they need to do just fine. But when I don't, they turn
into the twisted spaghetti nightmares. I see a massive sub-current of
dissatisfaction with Rails, and I think the reason for this is just a subtle
but markedly different priority of thought. I can't articulate it yet, I just
know what it looks like when I see it.

Anyway, I love Rails as it is now. Soon I hope I can deploy a single
application across web and mobile platforms natively, along with supporting
them all, as one guy. That's insane. Really like this blog post because I've
got some things I'd like to be able to do with the ActiveRecord API, but I'm
not really sure how. I don't know why the thought never occurred to me to just
ask!

------
fishnchips
I'm not surprised by this development. I'm familiar with Piotr's code and it's
hard to miss the fact that he's writing Ruby as if it was a functional
language. Sharing inspiration between languages and paradigms is an awesome
thing but if you're going to try hard writing Ruby like if you wrote Haskell
you'd probably be much better off writing Haskell in the first place. Back to
the original article I think it says more about Piotr's personal path as a
developer than Rails and Ruby community at large.

~~~
solnic
That's not true, although there's a lot I took from FP. Like avoiding mutable
state, and functional composition for data transformations.

This doesn't change the fact my code is OO - I use objects, composition,
decoration, delegation and many other OO techniques, and in general try to
avoid heavy inheritance-based patterns.

I can understand how people may think I'm trying to use ruby in an awkward
way, but this is really not the case.

~~~
fishnchips
I find your Ruby code super awkward. Like you're trying to turn it into a
language that it is not. At least it is not in my book but then again I'm just
some random dude on the internet, a sample of one ;)

------
vonklaus
Reminds me of Zed Shaw's critique of Rails[0] which explains many of the short
comings of Rails. Zed wrote the mongrel server for rails. Assume this article
is massively politically incorrect & vulgar as hell, just as a heads up.
Really good read though, and does explain some of the interior politics of
rails and how it evolved.

[0][http://harmful.cat-v.org/software/ruby/rails/is-a-
ghetto](http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto)

~~~
pcwalton
This article is nothing like "Rails is a Ghetto". Zed's rant is 90% personal
feuds, drama that is practically completely irrelevant today. The article
being discussed is 90% technical critique.

~~~
vonklaus
> This article is nothing like "Rails is a Ghetto". Zed's rant is 90% personal
> feuds, drama that is practically completely irrelevant today. The article
> being discussed is 90% technical critique.

True. And yet, it reminded _me_ of that article Zed wrote, which I summarized
as a vulgar critique of the internal politics of the rails community.

------
tunesmith
Having little experience with Rails, it's the tone of that "Crazy, Heretical"
article [1] that really strikes me. That tone where you're laboring to
describe something that really truly does make sense when you're in the
company of a bunch of people that just don't want to hear it.

There's too much purism in those kinds of arguments, arguments that really are
more about spectrums. It sounds like Rails is really great for learning the
shallowest 40% of a wide variety of programming concerns, and a lot of web
solutions for small clients aren't ever going to dip below that 40%. And as
soon as you get beyond that 40%, asking questions like "but what if it doesn't
make sense to do it that way?" and "what is that weird runtime bug that
doesn't happen in my development environment?" and "why can't I refactor
without being scared I'll introduce a weird regression bug?" then it's totally
fine to be attracted to the idea of static typing, compilation, and
libraries/frameworks that are more explicit.

[1] [http://jamesgolick.com/2010/3/14/crazy-heretical-and-
awesome...](http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-
way-i-write-rails-apps.html)

------
chuhnk
I was quite happy to walk away from the Ruby on Rails world 4 or 5 years ago.
I basically escaped before the onslaught of Rails 3.0 and what came next. I
think somewhere around the adoption of coffee script I got pretty concerned.

While at Google I became aware of Go and what that looked like at scale. I
would highly recommend trying out Go. I think the simplicity will be a
refreshing change but there will also be some familiarity coming from the
Ruby/C world, can't quite pinpoint why but just feels that way.

And if you're looking for frameworks, shameless plug, I'm working on this
[https://github.com/micro/micro](https://github.com/micro/micro).

------
mark_l_watson
I usually find "I am stop using XXX" type articles to be a bit negative. That
said, I stopped using Rails years ago myself, so the linked article resonates
with me. My goto web frameworks are Ruby+Sintra and Clojure+ring+compojure.
Sometimes I also use meteor.js but it is more like Rails in that it is a
complete package of everything you are likely to need, pre-configured.

------
Ericson2314
Now I never use dynamic languages and never thought Rails was a good idea. But
I'm glad I read as through as the "Convenience-Oriented Design" and the simple
vs easy quote. I've seen many designs which have sacrificed consistency or
orthogonality to make the common case as tiny as possible, and struggled to
articulate what was wrong when I was counter with "how simple the tool is to
use". Hopefully this will give me some better language.

~~~
Ericson2314
I feel like the very world "simple" is part of the problem.
Orthogonality/Consistency is much more important. Also don't treat odd use-
cases as gratuitous features to be someday supports. No, a use-case is not a
feature, but that hacks that will be added to accommodate those are. And
features are bad: "[things] should be designed not by piling feature on top of
feature, but by removing the weaknesses and restrictions that make additional
features appear necessary."

------
im_down_w_otp

      Secondly, avoiding mutable state is a general, good advice,
      which you can apply in your Ruby code. Ditching global state
      and isolating it when you can’t avoid is also a really good 
      general advice.
    

As an Erlang programmer I agree with the general sentiment here, but wouldn't
doing this in Ruby really lean hard on one of the pathologically nasty Ruby
runtime issues? Which is that it doesn't release memory back to the system?

When every new operation on a data-structure starts by producing a copy of the
previous version it seems like you'd really want a runtime which is efficient
and intelligent about how it manages memory?

Unless that idiosyncrasy of Ruby has changed since I last used it several
years ago. In which case. Nevermind. :-)

~~~
pdimitar
Ruby's MRI never returns RAM to the kernel, yes. But if you use immutable data
structures and release them relatively quickly, the GC will have much easier
time releasing their memory back to the pool that MRI is using for allocating
new ones. So the inevitable RAM bloat that MRI accumulates over time is still
there, but is slowed down.

As far as my not-so-big experience with them goes, the immutability
programming techniques in Ruby actually help a lot with its sticky RAM
problem. Complex object hierarchies of mutable objects and references to them
are a nightmare for the GC. Having structures/objects that are used and
[quickly] thrown away without (or rarely) being attached to complex object
graphs is making the GC work more reliably, and faster.

------
Bombthecat
I like rails. A lot. The syntax is amazing. Period. If you can get a gem or
get what you need from rails. It is simply close to amazing.

But dare you. You just go down one simple level. (first level is what you get
with rails and for example extending active record.) it becomes a horrible
mess of dependencies and magic / structures.

I never found a framework so hard to modify. ( for example writing your own
multi category / multi tag gem)

That's when i stopped web dev. It was just mind boggling. This is several
years ago. I think around version 3 or even 2? And every version broke the
active record stuff...

I really thought rails would catch on in germany. But if you look on indeed
there are literally like five jobs in Germany... Maybe I'm not alone with that
problem...

------
zinssmeister
Rails is great. And of course it isn't and will never be perfect. Obviously
the author would love some alternative frameworks, mainly so he can use some
more and some less exotic code patterns. Maybe after almost a decade of
writing CRUD apps in Rails he is a bit bored? I can't blame him and seeing the
Ruby community so focused on basically one framework is a tiny bit sad.

So I definitely see where he is coming from with all this, but truth be told
it was never Rails' indent to be a precision instrument. It has been a
reliable framework that makes a lot of Developers very happy. A great reliable
car for the masses so to speak. But not a Ferrari.

------
artellectual
Although I may not agree with your perspective entirely, but I respect it.

I think everyone has different needs, and you have your personal needs which
Rails no longer satisfies, so you are moving on.

Rails still solves a lot of problems for a lot of people I believe. I work as
a consultant for a few companies and in some cases I see people losing time
and money on what would be resolved immediately if they had just made the
right call by using Rails.

Good luck on your journey, and remember the rails community will always have
its door open for you :). Your projects on github look exciting, I will take a
look at them. Very cool stuff!

------
themgt
I've also seen the writing on the wall for leaving Rails/Ruby. I think a lot
is down to Ruby the language simply not being well-suited for an increasingly
multi-core/concurrent future. That said, a more reasonable approach is to
begin transitioning a few projects at a time, and make sure you've solidified
on your new tools of choice before chucking the old ones.

I remember a few years ago I teased with ditching ruby for node.js. I'm glad I
dipped my toes in the water and waited for Elixir.

------
bigtunacan
Things aren't always the best fit for a person and they have to decide to move
on.

Solnic has contributed a lot to the Ruby community and I'm not surprised to
see him leave.

Within the the web domain of Ruby there has very much been a Highlander
attitude of "there can be only one". That one has always been Rails. For
someone that wants to create better pieces or have more choices other
languages are more accepting.

On much of what he said in the article he is on point. Personally I've never
been a big DataMapper fan (sorry dude, I just prefer Sequel), but I do agree
ActiveRecord isn't great.

I've considered leaving the Ruby eco-system, but I look around and don't like
the alternatives I see either. One of the great things about learning Ruby on
Rails is job skill relevance. If you want to make a move and you know Rails
then pretty much all job search matches are a green light. If you know Java
and you are working with Play then nobody wants you because they want
experience with Stripes, Spark, or god forbid Struts; now you have to relearn
the whole framework and rinse repeat each time.

Personally I stick mostly to Ruby on Rails (and JavaScript) for my
professional work, and then on personal projects I work in various obscure
technologies that I just enjoy because I enjoy and I don't need to worry about
if it will help bring in the bacon.

------
VLM
Sounds like he wants Arachne. Which isn't written yet. He even mentions
learning Clojure. Linked article stops just short of mentioning it, but there
are some themes that are common between the linked article and the story of
what Arachne should fix.

[http://arachne-framework.org/](http://arachne-framework.org/)

The concept of the zeitgeist is interesting. A lot of general dislike of Rails
is in the air and the only question seems to be what the replacement will be,
not if there will be a replacement. Naturally the ruby guy thinks it'll be a
new OO ruby framework which has always done the impossible before and the
Clojure people think it'll be the usual immutable functional magic which has
always done the impossible before. Best plan for the future is wish them all
luck and wait and see. I don't see any other useful strategy at this instant?

My money is quite literally on the Clojure guys, I was one of the backers of
the Arachne kickstarter, but best of luck to Hanami and rom.rb and all the new
wave ruby stuff. One of you revolutionaries had better succeed, or else...

Some of it may be the natural result of success and age. A near decade of
continually having to revamp my rails code "because the guys at hulu really
need it" or "this is very helpful for github" is inevitably going to
eventually make me say (if you'll excuse the profanity) F them I'm sick of
rails and authoritarian monoculture in general and hulu is very nice but it
can just go help itself, I have work to do that isn't "I have to chase latest
fad that someone else needs". It may be a natural state for the lifespan of a
framework to enter a stage where staying on the bus is more expensive than
hopping off, maybe even hopping off anywhere. I tried some Play framework
projects and I felt the sirens pull of static typing, but, after a few years,
unless you keep up with changes, the technical debt just accumulates each
framework revision until I'm sick of seeing releases instead of pumped.

I'm talking about projects that last many years not a semester or so. I'm not
sure the chronological nut has been cracked of heres a magic solution for long
lived projects. Assuming there is a magic solution. Perl CGI I suppose (only
slightly tongue in cheek kidding)

------
hhw3h
Is it uncommon to use other patterns within rails like service objects? I like
using Draper, Pundit, and other gems which provide decorator and policy
objects.

I prefer to not use Helpers and AR callbacks (generally Concerns too) as I
don’t think they encourage good OO even though they are officially part of
rails.

Ultimately it comes down to what your goal is. Is it to deliver some business
value fast to end users? Build a new product with a small team? Then I think
rails is a great tool to achieve that.

------
__mp
Scrolling in Firefox (OSX) is very slow.

~~~
questionfy
I noticed that too. But it renders and scrolls perfectly on Chrome. I wonder
what's the difference? Firefox is typically a lot slower than Chrome, but the
performance difference this time is amazingly large.

~~~
__mp
It seems to be a bug. See here:
[https://news.ycombinator.com/item?id=11749503](https://news.ycombinator.com/item?id=11749503)

------
a2800276
What I don't understand is why people feel the need to proclaim that they're
leaving xyz? Why not just focus on the positive and focus your energy on the
new stuff you'll be doing. It sounds like someone who just broke up and keeps
claiming they're totally over it but just can't stop talking about what a
bitch their ex is. If you're planning to do haskell, elixir, clojure and
scala, write about that.

~~~
jordan0day
There's a small bit of irony here in that there was a rash of "Why I'm leaving
X for Rails" posts between 2008 and 2012 or so.

~~~
rhapsodic
Oh yes. I remember it well.

------
jakelarkin
my two cents on Rails (as someone who's worked with Rails/Ruby, Node, Scala,
Golang in some depth)

\- ORM is bad at any sort of scale/complexity.

\- Net IO that looks like property access makes it too easy for devs to do bad
things, N+1 queries etc.

\- ORM abstraction is not helpful when you know the exact efficient query you
want.

\- ActiveRecord Models + the Ruby module system encourage OO bloat.

\- ActiveRecord database drivers are too numerous and not well implemented.
Default schema generation includes many SQL anti-patterns.

\- ActiveRecord has too many public interfaces, too much meta-programming.
Hard to understand scope, Hard to analyze and improve performance.

\- ActiveSupport monkey patches too much of Ruby. Need an very deep
understanding of language to understand what's going on at a non-superficial
level.

\- Rails/Ruby community places too much emphasis on "clever" DSLs / APIs

\- If your stack/framework choices limited to dynamic languages, Rails is a
lot less efficient than Node and for web apps you need JS developers anyway.

~~~
est
> \- ORM is bad at any sort of scale/complexity.

ORM is good, as long as you use only SQL in your backend.

------
chaostheory
I'm not going to argue.

However if you've run into the same problem where you feel like you need to
either make fat model or fat controller in Rails, here's a simple solution:

[https://github.com/collectiveidea/interactor](https://github.com/collectiveidea/interactor)

------
charlysisto
A simple formula to take a lot of AR's bloat away is to use it mainly as a
read library (AR's great for generating complex queries in a simple & readable
manner).

For write operations (aka user interaction) I use a combination of solnic gem
(Virtus) with ActiveModel that way I remove a s __*t load of responsibilities
from AR and the controller : \- params management (and strong params) \-
validations \- nested associations \- callbacks \- And all the context
management (like user vs admin...)

That way I only mildly part from the rails way and yet have a good separation
of concern. Actually ActiveModel is used by ActiveRecord so having a form
object relying on it is still very much rails compliant. The refactoring is
minor (no hexagonal stuff) and the level of indirection very low.

------
fiatjaf
This should come at no surprise, although I don't see anyone criticizing Rails
anywhere.

I've never written a line of Ruby, but trying to read Rails code evokes me all
this: it seems like a framework created with the sole purpose of hiding
everything possible from the programmer.

~~~
gonyea
It's not hiding anything, other than the conventions. Django's spammy
boilerplate is just default behavior.

~~~
kowdermeister
Conventions is something I try to avoid at all costs. Conventions are usually
things that are hard to find in documentation. Conventions are things that
every experienced user says that "oh, this is common knowledge" and
conventions are the reason why things seem to work magically.

Obviously if you follow a framework from day 0 you don't even notice it. For
newcomers, it's a source of frustration.

~~~
lobster_johnson
That's not really what convention refers to here. Rails' motto "convention
over configuration" simply means that boilerplate should be avoided, and that
code should use sensible defaults whenever there isn't information.

For example, ActiveRecord class names map to table names through a simple
pluralizer (UserProfile -> user_profiles). That's a convention, no
configuration needed. Just write a class and off you go. You can override this
behaviour, but you can also write huge apps that just follow the convention.
Other frameworks would typically make this mapping explicit.

You do need to read the documentation to see what the conventional behaviour
is, but it's not very deep knowledge. It's not much worse than other
frameworks, where you need to find how things are configured.

~~~
majewsky
My experience is that programmers migrating to Rails are thoroughly confused
by these conventions like "UserProfile -> user_profiles". Although it's only
the second-biggest source of confusion after ActiveSupport, e.g.
"10.hours.ago" even though the integer class does not have an hours method
according to the Ruby documentation.

~~~
kowdermeister
Integers have methods? ಠ_ಠ

~~~
lobster_johnson
Yes, why not?

    
    
        42.times { puts "foo" }
    
        1.upto(9) { |n| puts n }
    
        puts 1.year + 7.months - 1.day

~~~
dedsm
one of the issues I see with rails precisely is that most people won't ever
know that 1.year is not a plain ruby method

~~~
dasil003
It's definitely _a_ issue, but I think it's far from the biggest issue. If
you're going to use ruby, you're going to have to come grips with the culture,
which for better or worse involves more "magic" and meta-programming than,
say, Python where the same power exists but is avoided on principle.

It takes a little getting used to, but once you are, then the tooling is there
to help you make sense of these things:

1.method(:year).source_location

The bigger issues with Rails I see are the monoculture issue raised in the
article, plus the intractable issues with ruby around performance, memory
bloat, concurrency, and last but not least, the multi-paradigm nature giving
you functional features, but without any of the usual immutability guarantees
(unless you follow a constrained and unconventional coding style which no one
does in the ruby community).

------
dk8996
I personally can't wait for Rails to be a distant past. So many start-ups got
burnt badly by using Rails -- easy to start, hard to scale, maintain, and
extend. Rails is too opinionated and if your use-cases don't fit into "Rails
way" your screwed.

~~~
pmontra
But at least it got them started and they could understand if there is a
market for their product. My bet: if twitter started with Java Struts (it was
2006) they would have had to spend so much money and have needed so much time
to launch that we would be using something else now. Not necessarily a system
bootstrapped with Ruby, but you got the idea.

> if your use-cases don't fit into "Rails way" your screwed

Of course.

If a startup service doesn't fit Rails, they should have picked something
else. I'm not using Rails for everything.

~~~
dk8996
Startups usually try on a bunch of use-cases (features, ideas, workflows)
before they gain traction or die. Your saying that startups should know all
the use-cases they plan on building before they even start -- that simply
impossible. Maybe your point is that startups shouldn't use Rails and its more
suited for dev projects with a clear spec.

~~~
danenania
Not really. Rails is good for quickly hacking things together across a very
wide range of the domains that startups usually play in, which makes it as
good as anything out there when upfront productivity is the priority and you
have rapidly evolving specs.

The only really common startup use case it's decidedly bad at is
realtime/sockets/streaming data, where Node takes its place as the hack-it-
together tool of choice--at a significant productivity penalty compared to
Rails.

It's also, of course, pretty bad at all kinds of tasks unrelated to web
development or REST apis. You wouldn't want to write machine learning
algorithms or do statistical analysis in Rails, just like you wouldn't want to
do 3d game development in Rails. And while you do occasionally see startups
who have bolted some heavy data processing or pseudo-ML monstrosity onto their
Rails apps, I've never seen anyone in the Rails community claim that was a
good idea. The vanilla recommendation there is to keep your main server stack
in Rails and then write services in something more appropriate for those
needs.

------
douchescript
The things that suck in rails are the views, the asset pipeline and the stupid
helper methods for routes that are so complicated for nested routes it's a
joke. The database part is actually the good part if you do it right.

------
pm24601
Another point that was subtly made, but needs highlighting.

If you are programming in ruby you are ONLY doing a front facing webapp. There
are lots of servers out there that run headless. The ruby ecosystem is
completely dominated and controlled by rails. As a result, ORM mappings and
gems are completely focused on a web-response centric world.

As monolithic ruby apps are broken into microservices, ruby as a language will
also be abandoned for those microservice back-ends - simply because the ruby
ecosystem has only one way of viewing the world.

------
agentgt
I have seen posts like this time after time of experienced developer
eventually hating (opinionated and/or coupling) framework.

I too eventually came to a similar conclusion albeit on different platforms.
Frameworks get you started quickly but you will eventually hate them. And I do
mean framework and not library (there is a subtle but massive difference...
yes the oxymoron was intentional).

Its even worse in Javascript land. You could rewrite this post and just insert
one of the many Javascript frameworks like Angular.

------
kyledrake
I'm not going to pretend it's better than Rails, but I implement most of my
projects as Sinatra psuedo-frameworks, with Sequel for the ORM. Sequel is a
solid ORM that has a reputation of being stable and reliable. Sinatra is just
simple (vs easy sometimes) and I like the way it integrates routing directly.
It's good enough to power Neocities anyways, and I've baked in some of the
niceties you'd expect from a larger framework (such as testing).

~~~
cyberferret
I wonder if the author of the article above has looked into Sinatra? It seems
to be the solution he is looking for, in a sense.

I have used Padrino ([http://www.padrinorb.com](http://www.padrinorb.com)) a
lot recently, which is really a framework on top of Sinatra that make things
like testing, ORMs and renderers easier to integrate into a raw Sinatra base.

I especially love that I can use 95% of gems written for Rails in it - about
the only ones I can't use are the ActiveRecord specific ones. (Note: I use
DataMapper in most of my projects, but looking at Sequel as the ORM for my
current app).

------
elliotlarson
I've been developing apps with Rails since it was announced. It's been an
amazing tool/toolchain, providing a very useful level of abstraction that
allows rapid development.

Recently, I've been doing a lot of Go (Golang) development. For me, it's sort
of the anti-Ruby-Rails. I really like the fact that it requires me to "roll my
own" in so many situations. I need to understand what's happening under the
hood to make things work.

But, the abstraction/magic of Rails is useful. Speed to market with trustable,
battle tested magic is a profitable proposition.

I _want_ to introduce Golang into my current project, but I haven't quite
found the right place for it yet. Rails makes it so much easier and faster to
add functionality at our scale.

~~~
pdimitar
It might be a better sell if you try to introduce Elixir, and I am guessing
its Phoenix library/framework as well.

I've tinkered a bit with Golang and I love it but IMO it's too much extra work
in the Web development part. It's exciting and very educational to pop the
hood and understand how many things fit together, especially if you're coming
from Rails, but you should be aware that after a while the novelty wears off
and sooner or later you'll start looking for the quicker paths to introduce
trivial Web cruft.

I am yet to experiment with Elixir + Phoenix but the community feedback so far
has been fantastic.

------
kazinator
> _First of all, it worries me that many people react like that. We’re
> discussing a tool, not a person, no need to get emotional._

Laughably, no.

Code is written by people; it's essentially a set of ideas that execute and do
things in accordance with the vision of the creators. The creators poured
themselves into the tool. Code is an extension of the self.

(If it isn't, it should be; people take the best responsibility for code when
it's like that, and it's probably the main essence that separates OSS from
most proprietary work. People don't fully invest themselves into creations
that can completely disappear out of their lives forever upon the next
organization restructuring.)

------
nine_k
This article formulates well why I strongly prefer libraries to frameworks.

A framework dictates you the structure of what you are doing. Libraries can be
combined, replaced, and used in various ways, fitting more the task at hand
than the mist common case.

------
dedsm
I've always said Rails is good for short-lived build and forget projects, it's
too "magic" for my taste.

I can't imagine what it must feel like to receive a mid-to-large sized Rails
project to maintain.

~~~
pdimitar
You don't want to know. I inherited and am currently tech-leading a large
e-commerce project powering an e-shop doing $10k+ sales a day. Even a small
bugfix or a very minor UI addition is taking _days_ because outdated tests are
breaking, because there are dozens of tight integrations directly in the code,
because there's zero separation of concerns, and awfully inefficient
ActiveRecord queries _everywhere_. Making a cart checkout with ONE item takes
50+ ActiveRecord queries. Yep...

It is extremely challenging and very educational for me, and I appreciate the
experience. I've always been a fan of repairing and improving things -- but
truth be told, it gets tiresome and annoying VERY quickly.

I am currently working hard to stabilize the entire process of small
refactorings for the sake of the new features/bugfixes, streamlining
deployment, making full separate QA/Staging environment (yes, even that wasn't
addressed by the previous team) so we can test with confidence and without
fearing we'll break Prod, and to reduce the 3rd party API dependencies --
right now they are 20+.

I am hopeful that after I stabilize the project and make the process of
introducing new code easier and quicker, I could then make the case for
gradual exodus to Elixir/Phoenix. Realistically, I am not seeing that Rails
abomination I inherited to be a sustainable job for even one year. Inevitably
I'll burn out, the customers will lose patience, and my employer will be
unhappy both with me and the customers. Not cool for anyone involved.

So I'll try to gradually run away from Rails. As pointed by numerous smart
people here, it's suited for medium-sized projects at best. Even
Sinatra/Padrino and 50+ attached libraries would have been much easier to
maintain.

~~~
AnthraxAlex
Ive got a similar problem, dealing with a rails app i inhereted that collects
telemetry data from thousands of remote units traveling out in the field.
Basically there is no separation at all of active record and buisness logic.
You end up with connections to ftp servers and other application layer
adapters down in active record models. With all of the application layer in
the AR models its only a matter of time before the developers end up weaveing
a thick carpet of spaghetti dependency through everything.

On top of that changing the database becomes a royal nightmare because the
database is what defines this AR model that all of your buisness logic and
application layer spaghetti dependency relies on. The databases usually end up
full of garbage because without complex validations and lots and lots of tests
which by the way were never written ruby and rails will dump any trash into
your db whenever. So you end up with columns with like 10 variations of the
definition of NULL or FALSE.

Usually around this point your app just slips into a state of quantum
uncertainty. It essentially ceases to behave deterministically at least when
viewed from within the bounds of human perception.

Its hard for experienced developers to bend rails in away so that things don't
become overly dependent on each other and neigh impossible for average or
beginner rails developers to manage.

Im just really not impressed with rails at all especially coming off of 6
years of development time on huge enterprise apps written with the c# .net
libraries. I mean really they are light years ahead using IOC dependency
injection for injecting service apis into controllers while using mapping
patterns for keeping buisness and database logic separate. Its the only way to
break up large apps and keep them sane and maintainable. Additionally static
typing is the only thing that keeps things sane in really large applications
doing complex business logic through many layers of interfaces.

~~~
pdimitar
Hey and sorry for replying with so much delay. I keep forgetting HN won't send
me mobile notifications for replies.

Truth be told, I am not sure how well will I cope. I am good, I have
experience, I have been doing lots of quality repairs in my life before. But
you know what? At certain point you don't think it's worth your time and
energy. That's the real enemy here -- demotivation.

I spent humongous amounts of time in the object-oriented land. I think I'll
just hop to the functional programming world -- isolated functions, functions
as first-class citizens, immutability (hell yes!), no shared shate (oh God
please, I want that!), and goodbye side effects. At least I hope so. It might
just be another shiny thing I'll be pursuing and won't be much better. We'll
see.

But you know what? I prefer working hard to build things from the ground up in
a new and much better language and ecosystem than to spend my life trying to
demystify somebody's strongly opinionated framework which doesn't cover even
40% of what I need in my project.

------
yodasays
Explicit is better than implicit.

------
dorianm
TLDR: People don't do what I want them to do. They don't think the way I want
them to think. And my way of thinking is way better than theirs.

~~~
cwyers
Alternatively: Rails doesn’t believe in doing anything that would make it
anything resembling modular so people who don't agree on everything can still
work together easily.

------
frostymarvelous
This is simply why I've never liked Laravel. Don't get me wrong, I love the
packages esp. Eloquent and Blade (validaton and translation not far behind)
and I reuse them in all my projects now.

I simply hate the "magic". I don't touch anything with too much magic going on
and even avoid some features of Eloquent because of that.

And since it is heavily inspired by rails...

------
Nemant
What is a good alternative?

~~~
robto
He mentions it at the end, but I'd strongly agree that Clojure addresses the
issues he mentions. I see a lot of discussion in this thread about Elixir and
Phoenix, but I'd take another look at Clojure.

It's got a strong, friendly ecosystem that encourages small, composable
libraries. For every level of your application, there's competition - http
servers, sql abstractions, front end libraries. And there's great resources to
help you choose what works best for your use case - the Luminus docs, books,
blogs, and several active forums for discussion with library owners and just
regular developers.

Couple that with a community that really took Rich Hickey's "Simple made easy"
talk to heart and the default immutability and functional paradigm and the
abstractions that Clojure itself has to offer, not to mention the performance
the JVM brings to the table, and I think it's a great language to hang your
hat on in the long haul.

~~~
Naomarik
I'm going Clojure route and in it for the long run. Being able to eval any
single piece of your code in a REPL direct from your IDE in the context of
your app is just insane. Also having one single language for JavaScript and
JVM is super useful.

Also after programming for 4 years a bit I've felt the core of programming
beyond CRUD/consuming APIs is about manipulating data structures. Having
powerful utilities for this and not having to shove everything into classes
and objects makes it really easy to get stuff done. Going back to Ruby feels
like I'm working with a kludge in comparison. Everything that doesn't need to
be a class is one, then you get caught up in naming things. Then you try to
debug things to end up with an object that has 500 methods on it and you don't
know where half of them came from because they were metaprogrammed in through
10 layers of indirection. Yesterday I tried upgrading to Rails 5 and gave up
because I couldn't debug an outdated library in 6 hours without realizing I
have to figure out what this library and ActiveSupport/Model is doing in order
to make headway. Ain't nobody got time for that.

------
funkaster
I have the same sentiment with Rails. I built a big warehouse/delivery system
(routing, etc) on 2006 with Rails 1.2.3. still being used up to this day.
After that, I never looked at rails again. All of my web apps small and medium
were made with Sinatra. After reading this article, I'll give a look to
hanami.

------
kfir
Without being negative anyone else found this statement a bit strange - "as my
bachelor thesis was about Rails"

* I am not aware of any CS program that do thesis at a bachelor level.

* It is hard for me to imagine getting approval for doing a thesis on "Rails", it is mostly a CRUD web framework.

~~~
geebee
I found it a bit strange, but not _that_ strange. First, a "thesis" isn't too
uncommon at the BA level. I majored in math at UCSC where this is an option.
Can't say if this is something people do in CS, but I wouldn't be surprised.

[http://www.math.ucsc.edu/undergraduate/compreq.html](http://www.math.ucsc.edu/undergraduate/compreq.html)

I could see how someone might find material in the emergence of Rails in web
programming for a thesis at the undergraduate level.

------
nicolasMLV
Here is a new blogpost from DHH "Provide sharp knives"

[https://m.signalvnoise.com/provide-sharp-knives-
cc0a22bf7934](https://m.signalvnoise.com/provide-sharp-knives-cc0a22bf7934)

------
garfieldnate
Funny, his complaint about Ruby completely owning your app and the creators
wanting it that way are the same that James Shore gives for Ember (also made
by the Rails people) on TDJS.

------
gonyea
This isn't a Rails gripe. He only seems to know Ruby/Rails and lashes out at
it. Frameworks = Lots of abstraction. At least the abstractions in Rails
aren't leaky.

~~~
eropple
solnic wrote the majority of DataMapper, its successor rom-rb, and the Virtus
object modeling library. He knows much more than Rails and understands its
problems.

~~~
waffle_ss
Not to take away from solnic's many valuable contributions to open source, but
I think it would be more accurate to say he was a heavy contributor to
DataMapper rather than that he wrote the majority of it

[https://github.com/datamapper/dm-
core/graphs/contributors](https://github.com/datamapper/dm-
core/graphs/contributors)

~~~
solnic
Yes, I was on the core team between 2010-20#{hard-to-tell}. DataMapper was
created by Sam Smoot and quickly taken over by Dan Kubb who did a crazy amount
of work, practically rewriting it and introducing all the crucial features,
and then maintained it for a couple of years with the help from a small group
of people.

~~~
dkubb
This is correct. It's probably hard to measure a person's total contribution
to DataMapper because the gems are spread out across 20 to 30 repositories,
not just dm-core.

I did maintain DM for a few years, but burnt out as there wasn't enough time
to keep up with the community demands and work a full time job. There were a
couple of years I effectively worked 40-60 hours a week on DM and only 5-10 on
work; this wasn't tenable long term and burned me out.

The small dev team, of which solnic was a core member, are an amazing group
and there's no way I could've maintained DM for even a fraction of the time I
did without their support.

------
samfisher83
Trying to visit this page makes my browser lock up.

------
tangue
Rails developers are spending more time fighting Rails these days than
improving it. I have the feeling that good coders have left the ROR ship and
that Rails is now the framework for code-schools and learn-to-code bootcamps.
It's a bit sad, but as long as Rails is tied to Basecamp I don't see any
solutions.

The author is right, competition is important, the Rails/Merb scenario is the
open-source version of Microsoft E.E.E

~~~
dhagz
Really, even if it weren't tied to Basecamp I think if DHH remains as Rails'
BDFL, we won't see the type of changes a lot of developers want to see. Which
just means we need to highlight other frameworks like Hanami, Trailblazer, et
al. in Ruby user groups.

------
jm3
Thanks for posting this, I otherwise I would never have learned about dry-rb,
hanami, trailblazer, and rom-rb!

------
vintageseltzer
Is Django any better?

~~~
dedsm
The main difference is that Django does not rely on monkeypatching or magic
methods, and for me the separation of concerns feels just natural in Django.

When I started with Rails it felt like magic, you didn't know why things
worked.

------
programminggeek
The elves are leaving Middle Earth.

~~~
gfgjmfgjmgh
...but these are the same people who made what Rails what it is today. What is
concerning is their occupation of top seats on other hot projects (Rust,
Elixir etc.).

------
geebee
Great article, and only 391 posts. Clearly I need to show up 24 hours after
the fact and put in my two cents ;)

From what I've read here, it really doesn't sound like his time with rails is
quite "up". It sounds like he has read the writing on the wall about rails,
after a very long time with the framework (certainly longer and more involved
than I've been, though I have used Rails quite a bit). This is different from
realizing that a technology won't last "forever", it's a more distinct
understanding that you see where things are going and how your current tools
don't quite match up anymore.

But when my time with Rails is "up", that will mean that I have largely
stopped using it. I'm mot counting maintenance, or perhaps the occasional one-
off, I mean that if my time with a technology is "up", that means I don't use
it anymore for day to day work.

I'd be interested in reading more from Piotr Solnica on this topic, because
I'm in a similar spot. I don't see Rails as the ideal match for much of what
I'm doing on the web, but I'm not anywhere near ready to give it up. I
increasingly need much more interaction between the client and server than I
get from the MVC approach, but I'm not sold on javascript front ends with a
web service backend, at least not the way it's been presented now. For
starters, I personally (yes, this is very much a personal trait) don't relish
the idea of giving up Ruby to write most of my app in Javascript.

It's not just that I like ruby, I don't really like the idea of giving up the
very rich set of languages I can choose from on the server side, or minimizing
their role, in order to allow javascript to take over most of my programming
work. I also feel that javascript front end frameworks are still a moving
target, and I have a suspicion (like I said, I'm trying to sort this out) that
when the dust settles, elaborate javascript front ends communicating with a
web service written in something else won't be where I go next. I've read
about some exciting new possible directions in this blog post, and I've read
interesting things elsewhere (Volt, specifically, non-js languages transpiled
to isomorphic javascript, more generally). It is all very exciting and
promising, but is this the moment to give up on Rails, which works though I
find myself increasingly shoehorning things into it? For me (again, just for
me, everyone has a different set of interests and tasks), no, not yet.

Drawing on my past experience - the last time I felt this way was when web
programming in java moved from the jdbc/servlets/html with libraries to
struts, struts2, spring mvc, pico, spring di, jpa, hibernate, ibatis, wicket,
tapestry and so forth. Looking back, I wish I'd had the conviction to stick
with the old way of doing things even though I knew its days were numbered.
Keep an eye on things, keep learning.

It sounds to me, from the end of this article, that this is what Piotr is
doing. There are some good suggestions of where to go next, but I guess my
question for the author is this: where are you going _now_? Is your time with
rails "up" in the sense that you no longer have a substantial day to day use
for it, that there is a new technology that you'll be working with now the way
you worked with rails for 9+ years? Or is this more a situation where you see
that your time with rails is ending - if not today, then certainly before
long?

~~~
solnic
> Is your time with rails "up" in the sense that you no longer have a
> substantial day to day use for it

It means that I'm no longer interested in supporting Rails in my gems and I
accept the fact it may hurt adoption of these gems. It also means that I will
be actively working on an alternative stack that can be used instead of Rails.
That's why I support Hanami project and experiment with dry-web project too
(which is more like a toolkit for building your own stacks, already supports
Roda, and we'll add support for Hanami too).

Apart from that I'll be spending less time on OSS and instead I'll be learning
new languages. That's pretty much it.

~~~
geebee
Yes, that makes sense. I'm not sure I'd read anything by you until this post,
but it sounds like you're talking more about where you are putting your
framework development efforts, rather than what you'd use as a framework for
the time being.

Framework development is pretty far from what I do (I rely on the efforts of
people like you, honestly), but like I said, I can see the need. I'll probably
be using something like what you're working on in the not too distant future.
Best of luck with your efforts, I hope good things come of it.

------
cloudjacker
What I'm trying to understand is why all these coding academy students are
learning ruby on rails:

To make them have to go back to coding academy school in two years?

So that they maintain legacy codebases and don't touch the new shiny features
the experienced engineers are working on until they get their training wheels
off?

Because there is actual demand for ruby on rails despite all the hate and
sunsetting of rails I see on HN?

~~~
larzang
I can't speak for other cities because I haven't watched their job markets
enough, but anecdotally in Chicago I've seen it break down mostly like this:

Big companies use enterprise Java unless they're stuck with a legacy
VB/ASP/Coldfusion stack, with C# less commonly.

Fintech companies use a mix of C# and C++.

Small companies started before ~2010 use PHP, with Rails less commonly.

Small companies started after ~2010 use Rails, with hipster Java
(Scala/Groovy/et al) less commonly.

I can only remember offhand seeing one job ad for a company using Sinatra
instead of Rails for their Ruby stack.

~~~
elliotec
Is node and the JS world not taking over Chicago yet?

~~~
cloudjacker
lol right!?

Chicago, the land the MEAN stack skipped.

------
blairanderson
️

------
btcboss
Another Rails is good/bad post. Just like the rest....

------
douchescript
Oh no, the Merb heresy comes back to haunt. No merb was not better, it was
just different and sucked in some different ways.

------
unclebucknasty
A few years ago if you said anything negative about Rails, you were either
pure evil or unbearably stupid; or both.

If you didn't fully embrace tableless design with CSS, despite the latter's
glaring defeciencies for that task, it was the same treatment.

I also recall great pressure to adopt EJB with its deeply flawed architecture,
etc.

I could go on, but the point is that there seems to come a time when all of
these things face a moment of truth, wherein sober minds feel a little freer
to speak aloud on their shortcomings. This frequently snowballs into all out
backlash against the tech in favor of The Latest Shiny Thing.

The enforcers of what's hip and smart for everyone now move on to browbeating
Developer Land with the new tech, and we all allow it to happen again. Why do
we keep repeating this process when we've all seen the movie so many times?

~~~
tariqali34
Reminds me of "The programming language lifecycle"[1] (written in 2006), which
essentially implies that the reason programmers continually search for new
languages is simply out of a desire to 'distinguish' themselves from their
peers, and have little to do with the actual merits of the languages in
question.

[1][https://quoderat.megginson.com/2006/03/06/programming-
langua...](https://quoderat.megginson.com/2006/03/06/programming-languages-of-
distinction/)

------
soheil
> rather than hitting F5. Just saying.

QED. My hypothesis was confirmed, up to this point I was pretty sure he's been
living under a rock possibly for decades complaining about how hard
programming can sometimes be until I realized he is an IE user.

Show us a better solution without sacrificing everything that rails has given
us and maybe we will listen.

~~~
ThisIs_MyName
What does IE have to to do with anything? F5 and ctrl/cmd+r work in all
browsers.

