Hacker News new | past | comments | ask | show | jobs | submit login
My time with Rails is up (solnic.eu)
716 points by lreeves on May 22, 2016 | hide | past | web | favorite | 438 comments

> 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.

I'm assuming you are not familiar with solnic's work. Because he is not just idling complaining. His rom project, and the ecosystem of supporting gems which have grown from it over years of work, are the exact opposite of "implemented again, by you, badly." It's more like "implemented for the first time, correctly, by someone who actually understands what good design is."

That's valid, and you're right, I wasn't familiar with his work.

But that doesn't diminish any of my points. So he did reimplement ActiveRecord. I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you.

With a framework, "works for me" is a perfectly valid reason to keep using it and to dismiss criticisms with. That's the whole point, to get you up and running with as little fuss as possible.

I personally hate CSS frameworks, I'd rather retain more control over the markup and selector semantics. That's a choice I make, and I'm aware of the tradeoffs. I would not make the same choice with web dev, because choosing the other side of that tradeoff involves way too much work.

But I'm a working coder, I'm not trying to make my mark on the world. I just want to get shit done and move on. Solnic obviously wants to make something bigger than just a website. He's looking for a bluer ocean to tame. Which is cool, we need all kinds of coders.

What this is really about is that Rails isn't for him. I can accept that. But his rationale is all wrong, it expects Rails to be something it isn't and never could be. Rails is absolutely the best at what it does for the kinds of coders it's intended to do it for. It tracks the state of the art of web development and boils down most of the complexity with user-friendly abstractions.

It's not terribly flexible, but Rails doesn't want to be flexible. It wants to be productive. He wants to go help build the next Rails. Godspeed. I hope he succeeds so that I can go use his framework when it's finally ready in 10 years or so.

I'm sorry but I just don't get this, in your previous comment, you mentioned:

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.

And right here, you also mentioned:

I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you.

So which one is correct here?

Flexibility is available in Rails. But is not a top priority. I would say that Rails gets most of its flexibility from Ruby. You have Rails Metal, which is intended to provide a modular way to extend Rails. If you know Ruby well, you can take advantage. Solnic had the capability to do so, and did, but eventually chose to leave the ecosystem. I'm fine with that. I don't expect the techs i use and love to be all things to all people. I just wish he hasn't chosen to shit on the tech that sustained him for so long.

I don't think the honest explanation of the reason he chose to leave the Results ecosystem is shitting on it; and I think that description is itself a sign of the kind of the kind of tribalism in technical communities that obstructs fruitful discussions of technical subjects.

> I just wish he hasn't chosen to shit on the tech that sustained him for so long.

Oh please stop treating your favorite tech like a religion.

Rails is not a religion, it a tech tool (a pretty poor one at that), discussing it's many flaws is not shitting on it.

>But that doesn't diminish any of my points. So he did reimplement ActiveRecord. I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library.

Who said that? Who carved that in stone? There are absolutely frameworks built to be perfectly OK to have all of their constituent parts used like libraries.

This is just repeating "this is how it always used to be" as an argument.

>It's not terribly flexible, but Rails doesn't want to be flexible.

That's his whole point.

> There are absolutely frameworks built to be perfectly OK to have all of their constituent parts used like libraries.

You certainly can use each individual part of Rails without having to bring in the rest of Rails. I bring in ActiveSupport all the time on non-Rails projects. For ORM I prefer Sequel, curious why solnik didn't mention Sequel, the creator of DataMapper even said that Sequel was everything he wanted DataMapper to be and I can't help but think that played a big role in the decision to not continue developing it.

You can use Sequel in Rails, I personally prefer ActiveRecord as I'm not aware of a Form Helper gem that works with Sequel, though to be honest I never really looked. Way more people use AR than Sequel, so Stack Overflow debugging goes much smoother.

I'm not saying he's wrong for leaving the Ruby / Rails ecosystem. I'm saying his stated reasons are inconsistent with his course of action. I'm fine with his real reasons, I just wish he wouldn't frame it as a slight to Rails.

> ... curious why solnik didn't mention Sequel ...

From the article:

> It would be unfair not to mention that Sequel showed up already around the same time and till this day it’s being used way less than ActiveRecord despite being a superior solution.

I lost interest in DM mostly because of my open-commit-access policy. I mismanaged the project horribly.

Just because something was called "Session" (ala Hibernate) instead of "Unit of Work", people would claim it wasn't "pure".

The only real compromises for purity were for performance. You saw the same thing play out with ActiveRelation. Ruby is (or was at least) just too slow for complex patterns unless you wanted to pay a huge performance penalty. The kind of slow that materializing 10,000 models in an O/R Mapper would bring your app to it's knees and use hundreds if not gigabytes of RAM.

And since a large reason for writing DM in the first place was AR's miserable performance at the time, it needed to be fast.

Most of the community wasn't that interested in closing open issues. Not that I blame them. It's not fun. But I was burnt out.

During the end, ActiveRelation started development, making many of the same mistakes early DM did in the quest for purity. By that point I just wasn't feeling it anymore. I'd spent orders of magnitude more effort on writing an O/R Mapper than I'd ever hope to recover, and I felt like some of the ideas were fundamentally flawed. So I moved on.

If I were still doing Ruby, I'd be using Sequel though.

Frameworks do not necessarily impose the complete design of the application. Spring Framework in Java, for example, is great, but the only essential part of it is DI container: you may not use persistence, presentation or security layer provided by it, if it does not fully fit your architecture. Good modularity defines quality of the framework and Rails is apparently not best on that criteria.

Another example is Symfony2, which is completely decoupled (not just loosely coupled). Oh but php programmers are bad, am I right HN?

No. PHP programmers aren't "bad", PHP is.

+1 for symfony being the perfect example if you're looking for a completely decoupled framework.

Magento and Shopify backend are awfully slow, it's the language, not the programmers.

Shopify is built on Rails, you know that right?

And Magento is slow for a whole lot of reasons, nine of which are related to symfony.

Magento is slow because it uses EAV

You mean the first version of Symfony (Symfony 1, which was monolithic like Rails), and not the current Symfony (Symfony 2/3) which has nothing to do with the old one other than the name.

I'm aware of that using Rails.

Nitpicking here, solnic didn't reimplement ActiveRecord (he did, but that's long ago) -- ROM implements the DataMapper pattern.

The idea that DM wasn't a DataMapper is misguided. Check out: https://github.com/datamapper/dm-core/blob/

The convenience methods were just wrappers. Earlier versions were even more true to the PoEAA version of a DataMapper with a Unit of Work in the Session class.

Turned out this was a bad idea if your primary motivation is performance.

The fact that it didn't bother to abstract away DataObjects was by design. Nobody would claim NHibernate (of the time, 2.x) wasn't a Data Mapper implementation just because it didn't have an adapter for treating an XML file as a database. That's a parlor trick.

The real effort is in making it work and making it fast. Porting Java designs to Ruby just didn't scale in the Ruby implementations of the time and conscious decisions were made to ensure DM would actually solve the problems it was developed to address (#1 being performance as I had a large set of data to migrate that initial experiments with AR projected to take a month(!)).

The primary concern turned out to be Ruby method dispatch performance. The shorter you could make the stack, the better. Since loading 1,000 objects might be operating on a 10,000 row set, and another order of magnitude more fields, the materialization pipeline had to be streamlined as much as possible. (AR implemented a nasty abomination of a hack for this by round-tripping to the database multiple times). When it's faster to round-trip to the database multiple times than it is to iterate a large object in memory, you've got a real problem.

The lazy loading, explicit fields, dirty tracking in the Unit of Work, (which at the time were all fairly controversial ideas in rails-core) etc were all an effort to address performance. The PoEAA was an inspiration for sure, but it turned out to be a prescription for poor performance on Ruby 1.8.x.

I can nitpick too! :) I never said he reimplemented active record, I said he reimplemented ActiveRecord. Though I suppose the better verb to use would have been 're-engineered'. Reimplementing seems to imply an algorithm or design pattern, where I meant to re-do the functionality.

>I never said he reimplemented active record, I said he reimplemented ActiveRecord

You didn't yet you did? You've said the same thing twice here

ActiveRecord is an implementation of the active record pattern. DataMapper is an implementation of the data mapper pattern.



The ruby lib DataMapper is actually an implementation of the active record pattern too ;) That's one reason to why ROM exists.

I think this is more about Active Record the design pattern, than ActiveRecord the Rails component. Active Record is a really easy to use pattern and ActiveRecord is a very humane implementation. Data Mapper (the pattern) is more complex. Trying to get a Data Mapper implementation to do all of the things the ActiveRecord implementation in Rails does is really hard- it's always going to be harder when you need the object model structure to significantly deviate from the database structure.

Jonah so good

As a counter point, are you sure web dev is the complex thing, or does it just seem complex because you're dealing with these massive gnarly frameworks that hide thousands of lines of code behind seemingly simple facades that perform incomprehensible magic?

I think the mention in the article of the User.Create(params[:name]) one liner is really instructive. Creating a user is one of the most important things you're going to do in an application! The business logic rules are incredibly important, the security implications are huge, everything. Trying to make it "easy" is ridiculous, because as a developer, you should be thinking about these things. That's the kind of thing that should contain absolutely zero magic, the logic should be upfront and visible.

I've worked as a web dev, and I've also worked outside of web development, and the number one thing that drove me insane doing web development was never knowing if any one line of code was doing some severe amount of impossible-to-debug magic. I'd rather just write javascript against the browser APIs with a lightweight http server.

