[DeathArrow]

It's a bit late. If it was released by the time Rails was hip and cool it would for certain help with Ruby adoption and retention. But people in search for new and shiny thing jumped ships already to platforms such as Node.js which has decent performance.

Even for PHP the new VMs and speed improvements might be too late.

[montblanc]

Too late how? Shopify isn't doing this so all the Node people will come back to Rails. They're doing it to run their platform faster and eventually save money. They also like Ruby. Also - for the companies running on Ruby (there are still quite a few) this is big news.

[DeathArrow]

Too late to stop Rails going out of favor of developers. Too late to retain it's user base or grow.

[vidarh]

Ruby is not Rails. Ruby has been my primary language for 16 years by now (my work projects are in Ruby; my text editor is written in Ruby; I'm close to switching to a terminal written in Ruby), and in that time only a couple of side-projects have involved Rails. For web projects I prefer Sinatra or Padrino depending on requirements.

While the loss of the Rails hype has certainly made things quieter in the Ruby community, for people like me who never liked Rails in the first place the reduced Rails hype has been a blessing, because it means I don't get asked about Rails every time I bring Ruby to the table anymore.

[psychoslave]

What is your text editor?

[vidarh]

Unimaginatively named "re" for "Ruby Editor" - I started with the very tiny "Femto" [1] and expanded it heavily.

It's on Github [2] but note that the version on Github lacks a huge amount of changes sitting in my local tree that I haven't gotten around to cleaning up and pushing (including dependencies on how I've structured my local setup), and it'd be rough for anyone who isn't me and knows where the issues are. I'll eventually around to putting it into a somewhat more usable state for others to try...

A couple of "fun" aspects of it, though:

- It uses Rouge for syntax highlighting, and generally I've tried to rely as much as possible on gems rather than writing custom code (and I'm on a quest to split out whatever I can make generic enough into separate gems).

- It talks to a server process via Drb (going to change that for various reasons). The server process holds all the buffers, and snapshots them to a json file frequently. As a result every single file I've opened in Re the last several years - all 1600 of them - are retained as buffers and loaded into memory when I restart my laptop. I've not gotten around to adding a way to kill a buffer because they take up "only" 68MB total. The client-server approach meant I could switch to use it long before it stopped crashing, since as long as my changes don't corrupt the server-side buffers, it usually only crashes the client (even server-side exceptions gets passed along by Drb to the client)

- I rely on it calling out to a script to split panes, since I use a tiling vm (bspwm), so I have emacs like keybinding to split horizontally and vertically that uses bspc to control bspwm (I have a script for i3 as well) to split the pane accordingly and start another copy of Re that opens a view to the same serverside buffer. E.g. "split-vertical" just does "bspc node -p south ; exec #{cmd}" where "cmd" is a command line passed from re that will typically be <full path to re.rb> --buffer <numeric id of the buffer to open>.

- To open files or switch between buffers, or select themes, I use rofi rather than build a selector into Re. But it calls rofi by calling out to a script so anything that can take a list of buffers and open a dialog to select one will work (such as e.g. dmenu). E.g. here's the "select-buffer" script that is executed when I do ctrl x + b:

    re --list-buffers | rofi -dmenu -filter `pwd`/ -p "buffer"

Part of the idea is to make the editor itself as minimal as possible, and farm out everything that can be farmed out to either separate tools or separate gems.

[1] https://github.com/agorf/femto

[2] https://github.com/vidarh/re

[Lio]

What's funny to me is that Rails 7 is the release I've most looked forward to in years.

Being able to do page interactions over Hotwire without Webpacker with be a real productivity boost for me.

Having stuff like YJIT and Sorbet Compiler available if needed only makes it more attractive.

[dragonwriter]

> Too late to stop Rails going out of favor of developers.

I don't think anyone investing in this aims to restore peak Rails hype, so saying its too late to do that misses the point entirely.

[joelbluminator]

Yes so thats not why they are doing it, and I am not quite sure people flocked to Node because the runtime is faster...