> 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
somewhatrandom9 5 hours ago [-]
byroot sets a great example sharing his code optimization expertise. His blog has many great improvements like this. A 7x improvement in Dir.join and similar calls?! Thank you, byroot!
vidarh 7 hours ago [-]
> More importantly, on CI systems it’s relatively common to check out code using git, and git doesn’t care about mtime
git doesn't care about mtime, but git maintains trees whose hash changes if any constituent part of the tree changes. It'd seem tempting to check for a .git and if present use the git tree to determine whether to invalidate the cache.
byroot 7 hours ago [-]
Aside from the oddness of making this cache git aware, with the new implementation I suspect querying git to revalidate the cache would take longer than just rebuilding it.
vidarh 7 hours ago [-]
Looking up the hash of a tree in git is few enough operations that I would be very surprised if that is true for all but the smallest caches. If you were to shell out to the git binary, maybe.
nixpulvis 8 hours ago [-]
Would this be possible to mainline into ruby in some way?
vidarh 7 hours ago [-]
From the article: "This new feature will be available in Ruby 4.1.0."
nixpulvis 7 hours ago [-]
Thanks, missed that.
blinkbat 8 hours ago [-]
don't take this the wrong way, but -- people still use ruby?
flats 7 hours ago [-]
Absolutely yes, all over the place! Startups are building greenfield software with Rails as we speak. Loads of established businesses have Ruby applications that are quietly chugging along doing their jobs well. & Shopify, a company with $1.6 billion in annual revenue, uses Ruby _very_ heavily & also invests in the wider Ruby ecosystem.
Ruby is not without its drawbacks & drama, but it’s elegant in a way that few languages are to this day (how many JS programmers _actually_ grok prototype-based object-orientation?) & compared to NPM, RubyGems is (lately) unexciting in the best way.
vidarh 7 hours ago [-]
For pretty much everything. My terminal is in Ruby, with a Ruby font renderer, running Ruby shell, and my editor is in Ruby, my window manager, my file manager.
(Yes, I'm taking it a bit far; my prototype Ruby compiler is self-hosting finally, so I guess sometime in the next 20 years I'll end up booting into a Ruby kernel for no good reason...)
simonask 5 hours ago [-]
I really like Ruby. It had a formative impact on my young programmer self, particularly the culture. So much joyful whimsy.
But like... something like a font renderer in Ruby? The thing that is incredibly cache sensitive and gets run millions of times per day on a single machine? The by far slowest step of rendering any non-monospaced UI?
The Earth is weeping my brother.
vidarh 4 hours ago [-]
It doesn't typically get run millions of times per day because in most regular uses it's trivial to cache the glyphs. I use it for my terminal, and it's not in the hot path at all for rendering, as its only run the first time any glyph is rendered at a new size. If you want to add hinting and ligatures etc., it complicates the caching, but I have no interest in that for my use, and then it turns out rendering TrueType fonts is really easy:
(Note that this is a port of the C-based renderer libschrift; the Ruby version is smaller, but much less so than "usual" when converting C code - libscrift itself is very compact)
andreynering 7 hours ago [-]
Ruby on Rails is the GOAT. Nothing comes close in joy and productivity, even in 2026.
nixpulvis 8 hours ago [-]
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.
t-writescode 4 hours ago [-]
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?
bradchris 3 hours ago [-]
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.
saghm 2 hours ago [-]
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.
bradchris 1 hours ago [-]
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.
weaksauce 3 hours ago [-]
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.
akerl_ 7 hours ago [-]
What’s the right way to take this?
x3n0ph3n3 6 hours ago [-]
It's my daily language and I don't even use rails nowadays.
vidarh 4 hours ago [-]
Same. I've used Rails a few times, but something like 95% of my Ruby use over the last 21 years has been non-Rails.
stackghost 4 hours ago [-]
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.
claudiug 7 hours ago [-]
ruby and rails is the only stuff that keep me doing web development.
when I touch js, and python... I prefer ONLY AI agentic style of working.
7 hours ago [-]
Rendered at 05:33:10 GMT+0000 (UTC) with Wasmer Edge.
Wow! I'd love to hear more about how that's achieved
git doesn't care about mtime, but git maintains trees whose hash changes if any constituent part of the tree changes. It'd seem tempting to check for a .git and if present use the git tree to determine whether to invalidate the cache.
Ruby is not without its drawbacks & drama, but it’s elegant in a way that few languages are to this day (how many JS programmers _actually_ grok prototype-based object-orientation?) & compared to NPM, RubyGems is (lately) unexciting in the best way.
(Yes, I'm taking it a bit far; my prototype Ruby compiler is self-hosting finally, so I guess sometime in the next 20 years I'll end up booting into a Ruby kernel for no good reason...)
But like... something like a font renderer in Ruby? The thing that is incredibly cache sensitive and gets run millions of times per day on a single machine? The by far slowest step of rendering any non-monospaced UI?
The Earth is weeping my brother.
https://github.com/vidarh/skrift
(Note that this is a port of the C-based renderer libschrift; the Ruby version is smaller, but much less so than "usual" when converting C code - libscrift itself is very compact)
Generally speaking Ruby has the best 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)
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?
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.
[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.
[].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.
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.
when I touch js, and python... I prefer ONLY AI agentic style of working.