#ruby

rv plan and progress update https://lobste.rs/s/wiugee #ruby https://andre.arko.net/2026/06/13/rv-plan-and-progress/

So #bundler added support for cooldowns. https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html Aside: This feature is mostly developed by Claude. I haven't reviewed the code. Maybe it's fine. Maybe hsbt did actually read, understood, and guided all the code generated here. But in any case it's kinda depressing that even #Ruby, "a Programmer's Best Friend" language with goals like happiness and fun is outsourced to AI that neither can have fun, nor can be happy, nor have friends. Anyway, I don't fully get the appeal. My main point of contention is that it's a solution trice removed from the problem. The problem is "supply chain security". Sometimes malicious packages get pushed to package registries. It's not that much of a problem if the package is completely new as it doesn't have users yet and people tend to be cautious about new packages. But it's a problem for established projects that get compromised. They have a lot of users and many people depend on them. So a compromised package with lots of users needs very little time to get installed all over and execute its evil plots. Someone noticed that it doesn't take much time for people to notice that something's not right. Just days, even mere hours. And they came up with a solution: what if we don't install packages right as they get released but wait, say, a week? It's a self-defeating strategy. Imagine everyone does this. No one installs packages until they get a week old. How will people know if something's not right if no one's using the package? The whole thing depends on someone noticing that something's not right. But the fewer people use the package the lower the chance that someone will notice. Package cooldowns work great for the small fraction of users in the beginning. But the closer cooldowns adoption goes to 100% the less effective it becomes. It also implicitly relies on someone noticing an issue. And someone investigating it. Someone needs to a) install the package, b) notice the issue, c) investigate it. None of this is guaranteed by cooldowns. A more explicit strategy would be that every package needs a certain amount of reviews from the users to become generally available. So every package upon release becomes available on the index for review. A package manager notifies users that a new version is available in staging and they can help it move along. The package is not available for automatic installation. There's a diff to the previous version that people can review. This is my first idea and it certainly can be improved but, as an example… Users who reviewed the package and approved it can install it right away. The package becomes generally available once a certain amount of reviews came in. E.g. 0.5% of weekly downloads, or 5, 10, 20, etc. approvals from highly trusted well known people in the community who are not involved in the project. As opposed to cooldowns this explicitly depends on actual reviews. Unlike cooldowns, wider adoption improves efficiency: more reviews—faster availability. It also promotes the "best practice" of actually reading the code you install. Now, to make it a thing I need a catchy name for it. I'm taking suggestions.

hi ruby.social 👋 i'm Razvan, rails dev based in barcelona. day job at Velory on rails 8 stuff. after hours i've been building EZLogs (ezlogs.io), a small gem that captures HTTP + Sidekiq + ActiveRecord into one plain-English card per user action. no AI in the path, just deterministic translation. got tired of being the person support pinged to "check what user X did yesterday". so i wrote the thing that translates. happy to be here. #introduction #ruby #rails

Formatting an entire 25 million line codebase overnight: the rubyfmt story https://lobste.rs/s/pv9i7j #ruby https://stripe.dev/blog/formatting-an-entire-25-million-line-codebase-overnight-the-rubyfmt-story

Blue Ridge Ruby 2026 https://lobste.rs/s/gzosvk #event #ruby https://microblog.thomascannon.me/2026/05/03/blue-ridge-ruby.html

Ruby for "shell scripting" (2024) via @wezm@mastodon.decentralised.social https://lobste.rs/s/bzdkdz #ruby https://ratfactor.com/cards/ruby-shell-scripts

7 reasons I switched back to PHP after 2 years on Rails (2007) https://lobste.rs/s/uhsedd #php #ruby https://sive.rs/rails2php

Who remembers this *other* #Ruby app deployment tool? 😬 https://web.archive.org/web/20130217071823/http://rubyhitsquad.com/Vlad_the_Deployer.html

spinel - Ruby AOT native compiler https://lobste.rs/s/kd4xkt #ruby #vibecoding https://github.com/matz/spinel

llm.rb is Ruby's most capable AI runtime https://lobste.rs/s/emcmxd #ai #ruby https://github.com/llmrb/llm.rb#readme

Using Perfetto in ZJIT https://lobste.rs/s/wx9ozr #performance #ruby https://railsatscale.com/2026-03-27-using-perfetto-in-zjit/

Ruby Association 2025 Grant Accomplishment Report https://lobste.rs/s/rle1gw #ruby https://www.ruby.or.jp/en/news/20260416

Another rubocop/standardrb gripe: Style/EmptyLiteral: Use hash literal {} instead of Hash.new Nah, I have my own heuristics for when to use which one. If it's inside a block with braces, I assert that: # the "approved" butthole syntax let(:params) { {} } looks worse than # ain't nothing wrong with this let(:params) { Hash.new } #rubocop #standardrb #ruby

Ruby Central report reopens wounds over RubyGems repo takeover https://www.theregister.com/2026/04/01/ruby_central_report/

Board-backed account of maintainer ouster is unlikely to settle row over governance, control, and trust

Ruby Central, a nonprofit that supports the #Ruby programming language ecosystem, just published an incident report regarding what it calls the September 2025 RubyGems fracture, when ownership of the #GitHub code repository behind the RubyGems package manager was wrested from existing maintainers.

Ruby Central publishes an incident report about the RubyGems repo takeover—and it immediately reopens all the wounds. The original controversy: Ruby Central (the nonprofit) asserted control over RubyGems and Bundler repos, removed maintainers from GitHub orgs, and blurred the line between running a service and owning the ecosystem. Investigations later alleged Shopify manipulated Ruby Central into the takeover. Now the report tries to provide closure but the community isn't having it. Classic open source governance crisis: who owns the infrastructure everyone depends on? #OpenSource #Ruby #Governance #RubyGems Source: https://www.theregister.com/2026/04/01/ruby_central_report/

Culada de cosas de adulto para hacer y obviamente me colgué a escribir un script en Ruby para el que tuve que instalar rbenv en la Raspberry Pi y ruby-build desde git para poder instalar Ruby 4.0.1 mientras pruebo implementar lo mismo con Bash pero me doy por vencido porque no me quiero aprender toda la sintaxis de jq. Pero bueno, ahí quedó todo andando. Aguante Ruby. #Ruby

Optimizing Ruby Path Methods https://lobste.rs/s/gisyhv #c #performance #ruby https://byroot.github.io/ruby/performance/2026/04/18/faster-paths.html

TruffleRuby 34: full Ruby 3.4 compatibility, up to 23% faster parsing, and a new Prism-based Ripper with 20x speedups https://lobste.rs/s/krdjnf #release #ruby https://truffleruby.dev/blog/truffleruby-34-is-released

Rails on the BEAM https://lobste.rs/s/mksk9n #elixir #javascript #ruby https://intertwingly.net/blog/2026/04/02/Rails-on-the-BEAM.html

Ruby 3.2 Is EOL: What You Actually Need to Do https://lobste.rs/s/kpizkt #ruby https://piechowski.io/post/ruby-3-2-eol/