As far as I can tell, the vast majority of frameworks aren't really about providing functionality, they're thought experiments in how to write software. That's fine, but they should bill it as such. I'm not going to say web development is easy, there are parts that are legitimately difficult on their own accord, but I think the web development community has made things massively harder on themselves by pretending all these abstractions are actually simplifying the task they've set out to do.

What's missing for me from this whole discussion is the allowance that both methods can be correct.

Use case: you're a solo developer and you need to build a proof of concept web application based on a fairly complex set of requirements. You probably want to use a framework like Rails and focus your time 100% on the specific project requirements, and use the framework to generate the common parts of the web app for you.

Another use case: you're on a large, multi-year project for a huge client where each developer has his/her own specialty area. Here it may well make sense to go with a Java Enterprise app and wire your own persistence layer or write your own SQL queries.

The mantra of Rails has always been "don't repeat yourself." Don't waste time rebuilding the same 90% skeleton every time you need a CRUD app with a postgres database.

Want absolute granular control over all parts of your application? Then almost by definition, you really don't need a framework. So great, don't use one and roll your own web app from the ground up. But there are many times it makes complete sense.

>because as a developer, you should be thinking about these

>things. That's the kind of thing that should contain

>absolutely zero magic, the logic should be upfront and visible

No, you shouldn't be thinking about these things. Because you'll get them wrong. Are you really going to account for all security cases?

Are you really going to account for all data coercion coming to/from the db? And even if you do, why go through the pain of those cases when there's a community of thousands of other developers, some of which have probably solved it infinitely better?

Eventually, we have to get shit done. The only code that is worth something is code that serves others. Eventually we have to pick some abstractions so that we can get on with the show.

> No, you shouldn't be thinking about these things. Because you'll get them wrong.

This attitude is really pervasive in web development, and I think it's kind of bizarre. If you're building something as a developer, you need to understand what it's doing, because at some point something will break and you will have to debug it.

When you get to the point you have to debug it, are you going to want to figure out some sort of insane meta-object protocol where you can't figure out where or why a method is dispatched, at what point inputs get santized, etc., or do you want to walk down a simple function chain?

Keep in mind I'm not advocating rolling everything yourself, I'm saying if you use a library it shouldn't be treated as a black box. I'm advocating avoiding abstractions that obscure your ability to understand what's happening (what I call magic). Use a library for user authentication, for sure, but if you can't explain how it works well enough that you could replace it, you shouldn't use it.

> No, you shouldn't be thinking about these things. Because you'll get them wrong.

"Magic" is good for beginners, because there's just too much they don't know.

Not thinking about all these things because the community of thousands should have done it better I did, is just lazy.

This is the kind of thinking that leads to unnecessary layers of abstraction and bloat.

So do you roll your own OS? Payment processing system? Web server on your own hardware?

Just because you aren't hand-coding it doesn't make it "magic" or "lazy," it makes it efficient. I'm perfectly happy to use Bootstrap for my web application's styling because they've handled most of the exact same styling problems I will have to, and quite well. I am quite confident I could replicate a lot of that functionality every time I needed to build a web app, but why would I do that when it's already been done and I can focus on other problems?

As an aside I'm curious why you think that "magic" is good for beginners. When you don't have a clue what is going on at all, you really should spend some time learning what happens when you create a user via ActiveRecord, which can easily be done if you study the log files for a bit and read the Rails documentation. Once you are comfortable with what's going on, then you can use the framework to auto-generate code for you.

The point is not about "hand-coding" at all.

It's about reading the code, and having a good mental model of what is happening. This is the point Rich Hickey tried to drive home with his talk "Simple Made Easy".


If you are a developer and haven't watched this yet, you really, really should. Very important distinction to keep in mind any time you are writing software.

Haven't read the Active Record source code, but would be interesting to find out where it falls on the "Simple vs. Easy" continuum.

Simple Made Easy is a really great talk.

> As an aside I'm curious why you think that "magic" is good for beginners.

I was referring to absolute beginners with little prior background. To them, technical documentation is a bunch of gobbly gook. For these people it's usually better to be somewhat opinionated and just tell them "there are other ways, but this is the tried and tested way and it works". A nice side effect is that they don't suffer analysis paralysis and panic attacks.

They don't know what they don't know, so it's sometimes useful to just tell them "this is the syntax to do X" (aka "magic") and gloss over the finer details. I've found that the time to unveil the magic is when they poke around under the hood, read up, and start asking questions about how things work.

The complaints weren't about the complexity of web dev, but the degree of tight coupling and bad application architecture that the author sees baked fundamentally into Rails and the approach it is designed to favor.

And as for leaving for what, the author identified both the other Ruby-based stacks and the noon-Ruby languages and frameworks that he sees as valuable. And, no, Java is not on the list.

Your rant looks like a reflexive defense of Rails from someone who hasn't read the source article more than superficially; the article doesn't dismiss the web as a serious domain, it just sees Rails as locked into a dated approach to the domain.

Look, if solnik thinks he can do Rails better than Rails, I really hope he succeeds, because I can't wait to meet the perfectly-flexible, perfectly-succinct web development framework that has the kind of support and tooling ecosystem that I enjoy with Rails.

I get it, tight coupling and forced architecture aren't ideal. I accept those limitations so I can get Rails' productivity superpowers. I don't just accept them, I embrace them, I've learned the wonderful joy of having everything you coded 6 months ago just slide right back into your mind because it didn't try to buck the convention. I spent extra time understanding that convention and why it exists when I wrote that code, I think most Rails devs don't do that, and so overcomplicate their applications.

I've been on the other side of that tradeoff, so I can see where you're coming from. There's a lot of appeal in making and using your own abstractions that fit the domain better. But the web is a complicated domain in its own right. The right approach is to use one DSL for the web, and make your own for your domain. DHH was right, Rails is your application. To do otherwise is to over-complicate your architecture.

> locked into a dated approach to the domain.

Ugh, seriously? Is this fashion or engineering?

My guess is that you haven't actually had to deal with any large rails applications, or that the one you are dealing with is the first one you've dealt with.

The abstractions Rails uses are fine for a relatively small app (up to 10 models). Beyond that is where the complexity mushrooms and the framework starts dragging down the project.

Solnik's points about create() are very subtle. Think about coercion, validation, and all the potentially invalid or confusing states an app can end up in.

The approach Rails takes with ActiveRecord is fine for a small project, and often benefits consultants who leverage the boilerplate to show superb progress after one month of development, but it fails in the real world.

To be fair to Rails, most approaches to input validation and the creation of multiple levels of nested objects are implemented poorly. Solnik's point is just that Rails serves up a lot of these flawed approaches into one toolkit, and so the resulting ecosystem is plagued by the sum of all the flaws, and the core team is not really seeing the big picture about how to improve the overall state of the ecosystem (why would they, they are getting paid a lot from the Rails status quo).

DataMapper was superior to ActiveRecord. When Merb got merged into Rails, I was certian DM would be the ORM of choice for new projects, but when it wasn't I personally stopped using Rails on new projects. Sinatra + DataMapper is such a superior approach to full-boat Rails too, fwiw. How many thousands of developer hours are spent upgrading to the latest Rails every couple of years for no benefit. How many useful gems are nearly obsoleted, etc.

Rails has had the worst kind of cargo cult success. Most of the gems are weekend projects that lead to a blog post and a bunch of speaking engagements for the writer, and then get left to wither after the community has naively embraced them. This is not the case for all, but it happens way too often.

There are also many, many subtle bugs that are introduced by ActiveSupport. I've personally wasted at least two weeks of time dealing with them over the past 5 years.

Ruby is a great language, but I'm glad someone as talented as Solnik is branching out.

> My guess is that you haven't actually had to deal with any large rails applications, > The abstractions Rails uses are fine for a relatively small app (up to 10 models). Beyond that is where the complexity mushrooms and the framework starts dragging down the project.

I've worked on several rails applications with a lot more models than that. Some with over 100 models. ActiveRecord has flaws, but I never felt it was a great impediment to getting things done.

A bigger issue (as you mentioned) is the large number of gems that are abandoned or sporadically maintained. I don't see that as a rails specific issue, but it seems to rear its head most often with gems that interact with rails.

> Some with over 100 models.

Very experienced developers can create a usable codebase in Rails with over 100 models, but it is highly unlikely to happen if someone in Rails' target audience uses it.

I'd suggest Play Framework and abandoning the idea of O/R Mapping entirely.

Once you grok pattern matching you'll never want to see another Ruby case statement again. Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions. There's really no such thing as functional Ruby.

You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.

Un uncached Play Framework app will probably outperform a highly tuned Rails app out of the box, even with hundreds of person-hours spent in tuning the Ruby app.

Which leaves you more time to work on actual features.

And then you have Akka. Which is a whole other paradigm to master (but with it's own rewards).

And then you have deployment. Which is a huge breath of fresh air.

Sure, you'll miss some few things in Rails. Like Inflection. Add a dependency for one of the ported versions (like: https://github.com/backchatio/scala-inflector. It's just a single file).

The learning curve isn't the smoothest (though API docs for Java/Scala libs in general and the Play Framework guide is far more complete than anything I ever experienced in Ruby-land). But the rewards.

Come to the dark side. :-)

> I'd suggest Play Framework and abandoning the idea of O/R Mapping entirely.

