Makes me miss Ruby. Been in node typescript recently. Everything is a callback returning a promise in some weird resolution chain, mapped and conditional types, having to define schemas for everything and getting yelled at by lsp all day... Oh then you gotta write react components and worry about rerenders and undefined behavior caused by impurity in state, npm, arcane .json configs
Versus active record, mvc, yaml configs, bundler, beautiful syntax, robust and trivially extendable stdlib, amazing native debugging and cli docs out of the box, everything out of the box if you're using Rails
I do not understand why it becomes increasingly irrelevant, especially in web development. I kinda get scripting--bash and python tend to run everywhere
Spot on. The worst thing is digging through 500 lines of nested JSON just to find one tiny type mismatch that broke the build. Most diff tools make it worse by showing 100 changes when 99 of them are just whitespace noise. Really makes you miss the simplicity of Ruby/Rails.
Lack of static types is one of the main reasons. Trying to decipher a complex ruby on rails codebase is unnecessarily difficult compared typescript. The tooling is also shit unless you use Ruby Mine.
An absolute shame given how good the functionality is baked into RoR.
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!
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.
What happened to Ruby? It was very successful at some point.
Maybe kids started using JS exclusively. But what happened to older developers? Did they move over?
Rails seemed to enable very fast prototyping and iteration. Isn't it still the case?
I see PHP usage going down, but PHP doesn't seem to have any advantages over JS, .NET, Python or Go. While Ruby coupled with Rails promised easy and rapid development.
Of course, Ruby might not be best suited for large code bases or microservices but probably 90% of the Internet are small to medium web sites.
> Ruby might not be best suited for large code bases
Ruby/Rails powers some of the largest platforms on the planet - Shopify, GitHub, GitLab. Both have had something of a resurgence lately, too, with Ruby 4 and Rails 8 shipping recently, and people rediscovering that Rails is excellent for vibe coding.
I've been a Ruby developer for 10+ years and have never struggled to find work, and the communities feel very active and growing - so I'm honestly not sure what you mean by "what happened to Ruby". If you don't actively follow or participate in the community, I can imagine you wouldn't hear much about it day to day.
I don't pay attention to the JS world these days - what happened to JavaScript?
Nothing has happened to Ruby, it's an excellent choice for software. We're basically at a point where majority of languages and stacks are on par with each other (unless you have niche requirements)
> But what happened to older developers? Did they move over?
I'm working on a project with a Rails backend and a Vue frontend.
I've been working on a JS backend and frontend project in the early 2010s but I think that it was the only project with a JS backend. There are plenty of projects with server generated HTML. In my case the backends were Ruby, Python, Elixir, Java, PHP.
PHP + Laravel give the same easy and rapid development as Ruby + Rails. Plus PHP reads as a programming language. Ruby reads as it was written by somebody with heavy brain damage struggling to put words into sentences.
> 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.
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.
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.
nice write-up! I wonder tho - did the optimization really affect CI wall time? In my experience such micro optimization rarely move the needle - it obviously matters because a lot jobs are running in parallel, but did it in the end improved dev experience? (honest question, just curious)
Alone it wouldn't have been very noticeable, but I did many small optimizations like that, which ultimately shaved about 20 seconds of setup time.
Looking from another angle, the app boot time on CI (not eager loading) was a bit more than 10 seconds, this saved over half a second, so a ~5% gain for an afternoon of work.
64 comments
Versus active record, mvc, yaml configs, bundler, beautiful syntax, robust and trivially extendable stdlib, amazing native debugging and cli docs out of the box, everything out of the box if you're using Rails
I do not understand why it becomes increasingly irrelevant, especially in web development. I kinda get scripting--bash and python tend to run everywhere
> Everything is a callback returning a promise in some weird resolution chain
Care to provide some examples of this? This hasn't been my experience, in general.
Any async chain really where the steps are in a pipeline
An absolute shame given how good the functionality is baked into RoR.
> getting yelled at by lsp all day
God forbid you get forced to fix bugs before they reach production.
> 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
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.
More EC2 workers means more parallelism means tests map to more workers and the CI build finishes faster. It’s just CI perceived complete time.
Maybe kids started using JS exclusively. But what happened to older developers? Did they move over?
Rails seemed to enable very fast prototyping and iteration. Isn't it still the case?
I see PHP usage going down, but PHP doesn't seem to have any advantages over JS, .NET, Python or Go. While Ruby coupled with Rails promised easy and rapid development.
Of course, Ruby might not be best suited for large code bases or microservices but probably 90% of the Internet are small to medium web sites.
> Ruby might not be best suited for large code bases
Ruby/Rails powers some of the largest platforms on the planet - Shopify, GitHub, GitLab. Both have had something of a resurgence lately, too, with Ruby 4 and Rails 8 shipping recently, and people rediscovering that Rails is excellent for vibe coding.
I've been a Ruby developer for 10+ years and have never struggled to find work, and the communities feel very active and growing - so I'm honestly not sure what you mean by "what happened to Ruby". If you don't actively follow or participate in the community, I can imagine you wouldn't hear much about it day to day.
I don't pay attention to the JS world these days - what happened to JavaScript?
> But what happened to older developers? Did they move over?
I'm working on a project with a Rails backend and a Vue frontend.
I've been working on a JS backend and frontend project in the early 2010s but I think that it was the only project with a JS backend. There are plenty of projects with server generated HTML. In my case the backends were Ruby, Python, Elixir, Java, PHP.
People moved to efficient IO requiring smaller servers.
If you make Ruby on Rails in a typed compiled language and show people how fast it is. People will switch in an eyeblink.
> 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.
Alone it wouldn't have been very noticeable, but I did many small optimizations like that, which ultimately shaved about 20 seconds of setup time.
Looking from another angle, the app boot time on CI (not eager loading) was a bit more than 10 seconds, this saved over half a second, so a ~5% gain for an afternoon of work.