Why I believe Rails is still relevant in 2019 • Hacker News Board

Re: Why I believe Rails is still relevant in 2019

#211

Post by gingerlime » Tue, Mar 19, 2019, 4:24 PM UTC

nathan_long wrote: post #201

gingerlime wrote: post #197

Earlier quoted context omitted.

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 (…

That's interesting to learn...

I always assumed caching is a necessary evil if you want to speed things up.

I certainly feel like rendering views is rails is slower than I'd like it to be (talking about the rendering part alone), especially with partials.

How do you deal with views that pull dynamic data that produce a heavy query however?

Re: Why I believe Rails is still relevant in 2019

#212

Post by bluesnowmonkey » Tue, Mar 19, 2019, 4:28 PM UTC

cutler wrote: post #196

wrestlerman wrote: post #165

Earlier quoted context omitted.

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.

Elixir definitely comes up short on raw computation. However we've been very satisfied with it for implementing a database. Use data oriented design (you want that anyway) and move any CPU intensive part into a native function. It's pretty straightforward to bind a C/C++/Rust library.

Re: Why I believe Rails is still relevant in 2019

#213

Post by expliced » Tue, Mar 19, 2019, 4:29 PM UTC

lmm wrote: post #121

your-nanny wrote: post #119

Earlier quoted context omitted.

better than postgresql? and what would that be?

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.

Which one of those tools should I use if in trying to achieve relational modeling?

Re: Why I believe Rails is still relevant in 2019

#214

Post by LyndsySimon » Tue, Mar 19, 2019, 4:45 PM UTC

I see nothing at all wrong with Rails - I find it to be a perfectly valid choice in 2019, if that's what you want to use.

That said, I'm not a huge fan of Ruby in general. I'm a Pythonist, and don't see that changing in the near future. Python seems more straight-forward and "shallower" than Ruby to me, and there's less "magic". I'll even contend that Ruby is a more powerful language than Python - but with the caveat that this in fact is its greatest weakness.

The example that comes to mind for me is when I needed to flash multiple alerts to the user using Rails; I re-opened the class Rails used to implement the behavior and modified it to keep an iterable of messages instead of only one. It was easy, sure... but what happens when the Rails class changes in the next version? My changes not only weren't guaranteed to be compatible, they weren't encapsulated from the parent class, and didn't define and verify its behavior. I can totally see a circumstance where my class would appear to work without error, but the underlying implementation might have changed in subtle and unknown ways.

With Python, I'd have subclassed the parent implementation and wired my subclass up to the application. RoR doesn't make this approach easy, and even if it did, it's not idiomatic for that language.

Re: Why I believe Rails is still relevant in 2019

#215

Post by temuze » Tue, Mar 19, 2019, 4:56 PM UTC

LyndsySimon wrote: post #214

I see nothing at all wrong with Rails - I find it to be a perfectly valid choice in 2019, if that's what you want to use. That said, I'm not a huge fan of Ruby in general. I'm a Pythonist, and don't see that changing in the near future. Python seems more straight-forward and "shallower" than Ruby to me, and there's less "magic". I'll even contend that Ruby is a more powerful language than Python - but with the caveat…

I agree 100%.

Ruby follows Perl's philosophy of "there is more than one way to do it."

That sounds terrible! When you scale an organization, do you really want everyone doing everything in their own unique way?

Python has a more practical philosophy:

> There should be one-- and preferably only one --obvious way to do it.

While this sounds a little fascist, it enforces consistency. It means that a senior Python programmer will see code from another senior Python programmer and say to themselves "yup, I'd make it exactly this way if I wrote it myself."

Re: Why I believe Rails is still relevant in 2019

#216

Post by JangoSteve » Tue, Mar 19, 2019, 5:03 PM UTC

nathan_long wrote: post #199

emptyroads wrote: post #191

Earlier quoted context omitted.

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 t…

Looks like the bullet gem does what you want.

https://semaphoreci.com/blog/2017/08/09/faster-rails-elimina...

https://github.com/flyerhzm/bullet

EDIT: It looks like this was already mentioned in another thread. I guess I don't understand the issue if that doesn't solve your problem.

Re: Why I believe Rails is still relevant in 2019

#217

Post by philwelch » Tue, Mar 19, 2019, 5:08 PM UTC

TheRealDunkirk wrote: post #210

philwelch wrote: post #202

Earlier quoted context omitted.

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…

Even for internal use, you have to worry about data integrity a lot of the time.

> I also worked at a bespoke consultancy that made Rails sites for startups

Ah, so didn't have to handle the maintenance burden afterwards. I did. Rails is awesome if you can just dump the maintenance burden on someone else and move on.

Re: Why I believe Rails is still relevant in 2019

#218

Post by yebyen » Tue, Mar 19, 2019, 5:11 PM UTC

richjdsmith wrote: post #131

gashaw wrote: post #118

Ruby is great, Rails is good enough. The main issue with Rails (it's the same with other frameworks) is that it discourages from doing proper design. The only design decision you make is where to put a piece of code, which is ridiculous ("Fat models, skinny controllers" is a bad design heuristic.) Following Rails conventions works for small (simple) applications, but over time you arrive at a point where no one under…

Adding a services directory with logic moved out from my models into POROs helped a lot for taming the mess.

Can you share a link about what you mean by this?

I went searching but came up pretty empty ... do you literally mean adding an "app/services" directory, is that all? Where you put classes related to external dependencies that aren't ActiveRecord?

Re: Why I believe Rails is still relevant in 2019

#219

Post by JangoSteve » Tue, Mar 19, 2019, 5:11 PM UTC

subfay wrote: post #168

freehunter wrote: post #147

Earlier quoted context omitted.

So let's just forget about Basecamp, Github, AirBnb, Hulu, Kickstarter, MyFitnessPal, Twitch and all the other Rails sites and continue to pretend Rails can't scale and won't work for the modern web.

None of them is on a standard unmodded Rails stack.

I'm not sure any highly-scaled, mature application is on a standard unmodded anything stack.

Re: Why I believe Rails is still relevant in 2019

#220

Post by yebyen » Tue, Mar 19, 2019, 5:15 PM UTC

freehunter wrote: post #151

gumcreme wrote: post #115

While reading this thread, it feels like a flashback from 2009 and now, I remember what was my biggest gripe with Rails (next to all the bad parts mentioned here in this thread): It is the culture. I really find the Rails culture odd or tbh, I utterly dislike it. I mean if met a Go guy, he tells me all good with Go, it gets the job done but it has its warts, the same with Rust, node, React and so on. People of other…

Maybe this is because everyone has spent the last 10 years telling them that Rails is dead, they're stuck to a dead technology, and Go no wait Dart no wait Rust no wait Javascript no wait Node no wait React no wait Phoenix is better.

Yes. Literally ten minutes before Amazon announced their Lambda support for Ruby at this year's re:Invent conference, one of our lead architects who was watching the livestream sent out (and I quote)

> I guess if you want to know which languages will dominate the industry going forward, just look at what Lambda supports.

> AWS Lambda supports code written in Node.js (JavaScript), Python, Java (Java 8 compatible), and C# (.NET Core) and Go.

Tongue firmly inserted in cheek, aimed directly at our large cohort of Ruby developers, as if to imply that we're mostly irrelevant to the future of the industry, and it shows in Amazon's lack of support for our ecosystems.

Then immediately following that message, Amazon announced they have added support for Ruby... and PHP, and Cobol. And suddenly it's "I guess AWS is out of the choosing business." I'm still salty about this, forgive me please. But the refrain is tiresome, and it continues even today.