TFA might be right about Rails but completely wrong about Spring. Spring is absolutely a web framework--templates and all. With Spring Boot and modern Java, the productivity is probably in same ballpark too.
templates: spring-mvc offers first class support for Thymeleaf, Freemarker, Mustache and Groovy Templates. Is having 4 equal choices too much for you? Spring seems to endorse Thymeleaf.
persistance: spring-data, the JPA/Hibernate based library for SQL access appears to be very opinionated and is very simple to fully understand. I have never used MongoDB, but spring-data-mongodb is probably of equal quality.
What is TFA? It’s always meant “Two Factor Auth” for me, but this is the second thread I’ve seen today that’s using it like it’s an acronym for a person.
And, as with the manual, it can also be fine rather than fucking. I tend to read it as the former when there isn't an R in front, and as the latter when there is.
You can use the DI and config management container spring-core by itself. There are actually THREE web-frameworks: spring-webflux, spring-web and spring-web-mvc. Webflux is the new framework for "reactive HTTP", spring-web contains the conventional web/REST-server capabilities and spring-web-mvc offers mvc functionality with templates and depends on spring-web.
> the productivity is probably in same ballpark too.
You are still missing Turbolinks, the rails console, JPA is nowhere as good as Active Record, rails scaffolding, Rspec, Devise, then you need to setup migrations... I could add a lot of other items, but no it's nowhere near rails yet. I've never found anything approaching rails for the speed of coding (but not the speed of execution unfortunately :/).
Rails templates is a very very small part of what makes it so quick to write code.
My main point and the only reason I mentioned templates was that Spring Boot is in fact a web application framework and a productive one. If your previous experience was with older versions of Spring or Spring Boot or you weren't using IntelliJ (or STS Eclipse if you must) to build your scaffolding and do your debugging then you might want to take another look. Turbolinks is a cool hack!
I think I agree about migrations. Flyway is useful but not as clean or easy as ActiveRecord and I think that depends on Ruby's dynamic nature so it would be hard to replicate.
No I really mean it that way. I've never tried an ORM which is as good as Active Record. Also the ORM should be coupled to migrations to be anything as powerful as Active Record.
Edit:
JPA is usable yes, most ORM nowadays are quite good anyway, it's just that Active Record is still always one step above, it's a pleasure to work with.
I have a few Rails gigs listed on my linkedin from years ago, and I constantly get recruiter messages looking to fill RoR positions despite not having used it for years. I've been told by the recruiters that I chat with that senior Rails positions are increasingly harder to fill with each passing year.
Whether that means the Job Providers in my sample simply aren't paying enough, Rails devs are sick of maintaining legacy Rails apps, or a combination of both, it seems like everyone I know who spent years working nearly exclusively with Ruby has now moved on to Go, Elixir, or Node.
I've had the same experience, having done exactly one, one-month RoR project and a lot of embedded Ruby.
At the end of the day though, the couple of jobs I did investigate were really pretty shitty. One company asked me to do a coding challenge... I said, "Sure, about how long will it take me?" "I dont know." "What's the subject matter?" "I don't know." "How will you grade the test?" "I dont know." "When do you need it?" "Thursday." "So the only thing you know about this test is it has to be done right now?"
I'm in the same boat as you. I haven't touched Rails professionally in years. I've gone on some of those interviews and every single time it's a quagmire of technical debt. An app where someone made all of the wrong choices and moved on. I even had done some consulting work with some "CTOs" who were running Rails 4 and insisting on doing everything from Rails 2 Railscast examples.
I don't even entertain those interviews anymore. All of the other Ruby work available is more interesting.
I did PHP, Java and Perl work for years before diving into Rails for a little over a year on a big job. As soon as that job was done and I updated my Linked In / Resume to include Rails I was FLOOOOOOOOOODED.
It actually makes sense to me. There are a lot of shops with legacy Rails apps, and they'll use Rails for new code too, because it's worked well and they don't need to do the shiny and new.
Like us. We started a newish project on Rails and couldn't be happier. 90% of the app's job is to do CRUD. Wouldn't want to use any other framework for that job.
The truth is that it is a declining platform. I guess that is why the author uses the words "still huge" and succumbs to the strange urge to compare it to the .NET and Java-platforms which are obviously much larger in terms of jobs and use.
As a Rails dev, I personally prefer "matured" vs "declining" – and to be fair, "mature" it's also one of those words that management would like to see associated with our choice of technology stack, too.
Some things get better with age. There's an advantage too, not being on the brand-spanking latest version of something – you get to let everyone else filter out the crap before it winds up in your production environments.
A few examples from recent Rails releases,
(1) Turbolinks is one thing that was widely regarded as absolute crap when it was released, but now I think it's a pretty non-controversial way for Rails developers to give their users a single-page experience without necessarily diving headfirst into JavaScript.
(2) If you rebuilt all of your Rails 5 apps to use the shiny new Encrypted Secrets in 5.1, ... surprise! 5.2 deprecates secrets in favor of the newer Encrypted Credentials feature.
I'm not saying there aren't good ideas in newer frameworks, but how many mature frameworks are still in active development? (Make a list) ... and how many of those would you actually like to use?
Though they may be more popular, I'm personally not seeing lots of people rallying behind Java and .NET, or making outrageous claims like that those platforms prioritize developer happiness. Rails developers like using rails.
That's fair! And I'll concede that I actually don't know anyone outside of my own working group (we had standardized on Rails), and the people that I actually met at the annual Rails Conference, who are still talking about using Rails.
Otherwise, the most prolific programmers I know personally that used Rails, have all moved onto other platforms at new jobs or for their new development projects. Mostly Go, modern JS frameworks (many of them), Python, and Kotlin.
There's increasingly nice out-of-the-box support in Rails for React. Last time I set it up it wasn't trivial, but it wasn't a bad. I wouldn't be surprised if Rails 6 had it extremely baked in.
My first (Rails) job was not advertised as looking for Rails dev, and I didn't touch any Rails code for probably the entire first year. Hiring manager was looking for a Ruby developer without tons of experience, or strong opinions about which gems to use. It was common for me to receive an assignment with instructions to complete it without downloading any gems.
Most of my projects, were not web apps. ETL type things. When it was time for me to develop something with a web front-end, we still did not use Rails. Sinatra and (pick any template language off the shelf.)
Ruby and Rails are both large skills that take lots of experience and maybe even training to become competent at using. When hiring junior developers, I think based on my experience at least, a hiring manager would do well to defer them from learning Rails until the latest possible moment. Better to learn one major skill at a time.
(Then again most HN readers are probably not trying to get hired as a junior developer anywhere.)
Totally disagree. Rails first learning means that junior devs are immediately productive. And writing code without using any gems? What the hell for? Most of the major standards are MIT, so it couldn’t be for licensing reasons. Not using gems is just wasting effort reinventing the wheel.
Ruby on Rails isn’t a major skill that takes lots of experience. It takes experience to master it, but a junior dev could easily become productive in the framework almost instantly.
Ruby is a language, and maybe if you already know 10 languages then it's a very easy language to pick up, but... how do you expect to know where Ruby ends and Rails begins, if you never separate the two?
I don't see this your way. Junior devs are immediately productive? What kind of fantasy land is this? Junior devs need to walk before they can run. Everyone should know enough Ruby to parse them some CSV, if that's going to be part of the stack.
Then, they can pick up a Gem library for parsing CSV and never do that again. But having the experience of working around the edge cases and knowing enough core language features to know what parts are easy without any gems, is going to make you better able to spot "using the gem wrong," or even "the gem is doing it wrong" (which also totally happens!)
In my company, CSV was something we needed to have as a core competency (customers sending us data files, and bad data files, all of the time, ETL pipeline shaping them up and making them loadable into our custom schema...) and there were just two of us devs, so nobody's got time for pair programming. You're honestly going to ask a junior developer to start with "rails new" and then somehow trust what they produced, putting it on the internet?
A junior dev could easily become productive with a handful of gems too, and practically understand every part of what they did. That's the point. You don't keep all gems out of the picture forever, just long enough to learn what hard problems look like without having them solved for you.
If I'm a hiring manager and you're my junior dev, I want to start by seeing how you think, and I want to see you thinking with first principles so I can tell you where you're going wrong. I'll help you figure out the hard parts if you're struggling with something. But I do want you to struggle with those parts a bit, and I want to see it. If 95% of the work is done for you by a gem, then I might as well let you ask Rubocop and Brakeman what else you're doing wrong, and there's probably no point in having me here at all.
I'm really confused by some of what you're saying.
For one, CSV is part of the standard library. just "require 'csv'". No gems required.
Two, nobody without a really good reason should try implementing their own CSV parse library. RFC4180 doesn't even remotely reflect reality. It's several hundred lines of code to do right (about ~700 in Ruby currently, down from a bit over 2000 in earlier implementations). I hope they're good at RegExp.
Seven years ago, at the time I was starting the job I mentioned, this was not a thing. The gem was called 'fastercsv' and it was made a standard library in 1.9 – we were mostly working on 1.8.7 when I started, and 1.9.2 when I did the CSV implementation(s). It was a brand new standard library and it did not do all things for all people. Almost like they just picked a pretty good one off the shelf!
It still does not do all things for all people... today, you also have other competing implementations, say 'smartercsv' with most recent commit activity 4 days ago.
It's an implementation of CSV. If you know your CSV is pristine, you can parse it in a lot less than 700 lines. We had a utility that would output "pristine CSV" dumped out from whatever garbage the client sent us, in whatever Excel or other columnular format, and we had another utility that would only accept this "pristine" format. Sometimes things went wrong. More often than you expect maybe, and we'd fix them ... or sometimes we'd get the clients to fix their shitty files, and leave it the way we thought it should work.
Depending on what you need to do with the CSV, or how many ways you're planning on handling CSV, one could argue that you will be better served by a minimal implementation that you know exactly what it does and does not do, because you told it what to do. If it's making a mistake, that's yours. You own it! That's another boon, when the quality of the data is not guaranteed.
The standard library I remember has some great idiosyncrasies that you'll know if you've ever used it to work on bad CSV. So do all of the CSV libraries. I don't work on CSV anymore and my memory of it is not so good, so I can't tell you the war stories in perfect detail, but... suffice it to say there are several CSV libraries with different strengths and weaknesses.
We mixed and matched parts that served the specific need we had at any given time and place, until I was a total CSV expert. It was not a perfect ecosystem, and 7 years ago `require 'csv'` was simply not a thing. You had to pick one off the shelf, or roll your own. I'm really not sure what's different today. (Probably not much! Parsing CSV is not a core competency of either Ruby core team, or Rails.) We had our reasons though, to be sure.
The one I remember in particular was a bit that converted your CSV rows and columns and then turned them into arrays of hashes, or converted arrays of hashes into CSV, and then another piece that expected the hashes to be identically ordered. If you used all of the standard pieces, this worked great! I think it took multiple libraries to do this, actually, and some of them were not so standard.
But wait... hash keys are not ordered at all, and that's a property of hashes that is standard and well known. But in some cases the hashes do come back with their keys in a particular, consistent order, and in a perfect walled-garden use of the particular CSV library configuration that was expected by the people that wrote this crap, yeah everything worked.
Well, everything worked until you do get a CSV with an uneven number of columns in some of the rows.
Like I said, CSV was supposed to be a core competency for us. We would not have been successful if we just picked one CSV library and stuck with it. Or, that CSV library would have got a lot of free labor from us, I'm not really sure which. I'm not sure which is worse, either. I don't do that anymore though.
Hah, I thought I was describing two unconnected things, but it turns out 'smartercsv' (at least the prerelease from 4 days ago) is actually designed to solve the very problem that I had described having seven years ago with fastercsv:
> Ruby Gem for smarter importing of CSV Files as Array(s) of Hashes, with optional features for processing large files in parallel, embedded comments, unusual field- and record-separators, flexible mapping of CSV-headers to Hash-keys
That is true! And it's also true that some environments require full code reviews of everything that isn't already certified.
Hypothetically speaking, I don't know how you get around the fact that Ruby has way more code in it than any of the gems you'll want to pull in, but ignoring that, what's easier... getting a new gem certified, or writing just the parts you need and putting them through the normal review process?
The answer is not going to be the same each time you ask it.
I started using Rails probably at 1.0 and it didn't have any learning curve worth telling back then. However I've been doing web development since 1994, including some CGI programs in C (nightmare), CGI.pm (Perl), Struts (Java) and occasional PHP (real garbage back then, better now) so I knew what's in a web framework. I only have to learn the way it implements what any web application has to do. There aren't many surprises, some occasional disappointments when a framework overengineers something (my general feeling with Python and Django and of course with Java.)
Rails isn't very complex even now, especially if you separate the front end (a JS SPA) and the backend (an API Rails project). You can develop two different projects in two different repositories and forget all the asset pipeline. However you must know the frontend really well or the sum of the two projects is going to be much tougher than vanilla Rails views.
> some CGI programs in C, CGI.pm (Perl), Struts (Java) and occasional PHP
I said junior developer, didn't I? :) and also mentioned that this was my first ("permanent") job (after college)?
Getting to know what's in a web framework, is exactly the learning curve I'm talking about. People complain about magic in Rails. I just wrote an ERB view "index.html.erb" and declared an empty method "index" in my controller. Add in a route definition, and now somehow they are all connected.
What is actually happening? Why does that even work?
If you've never used any web framework before, that's inscrutable magic. If you know what a correctly designed controller method looks like (it should maybe fetch some values, then render a view... and probably nothing else) then it's obvious. Getting over that hurdle is ... definitely not the kind of shit my first boss hired me to do. I'll say again, most of my assignments for the first year had nothing to do with "on a web page."
The magic isn't really magic if you have a basic understanding of how Active Record works, which really just means you know SQL and what kinds of queries all of those named relationships and parameters generate. This is like the critical piece to groking Rails and we minted too many "Rails developers" who don't know this. The only missing piece then is how internet requests are routed. Basic knowledge of how HTTP and TCP/IP work.
My stance on this (and how I did it as a junior) is to have someone implement a toy implementation of Active Record's basic relationships using Ruby meta-programming and to implement a basic request-response server. This is part of the curriculum of some bootcamps even.
If your junior developer can't do this, they shouldn't be touching your production Rails application. Your immediate goal on hiring them is to train them to be able to do this.
I read your first paragraph... but then I read the rest of what you said.
Having read the whole comment, I'd say that is spot on. I knew some SQL, but didn't start with Active Record. We used SQL client libraries to connect to our SQL database, which didn't have a Rails app built onto it until well into my second year.
I did all of that, except for the implementing ActiveRecord and the meta-programming. So I didn't really do any of that. We didn't have a production Rails app until it was clear that I was gaining proficiency, and I'd be sticking around long enough to get a handle on how to manage it. (I didn't write most of it. And we avoided metaprogramming pretty much at all costs.)
We had a production Microsoft Access app (no really, VBS in Access 2000), with a MySQL server on the backend, along with tons of perl, bash, and ruby to glue the important parts together. There was a Java app that handled the web side of things. I don't think I'll ever work in a place like that again! But it was the path I took, and now I work on pretty much exclusively Rails.
Didn't I just point out that all but 3 of the ruby jobs did not mention Rails at all?
They may be using it, but they didn't mention it.
As for Ruby work that I've done, infrastructure automation, ETL, systems programming and the occasional Jekyll or Sinatra project.
Used links to get just the text and not the HTML markup. Used grep -O to emit just the part of the regex which matches so we can feed it all into a pipe that emits a single histogram. By ordering the pattern we can match "javascript" before "java" and not need to add the space or "," after "java" to exclude javascript (you could also use "\b" with grep -E).Case-insensitve and case-folded. Added a few other keywords.
Since grep only emits the first match on a given line, this won't count properly if multiple keywords appear on one line.
Why did you search for "mean"?
Edit: here's another approach that splits the output into words first so that we can count multiple keywords on one line, along with a couple tweaks to the pattern to eliminate some false positives:
Yeah, we have to have comment pagination turned on these days to spare our poor single-core server with steam coming out its ears. Hopefully the performance improvements we've been working on this year can roll out in the next few months.
If you or anyone wants to run this query on the full comment set, email us (hn@ycombinator.com) and we'll turn pagination off while you do that.
I'm not sure why this continually comes as such a surprise on HN. It's a mature framework with tons of community involvement and 3rd party gems to help ship features out the door.
The vast amount of projects and internal tools out there don't need to be "webscale" or process millions of requests a minute.
They are dwarfed by most media companies etc. Github's website sees far less than 1% of Facebook's traffic for example. On the other hand they have almost 30 million users so they are not exactly tiny.
Regardless it helped them initially scale and attract users by shipping features and focusing on proving their business. Down the road as they attracted users they kept their rails core but started adding in other systems that were met their performance needs.
Rails allows companies to grow quickly and focus on attracting users and delivering business value at the sacrifice of a re-write or complexity of managing rails and performance issues down the road.
Also, Rails scales perfectly fine as a stateless web front end. If you have those scaling challenges you need an underlying architecture to handle it, not a silver bullet language.
If you need raw single process performance especially with parallelism then you probably should look beyond ruby. But the whole Rails doesn’t scale because Twitter meme is asinine.
Yeah. Not to mention that it is trivially easy to scale web apps horizontally. So the real bottleneck is the data store, not the programming language you used for your app.
Who needs to webscale to millions of requests per minute?
Really, the vast majority of web apps built today will see hundreds of requests per minute.
Still, Github and Shopify have proven that Rails can scale to hundreds of thousands of requests per second. Which is a great number.
Said that, if my goal was to build an app with a simple set of features that don't change often, and that will serve 100 million users, where none of them is paying user, I would probably not choose Rails.
> if my goal was to build an app with a simple set of features that don't change often, and that will serve 100 million users, where none of them is paying user, I would probably not choose Rails.
What would you choose in this case? I'm also a little confused where the user "paying" comes in. Is that in terms of the importance of that specific type of interaction or the concern of friction scaring of "free" users?
Go, Elixir or Java would seem like good options for building something that could handle that many users. If the expectation is 100 million users, then you're truly building for scale, not how fast you can get an app out the door.
In addition to be a full-time CTO, I run a referral network that helps connect high-quality engineers with great job opportunities whilst skipping bullshit interview processes.
I can attest that the demand of Rails engineers is still large - why wouldn't it be? It isn't like the 15+ years of Rails code in the world just converted itself to another language.
But I will tell you one trend that I find very interesting and did not think I'd ever see: The lead-in for a full stack or even a backend position is the React/Redux part, not the backend technology.
Very often a position will be React + whatever you can do on the backend. For years, it was quite the opposite. You wanted to hire a Rails engineer who would dabble on the frontend where need be.
A lot companies I work will pay handsomely for a React developer, and they're quite sure they can teach the React developer whatever backend they use (usually Rails, Django, Flask, Sinatra -- in that order).
The last team I worked with seemed to be going that way. I'm an old-school database engineer, and RoR had a familiar feel as I was learning it, since it got a lot of the database interface right, but my manager was a blame-the-tools type.
To me our app just needed a few tweaks for performance and some refactoring of a few poorly-designed classes which were obvious in the data model, but to him it needed React, .net microservices, and a whole lot of yes-men to implement these things.
This kind of culture has always been around since way before Rails; unfortunately I've never learned how to turn it around. The team no longer has a database engineer :).
The note about the frontend tech taking the priority when looking at candidates is super interesting to me. Especially as someone whose forte is on the frontend side of things and who definitively struggles more with the backend. I wonder if this speaks to the relative scarcity of developers with that frontend experience or whether frontend technology is actually harder to learn. Can you speak to that at all from your experience?
I'm especially interested as someone who's growing our own engineering teams and laser focused on getting people who can really crush it on the backend out of the gate (because I feel like we can teach the frontend pretty well).
If I was building a startup today I would choose Rails for the MVP without a doubt. So much time wasted with the modern JS ecosystem or even other mature frameworks like Django. I have almost 15 years of experience building web apps professionally with the majority of that being spent with Django.
There is no tech stack in the world that will get you shipped and proving your business faster than RoR.
As someone who is heavily invested in building web app MVPs for clients on a budget, I've been considering moving to RoR and away from Laravel if not just for the simple scaffolding Rails would give me. Given you spent time in Django where some things are a little manual just like Laravel, would you recommend me diving deep into Rails given what my business aims to do? Hope you can help!
I built an app from idea to mvp in 2 days with Rails last month. It has user accounts, reddit style threaded comments, collaborative maps, algorithmic popularity feed for posts (like HN front page or reddit) and a bunch of other little stuff. I basically had an idea on a Saturday and by Monday morning I could demo it to my team.
A word of warning to other people out there: in my experience, this tutorial is best suited to people who are already familiar with at least two of:
1. Web development
2. Ruby/Ruby on Rails
3. Test Driven Develepment
If you're new to programming, start with something else. Trying to learn all three of these at the same time is not a recipe for success. Source: personal experience watching 100% of former mentees fail to make any progress with this tutorial.
I found that skimming the Test Driven Development sections helped cut down the amount of material I needed to get through. Already knowing web development is a good prerequisite as well, and Michael Hartl's Learn Enough series should be able to fill in some of the gaps. Rails didn't make a lot of sense to me until I learned some Ruby, HTML, CSS, and enough Javascript & jquery to manipulate the DOM and make ajax calls.
Rails is not really for new learners in my opinion, since the famous Rails magic can obscure what's happening under the hood, and the framework itself has grown and evolved over the years. Nodejs is better for new devs in my opinion, but Rails really shines once you have the basics and a couple of small apps under your belt.
Don’t get too excited, with the right packages I could do the same thing in a day in React. Maybe less. And it would have optimistic UI, real-time updates and a static page distributed through a CDN.
I'm sorry that sounds like a load of BS. I've worked with Django 8 years and React since 2014. Nobody can replicate what django does using a client side view library like React. At least not without downloading half the internet via NPM or Yarn. I suppose your talking about React-Router, Redux, etc... etc... and pulling it all together via some Node/Express single page app?
I'll take django for simplicity any day and run React from it's templates.
First I'd start with creating the database in Postgres. Create tables to hold data and any views needed to represent joined tables for convenience. Once that's settled, the express server comes next to create a CRUD API to work with the data and handle user authentication and authorization. This is dead simple and once it works there's little you need to touch. The database handles any data dependent business logic.
By this point you can make API calls and use the application through any REST client.
So now I just need to create a React client to consume the API and give a great user experience. Don't need Redux. Grab React-Router and a couple packages for UI components and you'll be up and running with the MVP in no time. Checkmate.
> Create tables to hold data and any views needed to represent joined tables for convenience. Once that's settled, the express server comes next to create a CRUD API to work with the data and handle user authentication and authorization.
Not sure how you're beating Rails or Django at this, unless you're a 10X developer going against a normal one. For that matter, I'm willing to bet an experienced Drupal developer using drush would be faster setting things up.
I don't think being able to write some simple SQL makes you a 10x developer. I think it's normal. The way I prefer to see it is relying on ORMs makes you a weak developer.
If you're familiar with setting up a basic express app, and kind of know how you like to do things, can prob set up another one pretty quickly. None of the ORM's prob as mature on node (last i checked) but still not a huge amount of friction if you already know one.
Node will prob take longer if you're taking time to try out [new hotness lib of the day], though.
This could be a cool challenge. Someone volunteer to do equivalent MVPs in ROR and React. Two separate twitch streams side by side to see how the MVP is created in both these technologies. I think it could be a fun and informational/educational event. Any volunteers?
I'd like to see it. A throwdown between two different full stack developers of similar experience in their representative frameworks. Give them both an application to create and its requirements, and a prize money to whoever makes the best application within a set amount of time.
I have to agree. Our stack is currently Node.js. After all the abstractions that we've added to make it work for us, it's basically Django now. We could have saved a lot of time just going with Django first. (Or Rails if that's your flavor)
I had the same experience building up from Flask. By the time we finished, we had a more or less complete clone of Django, built with a unique combination of various tools that more or less worked together.
This is what inevitably happens to me as well. This past week I wrote what was literally a single file ruby script to do some automated QA testing for a website migration, since that day I've been requested to:
- make it a web app so the team can run tests
- add some charts
- keep it secure
- umpteen new semi related features
Would have been easier to just start at "rails new".
I think the surprising thing about this comment is that you actually developed using Django for all those years, and you still prefer RoR.
The vast majority of people on the web that comment invariably say they are pretty much the same and it depends on whether you know ruby or python better.
So people who already use python for finance or data science pick django.
I saw a study (old now, from the early days) that claimed they were about the same but that the admin page on django cut dev time by some %.
This is the first I've heard a long time django user say that rails was faster to develop and not about the same. Can you elaborate on why?
I've used Django a little bit, I can definitely believe the admin page cuts dev time if Rails doesn't have an equivalent. But I know Python well, and Ruby not-at-all, and I'm not sure I'd choose Django over Rails, because Ruby gems seem better for RoR than Python has in terms of Django-compatible packages. Maybe I'm just not looking in the right place but there doesn't seem to be nearly as much of an ecosystem there.
The efficiency you gain using Django on the admin side is lost with every other part of your app.
1. Active Record is superior to the Django ORM (which is still good). Being able to set scopes and do a lot of conveniences right on the model without needing to extend/override a manager is great. Being able to connect to an existing database for free is also great.
2. Controllers are great. The way they can be nested and composed is also powerful. Being able to mount a resource at any level in the hierarchy either alongside or beneath (or both!) is hugely powerful. I can state concerns at each level and 'forget about it' deeper. Eg, if my controller A needs to ensure a given user has access to that resource and all children, I can do that at level A and trust its handled so in the controller for level B or C (deeper layers) I am not worried about it.
2b. The syntactic sugar to add authentication/authorization/guards in controllers is incredible. `before_request :ensure_access`
3. Active Support is phenomenal.
4. You can build very elegant, flexible and powerful RESTful and RESTish API's REALLY quickly. And not just naive stuff that you can do with something like 10 lines of Flask ... but really foundational stuff that allows you to hit the ground running and then build on it layering in more security and functionality.
5. Polymorphic/STI power with Active Record. AR gives you so much more freedom to do polymorphism and bend your database to model your data as you see fit. With Django you are oftentimes stuck doing things their way. For instance if I want multiple classes to share a single database and get instantiated based on a 'type' field ... that is trivial in Rails and difficult with Django. Even moreso if you want to do relationships with those polymorphic objects.
6. Finally... the most important thing... it's sometimes difficult to model your domain/business inside of Django and by extension the Django admin tool. Let's say you have a friendship between two people. How do you create that in Django? You might have a many-to-many which means there is gonna be a join table somewhere. Do you ask your customer support folks to go into the FriendRelationship UI and 'create an object' connecting person_a to person_b and ensuring to choose the correct relationship type from the enum? Worse, you have too many users so you cant use a select field or search box without plugins and are left with two input boxes that expect a valid person ID to the FK. So now customer support needs a workflow for managing this data. I'd rather build my own "manage friends" page that will take me all of an hour and provide an experience modeled after the problem/task not the database.
Or let's say you have a more intricate transactional type of process where an object needs to be created with 3 or 4 child objects. The parent needs to be created first, then the children need to be created and linked to that parent. Sure, you can do this in the Django admin flow but at that point you might as well be writing `INSERT INTO...` queries. Again, I'd rather build my own tool. I will save SO much time building the API and the business logic for my program that I'll be afforded the time to build an administrative tool that is focused on tasks specific to my team/business not just a graphical representation of my SQL tables.
I could go on and on and on. I was a Django zealot for a long time and refused to drink the kool-aid. I bought into the hype from the community and trusted folks when they said "rails is magic, I don't like it" but that is a horribly naive approach and frankly I only hear it from less experienced engineers. When you get acclimated to Rails you realize there is no magic, it's all just straightforward code written by people who truly want to get things done. Perhaps I just align more with the Ruby way of thinking. Django folks tend to pride themselves o...
You take advantage of what the database gives you already (via Active Record) and Friendship is its own model of which People are members. People have many Friends (People) through Friendships. Friendships have many People.
You stick a check in the update controller for Friendship to destroy the object unless it has two members (or not to create without two) and additionally you add a "validates_numericality_of :friends, on: [:create, :destroy]" check on the model itself.
When someone "friends" another user, you create a new Friendship with both users as members. It's automatically bidirectional (but you probably want to add some approval logic in here, which is still pretty easy).
The manage friends page discussed is just a collection of all of the Friendships of which you are a member. You can use either update or destroy to remove you from membership, because now either will achieve the same thing.
> Django folks tend to pride themselves on boilerplate and more complex interactions... like it's some kind of badge of honor
It's funny hearing this because I was under the impression one of Django's core principles was to avoid boilerplate.
Like you, I've worked a ton in Rails and Django, but I started with Rails and always find Django work to be a slog -- particularly when it comes to environment configuration and administration. And the documentation for when you need to muck around under the hood is really not great.
And, invariably every Django application I've come across has tons of boilerplate.
You can even use the under-the-radar PyCall gem[1] if you find you need a little peanut butter for your chocolate.
I discovered it recently, and it has been great to be able to use various Python NLP libraries without having to learn a new stdlib, deployment stack, etc.
The problem is, the sort of devs who would jump right into Ruby On Rails a decade ago are now doing stuff with React, Node, Go, and (if they're lucky duckies) Elixir.
Elixir adoption is going nowhere. If you search Indeed.co.uk by job title there are currently 7 Elixir jobs in London compared with 104 Ruby and 364 Python.
We had a split into frontend and backend lately. The front end was only a little JavaScript on static HTML pages when RoR was trending (btw, does anybody remember Prototype.js?)
Still, it's easier to code a backend in Rails than in Phoenix (done that) or Django (inherited one). Both have extra layers that Rails proved to be unnecessary until the business scales to levels that very few companies reach. And if it doesn't, any MVP in any language can keep running fine for years. We can start debating about tradeoffs and premature optimizations but I don't remember any unicorn to shut down because it started with Rails (or PHP, hi Facebook!) and couldn't cope with the load. It's so much more about marketing and execution than technology.
Kind of shocked this is getting downvoted. Look, this isn't about X being better than Y, it's simply the fact that there are now a litany of other technologies to grab people's interest. In the aughts, I watched Rails' meteoric rise: it was revolutionary and had few equals. Rails shifted the conversation away from baroque, enterprise-y frameworks towards tools that provided real developer productivity.
Lol. Use a Java backend, that's performant and solid so it can scale beyond a million subscribers easily and write the Frontend in a framework like Angular/React/Vuejs and I see no reason why I would want a Rails app instead.
Agree. Incidentally Play Framework that supports both Java and Scala was modeled after RoR, so you get both convenience of fast prototyping and the power of the JVM at the same time.
Speaking of having to rewrite your entire application, play framework has changed how it interops with DI and a number of other significant details every single minor release, forcing significant changes to update versions frequently. We were pretty gung ho about it at first, but basically all our engineers have burned out on it and we are going so far as to embrace the relative stability and, dare I say, simplicity of spring-boot.
It's possible that for Scala development it is a fairly good option, and some of the pieces like the typesafe config library are pretty nice, but at this point we consider play to be more like a curse word representing incompatible inflexible garbage.
That's because they are not minor releases. Play seems to follow the Scala style version numbering (epoch.major.minor).
In any case, I'm with you in that some of the changes between major versions they did were painful, especially if the code was structured in certain ways.
Having used both Play (with Scala) and Rails to create some APIs in a professional environment, there's no competition. Play is extremely robust and quite featured, but Rails development speed is much much faster. Rails is extremely opinionated, but you can learn from every choice the framework made and apply it elsewhere. Play is much more freely structured, which is a double-edged sword.
If I had to create a new API from zero, I'd go with Rails.
You may be able to go faster with Rails, but scalability is where Play would blow it out of the water. If suddenly tomorrow my Play services get hit with 100 times the usual user number I wouldn't even notice.
It's the old tradeoff: dev speed vs performance. I just prefer to go with the tech stack that I feel makes me more agile, more capable of changing direction if need be. Both points of view are valid, of course.
I work for a company with a Java backend and no one has ever accused us of being fast. Worse is that development on the backend is so slow that small, competing startup have been able to build out 5x more features (and more useful features at that) than us, leaving us in the dust.
There are modern JVM backends for fast prototyping (Play, Akka-http, etc) and if you use them with Scala for instance your testing surface will be a lot smaller compared to dynamically typed languages due to strict typing.
I dont have much experience, but with react native, you only need to build 1 app for iphone and android, then potentially use react for web.
Is there any competition here? I could be unfamiliar with other solutions, but I thought the purpose of using JS was to eliminate re-writing code in multiple front end languages.
You can even go the Cordova route and just write your entire application ONCE and use it on any plattform that Cordova can compile it to. The JS hate on HN is obviously always strong, but in this case, not really justified. Ruby and RoR are slow, you can check that in any benchmark and scaling your application will become a nightmare very fast. Experienced that in projects I actively worked in where the Backend was eventually rewritten from scratch in Java.
> You can even go the Cordova route and just write your entire application ONCE and use it on any plattform that Cordova can compile it to.
You can't blame Ruby for speed and talk about Cordova just after, it's a bit ironic... Cordova is one of the slowest cross-platform framework I know and that's a big reason the adoption is not going that well.
The code for the server is different from the code for the frontend, even if they're in the same language. You're trying to do vastly different things. Front end is about user interface. Server is about controlling access to and storing data. IMO, you should use the best tool for each. Rails has been encapsulating the best practices around server side web apps for 15 years. The ecosystem is unbelievably mature and productive, regardless of whether you want to do a traditional server rendered app, or a JSON API for a JS, iOS, or Android client.
>Rails has been encapsulating the best practices around server side web apps for 15 years.
Not to be pedantic, but I worked on Rails projects in 2006 and 2007, and had probably heard of it just a bit before that. This was during the initial Web 2 boom. I would not have thought that Rails was created much earlier than that, since I usually keep some track of at least major tech developments (although could be wrong, of course - I could have missed reading about it when it was created, or only first read about it after it became a bit popular). So anyway, I googled, and the Wikipedia article for Rails says:
>Initial release: 13 December 2005; 12 years ago[1]
Haven't used it lately, but I do keep reading that it is very mature and productive, as you say.
I had a customer with a full stack JavaScript application, coded when Angular 1 was all the rage. The development stopped, the original contractors moved to other customers. The customer wanted to resume development but after one year they're still having a very hard time finding somebody to work with such an ancient technological stack. Task one would be porting it to whatever is current today and probably rewrite substantial parts of it along the way. My bet is that either they'll spend nearly as much as they did years ago or let it die.
On the other side I've got a customer which started with a Rails 2 application in 2011 and ported it with not much pain to new versions of the framework. The next one will be the jump from 4.2 to 5.2.
That's pretty much the story of most js app i know of. Some cow boy code with "libs not framework" as a moto and has, like every cow boy, a very personnal idea of what the libs should be. Plus a few new ones because testing new toys makes like more fun.
The of course, the js ecosystem being what is it, everything changes. Stuff are not compatible anymore, docs disapear, new things are hot.
Mean while I have a django 1.4 project we migrated to 1.8 last year. The author was not a great dev. No tests. No docs. But it's a very stable stack, with lots of tutorials and a well integrated and compatible ecosystem. It was work, but not remotly a rewrite, and any python dev could have done it.
The current JS state of things, bith technological and cultural, leans to disposable projects.
The only successful JS projects i witnessed are ones from great teams. But the world is not made of mostly 10x dev.
And even if you do need to scale, the vast majority of apps can just scale horizontally (aka, just deploy more application servers). Your bottle neck is almost always going to be your data store, not your executable code.
Untrue. I have personally cared for several applications that have lived from Rails 2 through to 5 - and most of the code hasn't needed to be touched.
Sure things change - hashrockets are out for example - and I have regexed the codebase a few times, but the core business and presentation logic has stayed the same, and the process has been fairly painless, even when skipping a version now and then.
I have mixed feelings about RoR, having seen both sides: the incredible speed of development as a startup bootstraps its MVP, and later as a mature company where the codebase becomes an immense behemoth of tech debt that's almost impossible to refactor. Don't believe the people who handwave and say you can avoid the latter by just "designing it right at the beginning". That's a lie, even the best engineers will build an unmaintainable monolith in RoR given enough time and if the business requirements are complex.
At this point I have a strong aversion to starting any product using a dynamically-typed language (regardless of framework). The initial speed and ease of development is repaid 10x later on in sheer engineering pain (if you're lucky enough to be successful, that is).
Assuming you last long enough to care about tech debt. That development speed of arails is often the difference between surviving as a company or folding before you even get off the ground. However Swift Vapor might be a good alternative.
Static typing alone won't save you from creating monolithic code that's hard to maintain. My current employer has been slowly decoupling their 20 year old core product written in .NET into microservices (mostly Java, some Node) for years. The legacy .NET codebase has tons of tightly coupled dependencies, logic heavy error prone stored procedures spanning thousands of lines, and laughably slow startup/deployment times.
This. People who believe this pipe dream that static typing will somehow protect you from technical debt either haven't dealt with Java or it's slightly better cousin C# or have only dealt with that one technology and believe whatever kool-aid advertising they were sold on.
The only way to adress (but not eliminate, since it's impossible) technical debt is to refractor mercilessly and constantly. And then there is some merit to static type advertisement - as the tools and techniques to safely refractor are both more feasible and more available for these environments.
> People who believe this pipe dream that static typing will somehow protect you from technical debt either haven't dealt with Java or it's slightly better cousin C# or have only dealt with that one technology and believe whatever kool-aid advertising they were sold on.
Hark! A counterexample has arrived! I spent a bunch of years creating and maintaining big Rails applications. I've spent the last couple years on a bigger application in Java. I didn't drink any kool-aid, I just think Java is a better tool for this. C# and other things may be even better; the key is the ability to write static analysis tooling, which includes, but is not limited to, a compiler's type-checking analysis. It's not that a language with strong static analysis support saves you from creating a mess, it's that it makes it easier and much less risky to clean up that mess over time.
I agree with everything in your second paragraph, and would emphasize the risk aspect of refactoring a big application without good static analysis tools. After the first few spooky-action-at-a-distance prod breakages due to refactoring, it becomes hard to argue for a merciless and constant refactoring culture, and much easier to become the grizzled veteran who is a risk averse gatekeeper discouraging major refactoring in code reviews (this was me).
You don't refactor "a big application". You refactor bits of it (sure it might mean moving things around) and then comes your barrage of tests before you merge that into master.
That and: You don't (or at least shouldn't) write a big application anymore. The only other thing (other than horizontal scaling, that is) that microservice design makes easier is exactly code maintainance / refactoring. The practices around it have matured enough.
On the other topic: I've spent last year or so writing mostly JavaScript, and have moved to VS Code as my primary IDE. I'm pretty happy (was doing Java/Python before that, and PHP/Python before that, and some embedded stuff before that).
The truth is that a good tool (and VS Code is one hell of a tool) makes working in a dynamic language very usable. VSCode static analysis tools make my JS experience better than my previous NetBeans Java experience, all things considered.
And I'm now dabbling with TypeScript to see how that goes. I quite like the idea of "just enough typing" and I think type-hinting rather than static typing is the way forward in this networked future. It's simply that these JSON-ed distributed environment people work in now will make static typing languages frustratingly un-agile for large majority of use-cases.
This is a complaint I hear a lot, and it's very valid. My question is: which frameworks protect against this "behemoth of tech debt" inevitability that comes with using rails?
I've worked with large rails, django, and node apps, and none of them have felt particularly enjoyable to work with from a feature development standpoint once a certain scale is achieved. This doesn't feel like a rails-specific problem to me, but that's just based on my experience.
None. This is not a Rails problem or a Django problem. If you're coming to that conclusion you haven't been building software long enough.
You can architect clean software in any language. What happens is this: you learn a new framework (or sometimes learn a new framework AND the corresponding language it is build in). You don't know what is idiomatic. You haven't made mistakes yet. You're making progress on your idea and getting shit done though, so it doesn't matter. Long story short: you don't know any better. Hindsight is 20/20!
Next time around you try something new and blame your old woes on the framework. This time around you've learned a thing or two about how to properly organize your code. You've been bitten by a third party tool that stopped being maintained. You've grown and learned and become more wise. But... you still blame your past issues on the old framework.
At some point you've been doing this for decades and you start to learn about abstract patterns that are not coupled to frameworks: service-oriented design, domain-driven design, CQRS (command driven systems), event buses and event systems, clean architecture, separation of concerns, SOLID principles, etc... ONCE you are at that point, you will begin to realize that NONE of the frameworks are going to solve these issues and NONE of them are more or less prone to causing tech debt.
Long story short: keep building software and focus on principles not frameworks. Read up on SOLID. It just takes time to get better and to start building things that don't encourage debt.
Another thing to note: tech debt is not bad. People throw that term around all the time and use it as a proxy for "messy code". Nothing in life is free. Everything is a balance. Perfectly architected software vs move fast and prove the business and make a profit? Pick one. You're going to acquire some amount of tech debt along the way. It's like real debt... sometimes you gotta accrue monetary debt to make progress elsewhere.
This is a software problem, not a Rails or even a Ruby problem. I've seen Java/C++/C# systems collapse under their own weight just as often as Ruby/Python/PHP because they don't invest the time in cleaning up the tech debt as they grow.
Parent is definitely right, projects that are "designed right from the beginning" do not exist in reality. Everything has unknowns in the future, and it is better to be flexible and adapt the code base to them as they come rather than trying to plan everything out from day 1. Static typing does help with these adaptations, but it doesn't compensate for a lack of diligence in keeping the code clean as the software grows.
I think the concepts built-into Go make building very large programs much more approachable. That was one of the design goals.
I'm not sure Ruby, Python, Javascript, etc. were really designed for large scale development (although people use them for that). I think this is the primary reason so many people complain about technical debt, hitting the wall/limit, needing to refactor, etc. And looking for another language. Their tools just were not meant to scale that large.
"Go was deliberately designed from the start to support large scale programs implemented by hundreds or thousands of different programmers. Those kinds of programs are written at Google, and Go was designed to be used to write programs at Google." - Ian Lance Taylor
which frameworks protect against this "behemoth of tech debt"
Yeah, that's basically what invalidates the assertion. There's no language or framework that guards against the complexity of a large code base. Period.
Following your opinion You'd say that there are no well design projects build with RoR, right? I think that's not true while you deal with the tech debt. Also, about the dynamic typing, you could really mess up the things with static typing programming languages like Java...
You can build poorly architected apps and accrue tons of tech debt in any tool. Likewise you can build very clean, fast, extensible and powerful applications in things like PHP.
Don't pin this on ROR. I have seen absolutely atrocious Django codebases, Clojure projects, etc...
Types do not solve this problem either. If you think static types prevent 'tech debt' you're delusional.
Good architecture can be had across the entire spectrum of tools and frameworks.
Designing it right at the beginning is a problem for every software. I have 100+ lines controller actions in rails and I'm not proud of them, but it has grown like this over the last 8 years, it has 100% test coverage that I probably wouldn't have to touch if I decided to refactor the method into a few (yes!) services.
This is true, and C# is a joy to work with, but I really cannot stand doing development in a Windows environment after having spent so many years in linux environments.
It's been a while since I've played around with this but I remember the "Great package management" story to be lacking with .NET Core. It was tough finding packages that worked with Core. Has the package ecosystem grown?
Basically all of your popular and widely used libraries support Core at this point. Also, starting with either Core 2.0 or 2.1 you can use most packages targeting .NET Framework with Core, and ~80% of them (IIRC) are supposed to be fully compatible.
Agreed. I looked at core on MacOSX at some point, don't remember exactly when, and it wasn't quite there yet. Glad to hear that progress has been made and am very curious to check it out!
Core works great now. I recently whipped up a micro service in it (on my MacBook) and rolled it out to our linux infrastructure with very little effort.
The author is seemingly interested in fixing these issues, at least. It’s been a contentious day. I’d expect it to be fixed reasonably soon, due to its apparent sponsorship and who is rumored to be using it in production.
I just saw their most recent response, which has ameliorated my concerns. Thanks for bringing my attention to it! Previously it seemed like they might have got unproductively resentful at the backlash, somewhat understandably. All's well that ends well!
I'm not a Spring fan, but i am surprised to see it this far down in the responses to that comment! There are really only three web frameworks in statically typed languages that have anything like the breadth, depth, and endurance of Rails, and those are .NET, Spring, and Java EE. Crystal? Come on.
I've been so curious about this framework, and Crystal in general, but sadly they've also inherited Ruby's attitude of Windows as "when we get to it".
I'll probably try it out when they eventually add Windows support, but if Ruby and Git are anything to go by, what starts out as second class always will be.
I'm currently using Rust, largely because `cargo` solves so many headaches, but I would prefer a garbage-collected language for most uses.
Type safety would change my world. Lack of it is the #1 thing causing errors for my company. You can either program defensively around it, jump through NilObject patterns (about the best option), or over-document every method which then will get stale soon to tell the intent of what's going to happen.
Method chains are a trap in Rails and will always lead to NoMethodError sadness.
The problem with Ruby isn't static typing per se, it is the terrible handling of `nil`. Ruby either has to make nil more evaluatable, or assure unexpected nils never come with options. For instance calling `each` on `nil` should have the effect of calling it on an empty enumerable like Clojure does would make it more evaluatable and stop the dreaded "No method found each on nilclass".
I've been programming in Ruby for 10 years and I have to say after writing Clojure for a bit I really enjoy the fact that nil behaves as an empty value, and is enumerable. It is not the purest CS interpretation of nil but it makes it way easier. If someone is really concerned to check to see if something is nil there is still .nil?
When have you had errors like Oh this is String [][]{} vs Int[][]{}? That kind of static typing gets in your way more than it saves you. Pretty much all my errors that would be saved with type checking involve nil and that could be handled as I stated above.
I'm at best an intermediate-level rubyist, but I was quite surprised when more experienced people didn't recognize that operator after I started using it. It seems like one of the most significant upgrades.
I got really into it and started using it with operators, eg
> For instance calling `each` on `nil` should have the effect of calling it on an empty enumerable
And I thougt it was only me. I love Rails, but when I started learning it this was so confusing to me. Well, I understood what was happening, but I always expected an iteration or a method acting on nothing to simply return an empty result instead of an error.
1. So much faster. I'm getting super consistent 30ms response times on a heavily trafficked web app. AND I did this while completely ripping out a complicated layered caching system that I was using in last iteration of the app. It's just web app talking directly to postgres database, which sounded crazy to me, but actually works.
2. Socket/Channel goodness baked in. I built a real-time chat experience in about a day with Phoenix channels/presence. Makes it quite easy.
3. Less moving parts. Language level support for async tasks and in memory caching lets you do A LOT without installing/managing redis, queues, and other tools. For fancier use cases you still might want to go there, but for a lot of common tasks (send email after user registers for instance) you can go a long way with just Elixir. And you can keep related code together more easily because of this.
4. Easier testing and maintenance. Functional language by nature tends to lead to more modular, maintainable and testable code. Hard to appreciate this until you build a large-ish project with it, but I've found this to be very true.
I posted this same comment to /r/ruby when this article was posted there:
Having serious large scale full stack Rails and non-Rails (Py or Node) under my belt now, it has become ever so clear how productive Rails is and how much of that is the fact that Ruby actually has a f*ing standard library (directed at JS). So I'm not surprised by these numbers.
Then with gems like devise, filterrific, simple_form, cocoon, carrierwave, sidekiq, and activerecord-import I can whip together apps so quickly it just boggles my clients' minds. The ecosystem is deep, rich, documentation is good if not great and the language has several paths to getting some serious speed improvements behind it (Graal/Truffle/Substrate and JIT).
Implementing the simplest things in the node ecosystem sometimes feels like wading through molasses. I love ES6/7 but damn for 95% of projects today regardless of (anticipated) scale I'd choose Rails to start with and then split off just the things which need to be fast or fancy like Delayed Processing / MQs, ETL, any data science, etc.
I'm completely with you. Rails is still my go-to for short one-off projects that I need to build something FAST.
Hell, I even use it for quick n' dirty data analysis because working with Active Record is so easy. Rake import the data, then muck around with the Active Record models in Rails console. I honestly prefer this to working with Jupyter notebooks, unless I need graphing or something fancy out of sklearn.
"Rails can't scale" is a misnomer. Heroku and Github are RoR apps (or at least started there). At scale you might start pulling in some other services and technologies.
I enjoy programming with other languages but nothing beats Rails when it comes to getting a product out the door.
Last week I found out that a Rails app I built for a SAAS company many years ago is still running reliably and generating millions of dollars per year.
The painpoints I often run into with Ruby/Rails are concurrency and memory use. Both are addressable though.
There are lots of playlists on youtube with tutorial walkthroughs. I'd go look for someone's todo app on Github and compare it to a language you know. Then write a todo app. That'll give you the initial questions you need to keep learning.
I think stuff like that is hard to do in rails. Also I was trying to do instant messaging in web2py and gave up and just wrote a service in node which was like 10 lines with express/socket.io.
Pragmatically I think it may be easiest to write the main app in rails of similar and link to a separate bit of node for stuff like the above.
We do precisely none of that sort of thing. Our department's workload revolves around the shifting needs of a demanding media agency, who just wants pretty looking content that's easy to manage. Everything even remotely hard they use their own media talent for. What we do is perfectly suited for Rails.
For curious onlookers: true, one can "can whip together apps so quickly", as long as:
* Your code is empirically around ~1 KLOC
* You won't have to maintain it in the future
So yeah: if you're going to make a one-off-deploy-once-never-touch-again message board/blog app with Google Maps integration, choose Rails. Otherwise: don't bother.
Making Ruby/Rails maintainable at scale is a sisyphean task: it's possible, but at an enormous cost. This is why there are several attempts to bolt a type system onto Ruby, the most recent one being developed by Stripe [0].
I've no hard numbers, but the narrative "without Ruby my startup wouldn't last long enough to worry about engineering it the right way" sounds very very suspicious to me when talking about even remotely complex problem domains. Your speed will drop to zero in about 3 weeks from the start when you have to refactor some fundamental piece of code/data structure anyway, and then better hope you at least wrote some tests. And having to write tests essentially halves your dev speed anyway, so I really am not sure where this "prototyping speed" meme comes from.
as a counterpoint, i work at instacart, where we have rails apps (we broke our application into "macroservices" several years ago) each around ~50-200k LOC which we have maintained for 5+ years while growing exponentially (customer base) and not exponentially (engineering headcount :)
i've talked to other companies that have done similar things.
I've worked on 5+ years old Ruby projects having around 100KLOC (including tests), and adding a timestamp to an internal API that affects several other internal microservices (something that shouldn't take more than 15mins) takes a week of code reviews and writing tests.
As I said, I don't claim it's impossible to make Rails maintainable. Instacart is apparently a good example of how to do that.
"Otherwise: don't bother." is a pretty strong statement and i think in the distinct minority.
how much of your statement is driven by that one example? that seems like a broken process or a poorly designed system (orthogonal to rails) than anything else...
I'm not so sure about that. Even though the HN rating system shouldn't be abused to express dis/agreement it often is, and my comment seems to have more upvotes than downvotes so far.
> that seems like a broken process or a poorly designed system
I'm sorry, but saying that as long as your process isn't broken (whatever this means) and your system isn't poorly designed then Rails is maintainable seems to be a pretty weak argument. In a perfect world with perfect, non-changing requirements, no deadlines and understanding clients you can probably make Brainfuck maintainable :)
> I'm not so sure about that. Even though the HN rating system shouldn't be abused to express dis/agreement it often is, and my comment seems to have more upvotes than downvotes so far.
fwiw i voted you up because i strongly believe in constructive discussion around these things. i don't think you should take that as a signal that folks support this position.
> I'm sorry, but saying that as long as your process isn't broken...
i'm merely saying that from several shops i've worked at, including instacart, with many 10k+ lines of code rails codebases, i've never seen problems like what you've described and it sounds pathological for that specific application/company.
again my (and many others') point is that rails is absolutely maintainable, even at massive scale, and even in a world with ever-changing requirements, hard deadlines, and very loosely-understanding clients, and that all that takes is doing rails the "right way" (a comprehensive test suite, reasonable architectural design), and that it is still massively productive.
>I'm sorry, but saying that as long as your process isn't broken (whatever this means) and your system isn't poorly designed then Rails is maintainable seems to be a pretty weak argument
If you've got a dysfunctional team and poor design, the language/framework choice isn't gonna help you. There isn't a framework in the world that will save you from tight coupling, lack of styleguide, business logic scattered all over the place, poor test suites, or monoliths made by bootcamp graduates.
What does "at scale" mean? I ask because my last job was at a web host with 80,000ish paying customers. We had over 100k users of our web portal (built with Rails) which customers use to manage their sites. This was a business with over $100 million ARR around when I left last year. The user portal is the primary point of contact between the business and it's customers and we never had serious issues "scaling" Rails. It was a totally fine tool for the job.
I worked on a many years old and k*10⁵ LOC Ruby application, and it's fine.
Talking about 1 KLOC and future unmaintanability is nonsense.
In order to scale, Ruby applications need very high coverage. This has nothing to do with Ruby and/or Rails though; it's a requirement of all the dynamically typed languages.
There are certainly missing functionalities that at some point will cause a roadblock (currently, threading is immature), however again, no framework can support all the possible functionalities.
Having high test coverage (especially in dynamic languages) has been industry standard for years. I haven't worked at a place that accepts poorly covered PRs in a very long time.
>Coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage.
In case folks are wondering about what we mean by coverage...
>Coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage.
In case folks are wondering about what we mean by coverage...
> In order to scale, Ruby applications need very high coverage. This has nothing to do with Ruby and/or Rails though; it's a requirement of all the dynamically typed languages.
I don't think typed languages all get you away from this. You're gonna learn things that make you want to refactor things. Your standard typed Java app isn't going to get away without tests, there, since compile != correct for the vast majority of program designs.
You might be able to get "less obviously broken" for free - logic bugs but no 500 errors from unexpected exceptions, say - but is that so much better?
That is some very specific criticism to level with pretty limited evidence. Stripe might be building their own type system, as is Ruby 3.0, but plenty of apps much larger than your provided number operate perfectly.
For the record, I do think typing solves real problems for Ruby. Speaking in terms of pure productivity, it will be helpful to bring in developers who just are not experienced at working without a type system. The downside is I think most of those problems are primarily generated by inexperienced Ruby developers writing non-expressive code. Working on large code bases with Ruby is a very strange and awesome skill. The way you name things and build standards around methods/class creation ends up being a huge positive IMO.
yeah this is some nonsense. I'm at a highly successful startup serving 40,000 requests per minute on a rails app. We're starting to split out into services but that's purely from an organizational standpoint as it's becoming unwieldy for 60 developers to all work in the same code base.
Making Ruby/Rails maintainable at scale is a sisyphean task:
it's possible, but at an enormous cost
Disagree. I've worked at two companies now with teams of less than 6 maintaining rails apps that have handled billions in sales.
Rails can scale; the problem that Rails faces is that it is easy to get things going quickly, and lack of foresight or simple inexperience can create bombs of technical debt or scaling issues. For many years, Ruby was the lingua franca of 12-week bootcamp schools, and the code that that cohort of programmers made spanned the spectrum of quality, but it all went to production.
In other words, the problem with scaling Rails is not with the framework or with Ruby, but with the accessibility and ease of development making it easy for pernicious problems to enter the foundation of codebases.
Good ruby scales, bad ruby does not -- both exist.
Another major pain point was the constant dependency churn in the RubyGem ecosystem, but all of that noise seems to have moved on to NPM along with the hype and bootcamp curriculums.
I suspect companies using Rails are quietly making money and do not feel the need to migrate to the latest and greatest. Money making code does not get changed in my experience.
I've been out of the game for awhile now, and sure, I find it eminently believable that Rails is much more productive than Node-based things, but has nothing better than Rails established itself by now? I always found it to be great for, as you say, whipping together small apps for clients quickly, but not well targeted at big long-lived software.
I have been using Ruby on Rails for a large distributed systems (using Sidekiq) deployed across over 100+ servers.
Gems like 'bluepill' and 'god' have been instrumental in deploying and ensuring mission-critical processes like elasticsearch, and redis are always up. This system has been in production for over 4 years, and we're still cranking :)
Fair enough, that sounds similar to the system I maintained for a similar length of time. I came away thinking it was not great - error prone, expensive to run, and hard to keep running reliably - from which I developed the interest in better options that led me to ask the question in this thread. I guess as usual, YMMV.
While consulting I had several clients in the top 10k websites using Rails making millions and millions of dollars a year.
So, I guess I just fundamentally disagree on the 'big' portion of that statement, but also, I think apps are by their nature not long lived, so I think it is a false requirement of a web framework.
That said, I also have had work I've done in Rails still powering the same website almost 10 years on, cacm.acm.org
"Big" has lots of different definitions. I was referring to code size and domain complexity rather than scale and revenue. Your experience of "apps" not being long-lived doesn't match mine at all: I've never worked on a piece of software that was decommissioned after a short period of time. Or are you using the term "app" in a specific way? I wouldn't call most of the things I've worked on "apps"... We started working on the software that I was thinking of as "big" back in 2008 and from what I hear, it is still going strong (though pieces have been tactically carved out and implemented in different ways over the years).
I think you and I may just have worked on different kinds of things.
Well, if I had to choose Rails vs Laravel, I would go for rails.
Rails is faster than laravel; besides why would anyone use a rails clone in php?
Check rails vs laravel frameworks, this is fresh stuff:
https://www.techempower.com/benchmarks/#section=data-r16&hw=...
"Rails is still the most taught web framework in prominent coding boot camps."
This is not true. Rails is the most common back-end framework at coding bootcamps. But if you're trying to understand is happening to Rails, the biggest update is "Rails' model of serving HTML is dead/dying, and React took over a lot of Rails' old job". Bootcamps mostly teach JS now, for that same reason.
I've done twoa startups (2005-2006 & 2008-2014) with Rails (Rails <1.0-1.X && Rails 2.x-3.x) and we are now rewriting most of the software at my current company with Rails (5+) + React (for most things). We even went so far as to create our own framework with react, loosely based on how Rails does stuff called Gluestick (github gluestick). It lets us do native, web and mobile web with like 95% code reuse if you are good with web views.
When we were confronting the task of rewriting a large, undocumented, untested, msft db, and java (macro services) Rails was the easy part. Choosing a full fledged react app, with Rails as the api server was a harder decision, but based on who we had and what our immediate plans were it made sense. There is a decent argument now that just doing it all in Rails would of been faster, but the mobile part is going to be huge for us.
Finding senior rails devs is harder than it used to be though, hands-down. We converted a lot of django devs to rails and it's been a big win, according to them. "whalesalad" listed a lot of reasons why and I agree with all of those. We, at least in the past, at startups found Rails people to be more capable of full stack development and we needed that. But, that was probably just our experience in the 2009-2010 in the valley.
> Finding senior rails devs is harder than it used to be though, hands-down.
Money talks. I'm sure you can find someone in no time if you advertise $500k in compensation. Most employers balk at that rate, so most of the talent take the freelance/consulting route.
I read/skimmed all comments, lot of people complaining about RoR and the big ball of mud that it creates. Trying to be positive, and some days is really hard, anyone has any recommendation to get out of it? I wish I could start small, but got spaghetti code in my hands, when I think I have the tail or head, there's more under.
One of the biggest telltales about the decline of anything is articles related to it claiming it is not in decline despite general public perception.
Sure, Ruby is amazing and sure Ruby on Rails is a great framework. But Ruby stalled right there -- RoR has been churning out regular updates and is still making strides in right direction, but look at Python and what happened with its community: the community didn't just stop at Django or Flask -- it went ahead in multiple domains and created useful libraries. The end result is, Python is used for far many types of projects (be it enterprise or robotics) where as Ruby is synonymous with only the Rails framework.
This is why Python has eaten up any potential share that could have gone over to Ruby and if that is not all, the Academics in Universities around the World are starting to take Python seriously and are teaching it (NOT RUBY!!) and if there was any space left for those grumpy Java Developers at the Enterprise level, well emergence of Spring and Spring Boot has swayed them back into Java's fold.
Node.js is taking as much mindshare from Ruby as Python, I'd say. Pivotal's support for Kotlin in Spring Boot 2 is even more likely to keep grumpy Java devs inside the JVM world. It makes me mad that Ruby isn't competing with Python which is an inferior language. With all the promised speed boosts around the corner I just think it's all too late. Python and Node have already won. Python:Ruby by many metrics is about 4.5:1 and Node:Rails 3:1.
252 comments
[ 4.0 ms ] story [ 251 ms ] threadThis means you have to go away and do some research to get your stack running.
This was enough to put me off.
persistance: spring-data, the JPA/Hibernate based library for SQL access appears to be very opinionated and is very simple to fully understand. I have never used MongoDB, but spring-data-mongodb is probably of equal quality.
DB migrations: What do you mean?
Support for Groovy Templates is legacy and not as equal as the other choices. Groovy is now Apache Groovy, and on the decline.
https://en.m.wiktionary.org/wiki/RTFA
You can use the DI and config management container spring-core by itself. There are actually THREE web-frameworks: spring-webflux, spring-web and spring-web-mvc. Webflux is the new framework for "reactive HTTP", spring-web contains the conventional web/REST-server capabilities and spring-web-mvc offers mvc functionality with templates and depends on spring-web.
Correct me if I am wrong.
You are still missing Turbolinks, the rails console, JPA is nowhere as good as Active Record, rails scaffolding, Rspec, Devise, then you need to setup migrations... I could add a lot of other items, but no it's nowhere near rails yet. I've never found anything approaching rails for the speed of coding (but not the speed of execution unfortunately :/).
Rails templates is a very very small part of what makes it so quick to write code.
I think I agree about migrations. Flyway is useful but not as clean or easy as ActiveRecord and I think that depends on Ruby's dynamic nature so it would be hard to replicate.
You surely meant to write that the other way round.
Edit: JPA is usable yes, most ORM nowadays are quite good anyway, it's just that Active Record is still always one step above, it's a pleasure to work with.
Whether that means the Job Providers in my sample simply aren't paying enough, Rails devs are sick of maintaining legacy Rails apps, or a combination of both, it seems like everyone I know who spent years working nearly exclusively with Ruby has now moved on to Go, Elixir, or Node.
At the end of the day though, the couple of jobs I did investigate were really pretty shitty. One company asked me to do a coding challenge... I said, "Sure, about how long will it take me?" "I dont know." "What's the subject matter?" "I don't know." "How will you grade the test?" "I dont know." "When do you need it?" "Thursday." "So the only thing you know about this test is it has to be done right now?"
They cant find talent and the company needs a budget programmer to clean up (legacy) problems.
I don't even entertain those interviews anymore. All of the other Ruby work available is more interesting.
It was nuts. Never seen anything like it.
It actually makes sense to me. There are a lot of shops with legacy Rails apps, and they'll use Rails for new code too, because it's worked well and they don't need to do the shiny and new.
Some things get better with age. There's an advantage too, not being on the brand-spanking latest version of something – you get to let everyone else filter out the crap before it winds up in your production environments.
A few examples from recent Rails releases,
(1) Turbolinks is one thing that was widely regarded as absolute crap when it was released, but now I think it's a pretty non-controversial way for Rails developers to give their users a single-page experience without necessarily diving headfirst into JavaScript.
(2) If you rebuilt all of your Rails 5 apps to use the shiny new Encrypted Secrets in 5.1, ... surprise! 5.2 deprecates secrets in favor of the newer Encrypted Credentials feature.
I'm not saying there aren't good ideas in newer frameworks, but how many mature frameworks are still in active development? (Make a list) ... and how many of those would you actually like to use?
Though they may be more popular, I'm personally not seeing lots of people rallying behind Java and .NET, or making outrageous claims like that those platforms prioritize developer happiness. Rails developers like using rails.
I agree that Rails today is a mature platform and very good at what it does: server-side rendered web applications with a relational database backend.
Otherwise, the most prolific programmers I know personally that used Rails, have all moved onto other platforms at new jobs or for their new development projects. Mostly Go, modern JS frameworks (many of them), Python, and Kotlin.
$ grep -i 'php' hn.txt | wc -l 8
$ grep -i 'python' hn.txt | wc -l 50
$ grep -i 'react' hn.txt | wc -l 71
$ grep -i 'java ' hn.txt | wc -l 6
$ grep -i 'java,' hn.txt | wc -l 8
grep -i 'javascript' hn.txt | grep -v 'javascript:void' | wc -l 35
^^ thanks busterarm
$ grep -i 'objective' hn.txt | wc -l 2
$ grep -i 'object-c' hn.txt | wc -l 0
$ grep -i 'object' hn.txt | wc -l 4
$ grep -i 'haskell' hn.txt | wc -l 7
$ grep -i 'rails' hn.txt | wc -l
24 <<<<<<<
$ grep -i 'mongo' hn.txt | wc -l 10
$ grep -i 'mean' hn.txt | wc -l 21
$ grep -i 'lamp' hn.txt | wc -l
$ grep -i 'docker' hn.txt | wc -l 19
$ grep -i 'aws' hn.txt | wc -l 3
$ grep -i 'devops' hn.txt | wc -l 28
$ grep -i 'android' hn.txt | wc -l 18
$ grep -i 'ios' hn.txt | wc -l 21
$
There.
$ grep -i 'ruby' hn.txt | wc -l 25
$ grep -i 'ruby' hn.txt | grep -v 'rails' | wc -l 22
Most of my projects, were not web apps. ETL type things. When it was time for me to develop something with a web front-end, we still did not use Rails. Sinatra and (pick any template language off the shelf.)
Ruby and Rails are both large skills that take lots of experience and maybe even training to become competent at using. When hiring junior developers, I think based on my experience at least, a hiring manager would do well to defer them from learning Rails until the latest possible moment. Better to learn one major skill at a time.
(Then again most HN readers are probably not trying to get hired as a junior developer anywhere.)
Ruby on Rails isn’t a major skill that takes lots of experience. It takes experience to master it, but a junior dev could easily become productive in the framework almost instantly.
I don't see this your way. Junior devs are immediately productive? What kind of fantasy land is this? Junior devs need to walk before they can run. Everyone should know enough Ruby to parse them some CSV, if that's going to be part of the stack.
Then, they can pick up a Gem library for parsing CSV and never do that again. But having the experience of working around the edge cases and knowing enough core language features to know what parts are easy without any gems, is going to make you better able to spot "using the gem wrong," or even "the gem is doing it wrong" (which also totally happens!)
In my company, CSV was something we needed to have as a core competency (customers sending us data files, and bad data files, all of the time, ETL pipeline shaping them up and making them loadable into our custom schema...) and there were just two of us devs, so nobody's got time for pair programming. You're honestly going to ask a junior developer to start with "rails new" and then somehow trust what they produced, putting it on the internet?
A junior dev could easily become productive with a handful of gems too, and practically understand every part of what they did. That's the point. You don't keep all gems out of the picture forever, just long enough to learn what hard problems look like without having them solved for you.
If I'm a hiring manager and you're my junior dev, I want to start by seeing how you think, and I want to see you thinking with first principles so I can tell you where you're going wrong. I'll help you figure out the hard parts if you're struggling with something. But I do want you to struggle with those parts a bit, and I want to see it. If 95% of the work is done for you by a gem, then I might as well let you ask Rubocop and Brakeman what else you're doing wrong, and there's probably no point in having me here at all.
For one, CSV is part of the standard library. just "require 'csv'". No gems required.
Two, nobody without a really good reason should try implementing their own CSV parse library. RFC4180 doesn't even remotely reflect reality. It's several hundred lines of code to do right (about ~700 in Ruby currently, down from a bit over 2000 in earlier implementations). I hope they're good at RegExp.
Seven years ago, at the time I was starting the job I mentioned, this was not a thing. The gem was called 'fastercsv' and it was made a standard library in 1.9 – we were mostly working on 1.8.7 when I started, and 1.9.2 when I did the CSV implementation(s). It was a brand new standard library and it did not do all things for all people. Almost like they just picked a pretty good one off the shelf!
It still does not do all things for all people... today, you also have other competing implementations, say 'smartercsv' with most recent commit activity 4 days ago.
It's an implementation of CSV. If you know your CSV is pristine, you can parse it in a lot less than 700 lines. We had a utility that would output "pristine CSV" dumped out from whatever garbage the client sent us, in whatever Excel or other columnular format, and we had another utility that would only accept this "pristine" format. Sometimes things went wrong. More often than you expect maybe, and we'd fix them ... or sometimes we'd get the clients to fix their shitty files, and leave it the way we thought it should work.
Depending on what you need to do with the CSV, or how many ways you're planning on handling CSV, one could argue that you will be better served by a minimal implementation that you know exactly what it does and does not do, because you told it what to do. If it's making a mistake, that's yours. You own it! That's another boon, when the quality of the data is not guaranteed.
The standard library I remember has some great idiosyncrasies that you'll know if you've ever used it to work on bad CSV. So do all of the CSV libraries. I don't work on CSV anymore and my memory of it is not so good, so I can't tell you the war stories in perfect detail, but... suffice it to say there are several CSV libraries with different strengths and weaknesses.
We mixed and matched parts that served the specific need we had at any given time and place, until I was a total CSV expert. It was not a perfect ecosystem, and 7 years ago `require 'csv'` was simply not a thing. You had to pick one off the shelf, or roll your own. I'm really not sure what's different today. (Probably not much! Parsing CSV is not a core competency of either Ruby core team, or Rails.) We had our reasons though, to be sure.
The one I remember in particular was a bit that converted your CSV rows and columns and then turned them into arrays of hashes, or converted arrays of hashes into CSV, and then another piece that expected the hashes to be identically ordered. If you used all of the standard pieces, this worked great! I think it took multiple libraries to do this, actually, and some of them were not so standard.
But wait... hash keys are not ordered at all, and that's a property of hashes that is standard and well known. But in some cases the hashes do come back with their keys in a particular, consistent order, and in a perfect walled-garden use of the particular CSV library configuration that was expected by the people that wrote this crap, yeah everything worked.
Well, everything worked until you do get a CSV with an uneven number of columns in some of the rows.
Like I said, CSV was supposed to be a core competency for us. We would not have been successful if we just picked one CSV library and stuck with it. Or, that CSV library would have got a lot of free labor from us, I'm not really sure which. I'm not sure which is worse, either. I don't do that anymore though.
> Ruby Gem for smarter importing of CSV Files as Array(s) of Hashes, with optional features for processing large files in parallel, embedded comments, unusual field- and record-separators, flexible mapping of CSV-headers to Hash-keys
Hypothetically speaking, I don't know how you get around the fact that Ruby has way more code in it than any of the gems you'll want to pull in, but ignoring that, what's easier... getting a new gem certified, or writing just the parts you need and putting them through the normal review process?
The answer is not going to be the same each time you ask it.
Rails isn't very complex even now, especially if you separate the front end (a JS SPA) and the backend (an API Rails project). You can develop two different projects in two different repositories and forget all the asset pipeline. However you must know the frontend really well or the sum of the two projects is going to be much tougher than vanilla Rails views.
> I've been doing web development since 1994
> some CGI programs in C, CGI.pm (Perl), Struts (Java) and occasional PHP
I said junior developer, didn't I? :) and also mentioned that this was my first ("permanent") job (after college)?
Getting to know what's in a web framework, is exactly the learning curve I'm talking about. People complain about magic in Rails. I just wrote an ERB view "index.html.erb" and declared an empty method "index" in my controller. Add in a route definition, and now somehow they are all connected.
What is actually happening? Why does that even work?
If you've never used any web framework before, that's inscrutable magic. If you know what a correctly designed controller method looks like (it should maybe fetch some values, then render a view... and probably nothing else) then it's obvious. Getting over that hurdle is ... definitely not the kind of shit my first boss hired me to do. I'll say again, most of my assignments for the first year had nothing to do with "on a web page."
My stance on this (and how I did it as a junior) is to have someone implement a toy implementation of Active Record's basic relationships using Ruby meta-programming and to implement a basic request-response server. This is part of the curriculum of some bootcamps even.
If your junior developer can't do this, they shouldn't be touching your production Rails application. Your immediate goal on hiring them is to train them to be able to do this.
Having read the whole comment, I'd say that is spot on. I knew some SQL, but didn't start with Active Record. We used SQL client libraries to connect to our SQL database, which didn't have a Rails app built onto it until well into my second year.
I did all of that, except for the implementing ActiveRecord and the meta-programming. So I didn't really do any of that. We didn't have a production Rails app until it was clear that I was gaining proficiency, and I'd be sticking around long enough to get a handle on how to manage it. (I didn't write most of it. And we avoided metaprogramming pretty much at all costs.)
We had a production Microsoft Access app (no really, VBS in Access 2000), with a MySQL server on the backend, along with tons of perl, bash, and ruby to glue the important parts together. There was a Java app that handled the web side of things. I don't think I'll ever work in a place like that again! But it was the path I took, and now I work on pretty much exclusively Rails.
They may be using it, but they didn't mention it. As for Ruby work that I've done, infrastructure automation, ETL, systems programming and the occasional Jekyll or Sinatra project.
Since grep only emits the first match on a given line, this won't count properly if multiple keywords appear on one line.
Why did you search for "mean"?
Edit: here's another approach that splits the output into words first so that we can count multiple keywords on one line, along with a couple tweaks to the pattern to eliminate some false positives:
Another issue: this only grabs the first page of comments.If you or anyone wants to run this query on the full comment set, email us (hn@ycombinator.com) and we'll turn pagination off while you do that.
The vast amount of projects and internal tools out there don't need to be "webscale" or process millions of requests a minute.
They are dwarfed by most media companies etc. Github's website sees far less than 1% of Facebook's traffic for example. On the other hand they have almost 30 million users so they are not exactly tiny.
Rails allows companies to grow quickly and focus on attracting users and delivering business value at the sacrifice of a re-write or complexity of managing rails and performance issues down the road.
If you need raw single process performance especially with parallelism then you probably should look beyond ruby. But the whole Rails doesn’t scale because Twitter meme is asinine.
Really, the vast majority of web apps built today will see hundreds of requests per minute.
Still, Github and Shopify have proven that Rails can scale to hundreds of thousands of requests per second. Which is a great number.
Said that, if my goal was to build an app with a simple set of features that don't change often, and that will serve 100 million users, where none of them is paying user, I would probably not choose Rails.
What would you choose in this case? I'm also a little confused where the user "paying" comes in. Is that in terms of the importance of that specific type of interaction or the concern of friction scaring of "free" users?
I can attest that the demand of Rails engineers is still large - why wouldn't it be? It isn't like the 15+ years of Rails code in the world just converted itself to another language.
But I will tell you one trend that I find very interesting and did not think I'd ever see: The lead-in for a full stack or even a backend position is the React/Redux part, not the backend technology.
Very often a position will be React + whatever you can do on the backend. For years, it was quite the opposite. You wanted to hire a Rails engineer who would dabble on the frontend where need be.
A lot companies I work will pay handsomely for a React developer, and they're quite sure they can teach the React developer whatever backend they use (usually Rails, Django, Flask, Sinatra -- in that order).
This kind of culture has always been around since way before Rails; unfortunately I've never learned how to turn it around. The team no longer has a database engineer :).
I'm especially interested as someone who's growing our own engineering teams and laser focused on getting people who can really crush it on the backend out of the gate (because I feel like we can teach the frontend pretty well).
There is no tech stack in the world that will get you shipped and proving your business faster than RoR.
You'll fly through it.
1. Web development
2. Ruby/Ruby on Rails
3. Test Driven Develepment
If you're new to programming, start with something else. Trying to learn all three of these at the same time is not a recipe for success. Source: personal experience watching 100% of former mentees fail to make any progress with this tutorial.
Rails is not really for new learners in my opinion, since the famous Rails magic can obscure what's happening under the hood, and the framework itself has grown and evolved over the years. Nodejs is better for new devs in my opinion, but Rails really shines once you have the basics and a couple of small apps under your belt.
I'll take django for simplicity any day and run React from it's templates.
First I'd start with creating the database in Postgres. Create tables to hold data and any views needed to represent joined tables for convenience. Once that's settled, the express server comes next to create a CRUD API to work with the data and handle user authentication and authorization. This is dead simple and once it works there's little you need to touch. The database handles any data dependent business logic.
By this point you can make API calls and use the application through any REST client.
So now I just need to create a React client to consume the API and give a great user experience. Don't need Redux. Grab React-Router and a couple packages for UI components and you'll be up and running with the MVP in no time. Checkmate.
Not sure how you're beating Rails or Django at this, unless you're a 10X developer going against a normal one. For that matter, I'm willing to bet an experienced Drupal developer using drush would be faster setting things up.
Node will prob take longer if you're taking time to try out [new hotness lib of the day], though.
If so, would be cool to post it here to get a discussion going on it: https://hackerforums.co/show-hf-f7/
- make it a web app so the team can run tests
- add some charts
- keep it secure
- umpteen new semi related features
Would have been easier to just start at "rails new".
I think the surprising thing about this comment is that you actually developed using Django for all those years, and you still prefer RoR.
The vast majority of people on the web that comment invariably say they are pretty much the same and it depends on whether you know ruby or python better.
So people who already use python for finance or data science pick django.
I saw a study (old now, from the early days) that claimed they were about the same but that the admin page on django cut dev time by some %.
This is the first I've heard a long time django user say that rails was faster to develop and not about the same. Can you elaborate on why?
The efficiency you gain using Django on the admin side is lost with every other part of your app.
1. Active Record is superior to the Django ORM (which is still good). Being able to set scopes and do a lot of conveniences right on the model without needing to extend/override a manager is great. Being able to connect to an existing database for free is also great.
2. Controllers are great. The way they can be nested and composed is also powerful. Being able to mount a resource at any level in the hierarchy either alongside or beneath (or both!) is hugely powerful. I can state concerns at each level and 'forget about it' deeper. Eg, if my controller A needs to ensure a given user has access to that resource and all children, I can do that at level A and trust its handled so in the controller for level B or C (deeper layers) I am not worried about it.
2b. The syntactic sugar to add authentication/authorization/guards in controllers is incredible. `before_request :ensure_access`
3. Active Support is phenomenal.
4. You can build very elegant, flexible and powerful RESTful and RESTish API's REALLY quickly. And not just naive stuff that you can do with something like 10 lines of Flask ... but really foundational stuff that allows you to hit the ground running and then build on it layering in more security and functionality.
5. Polymorphic/STI power with Active Record. AR gives you so much more freedom to do polymorphism and bend your database to model your data as you see fit. With Django you are oftentimes stuck doing things their way. For instance if I want multiple classes to share a single database and get instantiated based on a 'type' field ... that is trivial in Rails and difficult with Django. Even moreso if you want to do relationships with those polymorphic objects.
6. Finally... the most important thing... it's sometimes difficult to model your domain/business inside of Django and by extension the Django admin tool. Let's say you have a friendship between two people. How do you create that in Django? You might have a many-to-many which means there is gonna be a join table somewhere. Do you ask your customer support folks to go into the FriendRelationship UI and 'create an object' connecting person_a to person_b and ensuring to choose the correct relationship type from the enum? Worse, you have too many users so you cant use a select field or search box without plugins and are left with two input boxes that expect a valid person ID to the FK. So now customer support needs a workflow for managing this data. I'd rather build my own "manage friends" page that will take me all of an hour and provide an experience modeled after the problem/task not the database.
Or let's say you have a more intricate transactional type of process where an object needs to be created with 3 or 4 child objects. The parent needs to be created first, then the children need to be created and linked to that parent. Sure, you can do this in the Django admin flow but at that point you might as well be writing `INSERT INTO...` queries. Again, I'd rather build my own tool. I will save SO much time building the API and the business logic for my program that I'll be afforded the time to build an administrative tool that is focused on tasks specific to my team/business not just a graphical representation of my SQL tables.
I could go on and on and on. I was a Django zealot for a long time and refused to drink the kool-aid. I bought into the hype from the community and trusted folks when they said "rails is magic, I don't like it" but that is a horribly naive approach and frankly I only hear it from less experienced engineers. When you get acclimated to Rails you realize there is no magic, it's all just straightforward code written by people who truly want to get things done. Perhaps I just align more with the Ruby way of thinking. Django folks tend to pride themselves o...
You stick a check in the update controller for Friendship to destroy the object unless it has two members (or not to create without two) and additionally you add a "validates_numericality_of :friends, on: [:create, :destroy]" check on the model itself.
When someone "friends" another user, you create a new Friendship with both users as members. It's automatically bidirectional (but you probably want to add some approval logic in here, which is still pretty easy).
The manage friends page discussed is just a collection of all of the Friendships of which you are a member. You can use either update or destroy to remove you from membership, because now either will achieve the same thing.
It's funny hearing this because I was under the impression one of Django's core principles was to avoid boilerplate.
Like you, I've worked a ton in Rails and Django, but I started with Rails and always find Django work to be a slog -- particularly when it comes to environment configuration and administration. And the documentation for when you need to muck around under the hood is really not great.
And, invariably every Django application I've come across has tons of boilerplate.
I discovered it recently, and it has been great to be able to use various Python NLP libraries without having to learn a new stdlib, deployment stack, etc.
[1] https://github.com/mrkn/pycall.rb
PHP and the laravel framework will be quicker to develop and faster to ship and perform more requests per second.
JS - Node/ Vue/react base provide one environment which can speed up development.
Still fast compared to Django, java, asp, go, perl, etc
Still, it's easier to code a backend in Rails than in Phoenix (done that) or Django (inherited one). Both have extra layers that Rails proved to be unnecessary until the business scales to levels that very few companies reach. And if it doesn't, any MVP in any language can keep running fine for years. We can start debating about tradeoffs and premature optimizations but I don't remember any unicorn to shut down because it started with Rails (or PHP, hi Facebook!) and couldn't cope with the load. It's so much more about marketing and execution than technology.
It's possible that for Scala development it is a fairly good option, and some of the pieces like the typesafe config library are pretty nice, but at this point we consider play to be more like a curse word representing incompatible inflexible garbage.
In any case, I'm with you in that some of the changes between major versions they did were painful, especially if the code was structured in certain ways.
If I had to create a new API from zero, I'd go with Rails.
Is there any competition here? I could be unfamiliar with other solutions, but I thought the purpose of using JS was to eliminate re-writing code in multiple front end languages.
You can't blame Ruby for speed and talk about Cordova just after, it's a bit ironic... Cordova is one of the slowest cross-platform framework I know and that's a big reason the adoption is not going that well.
Yes. Building a responsive web application.
https://m.signalvnoise.com/program-to-where-the-performance-...
Not to be pedantic, but I worked on Rails projects in 2006 and 2007, and had probably heard of it just a bit before that. This was during the initial Web 2 boom. I would not have thought that Rails was created much earlier than that, since I usually keep some track of at least major tech developments (although could be wrong, of course - I could have missed reading about it when it was created, or only first read about it after it became a bit popular). So anyway, I googled, and the Wikipedia article for Rails says:
>Initial release: 13 December 2005; 12 years ago[1]
Haven't used it lately, but I do keep reading that it is very mature and productive, as you say.
But anyway. A long time.
I had a customer with a full stack JavaScript application, coded when Angular 1 was all the rage. The development stopped, the original contractors moved to other customers. The customer wanted to resume development but after one year they're still having a very hard time finding somebody to work with such an ancient technological stack. Task one would be porting it to whatever is current today and probably rewrite substantial parts of it along the way. My bet is that either they'll spend nearly as much as they did years ago or let it die.
On the other side I've got a customer which started with a Rails 2 application in 2011 and ported it with not much pain to new versions of the framework. The next one will be the jump from 4.2 to 5.2.
The of course, the js ecosystem being what is it, everything changes. Stuff are not compatible anymore, docs disapear, new things are hot.
Mean while I have a django 1.4 project we migrated to 1.8 last year. The author was not a great dev. No tests. No docs. But it's a very stable stack, with lots of tutorials and a well integrated and compatible ecosystem. It was work, but not remotly a rewrite, and any python dev could have done it.
The current JS state of things, bith technological and cultural, leans to disposable projects.
The only successful JS projects i witnessed are ones from great teams. But the world is not made of mostly 10x dev.
I've worked with large and small organizations whose whole business ecosystem is built on Rails.
Including some very large publicly traded companies.
Sure things change - hashrockets are out for example - and I have regexed the codebase a few times, but the core business and presentation logic has stayed the same, and the process has been fairly painless, even when skipping a version now and then.
At this point I have a strong aversion to starting any product using a dynamically-typed language (regardless of framework). The initial speed and ease of development is repaid 10x later on in sheer engineering pain (if you're lucky enough to be successful, that is).
The only way to adress (but not eliminate, since it's impossible) technical debt is to refractor mercilessly and constantly. And then there is some merit to static type advertisement - as the tools and techniques to safely refractor are both more feasible and more available for these environments.
Hark! A counterexample has arrived! I spent a bunch of years creating and maintaining big Rails applications. I've spent the last couple years on a bigger application in Java. I didn't drink any kool-aid, I just think Java is a better tool for this. C# and other things may be even better; the key is the ability to write static analysis tooling, which includes, but is not limited to, a compiler's type-checking analysis. It's not that a language with strong static analysis support saves you from creating a mess, it's that it makes it easier and much less risky to clean up that mess over time.
I agree with everything in your second paragraph, and would emphasize the risk aspect of refactoring a big application without good static analysis tools. After the first few spooky-action-at-a-distance prod breakages due to refactoring, it becomes hard to argue for a merciless and constant refactoring culture, and much easier to become the grizzled veteran who is a risk averse gatekeeper discouraging major refactoring in code reviews (this was me).
That and: You don't (or at least shouldn't) write a big application anymore. The only other thing (other than horizontal scaling, that is) that microservice design makes easier is exactly code maintainance / refactoring. The practices around it have matured enough.
On the other topic: I've spent last year or so writing mostly JavaScript, and have moved to VS Code as my primary IDE. I'm pretty happy (was doing Java/Python before that, and PHP/Python before that, and some embedded stuff before that).
The truth is that a good tool (and VS Code is one hell of a tool) makes working in a dynamic language very usable. VSCode static analysis tools make my JS experience better than my previous NetBeans Java experience, all things considered.
And I'm now dabbling with TypeScript to see how that goes. I quite like the idea of "just enough typing" and I think type-hinting rather than static typing is the way forward in this networked future. It's simply that these JSON-ed distributed environment people work in now will make static typing languages frustratingly un-agile for large majority of use-cases.
I've worked with large rails, django, and node apps, and none of them have felt particularly enjoyable to work with from a feature development standpoint once a certain scale is achieved. This doesn't feel like a rails-specific problem to me, but that's just based on my experience.
You can architect clean software in any language. What happens is this: you learn a new framework (or sometimes learn a new framework AND the corresponding language it is build in). You don't know what is idiomatic. You haven't made mistakes yet. You're making progress on your idea and getting shit done though, so it doesn't matter. Long story short: you don't know any better. Hindsight is 20/20!
Next time around you try something new and blame your old woes on the framework. This time around you've learned a thing or two about how to properly organize your code. You've been bitten by a third party tool that stopped being maintained. You've grown and learned and become more wise. But... you still blame your past issues on the old framework.
At some point you've been doing this for decades and you start to learn about abstract patterns that are not coupled to frameworks: service-oriented design, domain-driven design, CQRS (command driven systems), event buses and event systems, clean architecture, separation of concerns, SOLID principles, etc... ONCE you are at that point, you will begin to realize that NONE of the frameworks are going to solve these issues and NONE of them are more or less prone to causing tech debt.
Long story short: keep building software and focus on principles not frameworks. Read up on SOLID. It just takes time to get better and to start building things that don't encourage debt.
Another thing to note: tech debt is not bad. People throw that term around all the time and use it as a proxy for "messy code". Nothing in life is free. Everything is a balance. Perfectly architected software vs move fast and prove the business and make a profit? Pick one. You're going to acquire some amount of tech debt along the way. It's like real debt... sometimes you gotta accrue monetary debt to make progress elsewhere.
Parent is definitely right, projects that are "designed right from the beginning" do not exist in reality. Everything has unknowns in the future, and it is better to be flexible and adapt the code base to them as they come rather than trying to plan everything out from day 1. Static typing does help with these adaptations, but it doesn't compensate for a lack of diligence in keeping the code clean as the software grows.
I'm not sure Ruby, Python, Javascript, etc. were really designed for large scale development (although people use them for that). I think this is the primary reason so many people complain about technical debt, hitting the wall/limit, needing to refactor, etc. And looking for another language. Their tools just were not meant to scale that large.
"Go was deliberately designed from the start to support large scale programs implemented by hundreds or thousands of different programmers. Those kinds of programs are written at Google, and Go was designed to be used to write programs at Google." - Ian Lance Taylor
More from Ian here - https://www.quora.com/Will-the-Golang-code-become-unmaintain...
Yeah, that's basically what invalidates the assertion. There's no language or framework that guards against the complexity of a large code base. Period.
Something that uses a statically typed language?
Don't pin this on ROR. I have seen absolutely atrocious Django codebases, Clojure projects, etc...
Types do not solve this problem either. If you think static types prevent 'tech debt' you're delusional.
Good architecture can be had across the entire spectrum of tools and frameworks.
I need
* Migrations
* Models with validations
* Views (prefereably statically typed)
* Controllers with built in routing and type safe routing methods.
* Static type checking.
* Great package management.
* Deploy to Heroku
I'm looking at https://luckyframework.org/ and it's looking very good. Using crystal as a type safe ruby.
https://github.com/aspnet/home
Linux/OSX works just fine.
https://users.rust-lang.org/t/how-not-to-use-unsafe-code/181...
I'll probably try it out when they eventually add Windows support, but if Ruby and Git are anything to go by, what starts out as second class always will be.
I'm currently using Rust, largely because `cargo` solves so many headaches, but I would prefer a garbage-collected language for most uses.
You can also go with a Docker+mounted FS, which'll let you run the code in the container, but edit the code with whatever.
Hell, I even do this on my mac so I don't have to worry about the rest of the environment setup.
Method chains are a trap in Rails and will always lead to NoMethodError sadness.
Edit: yep https://news.ycombinator.com/item?id=17217815
I've been programming in Ruby for 10 years and I have to say after writing Clojure for a bit I really enjoy the fact that nil behaves as an empty value, and is enumerable. It is not the purest CS interpretation of nil but it makes it way easier. If someone is really concerned to check to see if something is nil there is still .nil?
When have you had errors like Oh this is String [][]{} vs Int[][]{}? That kind of static typing gets in your way more than it saves you. Pretty much all my errors that would be saved with type checking involve nil and that could be handled as I stated above.
I got really into it and started using it with operators, eg
And I thougt it was only me. I love Rails, but when I started learning it this was so confusing to me. Well, I understood what was happening, but I always expected an iteration or a method acting on nothing to simply return an empty result instead of an error.
http://phoenixframework.org/
1. So much faster. I'm getting super consistent 30ms response times on a heavily trafficked web app. AND I did this while completely ripping out a complicated layered caching system that I was using in last iteration of the app. It's just web app talking directly to postgres database, which sounded crazy to me, but actually works.
2. Socket/Channel goodness baked in. I built a real-time chat experience in about a day with Phoenix channels/presence. Makes it quite easy.
3. Less moving parts. Language level support for async tasks and in memory caching lets you do A LOT without installing/managing redis, queues, and other tools. For fancier use cases you still might want to go there, but for a lot of common tasks (send email after user registers for instance) you can go a long way with just Elixir. And you can keep related code together more easily because of this.
4. Easier testing and maintenance. Functional language by nature tends to lead to more modular, maintainable and testable code. Hard to appreciate this until you build a large-ish project with it, but I've found this to be very true.
https://www.asp.net/mvc
Having serious large scale full stack Rails and non-Rails (Py or Node) under my belt now, it has become ever so clear how productive Rails is and how much of that is the fact that Ruby actually has a f*ing standard library (directed at JS). So I'm not surprised by these numbers.
Then with gems like devise, filterrific, simple_form, cocoon, carrierwave, sidekiq, and activerecord-import I can whip together apps so quickly it just boggles my clients' minds. The ecosystem is deep, rich, documentation is good if not great and the language has several paths to getting some serious speed improvements behind it (Graal/Truffle/Substrate and JIT).
Implementing the simplest things in the node ecosystem sometimes feels like wading through molasses. I love ES6/7 but damn for 95% of projects today regardless of (anticipated) scale I'd choose Rails to start with and then split off just the things which need to be fast or fancy like Delayed Processing / MQs, ETL, any data science, etc.
Hell, I even use it for quick n' dirty data analysis because working with Active Record is so easy. Rake import the data, then muck around with the Active Record models in Rails console. I honestly prefer this to working with Jupyter notebooks, unless I need graphing or something fancy out of sklearn.
"Rails can't scale" is a misnomer. Heroku and Github are RoR apps (or at least started there). At scale you might start pulling in some other services and technologies.
I enjoy programming with other languages but nothing beats Rails when it comes to getting a product out the door.
Last week I found out that a Rails app I built for a SAAS company many years ago is still running reliably and generating millions of dollars per year.
The painpoints I often run into with Ruby/Rails are concurrency and memory use. Both are addressable though.
https://www.railstutorial.org/
Like for example I had a look at hackthon starters in rails, django and node and the node one has this cool dashboard https://hackathon-starter-2018.herokuapp.com/status
I think stuff like that is hard to do in rails. Also I was trying to do instant messaging in web2py and gave up and just wrote a service in node which was like 10 lines with express/socket.io.
Pragmatically I think it may be easiest to write the main app in rails of similar and link to a separate bit of node for stuff like the above.
* Your code is empirically around ~1 KLOC
* You won't have to maintain it in the future
So yeah: if you're going to make a one-off-deploy-once-never-touch-again message board/blog app with Google Maps integration, choose Rails. Otherwise: don't bother.
Making Ruby/Rails maintainable at scale is a sisyphean task: it's possible, but at an enormous cost. This is why there are several attempts to bolt a type system onto Ruby, the most recent one being developed by Stripe [0].
I've no hard numbers, but the narrative "without Ruby my startup wouldn't last long enough to worry about engineering it the right way" sounds very very suspicious to me when talking about even remotely complex problem domains. Your speed will drop to zero in about 3 weeks from the start when you have to refactor some fundamental piece of code/data structure anyway, and then better hope you at least wrote some tests. And having to write tests essentially halves your dev speed anyway, so I really am not sure where this "prototyping speed" meme comes from.
[0] https://news.ycombinator.com/item?id=17217815
i've talked to other companies that have done similar things.
where are you getting any of this from?
I've worked on 5+ years old Ruby projects having around 100KLOC (including tests), and adding a timestamp to an internal API that affects several other internal microservices (something that shouldn't take more than 15mins) takes a week of code reviews and writing tests.
As I said, I don't claim it's impossible to make Rails maintainable. Instacart is apparently a good example of how to do that.
how much of your statement is driven by that one example? that seems like a broken process or a poorly designed system (orthogonal to rails) than anything else...
I'm not so sure about that. Even though the HN rating system shouldn't be abused to express dis/agreement it often is, and my comment seems to have more upvotes than downvotes so far.
> that seems like a broken process or a poorly designed system
I'm sorry, but saying that as long as your process isn't broken (whatever this means) and your system isn't poorly designed then Rails is maintainable seems to be a pretty weak argument. In a perfect world with perfect, non-changing requirements, no deadlines and understanding clients you can probably make Brainfuck maintainable :)
fwiw i voted you up because i strongly believe in constructive discussion around these things. i don't think you should take that as a signal that folks support this position.
> I'm sorry, but saying that as long as your process isn't broken...
i'm merely saying that from several shops i've worked at, including instacart, with many 10k+ lines of code rails codebases, i've never seen problems like what you've described and it sounds pathological for that specific application/company.
again my (and many others') point is that rails is absolutely maintainable, even at massive scale, and even in a world with ever-changing requirements, hard deadlines, and very loosely-understanding clients, and that all that takes is doing rails the "right way" (a comprehensive test suite, reasonable architectural design), and that it is still massively productive.
If you've got a dysfunctional team and poor design, the language/framework choice isn't gonna help you. There isn't a framework in the world that will save you from tight coupling, lack of styleguide, business logic scattered all over the place, poor test suites, or monoliths made by bootcamp graduates.
Talking about 1 KLOC and future unmaintanability is nonsense.
In order to scale, Ruby applications need very high coverage. This has nothing to do with Ruby and/or Rails though; it's a requirement of all the dynamically typed languages.
There are certainly missing functionalities that at some point will cause a roadblock (currently, threading is immature), however again, no framework can support all the possible functionalities.
Exactly, this is the "at enormous cost" bit I hinted at.
In case folks are wondering about what we mean by coverage...
In case folks are wondering about what we mean by coverage...
PS. Love Rails.
I don't think typed languages all get you away from this. You're gonna learn things that make you want to refactor things. Your standard typed Java app isn't going to get away without tests, there, since compile != correct for the vast majority of program designs.
You might be able to get "less obviously broken" for free - logic bugs but no 500 errors from unexpected exceptions, say - but is that so much better?
For the record, I do think typing solves real problems for Ruby. Speaking in terms of pure productivity, it will be helpful to bring in developers who just are not experienced at working without a type system. The downside is I think most of those problems are primarily generated by inexperienced Ruby developers writing non-expressive code. Working on large code bases with Ruby is a very strange and awesome skill. The way you name things and build standards around methods/class creation ends up being a huge positive IMO.
Rails can scale; the problem that Rails faces is that it is easy to get things going quickly, and lack of foresight or simple inexperience can create bombs of technical debt or scaling issues. For many years, Ruby was the lingua franca of 12-week bootcamp schools, and the code that that cohort of programmers made spanned the spectrum of quality, but it all went to production.
In other words, the problem with scaling Rails is not with the framework or with Ruby, but with the accessibility and ease of development making it easy for pernicious problems to enter the foundation of codebases.
Good ruby scales, bad ruby does not -- both exist.
https://news.crunchbase.com/news/popular-web-frameworks-seed...
Set aside Angular could be the front end for Rails at the moment.
Consider this data: it would be interesting to know which of these get funded.
The funding may be an indication of agility i.e. which technology is the most successful and launching and iterating.
And then which technology makes it to scale will tell you which ones scale.
Gems like 'bluepill' and 'god' have been instrumental in deploying and ensuring mission-critical processes like elasticsearch, and redis are always up. This system has been in production for over 4 years, and we're still cranking :)
So, I guess I just fundamentally disagree on the 'big' portion of that statement, but also, I think apps are by their nature not long lived, so I think it is a false requirement of a web framework.
That said, I also have had work I've done in Rails still powering the same website almost 10 years on, cacm.acm.org
I think you and I may just have worked on different kinds of things.
Sure rails may be more popular than other frameworks, but that's because Ruby has one major framework, whereas PHP has had 5 or so now.
If you read down the page, you see that PHP is actually more popular than Ruby.
I'm a rails dev. This is nice.
This is not true. Rails is the most common back-end framework at coding bootcamps. But if you're trying to understand is happening to Rails, the biggest update is "Rails' model of serving HTML is dead/dying, and React took over a lot of Rails' old job". Bootcamps mostly teach JS now, for that same reason.
When we were confronting the task of rewriting a large, undocumented, untested, msft db, and java (macro services) Rails was the easy part. Choosing a full fledged react app, with Rails as the api server was a harder decision, but based on who we had and what our immediate plans were it made sense. There is a decent argument now that just doing it all in Rails would of been faster, but the mobile part is going to be huge for us.
Finding senior rails devs is harder than it used to be though, hands-down. We converted a lot of django devs to rails and it's been a big win, according to them. "whalesalad" listed a lot of reasons why and I agree with all of those. We, at least in the past, at startups found Rails people to be more capable of full stack development and we needed that. But, that was probably just our experience in the 2009-2010 in the valley.
Money talks. I'm sure you can find someone in no time if you advertise $500k in compensation. Most employers balk at that rate, so most of the talent take the freelance/consulting route.
Sure, Ruby is amazing and sure Ruby on Rails is a great framework. But Ruby stalled right there -- RoR has been churning out regular updates and is still making strides in right direction, but look at Python and what happened with its community: the community didn't just stop at Django or Flask -- it went ahead in multiple domains and created useful libraries. The end result is, Python is used for far many types of projects (be it enterprise or robotics) where as Ruby is synonymous with only the Rails framework.
This is why Python has eaten up any potential share that could have gone over to Ruby and if that is not all, the Academics in Universities around the World are starting to take Python seriously and are teaching it (NOT RUBY!!) and if there was any space left for those grumpy Java Developers at the Enterprise level, well emergence of Spring and Spring Boot has swayed them back into Java's fold.