For some reason people seem to constant doubt Ruby-ists and Rails Devs.
I completely get that other languages have huge benefits over Ruby. Golang being compiled or Java running anywhere, etc... And ruby is slow, totally understood.
But if youre talking about getting a functioning webapp up and running quickly... no way anyone is beating a Rails dev in setting one up. The piping and scaffolding are all built in and the gem ecosystem (for web apps specifically) is so well maintained and robust that you can drop it in to your app and get a functioning product with ease.
I know that's a loaded statement bc Rails becomes not so great in other cases like building speedy backend jobs. But for a small user-facing web app it's hands down the best.
I’d say the slowness of Ruby is really over exaggerated. For most web applications it’s good enough, and the speed of development (how fast you can ship) almost always outweighs any costs from it being slow.
You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later.
I’ve worked on all sorts of applications from corporate CRUD to mobile billing gateways written in Ruby (usually Rails), and in very few cases has Ruby itself been the bottleneck.
There are some properly large companies like github and shopify that run a large rails stack, it seems to work out pretty well for them. At my current workplace we have some streaming servers pushing about 15 gigabyte/second at peak load and the ruby processes easily saturate the available bandwidth on the EC2 instances. Like you say, the slowness of Ruby is greatly exaggerated. Sure we could rewrite the whole thing in Go/C++/Rust/etc, but it would not work any better and the gain of using 10% CPU instead of 20 is not really relevant since it's the NIC that is the bottleneck.
I second that resources consumption with Rails on the production system is only a problem in specific settings (e.g. when your business model depends on many cheap transactions, or when you are running on diverse sets of hosts outside of your control… I'm looking at you, GitLab).
Nonetheless, as a junior Rails developer coming into a 5 people team on a mid-sized project, I saw a diverse set of performance problems during the development phase. E.g. asset pipelines that take ages to compile so that rapid development cycles become impossible or a test suite that took heroic efforts to get down to 15 minutes despite not really doing much computationally-wise. I'm open to alternative interpretations, but I've got the impression that in more performance oriented frameworks the best practice would not turn out to be setting up and tearing down half your server stack before and after each controller test, but instead we would have chosen abstractions that can be plugged together more efficiently.
I think the rise of Mastodon is really pouring some hot water on that meme. Lots of really small VPSs are running some fairly big instances. Although I'm only personally using one of them, it's very fast, and the general view is that isn't unusual.
I get that it won't hit Twitter scale but that matches the majority of "how do I build a prototype" use cases.
"Twitter scale" wasn't so much a Ruby/Rails problem as it was an RDBMS (write-many + read-many = road to fail) and writing their own in-house message queue problem. Starling performed worse than just about everything else out there (and their Scala replacement Kestrel isn't much better).
One really insipid blog post and thousands of mindless followers later and the damage to Rails has been done.
That's not to say Rails doesn't/didn't have other issues -- it did. It's just telling that Twitter is the first example people reach for instead of anything else.
Agreed. I've been working mostly in Ruby since 2006, over hundreds or thousands of apps, depending on how you count, and I have only worked on 2 apps that actually had scaling problems with Ruby. The rest were 100% improperly designed or scaled databases.
Twitter is certainly of a scale that I would not be using Ruby on the primary load points. But even billion dollar companies don't often reach that scale.
at twitter’s scale, its not jus ruby, you would also have problems with php, python, node, and maybe even java. only language that will work well at that point are languages built for concurrencies such as scala, elixir, and go.
Or you break out your infrastructure into smaller components and move the more demanding/critical parts of your infrastructure to that other language and keep everything else you've built!
> You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later.
Maybe in an API server. But this is nontrivial in a monolithic application where you end up yakshaving the whole middleware stack to parity just to replace an endpoint.
Totally agree. Rails is really powerful; it not only gets you up and running fast, but it can carry you very far. Like, years and years. And for a lot of places (like github, hulu) they seem to manage fine with it as their stack.
> Rails becomes not so great in other cases like building speedy backend jobs
Rails is still pretttty good for this. I mean, gosh; maybe not a game engine or something like THAT - but for much of what is done on the web rails can be optimized to complete requests in ~25ms.
> But for a small user-facing web app
"small" as in 95% of websites out there that aren't facebook/google. I mean, shopify handles 80,000/req/sec on a rails stack and they are the backbone of a lot of small (and not so small) e-commerce stores.
I started building a SaaS in Java/Spring and months in realised Ruby/Rails would have been stunningly faster to get the same result. The full write-up is here for reference http://tayler.io/5-lessons-learned-as-an-indie-hacker/
> no way anyone is beating a Rails dev in setting one up
I disagree. Elixir/Phoenix is as simple as Ruby/Rails and an order of magnitude more performant out of the box. Especially if you already know Ruby and the basics of functional programming. Plus, unlike Rails, you probably won't need separate servers for background jobs, websockets and caching.
Sorry to fact check here but on my Rails app I am getting 200ms return times. This is running a web application and a few hybrid mobile applications. Are you saying that basically out of the box with Elixir/Phoenix I would get 20ms return times? That would be amazing but I find that highly unlikely.
That’s a highly unrealistic real world scenario. I’d like to see a page under load with actual queries. Heartbeat checks are far from actual real world examples of much of anything.
I guess my point was: that’s the baseline. It’s an order of magnitude faster the 20ms your saying is unlikely. That leaves a lot of headroom for hitting the db and things done. The api I’m working on isn’t currently being hit super hard, but for most of my endpoints 25ms is pretty average.
But since it is much newer, the docs and examples are much thinner than Phoenix.
Plus, except for unoptimized database actions (which would equally affect Crystal), Phoenix responses are usually sub 200ms. Some are sub 1ms. So it really isn't in need of performance increase.
I looked into rails in some detail about a year ago, and I think it's the only pretty good solution for this I've come across—but there's a steep up front cost in learning/setup etc. (or so it seems).
It's best to pick a project and try to build it, rather than learn things from the outside. In isolation, Ruby can be annoying to learn because it's syntactic sugar seems unnecessary. In context of an app, though, it's great. The sugar makes sense.
Rails has a bit of a learning curve, but that learning curve is well rationalized. To borrow a Steve Jobs-ism: you're starting on the 10th floor, when everyone else is starting on the 2nd floor. Out of the box, you get a killer asset pipeline and complete MVC system that's standardized and conventional.
You can throw together a well built webapp without cutting corners in a fraction of the time doing it by hand. Things like a solid REST API practically come free with Rails. That's really valuable.
This is what I used to jump from "I've hacked on a rails 3 app and gone through some ruby Katas" to "I am building out a full fledged SaaS product in a Rails 4 app as technical co-founder".
The community is so big, and so focused on conventions over configurations, usually googling "rails <questions>" returns a LOT of links to stack overflows and blogs that clearly explains everything.
Rails offer so much syntactic sugar/plug and play gem systems that usually things are setup in fewer lines of code than anywhere else.
The downside is that it's easy to build something while barely having any idea how it works, but if you want something up quickly (or if you already know how things work) then it's perfect.
There is definitely a learning curve. For me, Rails was unapproachable until I started to give up the idea that I needed a ton of custom stuff in my stack. The "allure" I saw of pulling together a basic routing system and hooking things up by hand completely disappeared after building a pretty substantial web app in _Sinatra_.
Rails makes a lot of decisions for you, but the decisions it makes are the _right_ ones. It's like having a "best practices" box that you can just shove your custom system into, rather than trying to build them in yourself. It's really quite something.
For context: I basically learned Rails by way of building a proof of concept election management system in Rails in about three weeks (more like 1.5 in actual programming time). It also stored votes on a blockchain (ethereum). Even with a relatively complex storage system and interaction model, the Rails best practices left me with a really satisfactory application in no time flat. Perfect for a fast PoC.
Depending on how long ago, I've noticed that the comprehensiveness of third party documentation (i.e. googling "how do I x?") can really change the experience.
My memories of trying to install Linux circa 2000? Not favorable. Though to be fair I was a lot younger then too.
Laravel. It's PHP and (assuming you know Laravel) you can get a it up in minutes. It's development time is as fast as Rails.
I'm not taking any chips from Rails. Rails was the first and is still one of the best. Just pointing out that there are other frameworks that are designed to move to production fast.
Phoenix loses my vote for being quick to set up for a web application, because last time I used it, it didn't have a good authentication framework that worked with JSON APIs. What took ten minutes to set up using Devise in Rails took me two days using Coherence in Phoenix.
Unless that's changed since I last tried Phoenix, I'd be hesitant to use it in the same niche as Rails.
I'm a huge fan of Phoenix, in part because it addresses the main issue I had with Rails (too much magic).
But I do agree that losing the huge ecosystem of gems is a significant downside. Hopefully that'll change over time, because other than that, Phoenix really feels like the next iteration of Rails to me.
That's my biggest gripe with Phoenix--so much good stuff can't be used. I understand that sometimes moving on the next thing requires this, but man, it isn't just Rails that has tremendous value when creating a web app. The entire ecosystem has so much good "drop in"/"near drop in" functionality.
Well, here's one reason: the amount of time saved when standing up a webapp on Rails is absolutely insignificant compared to the life of that webapp in all situations where that webapp is anything serious.
Not to say that Rails apps aren't serious! I'm just saying that the time saved in standing up a webapp with Rails vs., say, Java, is miniscule compared to the develooment life of that application, overall.
In short: you don't save any time at all, in the big picture, and now you have all the long-term disadvantages of Ruby.
Ah, that's an interesting perspective. Having written and supported websites in both Java and Ruby (plus some other languages), I think that your perspective is valid. Long term costs are worth considering. However, sometimes you can take a long term hit in order to deliver quickly.
> compared to the life of that webapp in all situations where that webapp is anything serious.
Actually there is a situation where the short term life of the webapp matters far more than the long term. That's when you are not sure if there is going to be a long term. This could be a startup, a spike to explore a new business model, or even just a prototype of an internal app.
In all those cases, delivering something that has value in a short time outweighs the value of something that might be more supportable/extensible in the long term.
We should all over engineer our applications by picking the most complicated stack possible because the long term goal may slightly benefit the short term goal of you know.. actually making money out of our business.
Why pick a simple Rails + Postgres stack when you can setup Oracle + Java because you will require enterprise level scaling for your first 1-100k users
Oh and just for the record, I am sure you are already aware but Rails gets you very..very far.
Github, Gitlab, Shopify, AirBnb, Basecamp, Groupon,.. I could go on.
Rails is optimised for fast development. That isn’t just about first bring-up, but about long-term velocity too. You will almost certainly save time over pretty much any other available solution, even over the long term.
Where Rails and Ruby fall down is going to be in performance and complexity. If your “simple” web app becomes a sprawling and complex mess, Rails won’t deal with that elegantly. And if you suddenly have to scale to millions of users, you might struggle.
Well, your comment contained a bit of a generalisation. It may or may not be true depending on the size of the app, its purpose, the number of developers, their level of experience, and a bunch of other factors.
The response contained a generalisation too. Horses for courses.
I'd describe my professional experience with Rails as: Rails optimizes for Day 1. Devise is a great example.
But I left Rails when I couldn't help but notice that it tends to break down over time without eternal vigilance. And even simple tasks required me to hold quite a bit of Rails trivia in my head.
These days I'm far less likely to give up simplicity so easily.
Assuming we’re talking about a startup, the expected lifetime of your product is ~0 and so is the number of customers. If you’re somehow lucky enough to ever have so many users that you have issues with rails, you will have the money (VC or otherwise) to deal with it.
The benefit of Golang isn't that it's compiled. It's that it has a good IO and concurrency model and the language is strict enough to force certain good practices on developers.
IMO it would be almost as good even if the code execution were as slow as Python or Ruby.
I hear this a lot about Go, but doesn't the webserver handle concurrency for you in most cases? I don't do a whole lot of explicit threading work when I write webservers in Java for example. Or is there something I'm missing that you use the Go primitives for in these cases?
I'm not as familiar with Java but It's more about concurrency than threads. I have more familiarity with Python, so using that as an example...
There are Tornado and asyncio libraries for Python that give you asynchronous networking. But you have to totally rework how you write Python code within those request handlers to factor out blocking IO which makes using existing libraries for DB and such a pain.
Go is built from the ground up to handle IO like that asynchronously so all of your libraries and stuff will just work in that context.
NodeJS is similar to Go in that regard, but the JS language has baggage that gives you weird blends of callback asynchronicity mixed with async/await and it generally just doesn't feel as nature as Go.
Sometimes a simple request/response model isn't enough. Maybe you need a streamed (chunked encoding) API or WebSockets where the performance for massive numbers of connections using threaded servers is going to tank quickly compared to a language like Go that handles the IO and concurrency better from the ground up.
Which version of Grails was that? If you mean version 3, why is virtually no-one starting new projects in it, or upgraded from v.2 ? Grails 3 looks like nothing more than a wrapper around Spring Boot, so why not just use that? If you're talking about version 2, why has its plugin ecosystem died?
From the Ruby side Sinatra is just as fast as flask to get something going. Having supported all three ( Rails, flask, Sinatra ) if it's going to be an API. I usually start with Sinatra.
Pyramid - https://trypyramid.com/ - lightweight like flask but with that little extra that makes life easier (authentication, sqlalchemy integration). Not as heavy/opinionated as django. In fact, would argue, not opinionated at all.. just the right balance.
You can literally start and publish a C# web app to azure in minutes if you wanted to. They have built in deploy from GitHub.
I usually rip a bunch of stuff out of their default app template and actually get the app doing something useful first before I deploy but it's really easy.
Agreed! I have a template built that allows me to spin up a basic web app with all my baseline common dependencies ready to go and a handful of little nice-to-haves in place and deploy to Heroku in well under an hour. I love Rails!
I keep on running into this problem where I try to use a new framework/language for backend, like Go, Kotlin, even Node, but I just get so damn bored with writing the same boilerplate. Say what you will about Rails, but at least the maintainers try to automate the boring parts. Not to mention between Elastic Beanstalk, Heroku and even plain old Capistrano on a VPS, deploying Rails is a breeze. Maybe some people take some perverse joy from writing CRUD operations for the millionth time, but I don't.
I’m curious: once one has written a CRUD app, why can’t they use that as the boilerplate for other CRUDs they need to write? Replace the bits specific to each individual app. If the program is designed in a sufficiently modular fashion, shouldn’t this be doable?
Eh, are you perhaps hinting at that horrible lawsuit where Oracle sued Google(?) for a lot of money for copying about 9(?) lines of code that was basically a looping routine?
That notwithstanding, I was asking about code that could be considered “boilerplate”, not things that could be considered proprietary business logic. So the code to do a login, or check for cookies, or get something from a db, or anything of that sort should be broadly reusable (for a general CRUD app).
Somewhere around 2006, after my first enthusiasm about Rails I realised I could get almost the same, with a language that is more natural for me, has more developers here, as well as cheap hosting options (less of a concern now) by going with php/symfony.
I completely get that other languages have huge benefits over Ruby. Golang being compiled or Java running anywhere, etc... And ruby is slow, totally understood.
But if youre talking about getting a functioning webapp up and running quickly... no way anyone is beating a Rails dev in setting one up. The piping and scaffolding are all built in and the gem ecosystem (for web apps specifically) is so well maintained and robust that you can drop it in to your app and get a functioning product with ease.
I know that's a loaded statement bc Rails becomes not so great in other cases like building speedy backend jobs. But for a small user-facing web app it's hands down the best.