Then I'd have to learn Scala. I do not want to have to learn an entirely new stack. It took years for me to learn Ruby's eccentricities. Sure it would take me less time to learn Scala, but I already know Ruby. You seem like quite the masochist, spending years in one ecosystem trying to build something, then burning it all to the ground and starting all over. Just looks like so. much. effort.

> you'll never want to see another Ruby case statement again

I never write case statements in Ruby. What I do when I find myself needing a case statement is to go looking for the missing class. I'm missing a domain element and OO programming to me is all about clarifying a domain.

> Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions.

I pipeline all the time in Ruby. A lot of times I'll wrap a data pipeline in a class so I can encapsulate the logic and manage it better. When you wrap a pipeline in a class, you can do things like add immutability to the instance variables. Sure, it's not true functional, but I don't want true functional.

> You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.

Let's take these in turn.

> more maintainable code

I love maintaining my code. I fail to see how learning a new stack could actually improve on this for me.

> lower LoC count

Mostly aids in maintainability. Again not at the top of the list of things to improve.

> easier testing

I've changed my approach to testing over the years. Again, this is not anywhere close to the top of the priority list.

> More mature libraries

Again, this is something I've fixed by changing my approach to the problem. Whenever I introduce a gem, I put an interfacing class between the rest of the app and the gem. That way it's easy to swap out if it becomes a problem.

> And then you have deployment.

Deployment sucks in Ruby, not gonna lie. But again, problems are indicators of overcomplication and I've tuned my workflow to drive more simplicity over time. I know Capistrano very well, seeing it evolve over time has given me a keen eye for how to keep it manageable.

On the whole, I like the idea of functional programming and am not opposed to coding in a functional style once in awhile. HtDP changed the way I thought about programming, though I eventually switched back over to OOP. I strongly disagree that there's any kind of magic to functional. Everything in programming involves tradeoffs, and OOP better fits my mind than functional does. I look at pure functional as math-heavy and harder to grok. I want stateful objects, because humans think in terms of objects and not data pipelines.

> The learning curve isn't the smoothest

That one issue outweighs all the purported benefits of all the others. I would much rather spend my time thinking about domains than learning new tricks.

There's nothing I love more than a long thread of point-by-point rebuttals, but I think I'll leave this one alone for once. ;-)

If you like what you're doing, more power to you. I picked up Ruby because I thought it showed promise as a good scripting language and web development tool (this was pre-Rails) at a time c# didn't really excel at either.

> You seem like quite the masochist

Maybe. DM was created to solve a problem. I didn't burn anything down. I just walked away. The best time to do the right thing is yesterday. The next best time is now.

After 8+ years, I realized I'd spent much of it trying to work around limitations in Ruby. It was just time to open myself up to the idea that there is more to programming than what I knew.

Things get dated in engineering too.

The writing has been on the wall for Rails for a while now, we're just seeing an increasingly large number of people publicly moving on from it.

Have ever took a look at django (Python)?

> Ugh, seriously? Is this fashion or engineering?

> It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.

Back when Java was introduced, it was partly taken up because the features it introduced made developers more productive - hardware agnostic code, network programming out of the box...

Nowadays a lot of developers have moved on from Java. Maybe the same thing will happen to Rails...

I'm not a rails dev, but I believe that you are misconstruing his argument. It is not about inevitable complexity, but about the ownership of that complexity. If you are able to control the side effects part of development, you can control how it scales and debug it much more easily.

I have a third interpretation: I think Solnic was complaining about a lack of diversity in the Ruby ecosystem. The most salient part of the post was (imo) the paragraph regarding how Merb was subsumed into Rails, instead of continuing to compete against Rails. Rails is essentially a monopoly.

> It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.

If projects such as Merb were more common, maybe Solnic could leave Rails without abandoning Ruby.

> It is not about inevitable complexity, but about the ownership of that complexity.

I've been there, done that--was part of a team that owned a java application that grew over a decade (and eventually ran the team). A year or so after I left, they retired the application.

Why? Because we owned all the complexity and couldn't support it.

Maybe that was my failing. Maybe the team's failing. But I don't think that having control of how the whole codebase fits together means you necessarily have more control over complexity.

Those who trade for buried complexity are doomed to start digging whenever they discover an edge case.

Maybe they never need to do that, in which case that's a bargain. But I tend to think that any old enough codebase continually accrues edge cases that must be solved.

I've never seen a ten year old Rails application, but from the Rails applications I have seen, I'm horrified by the thought of how it would look after that long.

I've been in a company that let their Rails applications grow for 7 years. Believe me, the oldest code was not pretty to read and almost impossible to refactor. When we finally had a real frontend team, the only way out was to reimplement the apps with a new architecture.

At one point I realized, I should not stick into one language and one framework. Ruby is good to know, but I'm better if I can also tackle Scala, Java, Rust, OCaml, Haskell, Python and so on. Also happier, I'd say... I can now choose the best tool for the job.

Having worked on systems like that, the problem is that you end up in a situation where there are literally two people in the world who can answer questions about how something works and integrating other third party libraries or solutions becomes harder and harder.

Java isn't that bad, I'd say. ;) I've been in web development for almost 20 years, and used quite a lot of stuff, including PHP, Perl, C++, Java, Ruby and even such a weirdo like Informix WebConnect. Java is still my favorite, and the reason is the true modularity. You can combine Java EE and Spring stacks (lots of XML already forgotten in distant past), you can choose any presentation layer implementation and the architectural flexibility is the real selling point for projects bigger than a homework. I can beleive if the author would switch to it and I'm surprised that you don't.

yeah i do Scala now but same deal. Where I think the OP comment really goes wrong is when he says something like "you're gonna need all that stuff and you're gonna end up re-implementing it yourself". I really don't find that to be the case... when you're developing with libs you are cognizant of your app endpoints and just add whats needed. It's better to consciously add a lib or turn a feature on than to just accept a big ball of yarn that some cowboy framework devs shat out. In the Rails app at my job it takes a ton of debugging just to figure out how many layers of decorators are firing off around every model.

I might even go so far as to say that a lot of where JVM has strength is that contexts are pretty measurable... Spring containers, Akka systems. You instantiate them and hold them basically in the palm of your hand, you understand your scopes. Any technology that allows application scope to slip out of your fingers and intermingle with everything else under the sun is something I'd be wary of.

My own anecdote: at a previous job, new development was done in Rails, while "legacy" Python applications were maintained by one (!) guy. The Python apps were about the exact opposite of the Ruby apps -- cherrypy was used for the HTTP interface; very low level (compared to Rails, at least). He used to shake his head at the stack traces that Rails would spit out. "Intermingle with everything else under the sun" sounds about right.

> 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.

I call this "magic" and I dislike it very much. I'm a very explicit person. I like the ability to jump into any project, regardless of language, and be able to figure out how it works. This is typically possible with Python, Node and PHP with most web frameworks. Ruby with Rails? Not at all and for precisely this reason.

I'm fine with abstracting things but only to a degree. If you're doing a laundry list of complex things with a single statement, and I'm referring to web server specific stuff not ASM instructions, then your framework is going to require more ramp-up time than any other explicit one.

Interesting point. I find I can be pretty okay jumping onto a rails project, as I know a lot of the conventions. Where to look to see how things are connected. Admittedly, it's taken me sometime to learn how a multi architecture go project using thrift is setup :)

ActiveRecord is terrible for any kind of complex database work. If your data models are simple or you decide to shoehorn your entire data model into an "object" representation then ActiveRecord will allow you to work, but if you need to run queries like "return every product that represents less than 2% of total revenue for the last year excluding products purchased by our top 10 most profitable clients" ActiveRecord is going to give you a very inefficient solution where you'll also end up writing Ruby code to accomplish what the database is already capable of.

ActiveRecord is not the right tool for a job like this. It's meant to return records needed for serving normal web traffic, not for running data analytics. This is a better job for a tool which can run queries like this outside of a latency-sensitive environment (hadoop, presto, whatever).

> you'll also end up writing Ruby code to accomplish what the database is already capable of.

This is for the best. Usually, you have only a few database servers, while you have lots and lots of web servers. If you have a computationally intensive task, it's better to perform it on those web servers, which you can scale horizontally.

In our environment, the problem is usually the opposite -- it's way too easy in ActiveRecord to ask the database to do computation like sorting for you. Also, it can be hard to predict what impact an additional clause will have on the server's use of indexes. We try to get engineers new to Rails to write the simplest, most performant queries and then use ruby to do any soft of complicated transformation or computation.

This is a better job for a tool which can run queries like this outside of a latency-sensitive environment (hadoop, presto, whatever)

Actually the right tool for this is plain old SQL. Even with nice formatting this is probably a 10-liner at most.

If you have a computationally intensive task, it's better to perform it on those web servers, which you can scale horizontally

It's only computationally intensive if you're doing it wrong.

SQL is the right tool for the job! I replied to tell you that fewer and fewer people think that way....which is terrifying. "Elegant" solutions are judged as such, by their ability to avoid SQL. It's not a hard language, why is everyone trying to avoid it at the expense of their applications speed and simplicity?

When I post job adverts, a large portion of applicants balk at the SQL questions: "just use PDO, or ActiveRecord, or ADO, or SQLAlchemy". Which is fine, if they can explain the difference between inner, outer, left/right joins - and they can't. SQL will be the next COBOL at this rate, or at least I hope so for selfish and monetary reasons.

Somewhat ironically, perhaps, it goes back to one of the author's complaints: ActiveRecord is not really what you need for complex data. The idea that there is a 1:1 relationship between a table and an object is a poor one. Normally you want a datamapper to map between the model object(s) and the saved abstraction.

