Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I believe Rails is still relevant in 2019

devbrett.com

Post reply on HN
Print view View original

201–210 of 264 posts

Re: Why I believe Rails is still relevant in 2019

#201

Post by nathan_long »

gingerlime wrote: post #197
nathan_long wrote: post #177

Earlier quoted context omitted.

Yep, I used it extensively on one project, configuring it to raise exceptions if it detected an N+1 query and gradually enabling it test by test as I fixed them. It's very helpful.

The problem I had with the bullet gem however is that some times you actually want N+1 queries. Especially with Russian-Doll caching. I want my cache key to be lean, only fetching one record without its associations, because if the data is cached, I don't need any further queries anyway. If I "fix" my N+1 queries and load all associations, I actually negate the benefits of the nested caching and incur a cost I can av…

> The problem I had with the bullet gem however is that some times you actually want N+1 queries. Especially with Russian-Doll caching.

I know it sounds like I keep beating the same drum, but to me this problem seems like "we have slow views, therefore we need to sprinkle conditional caching logic everywhere, therefore we need to allow lazy loading, therefore we need to watch for N+1 queries."

As I wrote elsewhere (http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io...):

> By contrast, by compiling templates to functions, Phoenix automatically and universally applies this simple view caching strategy: the static parts of our template are always cached. The dynamic parts are never cached. The cache is invalidated if the template file changes. The end.

With fast views, no lazy loading is needed and no N+1 queries need to be possible. I don't think this is a problem inherent to Ruby, just to the way ActionView and ActiveRecord currently work.

Re: Why I believe Rails is still relevant in 2019

#202

Post by philwelch »

TheRealDunkirk wrote: post #146
philwelch wrote: post #53

As a former Rails developer, I figured it would be worth mentioning reasons I disagree. > Rails is not the fastest framework in the world… but I will argue that performance is the last thing you should worry about when you want to scale. > In my experience, NodeJS or projects written in other frameworks start to collapse architecturally after an alarmingly small amount of complexity is added to them. > More important…

> If you want to go with “battle-hardened and industry-proven”, use the Spring ecosystem. Well, uh, there it is. As a Rails fan who was forced to use Java for a web application at a previous job, I've been all over this whole topic, and even ranted about it on this site a couple times. This is the conclusion I came to: some people like to have things done for them by a framework, valuing the tradeoff of time vs. spec…

My point wasn’t to use Spring, my point is that it’s ludicrous to refer to Rails as “battle-tested” when most people who test it abandon their Rails prototype eventually anyway. My actual advice is probably that every stack sucks, but some stacks at least get out of your way.

> The working example I took away from the exercise was that writing a simple edit page with a nested model. It took me 3 lines of code in Rails, with a few dozen more from the generators....

> Some people get hung up on, say, race conditions of database validations

Because those race conditions mean that your cute three-line edit page is eventually going to turn into a hundreds-of-lines monstrosity if you actually try to put it into production. Rails is a great rapid prototyping framework, granted, but once you try and run a Rails app in production, you’re still face-first in all the complexity Rails pretends to handle for you when it’s just localhost:3000.

Re: Why I believe Rails is still relevant in 2019

#203

Post by joelbluminator »

lmm wrote: post #110
fyfy18 wrote: post #45

Earlier quoted context omitted.

Right, but that's just because those companies have grown to a certain point where it's hard to remain productive with a monolith. If you are starting to have scalability issues it makes sense to rewrite key hot code paths in a language faster than Ruby. That doesn't mean using Rails when they started out was the wrong choice though.

