Hacker News Reader

Comment by crispyporkbites | Hacker News Reader

Rails is so productive and powerful these days that if you’re building a web app you need a really, really good reason not to use it

View on HN

I find Rails projects often grow larger than the formalisms available in Ruby provide for, and I tend to find myself missing types even in fairly tiny projects.

I look forward to Ruby 3 type annotations, and to the continuation of a long history of Rails setting the developer-experience standard for projects in other ecosystems.

Have you checked out Sorbet?

I haven't gotten a chance yet, no. My recent projects have been tiny things in PHP, or large ancient things in Java. Looking forward to an opportunity to try it out, though.

I have some: memory usage, CPU usage, raw performance, language safety, transparency. I think in the era of Elixir/Phoenix, Rust/Actix, Clojure/Luminus it is really hard to argue for Rails. Don't get me wrong, I have spent many years on it, but simply there are better alternatives, based what sort of requirements you got.

The main issue I see with these frameworks is that they cannot match Rails' support ecosystem. The framework has around for a really long while and rails developers have made - and documented - every error, kink and detour it is possible to make when writing code. I have often been pleasantly surprised to google an esoteric problem I imagined could only arise from my own unique brand of kludginess, and find that the community had encountered and solved same in the past. This is of massive value especially to new developers.

I am pretty sure. If you developing the next Basecamp these are essential. However, I rarely see Rails succeeding in other aspects of web development. I spent some time on trying to make Rails work for use cases that are not the perfect match for this ecosystem and failed. Yet, it is quite possible that there are millions on web applications out there, running on Rails happily. It is just not a great fit for things I do.

And how, exactly, are you differentiating a "Basecamp-like" startup from a "non-Basecamp" startup?

Basecamp's problems seem particularly well suited to a batteries included CRUD framework. There are plenty of problems out there that aren't CRUD-centric

Exactly.

non-Basecamp startups:

- processing images

- providing API for warehouse fulfilment for online retailers (peak load is 100x of base load, latency goes out of the roof before Rails just crashes with OOM)

- real estate indexing with huge amount of data (we could not make the full text search work reliably with Rails)

These were pre 6.0 and I am pretty sure many things changed since, I am just saying it is easy to run into these situations. The bigger your framework the more assumptions are built in that are hard to come by. It is good for Basecamp startups not good for non-Basecamp startups.

Image processing: Spin up sidekiq workers and do your image processing in parallel in background processes.

Providing API for warehouse fulfilment with peak load 100x greater than base: Run your Rails APP in any number of possible auto-scaling configurations.

Real Estate Full Text Indexing: Use ElasticSearch alongside Rails to provide highly performant full text indexing/searching

Are you suggesting that there is more to it than just Rails and an amazing ecosystem? I agree.

I'd be interested in knowing what areas you found Rails lacking. Care to elaborate ?

I might be wrong but aren't real-time areas like WebSockets not really strong points in Rails? I do see that Action Cable appears to have improved, and I don't know at what point performance issues would get in the way, and I also probably don't know about some potential solutions. Should one choose Rails for an application with significant real-time / reactive functionality?

For me the most important one is performance and the lack of trust in my code (run time errors).

- https://blog.codinghorror.com/performance-is-a-feature/

- http://www.nicolas-hahn.com/python/go/rust/programming/2019/...

I totally agree that app performance is important.

But I really think there is a difference between framework/programming language performance and acceptance-level app performance.

It is possible to have a good performance app (Github, Shopify ) even if you don't believe that Ruby is good enough in this category.

It depends on what you need. If you're building chat and want presence features so you can see who's online (and with how many and what type of devices), Elixir + Phoenix gives it to you out of the box.

I agree with your point about a sparser number of libraries, and sometimes that slows me down. That said, Elixir's ergonomics and documentation is fantastic.

There’s kind of a middle ground where Rails is widely-used enough that it has this advantage over stuff like Elixir, but by the same token the Python, Java, and probably .Net ecosystems have the same advantage over Rails.

The place where Ruby really wins is speed of development. Despite massive ecosystems and many libraries, Python, .Net and especially Java all lag Ruby in terms of how long it takes to build a web app.

I'd say part of the reason is expressiveness of the language (since it's very easy to make DSLs with Ruby and Rails benefits greatly from them), but another part is cultural. Python, .Net and especially Java communities tend to suffer (and benefit!) from a strong emphasis on correctness and purity over speed and developer experience.

I'm not sure that Ruby is actually any faster or more expressive than Python. Having used both languages I consider them roughly equivalent.

Can you write DSL like the Rails router DSL in Python?

If so, how much work is involved?

Having a cute API and leaving the parentheses out of your function calls isn't a DSL, it's just a cute API where you leave the parentheses off. I know Ruby people call them "DSLs" all the time, but they aren't.

Python doesn't have an idiomatic equivalent to block arguments, but you could probably write an equally usable routing API. It just wouldn't look as cute because there would still be parentheses.

