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

Friendly attributes pattern in Ruby

brunosutic.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Friendly attributes pattern in Ruby

#61

Post by whstl »

cortesoft wrote: post #54
whstl wrote: post #34

Earlier quoted context omitted.

This attitude towards wastefulness is how you have web apps that could run in a single machine but struggle to run in a server cluster. And after a couple years even Postgres is struggling because the amount of queries is too massive because of abstractions that don’t lend themselves to optimization. Also it’s how you have codebases that could be maintained by two or three suddenly needing dozens because the testing…

Again, though, these bottlenecks are because of how the system queries the database, not how methods are dispatched. I agree on the ORM abstractions causing huge performance issues, but it has nothing to do with Ruby’s dynamic method declarations.

I'm not talking about method dispatch, I'm talking about the "usual response to this complaint in the Ruby/Rails community".

Re: Friendly attributes pattern in Ruby

#62

Post by fny »

obiefernandez wrote: post #57
fny wrote: post #53

Earlier quoted context omitted.

The reality is most companies and products never blow bast the point of needed to ditch Rails. The argument made at the time was scaling horizontally is cheaper than hiring new devs, and you probably will never need to scale that much horizontally. Test suite bloat is a different problem that stems from the lack of incremental typing which I think is what ultimately killed Ruby and Rails. Any big Rails codebase can b…

Nothing has “killed Ruby on Rails”. Ridiculous comment.

I'm honored to have you of all people make that comment.

But with all due respect the excitement and job market for Ruby isn't anything close to what it used to be:

[0]: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...

Re: Friendly attributes pattern in Ruby

#63

Post by AlphaSite »

boredtofears wrote: post #47
dlisboa wrote: post #18

Earlier quoted context omitted.

> The usual response to this complaint in the Ruby/Rails community is that optimizing for nanoseconds, or even milliseconds doesn't matter when the same operation also involves multiple database queries or API calls The problem with that logic is that it’s pervasive: people have that same attitude everywhere even if no IO is being done. That’s how we get multi gigabyte processes. The whole language (and Rails) also p…

> For instance you’re probably iterating over those six plans and inserting them individually in the DB. Another approach would’ve been to accumulate all of them in memory then build and perform a single query. That’s not something people really consider because it’s “micro” optimization and makes the code look worse. This same pitfall exists in every language. This has nothing to do with Ruby.

eh. Ruby makes it easy to do the wrong thing. imo.

Re: Friendly attributes pattern in Ruby

#64

Post by AlphaSite »

sfgvvxsfccdd wrote: post #28

Haters gonna hate. My take: DSLs are a useful way to make code easier to read, and more importantly easier to write correctly . Exploring this space and sharing your learnings is useful and valuable.

Ruby is a language that optimizes for the local maxima at the cost of the global maxima.

Now every library, company or code base has its own pattern and you have to learn its pit falls. Better to learn once, cry once and just deal with it imo.

As they say, good enough is the enemy of perfection.

Re: Friendly attributes pattern in Ruby

#65

Post by boredtofears »

AlphaSite wrote: post #63
boredtofears wrote: post #47

Earlier quoted context omitted.

> For instance you’re probably iterating over those six plans and inserting them individually in the DB. Another approach would’ve been to accumulate all of them in memory then build and perform a single query. That’s not something people really consider because it’s “micro” optimization and makes the code look worse. This same pitfall exists in every language. This has nothing to do with Ruby.

eh. Ruby makes it easy to do the wrong thing. imo.

Maybe, but this isn’t one of the ways it does.

Re: Friendly attributes pattern in Ruby

#66

Post by Footkerchief »

drzel wrote: post #31

plans = { 1.month => {standard: 10, pro: 50, enterprise: 100}, 1.year => {standard: 100, pro: 500, enterprise: 1000} } plans.each do |interval, details| details.each do |name, amount| Billing::Plan::Factory.find_or_create_by!(name: , interval:, amount:) end end

Exactly. Use a fancy expressive structure if you want, but don't try to abstract away the mapping between that and the general-purpose code that it relies on. "Each domain has its own rules"? How would I even know where to look for those?

Re: Friendly attributes pattern in Ruby

#67

Post by sodapopcan »