To make it a bit more clear, it's exactly the same separation of concerns that you want when you write a view for the UI. The controller takes one or more model objects and uses the view to generate an abstraction for the UI. When we save and fetch information from the DB (or send data out on the wire as JSON, for example) we want the exact same thing.

BTW, be very careful about doing all your computation on the ruby/rails side. It's a good idea from a certain perspective, but you are building a very nice bottleneck there if you have anything of real complexity. For example if you have a report that needs to sort through millions of records, you are going to be hanging your server for a loooong time. As you say, in those kinds of situations, you really want to query a service that has the ability to scale the requests more reasonably. Rails is incredibly poor at this kind of thing.

My own personal opinion is that there is very little that rails gives me that is worth the pain that Rails imposes. I'm much better off building something with Sinatra. What Rails does do very well (which the author also acknowledges) is reducing the number of things you need to know to get up and running quickly. But if you are going to pay the kind of salary I demand, then you will expect me to beyond that level ;-)

Agreed. And the challenge with using Rails is that when you hit a problem for which ActiveRecord is not the right tool, you have to now discard your entire process because the whole of the Rails framework is assuming state manipulation via the ActiveRecord abstraction.

"Rails" is an appropriate term for the framework; step too far off of it, and you find you're on rocky terrain.

I keep telling people to accomplish this by encapsulating the query in a DB view, and using a read only active record model in front of it. You can then query the table through the AR interface, and use has_many and friends. Unlike using execute_sql where everything is a string, type coercion works as you'd expect.

This solves the problem if you know ahead of time the format of the query, e.g. The example you gave would probably fit well. But if you're offering some kind of query building interface, well god help you.

No one has told me I'm wrong yet with this approach and it's been working great for years.

Yeah, views are a good approach. Adding more first-class support for them would be a valuable improvement.

You can drop to sql if you find yourself fighting against ActiveRecord. It is simple as ActiveRecord::Base.connection.execute(sql) where you will end up working with arrays and hashes.

OK, what if you want to generate the SQL dynamically with attributes? connection.execute doesn't do sanitization for you by itself (though you can call a private method to do that). If the generation is more complicated than that, you also have to have code to concatenate together strings of SQL code. Not because Rails doesn't have a SQL generation library, just because it's tightly coupled to ActiveRecord and fuck you and the horse you rode in on if that isn't good enough for you.

I understand your general frustration, but to respond to your specific point here, AR does actually support executing generic parameterized SQL statements:

Model.find_by_sql(query, binds=[])


Model.connection.select_all(query, name = nil, binds=[])


Yeah, I generally advocate for find_by_sql and select_all, but think about what that actually does. It instantiates a bunch of ActiveRecord objects that have to be of a particular model (what if the query joins tables together and returns a result set that doesn't actually neatly contain the intended columns of a given model? I can't even use ActiveRecord::Base.find_by_sql, I have to choose an actual ActiveRecord model arbitrarily), has the columns of the result set dynamically bound to it as methods during runtime (slow), also has the methods of the model itself bound to it, which may have unexpected behavior based on the query (especially if we just choose an arbitrary model), and in exchange we get to treat the result set as an array of structs rather than an array of hashes (which admittedly has its performance advantages, but not if the fields have to be dynamically bound to each object as methods!).

Oh, and if you're writing an INSERT statement you have to use connection.execute after all. Have fun!

> what if you want to generate the SQL dynamically with attributes? connection.execute doesn't do sanitization for you by itself (though you can call a private method to do that).

You just answered your own question. You sanitize the string and then you call connection.execute. Not sure I understand your other issue but it doesn't seem too compelling.

Yeah but there's no public method to sanitize the string. Having to call a private method works, and I've done it, but it's hacky and fragile and the only way it could pass code review with a clean conscience IMO is if you add an apologetic comment saying, "I know I'm using .send to call a private method and that this could break at any time if we update our Rails version because private methods aren't supported, but there's no other way to sanitize a string programmatically in this context, blame DHH". And I don't like having to put those kinds of comments in my code.

> Not sure I understand your other issue but it doesn't seem too compelling.

If you don't understand the other issue, how do you feel qualified to comment on whether it seems compelling?

Use case: I want to pull up a table of aggregated data for my user. The table is built by joining multiple tables together. The user can dynamically select which columns in the table he wants to see.

Don't do complex database work with ActiveRecord. What I like to do is these days is do backend jobs outside of Rails. (ActiveJob doesn't support RabbitMQ yet, I may change my mind about this when it does) Then use whatever toolset you want without Rails getting in your way.

> I ask myself if this person is really just complaining about how complex web dev is

A major problem with rails is it tries to "simplify" the inherent complexity of web development by using abstractions & mappings that ultimately increase incidental complexity in the entire stack.

When performance matters, Java runs circles around Ruby, Python or any other scripting language used in application development.

Having been bitten by web applications written in scripting languages (Apache + TCL like AOLServer) with an architecture very similar to Rails, but done in 1999, Rails was never that interesting to me.

> about how complex web dev is

Isn't that part of the problem? Webdev is complex. But it feels to me like it's been overcomplicated by a factor of 100. It doesn't have to be.

Absolutely. At the end of the day you're doing some string substitutions then sending a text file over a socket. We were doing that in the early 90s! But to do it now we use these surreal Rube Goldberg contraptions with a hundred layers of abstraction.

And all programming itself is is turning strings of 1s and 0s into other strings of 1s and 0s.

Asking web dev to be less complex is like asking financial markets to be simpler. Websites are market tools, tools have to retain a competitive edge. You can't afford to ignore market trends. You can't afford to wait until everything is well-defined. You can't let craftsmanship get in the way of shipping.

You can buck the rules yourself and operate on whichever side of the tradeoff you want to operate in, but you can't expect everybody else to follow the same rules you do.

I mean, if you don't like the web, then by all means find a different domain. I personally love it, and find it absolutely fascinating. With the right tools, (Rails) the complexity is manageable.

I don't think the web's complexities are intrinsic. It's layers and layers of crap built on top of crap. Computers are so mind numbingly fast that in some respects it's impressive we've made the web as slow as it is.

Which isn't to say that the crap mountain wasn't the best choice. It may very well be the pragmatic choice. The highest net benefit choice. But I don't believe it's intrinsic. I don't believe it has to be this way. Which means it's at least worth considering alternate paths. Even if in the end we picked the same way.

I work in video games. Currently working in VR. Where you absolutely must hit 90fps and never drop a frame. A certain degree of craftsmanship is required to ship. Layers and layers of abstraction on abstraction need not apply.

Sort of unrelated, but any suggestions for experienced backend developer who wants to get into VR? I'm working on learning 3D graphics and c++, but could use a bit of direction.

What's your goal exactly? Depending on your goal there's a few routes.

If you want to produce compelling VR experiences then I'd recommend you download Unity. You should be able to start making real, valid prototypes for different types of VR interactions in under a week.

If you want to graphics then I might recommend you poke at http://humus.name/index.php?page=3D or https://github.com/bkaradzic/bgfx. But graphics isn't my specialty so my thoughts aren't the strongest.

If you want to learn C++ then... that's an interesting question I've not thought of before. Maybe I'd start with "Learn C the Hard Way"? http://c.learncodethehardway.org/book/ I'm not as much of a C fanboy/C++ hater as other game devs. I quite like C++11 lambdas and move semantics. But I hate boost and it's ilk. So starting with C and later adding a dash of C++ seems like a good way to start.

Just as a side note I will add a piece of advice I wish I knew back in the day: learn C++ itself, not what I did which was to think I was doing that, but actually really only learn MFC (this applies to any framework or library, Qt etc etc). Having said that, the STL will stand you in good stead whatever you decide to do.

mean, if you don't like the web, then by all means find a different domain. I personally love it, and find it absolutely fascinating. With the right tools, (Rails) the complexity is manageable.

I built my first website in 1994. I know the right tools. Rails is not one of them.

Curious. What do you suggest?

But at the end of the day aren't all platforms complicated.

It's been a while since I did GUI programming on the desktop, but I remember it being so complex to build cross-platform applications that rolling your own cross-platform abstraction would be downright ludicrous.

I think the parent commenters point is correct. People treat the web like it should be easy, like it should just be HTML, but its not. It's full of legacy stuff, it requires working on multiple "platforms" (browsers), it runs on all kinds of device sizes and shapes, and the applications being written for it are no longer trivial.

You should try Qt. It's always fun to write some open-source software, and find that someone ported it to Windows or Mac in a few minutes.

In my observation there are two things going on:

1) Broken platforms. How much "innovation" has occurred in javascript to compensate for a broken execution model? How much caching does your average rails app do because of the poor concurrency the the Ruby platform, requiring external services for persistence across requests?

2) Looking for challenging problems. Design patterns are often a solution to a meta problem. Building a CRUD app, there aren't too many hard domain. However, code maintenance is a hard problem. It involves many people using subjective judgement. So as a somewhat bored developer, I'm going to try to solve the meta problem.

It sort of pains me to see how much engineering effort has gone into essentially making broken systems more performant and maintainable.

> It boggles my mind why developers don't take the web seriously as a domain, like it's not real coding or something.

I'm glad to hear people say this. I want to be a webdev (second career), but rather than code school I went back for an MSCS, because I really wanted to dive into the nuts and bolts down at the database implementation level.

I've done a fair amount of machine learning, ai, large-scale parallel programming, and algorithm design, and while I'm super-green, it's good to see the top comment is that the web is a serious domain.

