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

191–200 of 264 posts

Re: Why I believe Rails is still relevant in 2019

#191

Post by emptyroads »

nathan_long wrote: post #178
emptyroads wrote: post #171

Earlier quoted context omitted.

I agree with a lot of what you've described, but 7 years of working in Rails and you never figured out how to turn off lazy loading in ActiveRecord?

I know how to preload associations, but I don't know how to globally disable lazy loading of associations. Do you know a way?

Hmmm, I don't want to assume too much (because of course everyone's project needs are different), but that just sounds like a terrible idea. I guess there are solutions like goldiloader (I've never tried it), but 99% of the time I'd rather not load associated records unless I use them. When I need to load/use them along with many parent records, it seems pretty obvious that I'll want to include those associations (eagerly loaded) in my AR query to avoid N+1 queries as you mentioned. Then again, maybe I've just spent too long taking those assumptions for granted where newer devs might not.

EDIT: After looking more into your claim that "N+1 queries aren't possible with Ecto", I think I have a better idea for what you might mean. Perhaps you don't want everything eager loaded, but you want an exception to be raised if you try to access an associated record that hasn't been preloaded. I suppose that's a fair point (probably good practice if having any N+1 queries will be a major problem in your project, or if subpar performance really is your biggest threat), and no, I don't know of a way to do that in AR.

Re: Why I believe Rails is still relevant in 2019

#192

Post by dentemple »

StevePerkins wrote: post #167

What is the Ruby community like in 2019? I've spent the past 20 years primarily working on JVM-based languages. Being told for about 19 of those years that my boring verbose tech stack stack is obsolete, and going away from the business world any day now. Most recently, that voice comes mainly from the Node.js community. But 10 years ago, it was a mix of Ruby and Python upstarts. I kinda saw those languages and commu…

Stereotyping large groups of people doesn't make for a good argument.

Not unless you're purposely trying to make JVM-stack developers look toxic.

Re: Why I believe Rails is still relevant in 2019

#193

Post by cutler »

ramblerman wrote: post #54
fouc wrote: post #9

All the standard web technologies are still relevant. MySQL & PostgreSQL are still relevant. Redis is still relevant. Ruby on Rails is still relevant. Javascript is still relevant.

Some of those are even more relevant these days. - JS has only grown in ubiquity and maturity of the language. - postgres also seems to be on a comeback now the honeymoon phase of nosql is over.

JS - mature? It still has no standard library and probably never will.

Re: Why I believe Rails is still relevant in 2019

#194

Post by eamike261 »

StevePerkins wrote: post #167

What is the Ruby community like in 2019? I've spent the past 20 years primarily working on JVM-based languages. Being told for about 19 of those years that my boring verbose tech stack stack is obsolete, and going away from the business world any day now. Most recently, that voice comes mainly from the Node.js community. But 10 years ago, it was a mix of Ruby and Python upstarts. I kinda saw those languages and commu…

This attitude reminds of the old engineers who cling to svn and refuse to learn git.

Re: Why I believe Rails is still relevant in 2019

#196

Post by cutler »

wrestlerman wrote: post #165
cutler wrote: post #159

Earlier quoted context omitted.

Elixir looks great until you look at modulecounts.com where Erlang/Elixir libs total a mere 7900. Compared with Ruby's 150900 gems that's a lot more code you're going to have to write surely?

That's a very valid concern. My personal opinion: Yes, the package system is pretty small. That's why it depends what kind of project you are gonna write and how much time you have. Ruby has a lot of gems, but many of them are buggy and deprecated... Proof: https://github.com/rubysherpas/paranoia I think that Elixir is gonna catch up. If you write a project where you need to use a lot of external libraries probably R…

Another concern with Elixir is that, like Node, it is optimised for IO, not computation. Take chatbots, for which Elixir is supposed to be ideal - what if my chatbot connects to a computation-intensive AI/NLP model. I'm going to need something else for that, surely? Elixir and Node are good for the orchestration layer but lack the all-round capabilities of, say, the JVM platform.

Re: Why I believe Rails is still relevant in 2019

#197

Post by gingerlime »

nathan_long wrote: post #177
KurtMueller wrote: post #172

Earlier quoted context omitted.

> chasing down N+1 queries to improve performance is something I spent far too many hours doing Just an FYI for any Rails dev reading this, the Bullet gem is excellent for pointing out n+1 queries.

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

Re: Why I believe Rails is still relevant in 2019

#198

Post by lmm »

danmaz74 wrote: post #184
lmm wrote: post #105

Earlier quoted context omitted.

A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best "framework" I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to). Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a fra…

To be fair, Rails now makes it much easier to swap libraries if you need to, compared to how it was at the beginning. I agree that that's something useful, but personally I still think that having a sane reference combination to start from is much better than having to choose everything yourself. Especially in the JS world, I could really feel a "library fatigue" when I had to evaluate so many different alternatives.

> I still think that having a sane reference combination to start from is much better than having to choose everything yourself.

That's why I'm such a fan of TurboGears - it's an easy starting point, but as soon as you want to step up to making your own library choices it's trivial to do so. I think the key insight is that no-one ever wants to go back to upgrading all of their different libraries in lockstep; a "platform" of libraries that are versioned together is a good starting point but at a certain point in the project lifecycle you want to unlock from that and after that trying to go back to the platform is only ever going to be pain.

Re: Why I believe Rails is still relevant in 2019

#199

Post by nathan_long »

emptyroads wrote: post #191
nathan_long wrote: post #178

Earlier quoted context omitted.

I know how to preload associations, but I don't know how to globally disable lazy loading of associations. Do you know a way?

Hmmm, I don't want to assume too much (because of course everyone's project needs are different), but that just sounds like a terrible idea. I guess there are solutions like goldiloader (I've never tried it), but 99% of the time I'd rather not load associated records unless I use them. When I need to load/use them along with many parent records, it seems pretty obvious that I'll want to include those associations (ea…

> Perhaps you don't want everything eager loaded, but you want an exception to be raised if you try to access an associated record that hasn't been preloaded.

Yes, exactly.

> When I need to load/use them along with many parent records, it seems pretty obvious that I'll want to include those associations (eagerly loaded) in my AR query to avoid N+1 queries as you mentioned. Then again, maybe I've just spent too long taking those assumptions for granted where newer devs might not.

You know that and I do too, but legacy Rails apps tend to be full of N+1 queries in my experience, and it's a major cause of slowdowns.

Re: Why I believe Rails is still relevant in 2019

#200

Post by dehrmann »

gjmacd wrote: post #185

The author took a bit of a pot shot at NodeJS (which I do understand why). But I think it's a bit naive to think NodeJS is any more complicated of a stack or problematic as a whole than Ruby -- it's simply not. As someone that's moved between many different stacks, once you're in that stack and being productive, you tend to realize "oh, this is why this is a good stack." From the outside, if you've never used the sta…

> When you can code on the server and on the client in terms of the same language

This was the promise of GWT.

Post reply on HN