True as far as it goes, but does Rails offer a compelling advantage over higher-performance languages these days, even when starting out? Modern compiled languages have closed the expressiveness gap with Ruby a lot in the last decade or two. E.g. I find I'm just as productive in Scala as in Ruby - if anything more so - so I'd sooner work in Scala/Wicket from day 1 (for use cases where server-side rendering makes sens…

That's quite hard to measure, how do you measure expressiveness? Or easiness to grasp and get into? Take a CS graduate and have them build an app either with Rails or with Scala, in which stack will they be more productive? That to me will say a lot about a stack's productivity - because quality of documentation, community, stackoverflow questions, 3rd party libraries, general framework architecture etc etc etc..all those things are crucial for productivity.

Re: Why I believe Rails is still relevant in 2019

#204

Post by lmm »

KurtMueller wrote: post #190
lmm wrote: post #121

Earlier quoted context omitted.

Depends what you were trying to achieve with it; for the various things I've seen it used for a mix of protobuf-in-flat-files, Cassandra, and Spark.

I don't know the kind of work you do, but in the work I do, postgresql offers a lot of bang for your buck and works for me in the majority of all my web apps. The fact that I have one backend that can accomplish so much at good performance is a win for me.

The problems I have with postgresql in a web backend context are:

Limited support for master/master replication (for availability); there are various approaches but none of them is really first-class in terms of driver support etc.

Limited support for async (non-blocking) connection in a lot of languages. Again, it's often an option but not really first-class.

Limited support for working with non-square-table data (even just simple things like having a "column" that holds a collection). Again supported by the server but often not really first-class in the driver etc.

Rarely clear what the performance behaviour of a given query is going to be - you can write a query that looks exactly like an indexed join (fast) but it will silently decay into a table scan (very slow).

Performance is slowed by mandatory transaction functionality that hardly ever makes sense in the context of a web app. You have to have a lot of indexes (otherwise you'll get aforementioned silent slow queries) but Postgresql will insist on updating all of those indexes before it will ever acknowledge a write. The overwhelming majority of the time, what you really want in a web app context is a "deferred index", but Postgresql doesn't have those; your only options are to wait for all index updates to happen or to do a fire-and-forget write without getting an acknowledgement at all.

The design encourages you to run reporting queries/aggregations without any separation from your "live" operational updates. Because of the aforementioned mandatory transaction isolation that you're almost certainly not actually getting any value out of, it's very easy for those reporting queries to block, deadlock, or slow down your live operations. The tooling around tracking and restricting slow queries is very limited, and because of the aforementioned unclear performance it's not always obvious which queries are going to be slow ahead of time.

Aggregation has to be done in a horrible pseudo-English query language where it's impossible to compose more than one query together. Also, even simple key lookups use this language, meaning a lot of time wasted in parsing (I once saw profiling results that something like 3/4 of the time taken to process a simple pkey fetch was spent parsing the query).

A lot of serious engineering effort goes into these systems, but most of it is wasted in a web backend context. (Indeed for a long time the most popular RDBMS for web backends was MySQL, despite it (at the time) having very little support for all the supposedly-important RDBMS features like ACID). If the RDBMS was invented today I don't think anyone would use it for a web backend - it just makes the wrong tradeoffs for that context.

Re: Why I believe Rails is still relevant in 2019

#205

Post by dehrmann »

KurtMueller wrote: post #186
chvid wrote: post #78

I think for what it is - for its paradigm if you will - ruby on rails is an extremely well-designed platform. But I think things have moved on and what was back then seen as the right way (or just fresh new way) is now seen differently. For example - is it really "better" to say 7.even? rather than isEven(7)? (Strict OO vs multi-paradigm/functional programming). Or is the article's example of a data model migration r…

> And why not go for a pure SPA rather than an AJAX-sprinkled compromise between a traditional server-side rendered html app and a SPA? Not every app needs to be or should be a SPA. IMHO, unless you're creating an actual web application like Pivotal Tracker or Google Docs or etc, then maybe you should go with meat and potatoes server-side rendered html and javascript.

The company I'm at right now uses a SPA for both static and interactive things. On the static side, it's comedically slow and complex for what should be an HTML file with resources. On the interactive side, the load time is abysmal (and that's on a corporate network), and it does work well once you try to open a new tab. On the other hand, it makes for cleaner code.

Re: Why I believe Rails is still relevant in 2019

#206

Post by jashmatthews »

gumcreme wrote: post #180
jashmatthews wrote: post #142

Earlier quoted context omitted.

> proper http/2 support in Rails-land Between early hints support in Rails 5.2, nginx proxying to HTTP2, and an http2 enabled CDN what's actually missing?

ngninx supporting http/2 != Rails supporting http/2 Depending on the use case you leave out nginx sometimes, eg. when doing microservices. Not that nginx is bad but with other stacks you very often don't need nginx and/or connect directly to the CDN reducing complexity in a stack.

nginx transparently proxies using http2 to client and http1 to server. In a standard setup at any scale with a load balancer it doesn't matter that Rails doesn't support all of HTTP2. The client still gets all the benefits of header compression etc.

Re: Why I believe Rails is still relevant in 2019

#207

Post by lmm »

robenkleene wrote: post #117
lmm wrote: post #107

Earlier quoted context omitted.

Disagree with all of those except Javascript (and that only as an execution layer). All of the things that those technologies promised, we now have better ways of achieving.

Yet here we sit in entire thread that’s the perfect place to discuss these “better ways” of doing things and I'm seeing zero consensus about what those better ways might be. Are other people interpreting this thread differently?

There's no clear consensus on which way is best. That doesn't mean there aren't better and worse ways.

Re: Why I believe Rails is still relevant in 2019

#208

Post by jressey »

nathan_long wrote: post #157

I spent a couple of years dreaming of getting paid to work in Ruby and Rails and about 7 years doing so. There are many things I loved about Ruby, and Rails brought a ton of good ideas to web development, as this post describes (though I don't agree with all the highlights). I've since moved to using Elixir and Phoenix, and then even more recently, done some consulting on a Rails project. So the contrasts are on my m…

Callbacks suck, so write service functions for complicated CRUD. Working around ActiveRecord defaults is like the 2nd thing you learn to do at a serious Rails shop. I'm afraid you may not have been working with sophisticated Rails engineers, because we certainly modify defaults in our applications.

Elixir is hot, but it's hard to learn and will always have a barrier to entry that Rails won't. Rails and .NET will live longer than us.

Re: Why I believe Rails is still relevant in 2019

#209

Post by swat535 »

nathan_long wrote: post #157

I spent a couple of years dreaming of getting paid to work in Ruby and Rails and about 7 years doing so. There are many things I loved about Ruby, and Rails brought a ton of good ideas to web development, as this post describes (though I don't agree with all the highlights). I've since moved to using Elixir and Phoenix, and then even more recently, done some consulting on a Rails project. So the contrasts are on my m…

I love how every time there is a post about Rails, someone preaches the holy grail of Elixir/Phoenix.

I think you are missing the forest of the trees, regardless of whether or not the success of rails is circumstantial, the fact remains that Rails is in the lead position because you can build a business on top of it.

It is a solid, battle tested, mature framework that one can use and scale it (up to a certain point) and beyond that, it might get harder but scaling is never easy and I am sure you would agree that Phoenix is not a magic bullet when it comes to scaling.

Again,I don't have to recount the number of services built on rails that thousands of people depend on today: Shopify, Github, Gitlab,..

Us engineers think the only thing that matters is your rendering time.. but it's not , the main thing that execs care about is the bottom line and how fast we can push products to production.

All that being said, I agree that Phoenix is great but let's not kid ourselves, we are here to make cash first and foremost.

To any young devs out there, I strongly encourage you to not pick a framework by its hype but evaluate it based on your system needs / maturity.

Re: Why I believe Rails is still relevant in 2019

#210

Post by TheRealDunkirk »

philwelch wrote: post #202
TheRealDunkirk wrote: post #146

Earlier quoted context omitted.

> If you want to go with “battle-hardened and industry-proven”, use the Spring ecosystem. Well, uh, there it is. As a Rails fan who was forced to use Java for a web application at a previous job, I've been all over this whole topic, and even ranted about it on this site a couple times. This is the conclusion I came to: some people like to have things done for them by a framework, valuing the tradeoff of time vs. spec…

My point wasn’t to use Spring, my point is that it’s ludicrous to refer to Rails as “battle-tested” when most people who test it abandon their Rails prototype eventually anyway. My actual advice is probably that every stack sucks, but some stacks at least get out of your way. > The working example I took away from the exercise was that writing a simple edit page with a nested model. It took me 3 lines of code in Rail…

I've made at least a dozen LOB Rails apps for internal use at companies. I also worked at a bespoke consultancy that made Rails sites for startups, and I've seen dozens of Rails apps "in production," out on the open internet, and making money for their owners. I think there may be some conflation here between "production" and "Twitter- or Facebook-scale production." And I wouldn't trust ANY framework to applications at that scale.
Post reply on HN