Xavier Noria
@fxn.bsky.social
Everlasting student · Rails Core · Zeitwerk · Freelance · Life lover
They are symptoms of insufficient API we can workaround because even Kernel is open.
If I had hooks before/after, before can halt, and within synchronization, I could remove the decoration.
If I had hooks before/after, before can halt, and within synchronization, I could remove the decoration.
February 5, 2026 at 12:13 PM
They are symptoms of insufficient API we can workaround because even Kernel is open.
If I had hooks before/after, before can halt, and within synchronization, I could remove the decoration.
If I had hooks before/after, before can halt, and within synchronization, I could remove the decoration.
So on Linux, common in production servers and CI, eager loading won't save as much?
February 5, 2026 at 12:01 PM
So on Linux, common in production servers and CI, eager loading won't save as much?
Yep, close to that:
github.com/fxn/zeitwerk...
And I need to handle concurrency by hand, should check if that is needed anymore:
github.com/fxn/zeitwerk...
github.com/fxn/zeitwerk...
And I need to handle concurrency by hand, should check if that is needed anymore:
github.com/fxn/zeitwerk...
February 5, 2026 at 10:59 AM
Yep, close to that:
github.com/fxn/zeitwerk...
And I need to handle concurrency by hand, should check if that is needed anymore:
github.com/fxn/zeitwerk...
github.com/fxn/zeitwerk...
And I need to handle concurrency by hand, should check if that is needed anymore:
github.com/fxn/zeitwerk...
I could skip compilation for TruffleRuby if that was better.
February 5, 2026 at 10:46 AM
I could skip compilation for TruffleRuby if that was better.
It is 3 seconds aprox in Gusto's eager loading: 46s vs 43s roughly.
It's really interesting how, with all the things that are happening during eager loading, those syscalls save a non-trivial amount of time.
It's really interesting how, with all the things that are happening during eager loading, those syscalls save a non-trivial amount of time.
February 5, 2026 at 10:38 AM
It is 3 seconds aprox in Gusto's eager loading: 46s vs 43s roughly.
It's really interesting how, with all the things that are happening during eager loading, those syscalls save a non-trivial amount of time.
It's really interesting how, with all the things that are happening during eager loading, those syscalls save a non-trivial amount of time.
In the same line, regarding creating implicit namespaces upfront, I am not fully convinced for now. It introduces an asymmetry that could be saved if Ruby provided
autoload :Admin { Module.new }
*That* would be the way I'd like to remove the hack.
autoload :Admin { Module.new }
*That* would be the way I'd like to remove the hack.
February 5, 2026 at 10:24 AM
In the same line, regarding creating implicit namespaces upfront, I am not fully convinced for now. It introduces an asymmetry that could be saved if Ruby provided
autoload :Admin { Module.new }
*That* would be the way I'd like to remove the hack.
autoload :Admin { Module.new }
*That* would be the way I'd like to remove the hack.
Yep, I will play with it a bit still, and I agree with @byroot.bsky.social that saving even a bit is worth it. But the cost here is perhaps disproportionate.
A dramatic speedup would have felt different.
A dramatic speedup would have felt different.
February 5, 2026 at 10:24 AM
Yep, I will play with it a bit still, and I agree with @byroot.bsky.social that saving even a bit is worth it. But the cost here is perhaps disproportionate.
A dramatic speedup would have felt different.
A dramatic speedup would have felt different.
I am improving some details, let me ping you back before testing.
February 5, 2026 at 7:56 AM
I am improving some details, let me ping you back before testing.
/cc @byroot.bsky.social @eregon.me (just in case that one does not show up as a notification)
February 5, 2026 at 12:11 AM
/cc @byroot.bsky.social @eregon.me (just in case that one does not show up as a notification)
I have a first draft:
github.com/fxn/zeitwerk...
Speedup is measurable, it is of the order of 3.85% when booting Gusto's main app, and 6.52% when eager loading.
Is it worth it? I don't know, what do you think?
If you'd like to try, depend on the native branch.
github.com/fxn/zeitwerk...
Speedup is measurable, it is of the order of 3.85% when booting Gusto's main app, and 6.52% when eager loading.
Is it worth it? I don't know, what do you think?
If you'd like to try, depend on the native branch.
February 5, 2026 at 12:06 AM
I have a first draft:
github.com/fxn/zeitwerk...
Speedup is measurable, it is of the order of 3.85% when booting Gusto's main app, and 6.52% when eager loading.
Is it worth it? I don't know, what do you think?
If you'd like to try, depend on the native branch.
github.com/fxn/zeitwerk...
Speedup is measurable, it is of the order of 3.85% when booting Gusto's main app, and 6.52% when eager loading.
Is it worth it? I don't know, what do you think?
If you'd like to try, depend on the native branch.
Books by top authors accelerated learning.
USENET and mailing lists did so even more.
They were catalysts, not obstacles.
So we need to see how this unfolds. Some things won’t work, but what sticks is going to be a new paradigm.
USENET and mailing lists did so even more.
They were catalysts, not obstacles.
So we need to see how this unfolds. Some things won’t work, but what sticks is going to be a new paradigm.
February 4, 2026 at 12:00 PM
Books by top authors accelerated learning.
USENET and mailing lists did so even more.
They were catalysts, not obstacles.
So we need to see how this unfolds. Some things won’t work, but what sticks is going to be a new paradigm.
USENET and mailing lists did so even more.
They were catalysts, not obstacles.
So we need to see how this unfolds. Some things won’t work, but what sticks is going to be a new paradigm.
At the same time, we should be cautious about extrapolating from the previous world.
When the printing press was invented, people worried that memory skills would deteriorate, as oral transmission faded
And here we are, in a different world.
(BTW, did those people ever play the telephone game?)
When the printing press was invented, people worried that memory skills would deteriorate, as oral transmission faded
And here we are, in a different world.
(BTW, did those people ever play the telephone game?)
February 4, 2026 at 12:00 PM
At the same time, we should be cautious about extrapolating from the previous world.
When the printing press was invented, people worried that memory skills would deteriorate, as oral transmission faded
And here we are, in a different world.
(BTW, did those people ever play the telephone game?)
When the printing press was invented, people worried that memory skills would deteriorate, as oral transmission faded
And here we are, in a different world.
(BTW, did those people ever play the telephone game?)
*paradise mod it has to be seen how these solutions are maintained.
Becasue something that is happening is that people create. And, as it happens in business models, creation is the easy part.
Becasue something that is happening is that people create. And, as it happens in business models, creation is the easy part.
February 4, 2026 at 11:06 AM
*paradise mod it has to be seen how these solutions are maintained.
Becasue something that is happening is that people create. And, as it happens in business models, creation is the easy part.
Becasue something that is happening is that people create. And, as it happens in business models, creation is the easy part.
As most people, I am figuring AI out. Not AI per se, but my related personal feelings.
You won't grow as before. Can a junior develop seniority to review AI generated solutions? Maybe? To be seen.
The builders are in a paradise, the thinkers... not as much fun.
www.jernesto.com/articles/thi...
You won't grow as before. Can a junior develop seniority to review AI generated solutions? Maybe? To be seen.
The builders are in a paradise, the thinkers... not as much fun.
www.jernesto.com/articles/thi...
I miss thinking hard.
www.jernesto.com
February 4, 2026 at 11:03 AM
As most people, I am figuring AI out. Not AI per se, but my related personal feelings.
You won't grow as before. Can a junior develop seniority to review AI generated solutions? Maybe? To be seen.
The builders are in a paradise, the thinkers... not as much fun.
www.jernesto.com/articles/thi...
You won't grow as before. Can a junior develop seniority to review AI generated solutions? Maybe? To be seen.
The builders are in a paradise, the thinkers... not as much fun.
www.jernesto.com/articles/thi...
Reposted by Xavier Noria
📆 The CFP is closing soon! Join dedicated Rubyists, spark great conversations, and share ideas that inspire.
balkanruby.com
#RubyConference #RubyCommunity #CFP #CallforSpeakers
balkanruby.com
#RubyConference #RubyCommunity #CFP #CallforSpeakers
February 4, 2026 at 9:45 AM
📆 The CFP is closing soon! Join dedicated Rubyists, spark great conversations, and share ideas that inspire.
balkanruby.com
#RubyConference #RubyCommunity #CFP #CallforSpeakers
balkanruby.com
#RubyConference #RubyCommunity #CFP #CallforSpeakers
I guess my Stevens from 2001 could be updated 😅.
February 3, 2026 at 9:01 AM
I guess my Stevens from 2001 could be updated 😅.
Awesome, yours is battle-tested.
February 2, 2026 at 7:16 PM
Awesome, yours is battle-tested.
@eregon.me @byroot.bsky.social I am writing that extended directory listing in C in Zeitwerk itself, with fallback to stat functions if needed, and to Ruby as last resort.
By being internal it can ad-hoc, like, filter hidden files out, and only return :file, :directory, or nil. That is all I need.
By being internal it can ad-hoc, like, filter hidden files out, and only return :file, :directory, or nil. That is all I need.
February 2, 2026 at 6:30 PM
@eregon.me @byroot.bsky.social I am writing that extended directory listing in C in Zeitwerk itself, with fallback to stat functions if needed, and to Ruby as last resort.
By being internal it can ad-hoc, like, filter hidden files out, and only return :file, :directory, or nil. That is all I need.
By being internal it can ad-hoc, like, filter hidden files out, and only return :file, :directory, or nil. That is all I need.
And that cache saves a ton of time in gem dependencies, which generally do not change, they are just sitting there.
Where do you store the cache?
Where do you store the cache?
February 2, 2026 at 12:57 PM
And that cache saves a ton of time in gem dependencies, which generally do not change, they are just sitting there.
Where do you store the cache?
Where do you store the cache?
Aha, if the stat + cache says no entries were added/removed, you save the syscall for its listing right?
Yeah, so without the cache I'd do roughly twice as many syscalls for directories in the worst case.
That cache is a cool trick.
Yeah, so without the cache I'd do roughly twice as many syscalls for directories in the worst case.
That cache is a cool trick.
February 2, 2026 at 12:54 PM
Aha, if the stat + cache says no entries were added/removed, you save the syscall for its listing right?
Yeah, so without the cache I'd do roughly twice as many syscalls for directories in the worst case.
That cache is a cool trick.
Yeah, so without the cache I'd do roughly twice as many syscalls for directories in the worst case.
That cache is a cool trick.
You need to stat the dir to get the mtime right?
I believe forbidding extensions in directories that represent namespaces would have a comparable amount of syscalls in practice without the extra complexity.
I believe forbidding extensions in directories that represent namespaces would have a comparable amount of syscalls in practice without the extra complexity.
February 2, 2026 at 12:01 PM
You need to stat the dir to get the mtime right?
I believe forbidding extensions in directories that represent namespaces would have a comparable amount of syscalls in practice without the extra complexity.
I believe forbidding extensions in directories that represent namespaces would have a comparable amount of syscalls in practice without the extra complexity.
Ahhh, persisted would work yes.
February 2, 2026 at 11:55 AM
Ahhh, persisted would work yes.
Let me clarify just in case that booting the app does not mean launching a web server.
It means running the boot process that allow you to use the stuff. As in the runner or console commands, things are ready for you.
It means running the boot process that allow you to use the stuff. As in the runner or console commands, things are ready for you.
February 2, 2026 at 11:54 AM
Let me clarify just in case that booting the app does not mean launching a web server.
It means running the boot process that allow you to use the stuff. As in the runner or console commands, things are ready for you.
It means running the boot process that allow you to use the stuff. As in the runner or console commands, things are ready for you.