What you end up doing in e.g. Flask is decorating your controlle method with the path that routes to it. Turbogears controllers serve routes based on class and method names without the extra wiring that Rails has. Django has a Rails-style "URLconf" (https://docs.djangoproject.com/en/2.2/topics/http/urls/) that actually seems a lot more intuitive and explicit to me.

> Elixir/Phoenix, Rust/Actix, Clojure/Luminus

These provide like a tenth of the functionality of a bog-standard Rails app, and have a hundredth of the ecosystem built up around them.

Yep, the 1/10th I actually need.

Not a Rails dev myself, but curious: let's say Rails gives you 80-90% of the simple CRUD screens you might need for a project with minimum effort, but you need a couple of high performance services for, say processing images or accessing a data warehouse. Would it be possible to just write these services using e.g. Go or Elixir, and access these APIs through your Rails app?

The real question is: if you already writing the services in Go or Elixir why would you want a Rails app on the top? You could very well implement it in Go or Elixir. Theoretically it is possible though.

I think the point here is that Rails is a very productive platform for building CRUD workflows - much more so than, for example, Go (perhaps less so for Phoenix/Elixir). So you can build the vanilla CRUD screens in Rails in minimum time (and therefore minimum cost), where performance is not going to make much of a difference either way, then use Go microservices for those parts of your platform where performance is essential. So use each tool where it is best suited for the job - Rails for productivity and Go for performance.

How many http requests do you need before you have to switch to any of these?

Unless you’re at serious scale the answer is going to be not enough.

>> How many http requests do you need before you have to switch to any of these?

Or how many metric tons of CO2 do you want to produce before switch to any of these. You see performance is an interesting problem.

This is a non-issue for literally 99.99% of applications and considering it before being "at scale" is simply a waste of mental energy.

You are missing the point.

As somebody pointed out there are millions of applications that can use Rails because scale is not a problem for them. If all those millions of applications do 1 req/s then you have 1M req/s served with Rails instead of something that is more reasonable. The CO2 production of these low scale Rails web app quickly add up.

How comes this? A higher CPU consumption currently it is going to have a higher CO2 footprint, even in a cloud-based, shared-VMs scenario.

I’m currently comparing Rails with .Net Core.

Does anyone have experience with both?

I’m especially interested in how .Net Core works with Postgres on Linux.

Most of then tutorials focus on using the entire MS stack.

I use .net core by day and rails by night (side business) and I can honestly say .net core MVC is kind of influenced by rails (not a lot but like 30%). After more than a year using both I found more joy with rails.

I find Rails gems and ecosystem to be more mature also ORM is friendlier since I felt more comfortable using active model than EF

All of the above could be a personal preference since I worked on rails for a longer time. At the end of the day I got to an end product with both

However I use .net core with MSSQL and on a Windows machine.

I've used rails back in the 3.2 days and after 7-8 years I still can't find the simplicity of rails in .net core and I really wish it was the case. I'll bet getting a rails 6.0 project from first scaffold to fully working site with admin interface and login system would take just one night of work without really remembering anything. With .net core, no idea how long. I saw some code generation commands for the most recent versions, so maybe there is some hope for .net core.

.net core works fine with postgres. Though I tend to use Dapper rather than Entity framework. I just use .net core as a REST backend / host for a vue front end.

There's always a bunch of pros and cons to comparing languages and frameworks, I'll just say neither are really going to hold you back from doing anything.

How is Rails compared to Django?

More similar than different in a lot of ways, but I suspect the differences come out of their background. Rails was originally developed by a consulting company for both client work and their own apps, so it really emphasizes rapid development -- it pushes convention over configuration very hard, had database migrations from its first version (Django didn't get those for years, etc.). Django came out of a newspaper (the Lawrence-World Journal), and seems really optimized for building custom CMSes -- there's nothing I've found in any other system that's truly like Django's admin console, for instance. (Another sign of its newspaper heritage: it's the only template language I've ever seen whose date filter has extensions to match Associated Press style!)

ActiveAdmin is just as good as Django's built-in admin system, if not better (in my humble opinion)

I used Rails for 4 years, then Django for 2 years, then back to Rails (now for another year).

Programming with Ruby and Rails is like a breath of fresh air compared to Django. Working with Django was just so painful and awkward (especially if you are trying to write tests for things). I used to have a laundry list of a couple of pages worth of things that I hated about Python and Django when compared to Ruby and Rails, but I can't seem to find it right now.

Can you elaborate on that? These Ruby praises makes me want to know more as I know only Django.

Ruby has unconstrained lambdas for a start and a much more composable, expressive syntax facilitating the creation of elegant DSLs. Rails, Chef and other Ruby projects lean on this feature. The goals of Ruby's creator, Matz, were more idealistic and artistic than those of Python's creator, Guido, whose values are more pragmatic and math-focused. Matz took inspiration from Perl, Smalltalk and Lisp whereas Guido set out to solve a much more local, project-based problem when he created Python.

Availability bias. The Django praises are all in the Django threads. This is a Ruby thread after all ;-)

Different philosophies. I think the biggest difference is that Rails has a much bigger ecosystem and more developers than Django does. There are gem's out there that support almost everything you want to do and if there's not there are resources from people who have had to solve similar problems.

And by the same token, outside the context of "web stuff," Python generally has wider set of domain-specific packages (e.g. ML) you can easily incorporate into your web app.

> I think the biggest difference is that Rails has a much bigger ecosystem and more developers than Django does.

Going to have to disagree with you there.

> Rails has a much bigger ecosystem and more developers than Django does.

[citation needed]

Reply on news.ycombinator.com