I've written quite a few web apps over the years, sometimes in ruby, sometimes in go, sometimes python, sometimes C#, and I've actually never had to implement 'ActiveRecord::Base.create', much less poorly. I don't see what an ORM framework has to do with HTTP, honestly, the last 2 apps I worked on didn't even use a relational DB. I'd be curious how you'd finagle ActiveRecord to work with ElasticSearch - what would you do in that case?

I don't understand why web dev is so "scary" or "complex" that it needs 8 abstraction layers on top of it for my own protection. The only time I thought I needed hand-holding was when I didn't understand SQL injection and cross-site forgery/scripting (and once you do understand them, it's not difficult to protect yourself against those either).

If I found HTTP methods and headers, Javascript, CSS, Cookies and the rest of the web stack "scary" and needed hand-holding from Rails in order to get shit done, I'd be really, really worried about my skill set...

The web world is changing quickly and you have to ask yourself if you're a "web developer" or a "rails developer". I think you'd want to be the former.

He said he's been dabbling with functional programming. I saw mentions of Elixir, Clojure, Scala and Haskell. Where did he say he was going to work in Java?

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

How is this relevant, exactly? Ruby was written on and designed to run on *NIX OS's, as is most of the software commonly found in webapps, because it all runs on Linux servers. I'm sure it'd be a pain in the ass to get MS Paint to run on Debian, too.

MS paint on Linux is easy.I double click on paint.exe and it runs.

And I have WINE to thank for that layer of compatibility.

You realize it is that easy for you because it was a pain in the bottom for someone else, yes?

Isn't that the esssence of programming?

Historically, Ruby in general on Windows has not been awesome. But it's not going to matter when the Windows Subsystem for Linux hits stable in a few months. http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.htm...

I think that might be a bit too sandboxed for your needs.

It doesn't really matter anymore. It's been conventional wisdom for years to develop in a Linux VM if you have to use Windows otherwise. Unless that turns out to be more complex that the Windows Linux subsystem, I can't see VMs becoming an also-ran.

If a Linux VM is fine for deployment, well then that specific component doesn't really need or use Windows very much does it. (That all unixy things need to put in VMs on a host running Windows is a very different constraint.)

If it's important to deploy as a Windows process, then the Windows Linux subsystem is not much better than a VM. Point is, its no substitute for a (better) MSYS2/Cygwin.

I think I understand your point, and it's been a while since my MCSE expired, but unless Cygwin has improved a lot I would estimate a VM wrapped by Windows would be much easier to manage and admin.

Now if you're saying that the webapp itself would be required to be a Windows process, there's really no way around that. But as I implied elsewhere, the biggest stumbler for Rails on Windows has always been the lack of a compiler. Whether you compensate for that by installing a subsystem with that capability or by using a VM with the capability is largely a local problem to the company.

I've done that over the years and I used to answer questions on the RailsInstaller list, and yes, at times it was harder than at other times. I'm expecting it to be easier than ever thanks to Microsoft's recent announcement to support running Bash as a full-fledged citizen on Windows:


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

Node is a one click install on Windows, no cygwin required.

True, until you want to build native modules. Then you need Python and parts of Visual Studio

So? If I want to build native modules on Linux or OS X I still need Python and other build tools. It's not fool proof on any OS.

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

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.

Never had any significant issues with Java stuff, or php for that matter

I don't know how long ago you tried it last time, but recently this has got much better. You surely could find some gotchas here and there, but it's not as much frustrating as it was before.

I did until 3.2. The only real problem was native extensions, and many gem developers provided win32 bins for those things if they support win32 at all. Granted, I personally wasn't (...) God's gift to clean code, but I could certainly work with anything other people (say, on IRC) were working with and talking about.

The rails stack isn't designed for Windows, why should they waste dev cycles trying to support it? In any case, I do a fair amount of webdev on my windows gaming computer (don't want to mix work and side projects), VMs are so easy to set up that I barely install any dev tools on base os.

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.

You jumped in the deep end without knowing how to swim.

You're starting a new project, with new technologies and you tried to use the most complex stack from day 1. It's a classic mistake people make with React projects. You don't need webpack, you don't need hot reloading etc (at least not to start with), you don't need a boilerplate.

Go with browserify at first. It's simple and can be migrated to webpack later. To setup browserify?

    browserify in.js -o out.js -t babelify
And you're done! Add --debug flag for source maps. Want to setup a watcher with caching in dev for speedy builds? `npm install watchify` and swap out browserify.

When you need bundle splitting, async module loading, and all the other stuff you can do with webpack, then you can easily migrate from browserify.

Don't jump in the deep end without knowing how to swim.

The most used frameworks are always the most complained about.

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

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...

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.

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

I always disagree with "always". I think Django and Flask in python world are used a lot, and didn't notice a flood of complains about them.

I've been working on React projects lately and also spent a lot of time gluing together all the different libraries and setting up a proper build process via Webpack. I've also worked on Rails projects in the past, and I have to say that I prefer the modularity of being able to structure my projects according to the problem they're trying to solve. For instance, you wouldn't create a single-page app in Rails.

Also, with regards to Webpack, even though it's complex, it's extremely powerful, more so than anything else I've found. It includes many ways to optimize asset bundles considerably, by splitting them up into different files, removing unused code, and of course all the usual stuff like minimizing and gzipping the assets. In comparison to Rails it also compiles way faster, by only recompiling the code that you changed. It also includes many development tools, like an auto-reloading server and even updates your webpage without a refresh (HMR). All these are things that just aren't possible in Rails without much, much more effort.

Edit: I guess there's a first for everything, but I'm really confused as to why this was downvoted. If something I said is wrong or debatable, I'd be happy to hear it and discuss it.

