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

Optimizing Ruby Path Methods

byroot.github.io

Post reply on HN
Print view View original

21–30 of 66 posts

Re: Optimizing Ruby Path Methods

#21

Post by stackghost »

blinkbat wrote: post #2

don't take this the wrong way, but -- people still use ruby?

I use Rails for many of my side projects. Because of the emphasis on convention over configuration, Rails codebases tend to be succinct with minimal boilerplate, which keeps context windows small. That in turn makes it great for agent-assisted work.

For web stuff, with server-side rendering and partials it means minimal requirement to touch the hot mess that is JavaScript, and you can build PWAs that feel native pretty easily with Hotwire.

Ruby is slow as fuck though, so there's a tradeoff there.

Re: Optimizing Ruby Path Methods

#22

Post by t-writescode »

nixpulvis wrote: post #4
blinkbat wrote: post #2

don't take this the wrong way, but -- people still use ruby?

People should. I seriously miss using it at my day job. It's not for code where type systems make things a lot more stable, but it's great for scripting and quick things. Also ORMs in ruby are truly nice, and I haven't found anything as good anywhere else. Generally speaking Ruby has the best APIs.

Frameworks and packages, sure. I’m not sure I would agree with APIs.

ActiveAdmin is best in class, Rails is fantastic; but there’s a lot of insanity in the API for a language that “gets out of the way” and “just works”

Slice is my favorite example. (It’s been a bit since I’ve used it)

  [0].slice(0, 100) == [0]
  [].slice(0, 100) == …
exception? Or nil? Why does it equal []?

For a “give me an array back that starts from a given, arbitrary index, and auto-handle truncation” not having that behavior continues to confuse me from an intuitive perspective. Yes, I understand the source of it, but why?

Re: Optimizing Ruby Path Methods

#23

Post by bradchris »

t-writescode wrote: post #22
nixpulvis wrote: post #4

Earlier quoted context omitted.

People should. I seriously miss using it at my day job. It's not for code where type systems make things a lot more stable, but it's great for scripting and quick things. Also ORMs in ruby are truly nice, and I haven't found anything as good anywhere else. Generally speaking Ruby has the best APIs.

Frameworks and packages, sure. I’m not sure I would agree with APIs. ActiveAdmin is best in class, Rails is fantastic; but there’s a lot of insanity in the API for a language that “gets out of the way” and “just works” Slice is my favorite example. (It’s been a bit since I’ve used it) [0].slice(0, 100) == [0] [].slice(0, 100) == … exception? Or nil? Why does it equal []? For a “give me an array back that starts from…

Because [] is an array with nothing in it, and [0] is an array with something in it.

So saying “give me the array containing the first 100 elements of this array with one element” would obviously give you the array with one element back.

Saying “give me the array containing the first 100 elements of this array with zero elements” would follow that it just gives the empty array back.

On top of that, because ruby is historically duck-typed, having something always return an array or an error makes sense, why return nil when there’s a logical explanation for defined behavior? Ditto for throwing an error.

Seems thoughtfully intuitive to me.

Re: Optimizing Ruby Path Methods

#24

Post by weaksauce »

t-writescode wrote: post #22
nixpulvis wrote: post #4

Earlier quoted context omitted.

People should. I seriously miss using it at my day job. It's not for code where type systems make things a lot more stable, but it's great for scripting and quick things. Also ORMs in ruby are truly nice, and I haven't found anything as good anywhere else. Generally speaking Ruby has the best APIs.

Frameworks and packages, sure. I’m not sure I would agree with APIs. ActiveAdmin is best in class, Rails is fantastic; but there’s a lot of insanity in the API for a language that “gets out of the way” and “just works” Slice is my favorite example. (It’s been a bit since I’ve used it) [0].slice(0, 100) == [0] [].slice(0, 100) == … exception? Or nil? Why does it equal []? For a “give me an array back that starts from…

because it's meant to be a more functional language. if slicing an array out of bounds threw an error it would be java.

[].slice(0, 100).each do |x| puts x end

that shouldn't be an error and it seems to be the principle of least surprise imo.

Re: Optimizing Ruby Path Methods

#25

Post by saghm »

bradchris wrote: post #23
t-writescode wrote: post #22

Earlier quoted context omitted.

Frameworks and packages, sure. I’m not sure I would agree with APIs. ActiveAdmin is best in class, Rails is fantastic; but there’s a lot of insanity in the API for a language that “gets out of the way” and “just works” Slice is my favorite example. (It’s been a bit since I’ve used it) [0].slice(0, 100) == [0] [].slice(0, 100) == … exception? Or nil? Why does it equal []? For a “give me an array back that starts from…

Because [] is an array with nothing in it, and [0] is an array with something in it. So saying “give me the array containing the first 100 elements of this array with one element” would obviously give you the array with one element back. Saying “give me the array containing the first 100 elements of this array with zero elements” would follow that it just gives the empty array back. On top of that, because ruby is hi…

Yeah, returning an empty array is pretty much exactly what I would expect given the first example. It would be a lot weirder to me if you were allowed to give an end index past the last element only if the array happened to be non-empty.

Re: Optimizing Ruby Path Methods

#26

Post by bradchris »

saghm wrote: post #25
bradchris wrote: post #23

Earlier quoted context omitted.

Because [] is an array with nothing in it, and [0] is an array with something in it. So saying “give me the array containing the first 100 elements of this array with one element” would obviously give you the array with one element back. Saying “give me the array containing the first 100 elements of this array with zero elements” would follow that it just gives the empty array back. On top of that, because ruby is hi…

Yeah, returning an empty array is pretty much exactly what I would expect given the first example. It would be a lot weirder to me if you were allowed to give an end index past the last element only if the array happened to be non-empty.

Especially because in ruby

[0, nil, nil, nil, …x100, nil] is the same as [0] in terms of access.

In both cases, trying to access the 100th element (e.g. [0][100]) will give nil.

Re: Optimizing Ruby Path Methods

#29

Post by digitaltrees »

nixpulvis wrote: post #4
blinkbat wrote: post #2

don't take this the wrong way, but -- people still use ruby?

People should. I seriously miss using it at my day job. It's not for code where type systems make things a lot more stable, but it's great for scripting and quick things. Also ORMs in ruby are truly nice, and I haven't found anything as good anywhere else. Generally speaking Ruby has the best APIs.

I actually think types are an anti pattern. I’ve seen more code with type escape hatches than bugs in Ruby. The truth is if you follow TDD and good coding patterns the bugs in a dynamic environment are unlikely to show up.

Re: Optimizing Ruby Path Methods

#30

Post by byroot »

chi_features wrote: post #27

> Given that the Intercom monolith CI runs with 1350 parallel workers by default Wow! I'd love to hear more about how that's achieved

Nothing ground breaking we simply deploy Buildkite agents on EC2 nodes.

As mentioned in the post, the only thing really limiting CI parallelism is the ratio of "setup time" vs "test time". If your setup time is too long, you hit diminishing returns fast.

Post reply on HN