shevy-java wrote: post #4

I don't really like the API design. Perhaps in the rails-world this makes sense, but it looks really strange to me. Billing::Plan::Factory.find_or_create_by!( name: :pro, interval: 1.month, amount: 50 ) It is not only the verbosity or use of trailing '!' in a method for no real reason, IMO, but also things such as "1.month". I understand that rails thrives as a DSL, but to me having a method such as .month on an Inte…

`1 + 1` in Ruby is syntactic sugar for `1.+(1)`. Nothing wrong about it at all, it's just different from what you're apparently used to. This type of thing isn't even unique to Ruby or even OOP.

Re: Friendly attributes pattern in Ruby

#68

Post by dlisboa »

radanskoric wrote: post #36
dlisboa wrote: post #29

Earlier quoted context omitted.

Yes, every web app I’ve worked on the past ~18 years has been with Rails. I’ve seen it all except an efficient app. Sure, Ruby and Rails never bankrupted these companies but they’d all have been better off with something else. Certain cloud bills would’ve been much smaller for sure. Those optimizations to the VM are just very workload specific and become less relevant today when you’re using containers and fractional…

Can you explain why you say they would be better off? What else would be a better choice and why?

Just want to reiterate what the sibling commenter said, it's dead on with my experience.

Static typing would be the main thing teams would've been better off with. I was big on dynamic languages, love Clojure/LISPs and still work with Ruby and JS today, but you just can't trust 100 developers with it. Last company I worked for I ran the dev team and did some bug analysis: conservatively 60% of bugs were things a simple static type system would've caught.

Very few business logic bugs. We had loads of tests but these simple bugs still popped up. Someone in team A would change a method's return type, find and replace in the codebase, but miss some obscure case from team D. Rinse and repeat. Nothing complicated, just discipline but you can't trust discipline on a 500k LoC codebase and a language with no guardrails.

Performance would've been the other main advantage of static typing. While most people think their Rails app will be IO-bound forever that's really downplaying their product. In actuality every company that mildly succeeds will start to acquire CPU-bound workloads and it'll come a point where they are the bottleneck. One might argue that it is at this point you ditch Ruby but in reality no one really wants to run a polyglot company: it's hard to hire, hard to fill in gaps, hard to manage and evaluate talent.

People underestimate the impact of performance on the bottom line these days with phrases like "memory is cheap; devs are not". Like the sibling commenter put it the monthly cloud bill on that last company would've paid about 20 dev salaries. Most of that was for the app servers. That for an app that served about 500 req/sec at peak. You can imagine the unnecessary pressure that puts on the company's finances.

Better choices would've been Go, Rust, even something on the JVM.

Re: Friendly attributes pattern in Ruby

#69

Post by nosman »

jaredcwhite wrote: post #40
montroser wrote: post #39

This is...not for me. It follows a big pattern in Ruby/Rails culture where to understand the code, you first have to understand the magic. And, it's never all that obvious where to go to try and understand the magic, because the magic itself has been imported by magic. I once was hackathoning with a colleague who was trying to get me excited about Rails, and he said, "look how great this is -- if you want the idea of…

1.method(:day).source_location shrug Look, I'm not a big fan of all of Rails' monkeypatching. That's why I don't use Rails anymore, I use other Ruby frameworks like Bridgetown, Roda, and Hanami. But there's definitely a way to dive into the "magic" and find out what's going on.

how does this work if i import two different gems that both monkeypatch the same classes?

Even if you can see the source, it still seems difficult to understand where the monkeypatch came from if you have transitive dependencies and whatnot.

Re: Friendly attributes pattern in Ruby

#70

Post by rokob »

nosman wrote: post #69
jaredcwhite wrote: post #40

Earlier quoted context omitted.

1.method(:day).source_location shrug Look, I'm not a big fan of all of Rails' monkeypatching. That's why I don't use Rails anymore, I use other Ruby frameworks like Bridgetown, Roda, and Hanami. But there's definitely a way to dive into the "magic" and find out what's going on.

how does this work if i import two different gems that both monkeypatch the same classes? Even if you can see the source, it still seems difficult to understand where the monkeypatch came from if you have transitive dependencies and whatnot.

The last one wins
Post reply on HN