(didn't downvote, but:)

> I prefer the modularity of being able to structure my projects according to the problem they're trying to solve. For instance, you wouldn't create a single-page app in Rails.

Those two sentences don't follow logically the way they appear. A project's structure has nothing to do with its functionality, which SPA is. I admit that rails is late to the SPA game, but if the new websockets (ActionCable) and API mode do what the docs say (haven't tried), there's no reason why it wouln't work nicely. For a given rails project, less than 5% of non-template code should change: create an API (one line for most projects) and... well, I can't think of anything else.

The rails view architecture is also almost identical to React: a bunch of nested templates. React best-practice is a bit more insistent on modularity (small & more generic components), but a 1:1 mapping of React and rails templates is possible.

What I meant to say was that I felt Rails was too rigid for some purposes, especially creating single-page applications. It's true that Rails wasn't built with that in mind originally, but it seems that it's becoming a bit easier now (I haven't been following Rails lately and had never heard of the "API mode" you mentioned).

I also know about a couple of projects using React successfully within Rails apps, but I would personally not do that if I were to start a new project today, even though I love Ruby.

There is nothing stopping from creating a single page app in rails. I have a SPA running on rails 3 using backbonejs. Some parts of which now use reactjs.

AngularJs had/has much worse and more criticism then rails and it's much younger.

Webpack, React etc... are not frameworks in the sense that Rails and AngularJs are frameworks, if you started with them and something in them is not like you like, you can use other libraries alongside them easily enough or replace them without huge sunk cost.

This isn't true for Rails (Or Django, or AngularJs) which are huge frameworks that touch every part of your development process.

Well, but that's because Angular sucked. I mean, even the developers agreed and wrote something new without thinking of a new name.

I wasn't neccessarily defending Rails as being "better than neutral" (although I think it is). I just felt the attitude at HN is negative to a degree that isn't objective any more, and that, to me, seems like it is less informational and more hurtful for a few people I have deep respect for.

Documentation of Webpack is getting better. I still use Gulp but at least the Webpack docs aren't just a bunch of 'Coming soon' pages like they used to be - take a look at the comments here: (http://webpack.github.io/docs/usage.html)

I think using Webpack still requires reading a lot of source code and examples, the docs aren't quite there yet. But it seems they're improving - the last time I checked the page you linked, it was completely empty!

Webpack is the worst about using React. No complains about anything else.

Took me a few days to me to get it working and "kind of" understand what it was doing. That really should not be that way.

I don't think time spent on swift is wasted, it's a fantastic language with a lot of practical application.


Webpack is usually the biggest source of bugs and questions on any given React boilerplate. Something won't compile, circular dependencies causing the build to fail the first time, some strange bug in CSS inlining, hot reloading not reloading, etc.

It's very powerful yet very hard.

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.

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.

Java and C# are of course equally boring

And they're the ones who don't write medium posts daily whining about how their frameworks are the worst in the world.

It's boring, it works, it scales.

I don't know why but the Ruby on Rails community has the most drama around it. Does that start with DHH?

No. Rails just happened to be in the right time and place to attract relatively young, progressive people who tend to use social media more.

There's plenty of "drama" in many programming communities, but a lot of it is hidden, because your median Java developer is less likely to be on Twitter, Medium, or even HN.

I have seen a fair share of Java web app hate posts.

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.

> 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.

No, I'm aware of that. I love Node and npm and UNIX and I use only small single purpose modules and its amazing. But I am effectively a research engineer. And honestly, if you want your company to run on Node, you need to be a research engineer too, because "which infrastructure should we use?" is an open question in the world you describe.

Compare to Rails, where you start of with OK infrastructure by default. That's not better, it just means you can hire a random person off the street and they're on the same page as you. If you want to keep a team of 50 JavaScript developers on the same page you need a really strong culture. Or just say "Use Ember and Express, end of story". But at that point you no longer have the "developer freedom" you correctly cite as the core selling point of Node.

And by "on the same page" I mean "we both have a similar understanding of a sensible default way to transport persist text fields from an HTML form". Put 10 JavaScript programmers in a room and you'll get 8 different approaches.

> Node doesn't aim to have one correct way of doing one thing as Rails often does.

Or any correct way of doing one thing, starting with the language (JavaScript) and moving on from there …

> 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.

Java is culturally open source at this point; nearly every widely-used Java library is open source and there is a huge open source ecosystem around Java (namely everything maintained by the ASF, but there are plenty of other open source projects like Gson, etc.). Bonus points for tying in to any of the bazillion proprietary software systems also built in Java.

The problem with Java is that it's so damn verbose -- it can take forever to build a moderately complex system because you just have to worry about so many things (maven, spring, jetty, etc.) just for a simple web service. This means you're spending time up front solving a lot of technical problems just to get a simple web service up and running.

Rails is great because it implements a set of sensible defaults and lets you worry about product design rather than implementing yet another database backend for a user store. Its event-routing model also makes a lot more sense for the web; in Java everything is kind of a hack to link the web stuff back to the JVM. But yeah, once your project gets complex, it might as well be Java -- complex software is just complex to write. Rails kind of sucks when the "sensible defaults" don't make sense anymore because you need heavy customization. It's a great prototyping platform, and that means a lot -- but it still won't let you escape the problems caused complexity.

One advantage of starting with Rails is that you can progress to JRuby on Rails when scaling is required. From there you can factor out services to Clojure or Scala without rewriting everything. So I'd say Rails has much more to offer than a quick starter app.

Did you just call JavaScript a research project? I seriously hope you meant Node.

Yes, I'm talking about the consensus web development framework around Node, to the extent that there is any. Same for Go and Haskell. Obviously all three are mature languages.

The Go community is just not that big into web development. There are web frameworks (eg. Revel) but they're not seeing that much traction. I truly love Go but I just don't think it's a good building material for more than a JSON API - for which it is awesome BTW.

Can't speak about the Haskell community though. To the extent I know the language I probably wouldn't want to use it to create HTML forms, either.

Haskell has a healthy and growing web ecosystem, from larger frameworks like Yesod to leaner ones like Snap, Scotty, and Spock. Servant is also looking promising as toolkit for building both API servers and clients. And GHCJS lets you write your frontend code in Haskell as well, if you so choose.

Uh, Go is not a research project. It was written to be used, not to explore previous unexplored language features. Basically nothing in the language is new (or at least wasn't new to the creators), something that it is often criticized for.

Dropbox has stated that pretty much their entire backend is written in Go. Go is also (obviously) used in production at Google. Neither Dropbox or Google is screwing around. Once a project is run at Google or Dropbox scale, it is no longer a research project.

Go is very simple (many people say too simple) and writing a web app in it doesn't really require a very good understanding of the language. This is because very few of its more advanced features are really required for writing a normal web app. Because it isn't really a framework, it does require a good understanding of web development.

I think Haskell can be fairly described as a research project and definitely requires a good understanding.

I think what erikpukinskis means may be more that Go is still a "non-mature"/"research" ecosystem - for example, what do you use for version control of dependencies? Rails has bundler, Go has a few different approaches, none of which are the go-to thing everybody uses.

> Go is very simple (many people say too simple) and writing a web app in it doesn't really require a very good understanding of the language.

But you do have to know to how to use the standard libraries well to write anything beyond a Hello World web app in Go.

Just because the Go language itself is simple, it does not mean web development is easy in Go. Quite the opposite, you have to write a lot of boilerplate code in Go (even with Go frameworks) to do things that would seem trivial in other frameworks.

Standard Chartered is a massive multi-national bank with a £17 billion market cap and a multi-million line Haskell code base. Is that still a research project?

Do the customers know what Rails is enough to like or dislike it? Or do they like the promises of quick functionality which you translate in to lower costs?

If I may also ask, have you run in to an older rails app when someone wanted some fairly minimal additions? Have you been the "next guy?" or do you avoid those projects? Did you migrate it to a newer rails? rewrite it? Or write old rails code? I've run in to a couple of ancient apps that were running untouched for like 4 years, they want to freshen the application, maybe add some features, you have to sell them a major refactor, or you can't touch it, like they depended on some gems that were orphaned. It's not exclusive to Rails, I've seen this with node too, once the application needs to be living and breathing to stay healthy, once you put it on the shelf, it's dying. An express.js 2 to 4 migration is effectively a rewrite, it's not super terrible but it's a chunk of work that isn't adding their new features.

I've simply never heard a long term success story with rails or node when it comes to maintenance. It's maybe not a technical thing but it seems like it's the culture of both communities. Blue sky and green field code? It's a blast, fixing up or adding to someone else' existing code? I probably wouldn't touch it. Oddly, I don't feel the same way about a lot of Java stacks though.

I try to answer all your questions.

No, those customers only know that Rails is mainstream and so it's a safe choice. If I propose Phoenix to them I bet they will look puzzled and ask me about PHP, Python, Node, Rails, maybe even Java. I'll make a test.

I've been the next guy many times. Rails makes that easy because I know where to look. The worst are custom PHP projects because I need to understand the original programmer's way of thinking. It can be a smart architecture (usually it's not) but it's time consuming and inefficient cost-wise.

I migrated every single version of Rails.

Never total rewrites, no need to do that.

I'm maintaining Rails 3, 4 and 5 beta apps right now. The customer with the 3.2 one has very little budget (we atarted and paused the upgrade to 4.2) and it's going to be EOL very soon. We'll see what happens. I was the next guy, that app started in 2011, I got it in 2012.

Orphan and incompatible gems happen. They make upgrades more difficult but I always handled them. With node it's an order of magnitude worse because of the much more rapid pace of change. It's the main reason for I would not recommend using Node.

Java just costs more to the customer. I use it only when I'm the next guy in a Java project. It's always a pain to work with it. It's like those ten lines would be one if this was Rails and I would have delivered two days ago (small new features). I just don't understand why developers want to inflict that environment to themselves.

"Java" is a big world now. A java 8 app with spring boot and jooq is just as simple to work in as any other backend software. If someone is stuck on java 6, classic spring, and hibernate...I feel your pain.

I had to quickly patch a Java 8 web app weeks ago, years after I worked with Java.

Java 8 is not bad but still trailing Ruby by a long shot in terms of readability. Thinking in Ruby I wanted to implement the Java equivalent of

    input.select {|i| validations.include?(i) }.map {|i| "'#{i}'" }.join(",")
where validations is a List<String>.

I ended up with a small nightmare with streams and collectors. That boilerplate shouldn't belong to this world, probably it's there because of the Java way to static typing.

They use Spring, don't know which versions, but it's got @RequestParam annotations to extract parameters from the request body. I think this is Spring Boot. It looks like Sinatra because of the @RequestMapping. Having @RequestParam in the action arguments looks a little like Phoenix pattern matching but I didn't have time to dig into the web and understand if it can really route requests to different actions according to the RequestParam. Overall is more or less where Ruby frameworks where ten years ago unless it's got pattern matching.

The webapp I had to work on still use ctags, which are a major PIA which slows down work and raises costs.

Queries are written in SQL, which is perfectly OK, and executed on a connection returning a java.sql.ResultSet. Not shiny but everybody can understand that. I googled jOOQ and it looks like ActiveRecord/AREL for Java. Nice but it would have cost me more time for this kind of quick hack.

What's so bad about this?

  input.stream().filter(i -> validations.contains(i)).map(i -> "'" + i + "'").collect(Collectors.joining(","))
It doesn't compare with ruby for code golf, but for readability it's practically identical.

I agree. Depending on how validations is defined you could also use a method reference .filter(validations::contains).map...

Re: Java environment.

Because Java is a huge chunk of the job market (at least in the Sacramento area), not because it's a "language of choice" . Actually, the JVM is a nice thing, even if the Java language is primitive and verbose.

Too bad the jFoo alternate language implementations haven't got more traction yet. (jRuby, Jython, Nashorn, et al)

I can tell you why, speaking about jRuby.

Because it takes so long to start and you feel it whenever you run the tests. It gets a little better if you disable the JIT compiler and so... in dev mode, where developers spend all their life, it's not faster than RMI. Because it used to support only the syntax of older versions of Ruby. Basically devs get all the pain of the JVM and none of the gains. Guess what they want to use? A customer of mine asked me how to migrate from jRuby to MRI because devs where having problems. I explained and suggested they could try using MRI in dev and keep jRuby in production. They're a JVM shop. I'll ask them what they decided to do.

> I've simply never heard a long term success story with rails or node when it comes to maintenance.

Basecamp, Shopify, GitHub aren't long term successes? smh...

Basecamp went through a massive rewrite, and GitHub went through a long period of (perceived) low pace innovation culminating in "Dear Github".

I don't know whether Rails maintenance issues played a part in either of those things. However I do know that YAGNI and tight coupling are traditionally things than come back to haunt you 5+ years later. Front ends may change in that time but the fundamental logic of applications, especially their data structures tends to evolve much slower. Isolating the two can only be a good thing if you're not building a throwaway project.

Everything long term is going to need serious refactoring or a rewrite at some point (or just hire exponentially more developers). I don't think it has anything to do with the language or framework.

But the ease with which you refactor or rewrite does depend on the language or the framework.

Depends if it was written well in the first place. I am maintaining a Django app, and because they have gone for "thin models fat controllers philosophy" (the opposite of Djangos best practices) it is a pain in the arse to modify stuff that should be easy.

Ok, maybe the framework doesn't have much influence, but a language with sane types will make refactoring easier. I'm not saying it will make it easy, just easier than other languages.

Yes, one of the benefits of Rails most overlooked by it's opponents is how immensely productive it is for small to medium sized apps. This comes from not only the DRY perspective but also from having strong standard ways to do things, and quite a stable API.

I don't agree on the sentiment in the article that it's hard to follow what happens in rails/activerecord. It's pretty well documented and all the quirks are thoroughly discussed on stackoverflow. Ruby has excellent tooling and it's easy to find performance bottlenecks.

On the negative side though, I find that I use other languages when I need performance or better concurrency, but that always comes at the price of lengthier development.

> Yes, one of the benefits of Rails most overlooked by it's opponents is how immensely productive it is for small to medium sized apps.

That's the only justification anybody ever uses for choosing Rails, so I'd hardly say it's overlooked.

> Try to sell them a new page with attached the price of a major refactoring... good luck with that

Could it work to include a "technical debt" figure in your quotes (where each feature without refactoring increase the debt and the "interests" on each future invoices)? Might be useful to explain them that quick-and-dirty is not always the best solution.

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.

> his stated reasons reveal a lot more about him than about Rails.

They reveal that he has tried to build sotware that didn't fit the Rails approach. They reveal that he has been frustrated trying to build tools that allow him to stray from the standard Rails approach without abandoning Rails completely. They reveal he's tired of the lack of success on that front and is going to just move on.

Something something right tool for the job. Totally agree.

Rails has its place. If it's all you know, everything looks like a rails app...

I think the prevailing problem people have with Rails is there narrow definition of a "Rails app" and a very wide space for "what my app will look like in a year".

Yes, this - in my experience, most web apps start out as "good Rails apps", but few remain so indefinitely. Many people over the years of Rails' popularity have experienced the transition from feeling supported by the "Rails Way" to feeling like they're fighting it, and it isn't surprising that this burns people out eventually.

I'm sure I'm wrong, but the fact that you keep using the word "simple" makes me feel that you skimmed over the article. The author disagrees that Rails makes things "simple," and argues that it attempts to mask complexity by making things easy/convenient.

Yes. But I'm not sure that argument is any more valid here than it is when talking about high level programming languages vs assembly. Of course abstraction hides complexity—that's kind of the point.

Abstraction isn't for hiding complexity. A good abstraction redefines the problem to eliminate complexity.

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

It's enjoyable until you want to do something else rather than the default behaviour.

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

Yes, it's terrible architecture. Your business logic should know nothing about what framework it's sitting in or which database it's connected to.

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

Speak for yourself. The last time I worked on a rails project this was the part I most disliked. It made debugging annoying, I never knew what each line of code was doing in totality and and I had to practically live in the documentation to figure out the side affects of everything I did.

This is versus most other frameworks I've used for web services where most things are explicit enough that, even if you don't know the language well / at all, you can still figure out what most of everything does. Jumping into a rails project without knowing ruby and how rails works? Good luck figuring that out without studying the documentation.

Arguably the "central gripe" of the article is one level higher, in which Rails has no competition in Ruby-land, and if you don't agree the architectural preferences of a few thought leaders, your only choice is to abandon not just Rails but the entire Ruby world. At least that was my takeaway.

> 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?

It depends: what does it do when? What does it do when the interpreter parses that line? What does it do when you call `save` on an object? What does it do when you call `create`? What does it do when you call `create!`? Etc. etc.

Of course, you always have to know how the tools you're using actually work, but Rails does have a tendency to make it seem like you don't, and to defaults that make it perhaps too easy to create bugs caused by mistaken intuition.

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

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


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.

Ah gotcha - yes this is a flaw in Rails - from the first version, Rails aimed to be "database-agnostic," which isn't actually a valuable property in practice. And DHH disregards when he feels like it, eg. nonsense like https://github.com/rails/rails/commit/9f6e82ee4783e491c20f52... .

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.

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.

I think you've either not read the article completely, or failed to understand the central point that the author tried to illustrate.

The issue is with culture. There is no problem if rails wants to go one way, and the author wants to go another. The issue at hand is that Rails is stymieing growth, not just in its own ecosystem but in the ruby ecosystem as a whole.

I think this is a very good point, and in contract I can imagine that if Django had total and utter dominance in the python world, python would be in a similar position.

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

A lot of people would argue that you should structure your application in such a way that as little of the behavior as possible is entangled with the Web framework you choose, making it easier to understand and easier to (for example) develop a different application reusing that code. DHH thinks that's "wankery," apparently, which I have to say strikes me as an odd opinion.

This is how Rails works, classic example:

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?

The point I made is that this is all happening in your ORM layer, in ActiveRecord these concerns are not separated. Recent addition of Attributes API at least isolated coercion logic, but it's still part of the ORM, which for me is a mistake.

This might no be the the best example, but this is not a Medium blogspam, the guy has wrote several widely used gems and we should not stop at this technical example to invalidate the whole points he is trying to make (and I don't consider this code to be the core argument of the post.)

> 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.

There's enough context for me to start putting up the horns and cheering, because AR is one of the more persistent boils on my ass when I'm building things in Ruby (because I use Ruby for Ruby, rather than Rails, my frontends are all JavaScript and my services are all Grape). His last point is sufficient to me to demonstrate inadequate separation of concerns--the better design is the one that doesn't require an active database connection to know what fields the object has in it. Answering "how do I build an SOA without every service having a line to every database?" inevitably becomes "don't use ActiveRecord, ever".

What solnic has done with Virtus (which I use in all my projects, it's awesome, he's one of my favorite current Ruby people because of it and I'm sad that he may be leaving) is to return to the novel notion that an object knows what's in it. Dumb data objects are in almost every case a better long-term strategy, and solnic's frustration, if not expressed perfectly, is one that inevitably burns even Rails projects that grow to scale. And while this is a single example of Rails's monolithic nature choking out a lot of the Ruby ecosystem, it's not the only one (see his comments on ActiveSupport).

That's a totally valid point, but is 100% orthogonal to what's being discussed. Invoking a single command to validate, run callbacks, persist to the database, etc, etc. a model (and the larger argument of whether conflating DB access and persistence logic is a good thing) has nothing to do with whether the object is aware of it's own properties.

They are both critcisms of ActiveRecord, for sure, but quite a bit different in content. One (AR objects not knowing their own properties) feels, at least to me, like an unfortunate early design decision, while the other (encapsulating everything involved with saving a model in a single statement, "magic avoidance" be damned) is very much in line with the core philosophy of ActiveRecord and Rails.

> a single object or an entire object graph must be stored in the database

Hence "the last point" (though you might have caught me mid-edit). I view these as functionally the same problem: not only are you instantiating the object, but it must immediately go to live in the database or it's useless.

But you're right in that it is a philosophical problem. Rails is wrong. =)

There are always pros/cons to any approach one can as easily argue that without AR your code is less DRY as you need to keep your models in sync with your DB schema manually. (I am not a fan of AR either)

You could easily build a unit test that compares the set of exposed properties of your model class with the columns of the table in your test DB.

That's not really a unit test and not really a good idea to do it this way. You'll still have to keep model in sync with schema you'll just know when they diverge.

If that's a concern, invert it and create tables off of your object model. It's Ruby, that's trivial.

I agree with the author that abstractions should be optional, whenever possible.

However, just because something is heavily abstracted doesn't mean it's a bad approach, at least from a productivity standpoint. Without certain things being heavily abstracted, we'd go insane.

Just as

gets translated to thousands of lines of Ruby, so also

  CoolClass.new('foo', 3)
gets translated to thousands of lines of C, and

  printf("It's %d degrees today in %s.\n", temperature, city);
gets translated to thousands of lines of assembly.

Are they all heavy abstractions? Yes. Is it oftentimes very nice to be able to use heavy abstractions? Also yes.

To me the point isn't so much separation of concerns as it is separation of side-effects.

printf has a well design side effect (printing to stdout). Coolclass.new has an expectation of an instantiation of object in memory. If Coolclass.new also called an external service, then that would be a violation in my opinion. Thankfully, we generally don't do that.

User.create is not only capable of tons of side effects (just like Coolclass.new) but it is encouraged to do so (via callbacks and such).

There was a recent article about Julia that discussed how a printf in C translate to very few instructions in assembler.

Also I would like to point that "translates" is a little misleading word. There are two ways of implementing an abstraction from a higher level system to a lower level one.

You can generate code or you can write a runtime framework that does the work dynamically. Although from the higher place both may seem the same, there's a huge difference between them that has consequences.

The link to that article is below. printf in C tranlates to a few lines of assembly in preparation for a call to sprintf. That in turn will have a lot more instructions in assembler.


Indeed and OP is mixing up language implementation and standard libs with a framework.

>There was a recent article about Julia that discussed how a printf in C translate to very few instructions in assembler.

I wouldn't doubt it; compilers have become amazing at optimizing. But printf is hundreds of lines of C, at very least: http://opensource.apple.com//source/Libc/Libc-1082.20.4/stdi...

Well, hundreds is not the same as thousands ;-)

And most important, a call is not the same as the implementation of the called function, my point to begin with, please see my comment in the context of yours.

Per cloc it's actually 1093 lines of C (plus some more in the printf.c file), and generally speaking hundreds of lines of C is the equivalent of thousands of lines of assembly.

In any case, the complexity of the called function is exactly what we're discussing — it's why the author objects to "User.create(params[:user])"

For anyone who wants to know how all these pieces work together, I've been writing a series that actually dives into the source of Rails:


Sure, Rails is complex, but it takes on that complexity to let us be productive. When you run into that complexity, read the source.

My problem is whenever something spooky doesn't work, I never know which part of the source to read through. You need to understand the architecture to even know where to look. Which means you have to go through a huge up front process (like reading a webseries on the subject) to even get started. This front loading is the kind of thing that keeps more people from getting into programming, and is one of the primary ways we keep our salaries high.

I agree that this is not a good example of simplicity vs ease, but I think his core argument is still correct about what Rails is. (Whether you or I may like/dislike "What Rails Is" is, of course, another matter.)

The other way to look at Rails is that, as a framework, it has made a decision to have the model carry most of the weight for domain logic. In a "fat model skinny controller" framework, you're not surprised to see single lines of "magical" code like this in the controller, any more than you're surprised that each line of the route table masks thousands of lines of code that execute when a URL is matched.

This is very much not Merb's design. But that doesn't make it an invalid design; it just means that understanding a Rails app might best start with the models, not the controllers.

(There's a lot not to like about Rails! It's been years since I worked in it full time and I don't miss it.)

> that doesn't make it an invalid design

In 2016, with systems regularly decomposing into services for both perf and code management purposes, I'm trying really hard to find a reason to say this isn't an invalid approach except for what amount to toy problems (the kind where "if you don't know where you're trying to go, any road will get you there"). ActiveRecord being a mudball of "what X is" and "how to get X" is a really, really big problem, and my view of it as an observer--heavy in Ruby, heavy in avoiding Rails at all costs--is that it seems to be sourced from an unwillingness of the Rails community to consider that not everything is Rails. Services become intractable, as I note in my reply to your first post--and I don't even mean "microservice all the things", just the profoundly unsexy and unbloggable "SOA".

Rails can be used in many contexts, but its first love is the making of integrated systems: Majestic monoliths!--DHH

Source: "The Rails Doctrine" http://rubyonrails.org/doctrine/

That DHH might even believe with a straight face enough of that essay to write its contents like an English major who just discovered the adjective doesn't really change that the universe is continuing to shrink the place in which his viewpoint can make sense. And, with it, goes Ruby's relevance, because of the heavy weight of Rails on the Ruby world as a whole.

> No matter how we handle "users", we are going to need to do all 6 things in the list the author presented.

I think maybe your broader thesis is we almost always need all 6 things. And if that's true for you then Rails is a good tool for you.

If we only ever need one out of the 6 things at a time then ActiveRecord is only adding extra complexity for us.

I think OP is basically saying I usually only need one or two and that they'd rather not have the extra layer of indirection... "save(andValidate)" is fine for them. They don't need the orchestration abilities that the declarative "afterSave(validate)" step affords.

DHH's suppress really is a good example. If you are calling save(andValidate) everywhere, you can't really do something like suppress(), because your validation logic is disbursed.

My opinion, and I think maybe OP would agree, is that there's usually a nice, composeable way to get the same problem solved, without resorting to a giant engine that understands all the different parts. But that's just an empirical assertion on our part. Obviously your mileage will vary.

> because your validation logic is disbursed

I think you want "dispersed" here.

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

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.

"Explicit is better than implicit"

Hm. I was trying to guess what Ruby was doing and it appears I guessed wrong. Thank you.

I haven't worked with Rails, but have worked extensively with Django and this doesn't seem to be the case. Even though Django is very similar to Rails in some ways, to pretty big differences is that Django seems to be much more explicit in general and (I might be wrong about this) Django seems to be easier to use in a SOA since your controllers (views in Django) are not as tightly coupled to your models.

That's correct. Around the time that Rails became popular, Django was undergoing a major refactoring to remove "magic" and make its underlying logic more explicit.

Further smaller changes have been made since then for the same purpose: explicit over implicit, code or configuration over convention is part of Django's philosophy.

IMO that also makes it easier to graduate from a beginning to an intermediate level use of the framework because while there are sane defaults in many places, in others you're required to define your specific implementation explicitly from the start. It's a tiny bit more code up front, but all the details are exposed and it's obvious how to override default behavior. And at the same time the framework supports keeping your code reasonably DRY and takes care of much of the tedious, repetitive stuff.

There's still tight coupling in some places (ModelForms, for instance, are arguably part of the controller layer and are tightly coupled to the ORM). But they're reasonably optional (you can use plain Django Forms instead of ModelForms in your views or not use the Forms library at all.)

This argument often comes up and I'm genuinely curious why people think Django is less "magic" than Rails, in my experience it has been the opposite.

My experience with Django (for instance: class-based views and admin parts) is actually that you have dozens of magical classes or methods and if you don't know them all, you're screwed. Often when I try to do something, many aswers on StackOverflow boil down to "just override a_method_that_is_hidden_somewhere()" or "just use ListButWithSpecificBehaviorView(), easy you see?".

Are there any specific example you have in mind where Rails do something magical that requires more code in Django but where Django is more explicit?

PS: not trying to start a flamewar, both are OK-frameworks, bla bla bla ;-)

I had a hard time understand how Rails works under the hood by reading the source. No such issue when reading Django source code. Rails magic is really powerful and I got overwhelmed. Maybe its just my Ruby-fu is not strong.

I get the feeling its not your Ruby-fu, but Rails is a lot like trying to jump into the show Supernatural in Season 10. I did some Rails sites early, and now have very little clue what's going on when I read new code. I'm sure I could get it, but its going to be a time investment. This seems to be the way of opinionated frameworks.

It's been awhile since I looked at either but I remember as a beginner I had trouble parsing both the Django source and the Rails source. The rails source was the hardest because I didn't understand ruby and the Django source was hard because I didn't understand python.

I feel like people really forget what it's like to be a beginner when they say "read the source".

"Oh, if you are a beginner, you should work on documentation!"

Better design? In all seriousness Django - they get this right. It seems to hurt rails developers that it means typing a bit more, or is a little less 'magic', but then python did always attract software engineers, whereas Rails always seemed to attract code "ninjas" at best.

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.

I whole-heartedly agree with everything you said, but I also felt stifled and stymied by Rails for years, and am happy to be doing other things at the moment. It is possible (and I think fairly common) to both deeply appreciate Rails while finding fault with it, and to respect the validity of its approach while preferring other tools.

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

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

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.

This is my initial response as well. I came from the land of Java web dev and Rails was the best thing to ever happen. But it's been 10+ years since it really took the world by storm and things have changed. This "I will never use Rails again" saber rattling is just linkbait crap but well reasoned critiques of tools and patterns are always a good thing.

I would argue that is was perfectly possible before rails, many projects never left PHP and are doing just fine with it. Wordpress for instance, i think Facebook also?

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.

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

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/.

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

Spun up my first Phoenix toy project 6 months ago and fell in love. You can really tell that a number of the core contributors are/were rails contributors, it carries over a lot of its strengths and tries to learn from its failings. Could really see Phoenix replacing Rails some day.

The creator of Elixir is in the Rails core team and helped (wrote?) write Rack. The creator of Phoenix built Rails apps for quite a while before finding Elixir—their experience definitely helps because they take what is good about Rails but know which "pain points" to improve on.

I've been trying out Phoenix, and it seems like the top contender for a Rails successor. It's not quite as fluent as Rails, but it's close. But I'm curious: since it is so much like Rails, won't it suffer from all the same complaints as in the article? It is still a monolithic, "Phoenix is your app" kind of framework, isn't it? Isn't the Devise-but-for-Phoenix library going to require Ecto? I think of Phoenix as just "Rails but faster." How is it different from Rails in ways the article author would appreciate?

(Edit: Btw I happily accept Rails' monolithic nature for all its conveniences, and I don't really identify with this author, but I'm curious to hear your opinion whether Phoenix would be a good fit for him.)

I'm a bit short on time, but I'll try.

Phoenix apps aren't actually monolithic, but I'll let the creator of Phoenix explain this himself (https://news.ycombinator.com/item?id=11749741):

> 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.

I think it's really quite a testament to Phoenix that so many people think it too is monolithic. A client can request a Phoenix application and I can get productive immediately without worrying about creating an unmaintainable, unperformant mess. No wasting 2 days on configuration hell. I can even jump into an existing project and be productive.

Another point is that the libraries around Elixir aren't (in my experience) Phoenix-focused or obsessed with magical Phoenix integration. In most cases, things work well together. Just call functions.

Monkey-patching, thread-unsafe operations, and uncontrolled shared global state are all non-problems in Phoenix. Decent code architecture and testability aren't usually a problem either because proper separation is enforced. Functional/immutable programming makes a huge difference here too.

Ecto 2.0 is really what ActiveRecord should've been. It's incredibly well thought-out. I suspect the author would be really pleased with Ecto.

Finally, Phoenix favors simplicity over ease in most cases. Complexity is not hidden in 100 layers of abstraction and callbacks.

The author also mentioned DHH's... colorful personality. So I'll take this opportunity to mention how much more welcoming and humble Jose Valim and Chris McCord are.

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.

Community: Very good, both Jose and Chris are outstanding examples of how you run a community.

Can't comment extensively on the library ecosystem but you have access to everything from Erlang via trivial interop.

Thanks! Great list.

Elixir/Phoenix is the way. Just try it, it's awesome.

I have not stopped using rails. Its mature and works well. But i love elixir and i think phoenix is the future rails.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact