[HN Gopher] Ruby 4.0.0 Preview2
       ___________________________________________________________________
        
       Ruby 4.0.0 Preview2
        
       Author : pansa2
       Score  : 182 points
       Date   : 2025-11-18 13:34 UTC (9 hours ago)
        
 (HTM) web link (www.ruby-lang.org)
 (TXT) w3m dump (www.ruby-lang.org)
        
       | lloydatkinson wrote:
       | I didn't know Ruby has three different JITs
        
         | hartator wrote:
         | Yes, specially ZJIT is news to me.
        
         | shevy-java wrote:
         | Mostly the newer ones try to improve the older ones.
         | 
         | I guess at some later point one will dominate and the others
         | will go sleep mode. Just like in the movie Highlander - there
         | can only be one. (I couldn't name offhand which JIT is the main
         | one right now ... I always think it is from Takashi Kokubun but
         | that may now be outdated. MJIT YJIT ZJIT HUJIT WAJIT WTFJIT
         | GRANDMAJIT - too many JITs.)
        
         | Lio wrote:
         | I was actually hoping it would be four JITs and we'd get
         | Tenderlove's tiny FFI JIT too.
         | 
         | https://railsatscale.com/2025-02-12-tiny-jits-for-a-faster-f...
        
         | pjmlp wrote:
         | It actually has several more, if you take into account JRuby +
         | all JVM implementations (OpenJDK based distros, OpenJ9, Azul,
         | PTC,...), ART even if not JVM proper with Ruboto, and
         | TruffleRuby on GraalVM.
        
       | falcor84 wrote:
       | Any particular changes of interest?
        
         | dudeinjapan wrote:
         | ZJIT is supposed to be an improvement on YJIT. I'm happy to get
         | any free performance improvements!
         | 
         | The Ruby Ractor (Actor) interface is now completely changed to
         | use a Ractor::Port class, mirroring IPC (inter-process
         | communication) semantics. Ractors were added in 3.0 as a way to
         | get around the GVL/GIL, but having N number of Ruby
         | interpreters running in a Ruby process which would enable
         | executing on N cores at once. For me, hot take but Ractors
         | don't seem to offer major advantages over plain-ol' copy-on-
         | write (COW) forking.
         | 
         | The one "big" feature was supposed to be namespaces, which
         | apparently have now been renamed to Ruby::Box
         | (https://docs.ruby-lang.org/en/master/box_md.html). From what I
         | can glean from the Ruby issue tracker, it appears this feature
         | has been radically descoped, primarily because it had
         | performance impacts, but also, I think probably there are
         | realistic concerns about fit with the existing ecosystem.
         | Unlike Javascript/Python, Ruby has never used "modules" for
         | code isolation--everything is loaded into the global namespace
         | (the "global dumping ground" as I call it.) Now the Box feature
         | is only enabled with an environment variable RUBY_BOX=1
         | 
         | https://bugs.ruby-lang.org/issues/21311
        
           | shevy-java wrote:
           | I don't think it has really descoped. They just want the
           | transition to be smooth. So they start slowly. The lead
           | japanese dev will most likely in 2026 go for more extension,
           | and I also think this kind of has to be synced a bit with
           | ractor (I think?).
           | 
           | Ractor is also strange. Do many people use ractors? I rarely
           | see them used in actual ruby code out there. Right now it
           | seems to me as if ractors are used by only ... say ... 1% or
           | fewer of the ruby developers out there. A bit more than
           | refinement users ... :P
        
             | dudeinjapan wrote:
             | Ractors have promise but the implementations up till now
             | haven't had strong concurrency safety. It seems in the
             | latest release some of the heavy-hitter contributors like
             | Jean Boussier (byroot) have taken a detailed look at
             | Ractors and started to clean things up.
             | 
             | https://byroot.github.io/ruby/performance/2025/05/24/unlock
             | i...
        
           | frou_dh wrote:
           | I'm happy if that feature has been descoped because when I
           | last read up on it, it seemed like it was being ramrodded in
           | by an inner circle who were hardly interested in constructive
           | criticism even from other Ruby core maintainers.
        
             | dudeinjapan wrote:
             | I had a talk with Matz 1-on-1 about 6 months back and
             | expressed my doubts about namespaces :) He's a nice guy, he
             | just smiled.
        
               | bradly wrote:
               | I had a similar experience when I asked him what he
               | thought about vars being able to end in a question mark.
               | Very nice guy who probably hears a lot of very bad ideas.
        
           | throw-the-towel wrote:
           | Isn't everything loaded into the global namespace in
           | Javascript as well? I'm talking about named imports.
        
         | sdwolfz wrote:
         | The NEWS link details a bit more:
         | 
         | https://github.com/ruby/ruby/blob/v4_0_0_preview2/NEWS.md
         | 
         | What is interesting to me is the `Ractor.shareable_proc`
         | changes that solved a bug for a use case I was having. And in
         | general fixes for Ractors make them more appealing to use right
         | now, even though they have not removed the `Experimental` flag
         | from them. They are still missing a built-in concurrency
         | primitive like channels or a lock free queue; I'm curious what
         | they will settle on, Ractor::Port is nice but not enough.
        
         | thomascountz wrote:
         | Ruby::Box (formally: Namespace)
         | 
         | https://docs.ruby-lang.org/en/master/box_md.html
         | Ruby Box is designed to provide separated spaces in a Ruby
         | process, to isolate applications and libraries.
        
       | shevy-java wrote:
       | It is 4.0.0 largely because matz created ruby 30 years ago.
       | 
       | matz is no longer the youngest - although he does look young, he
       | is already 60 years old. He also said he has a retirement plan,
       | e. g. avoiding a situation such as when Guido quit (or semi-quit)
       | from Python (due to fatigue/frustration; Guido is not 100%
       | retired but he is also not necessarily the solo-design-dev
       | either, so it is a bit of a semi-retirement). So we won't know
       | how long matz will be the lead designer of ruby - and who will
       | succeed. Which may be reason to worry depending on who it would
       | be. Imagine DHH takes over - man, there would be an insta-exodus
       | of people ...
       | 
       | So while this release does not have a lot of content as such, one
       | thing that is quite big, even though right now it is not, is
       | Ruby::Box. There are many who don't understand it. The thing is
       | ... I understand the use cases for it. I was not involved in any
       | way with regards to its design, mind you - that was mostly a
       | japanese-group in design. But there are objective use cases for
       | it.
       | 
       | Many years ago I recall on IRC (we oldschool people used IRC back
       | in the pre-discord stone age) some C# hacker said he won't use
       | ruby because there are no strong namespaces, that is, someone
       | else can just overwrite things and then nothing works. Although I
       | think he was a drama guy, and any "danger" to be minimal,
       | objectively he has had a point, simply because ruby had no strong
       | concept of isolation here. Lateron there came refinements. Now
       | refinements are strange, because while I think the use case makes
       | sense, the syntax is strange. Syntax is one huge reason why I do
       | not use refinements; but also because I try to avoid putting my
       | own modifications all over the place, largely because I'd have to
       | distribute that too, and also because modifying core classes,
       | while that has a use, should not be done excessively, IMO.
       | 
       | Ruby::Box kind of builds on that and makes the refinement use
       | case more generic (eventually; I am aware that right now this is
       | not the case but you need a transition stage. Syntax-wise
       | Ruby::Box is also weird, so hopefully the syntax gets easier too,
       | but I instantly understood the use cases. Many people don't, in
       | particular about 95% who demanded a name change away from
       | Namespace to something else, really don't understand the
       | underlying use case.)
       | 
       | Now - making isolated per-project changes is not the only use
       | case. For instance, ractors could be simplified if you know that
       | there are separate ruby processes; ruby threads probably too.
       | These I consider secondary benefits though (and yes, that may be
       | far in the future, who knows; when python removed its GIL though,
       | it put ruby under pressure, aka shape-up-or-go-extinct mode).
       | 
       | One thing I would complain a lot is that on rubygems.org, before
       | RubyCentral went shopify-controlled-only, that people would
       | occupy namespaces. Such as Configuration. I wanted to have a
       | project called Configuration so I can do Configuration.new or
       | Configuration.parse_this_file(). This is possible of course, but
       | when it comes to distributing code, who owns that toplevel
       | namespace? Normally the one who occupied the name first on
       | rubygems.org, sort of. Via Ruby::Box, it should be possible to
       | have ownerships. This could be strong or weak; weak as a hint,
       | aka "psych is owned by ruby core ownershiper but it can be
       | modified", or strong aka making it immutable. Both have use
       | cases. Could also be both. Having this more organized would be
       | really convenient for developers. I would not have to worry
       | whether anyone else uses that "namespace". And of course we need
       | a way to query this state from within ruby code too aka, say
       | immutable:
       | 
       | "If psych is owned by ruby-core, continue to use it."
       | 
       | psych (for yaml) is not a good example here but you can think of
       | any other namespace where you may only want to consider some
       | gems/projects but not others. (Again, the use case may differ
       | between strong and weak ownership, but the thing is that this is
       | an improvement over the prior status quo.)
       | 
       | There are several additional use cases to be had but I'll stop
       | here. What I find strange is that many people who complain, don't
       | refer to the old issues and discussions. We had discussions
       | before refinements were added. About 80% of the people involved,
       | DON'T EVEN KNOW THESE OLD DISCUSSIONS. Either they have dementia,
       | or these are young ruby users who never were active in the old
       | days. It's very strange.
       | 
       | I am not saying all is perfect about Ruby::Box, in particular
       | syntax-wise I'd like improvements, but many people don't seem to
       | understand the use cases, and this is very very strange.
        
         | dudeinjapan wrote:
         | Ruby::Box in its current form seems to radically miss the mark.
         | Any namespace paradigm only has utility if it is widely adopted
         | across the ecosystem. Javascript did this with ES modules 10
         | years ago--it IS possible--but it takes a ton of buy-in and
         | effort from the community to achieve it.
         | 
         | I just don't think Ruby has this "burning need" to have
         | namespaces/modules/erm... "boxes". So we're likely to end up
         | with sporadic usage of Boxes leading to inconsistent behavior.
        
         | thebigkick wrote:
         | Curious, why would DHH trigger a mass exodus?
        
           | flykespice wrote:
           | Would you keep using a programming language leaded by a
           | racist? I wouldn't
        
             | npteljes wrote:
             | If programming is just my hobby, then maybe. But would you,
             | for example, quit your current job and look for another,
             | just to change the programming language? I know I'm not
             | that sort of person.
        
               | chipotle_coyote wrote:
               | I think it's not as much "if this guy becomes the lead
               | I'm immediately quitting my Ruby job to return to PHP" as
               | much as "if this guy becomes the lead I'm probably going
               | to return to PHP for my next job."
        
               | npteljes wrote:
               | I have my doubts, even for this softer version. These are
               | things where one might feel very strongly in a moment, or
               | even for a longer time, but facing a real life decision,
               | there are so many other factors.
               | 
               | Of course we will never know the outcome of this, it's
               | just my two cents.
        
               | yes1would wrote:
               | Yup, I quit Shopify because the CEO and COO are both
               | Nazis, and coincidentally Tobi is good friends with DHH.
        
             | dudeinjapan wrote:
             | This is exactly why we shouldn't use KKScript either. Plus
             | it has 1-based array indexes.
        
             | jeltz wrote:
             | Ruby is not and has never been led by DHH.
        
           | throwaway48921 wrote:
           | I'd much prefer Jeremy Evans[0] taking over rather than DHH.
           | Jeremy is a Ruby core committer (and much more pleasant
           | person), unlike DHH.
           | 
           | [0] - https://github.com/jeremyevans
        
             | brigandish wrote:
             | _Anyone_ who won 't discriminate against others for their
             | politics would be an improvement, because that's not what's
             | been happening in many core projects.
        
               | throwaway48921 wrote:
               | I am not suggesting Jeremy Evans simply because of
               | politics. I think he's very underrated in the community
               | and the work he does is incredible. Having interacted
               | with him a number of times, he's been really helpful and
               | pleasant. I think those qualities make him a good
               | candidate.
               | 
               | Fun fact: Jeremy won the Ruby Prize 2019:
               | https://rubyprize.jp/19_iv-nominees01-2-en.html
        
               | brigandish wrote:
               | I agree. He has scolded me before though, for submitting
               | code he didn't like the look of. Felt a tad harsh at the
               | time, that's the kind of thing that puts people off
               | contributing. However, he's a better programmer than me
               | so if he didn't like it he's probably right. Could
               | improve his bedside manner a bit though. I'm sure others
               | have said that about me too, perhaps I'm a hypocrite.
               | 
               |  _Regardless_ of that, _anyone_ who doesn 't discriminate
               | against others for their politics would be an
               | improvement.
               | 
               | Edit: a improvement on the other westerners in the core
               | team who might be touted as the next benevolent dictator,
               | as I doubt that benevolence would maintain.
        
               | throwaway48921 wrote:
               | > I agree. He has scolded me before though, for
               | submitting code he didn't like the look of.
               | 
               | Heh, do you have a link to the PR?
        
               | jeltz wrote:
               | In every interaction with Evans I have had he has been
               | super nice and welcoming to contributors. Maybe he had a
               | bad day.
        
             | throwaway48921 wrote:
             | Curious why this suggestion was downvoted to hell.
        
               | jeltz wrote:
               | No idea, Jeremy Evans is a really good coder and a nice
               | person. Also a much more influential voice in the Ruby
               | community than DHH.
        
               | igravious wrote:
               | I've no idea Jeremy ;-)
        
               | jeltz wrote:
               | That is clearly not Jeremy Evans. Maybe a funny joke if
               | that innocent commenter had not been downvoted to hell.
        
           | brigandish wrote:
           | The Ruby "community" has long been dogged by politics and
           | culture war stuff. This comment[0] on a flagged submission
           | has lots of links for getting up to speed.
           | 
           | Maybe they're right, there would be an exodus, I just wonder
           | if other languages' _communities_ will want the trouble. The
           | Japanese Rubyists don 't care for a second, a nice by-product
           | of Japanese insularity. Ruby would continue in Japan just
           | fine without westerners, don't worry.
           | 
           | [0] https://news.ycombinator.com/item?id=45379652
        
           | dymk wrote:
           | Ignoring DHH's politics (which are enough to make me look for
           | alternatives), he makes breaking technical decisions to
           | tooling with little to no community involvement. E.g.,
           | https://github.com/hotwired/turbo/pull/971
           | 
           | He makes it difficult to trust that, were he in charge of
           | Ruby, he wouldn't just take the reigns and stubbornly do
           | whatever he thinks is technically right for "aesthetics" at
           | the cost of all else.
        
           | culi wrote:
           | A mantra in the Ruby community is "Matz is nice so we are
           | nice". By contrast, DHH is the type of person who would use
           | the hey.com domain[0] to post rants about London being only
           | 1/3rd white, "Pakistani rape gangs", etc. His racist tirades
           | used to be limited to his twitter, but he's shown he's very
           | willing to use business resources to push his racist
           | politics. More discussions here:
           | 
           | - https://lobste.rs/s/fpri94/dhh_problem_2014
           | 
           | - https://old.reddit.com/r/ruby/comments/1no4zu2
           | 
           | [0] https://world.hey.com/dhh/as-i-remember-london-e7d38e64
        
         | werdnapk wrote:
         | Ruby dev since 2000 and looks like refinements have been
         | available since 2.4. I just used them for the first time this
         | year. Definitely not a go to feature for me, but it was nice
         | the feature was available.
        
         | davidw wrote:
         | As a practical matter, I don't think DHH is a Ruby internals
         | geek, particularly, and seems to have other hobbies as well, so
         | I don't think that's likely to even be a thing the community
         | faces.
        
         | ecshafer wrote:
         | If Matz ever retires, I hope it is still maintained by Japanese
         | devs, to keep the insanity that is western politics out of it.
        
           | bdcravens wrote:
           | While there's certainly drama of technical and personality in
           | many projects, are there any languages that we can see
           | evidence of "insanity of western politics" being present?
        
             | ecshafer wrote:
             | There are literally people in this thread saying they
             | wouldnt use ruby if dhh became lead because of his
             | politics. Ruby in the west it seems to come up a lot.
             | Mozilla/JS it came up with brendan eich being fired for his
             | politics. Mostly its against anyone that steps out of line
             | with far left san fransisco politics.
        
               | culi wrote:
               | i don't think it's unreasonable to not want someone who
               | has a habit of ranting about "Pakistani rape gangs" on
               | twitter to represent/head a community project. Especially
               | one that has contributions from people all over the
               | world. Even ethics aside it's just bad business
        
       | ksec wrote:
       | Nothing about Fibres and Async from Samuel Williams ?
        
       | kmarc wrote:
       | I'm tasked to amend a project written in ruby. With a python
       | background (and some nice pydantic, type annotated, etc "strong"
       | code bases behind my back), every day I spend with ruby is a
       | minefield, a nightmare.
       | 
       | I hoped that ruby4 maybe implements stuff that python has, like
       | type annotations or making the damn parens mandatory, but no. Not
       | surprised that python has ten times more developers according to
       | stackoverflow's survey... I can't possibly imagine a
       | collaborative project where other people also have to work on the
       | same code base, and not having any clue what a symbol under the
       | cursor might be.
       | 
       | No type hints. No mandatory requires. No parens, so never know if
       | something is a method or, callable, or variable. Basically IRB is
       | a must for development, because in the editor, I'm blind.
       | 
       | And the ecosystem is just sad. Swagger-rails libraries out there
       | are rookie jokes compared to what python has. At least there is
       | decent GRPC / protobuf integration, so all new services I am
       | writing can be in python. Or any sane language.
        
         | phantasmish wrote:
         | I've sworn off Rails development for anything short of stupid-
         | high compensation for similar reasons.
         | 
         | Implicit imports ("... which package defined this symbol? Who
         | knows!"), dynamic definitions all over the place ("where's this
         | defined? Literally nowhere until the program runs!"), all that
         | stuff. It's awful. I feel blind not being able to answer basic
         | questions about a codebase with grep. And that's not even
         | considering the lack of static typing.
        
         | dalenw wrote:
         | I used to be a big ruby/rails fan but I have to agree with you.
         | I now write c-sharp and it's a lot less stressful than Ruby. If
         | a Ruby/Rails codebases get to a large enough point it's really
         | difficult to keep track of what types a method you wrote
         | accepts. You end up just constantly double checking your own
         | code. Or you end up with a few type checks and/or type
         | conversions at the top of every method. And maybe I was doing
         | it wrong because it was early on in my career. But when a
         | method can accept literally anything and return literally
         | anything, not even a strong IDE like RubyMine can save you.
        
         | chihuahua wrote:
         | People on HN seem to hate it whenever someone criticizes Ruby.
         | But the language is a sad joke that's gone on for too long. I
         | totally agree with your points and have many more I could
         | mention (lack of proper debugger support and shitty tooling in
         | general - these things exist, but they break every week)
         | 
         | The 4.0.0 release notes (TFA) are like a joke. Here are the
         | language changes in their entirety:
         | 
         | Language changes: *nil no longer calls nil.to_a
         | 
         | That's it.
        
           | zem wrote:
           | if you just need to write a few hundred lines of code to
           | automate something ad hoc, or play with an idea, or do
           | something exploratory like reverse engineering a file format,
           | ruby is a truly gorgeous language. it just hasn't added the
           | affordances you need to maintain a large code base, which is
           | sad because python has shown that you really don't need that
           | many of them - type annotations and explicit exports that act
           | as namespaces would go a long way.
        
           | phantasmish wrote:
           | I actually love it for small scripts (not more than a couple
           | hundred lines), including small web services and such. Much
           | more pleasant than Python (though Python handles growing
           | beyond a couple hundred lines _way_ better than Ruby does)
           | 
           | I really like a few of its smaller libraries. Just not Rails.
        
         | wiseowise wrote:
         | What's with the downvotes? Every word here is true.
        
           | arp242 wrote:
           | Because it's just generic complaining on a random Ruby post.
           | It's just boring language flamewar bollocks that we can have
           | on every post on every language.
        
             | kmarc wrote:
             | I guess the relevant point I missed to emphasize is that I
             | would have hoped that the situation is becoming better with
             | the next major version, but as others also pointed out, it
             | doesn't.
        
           | jazzyjackson wrote:
           | Truth <> Relevancy
        
         | pkkm wrote:
         | Similar feelings here. Ruby's philosophy of providing a ton of
         | different ways to do the same thing can lead to some pretty
         | sweet-looking code, almost like poetry... but I'd rather have
         | Python's stylistic consistency and better-integrated type
         | hints. Now that Python has Poetry and uv, Ruby's main remaining
         | advantage has evaporated and it's hard for me to justify using
         | the language.
         | 
         | Another thing I don't like about Ruby is how much the community
         | has embraced the Clean Code brand of readability snake oil.
         | It's easy to come by the opinion that any function over 5 lines
         | is a code smell and over 10 lines it's outright bad. I've even
         | heard the view that if-else statements are a code smell and I
         | should always try to replace them with different classes that
         | have the same interface. To be fair, that only happened twice,
         | but that's two more times than I've heard it from users of any
         | other language. I think that the Python community usually
         | strikes a better balance between avoiding excessive
         | function/class length and avoiding excessive indirection.
        
           | throwaway48921 wrote:
           | > Another thing I don't like about Ruby is how much the
           | community has embraced the Clean Code brand of readability
           | snake oil.
           | 
           | This also puts me off every time, and I've dealt with people
           | who embrace this a lot as a Ruby programmer. Fortunately, you
           | can ignore them and still enjoy writing Ruby code the way you
           | want.
        
           | kmarc wrote:
           | I feel you. Rubocop is certainly rather a bikeshedding tool
           | than a linter at this point.
           | 
           | The forced if/else transformations drive me nuts.
        
         | arp242 wrote:
         | This is a classic "I am used to language X. I am now trying
         | language Y, but nothing in language Y is like language X! Why
         | can't language Y be like language X?!"-type post. Yes, Ruby is
         | a different language. It does things differently and priorities
         | different aspects.
        
         | dragonwriter wrote:
         | > I hoped that ruby4 maybe implements stuff that python has,
         | like type annotations
         | 
         | Ruby has had type annotations and typecheckers for quite a
         | while. Unfortunately (IMO) the annotations are not inlinine.
         | 
         | > or making the damn parens mandatory, but no.
         | 
         | A linter/formatter can give the effect of that (and tune it for
         | where it is appropraite) whether or not the language has it,
         | though there are good reasons Ruby does not in general.
         | 
         | > No parens, so never know if something is a method or,
         | callable, or variable.
         | 
         | Method and local variable are the only possibilities (callables
         | are either the value of local variables or the return value of
         | method calls),
        
         | haolez wrote:
         | I don't know. In my experience, the real nightmare is when a
         | competitor uses Rails and has strong developers. Their velocity
         | is insane and I don't see things falling apart when the project
         | gets bigger. Nowadays, I pray that my competitors use something
         | like .NET or Spring Boot. And this comes from someone who never
         | developed in or lead teams that use Rails.
        
       | thiago_fm wrote:
       | Very little happened in Ruby since 3.2 or even 3, it feels
       | stagnated. Still a very beautiful language from my point of view,
       | but yeah, stagnation.
       | 
       | Wish we'd see more action on RBS, perhaps getting Sorbet to core
       | or something. At least having some sort of consensus in the
       | community.
       | 
       | Or even some considerable project in the JIT, dunno!
       | 
       | Python is definitely ahead in types, work on removing the GIL...
       | list is huge.
        
         | honeycrispy wrote:
         | I was so disappointed in how RBS was executed it caused me to
         | give up on Ruby and move onto something else. I haven't looked
         | back.
        
           | rco8786 wrote:
           | I'm still a Ruby fan but I share your immense, nearly
           | immeasurable disappointment on the implementation of RBS.
           | It's as though someone was tasked to add types to Ruby but do
           | it specifically in a way that would guarantee zero adoption.
        
             | dtech wrote:
             | Out of curiosity, why was RBS so poorly executed and
             | adopted?
        
         | culi wrote:
         | > Wish we'd see more action on RBS
         | 
         | This is always my biggest complaint about Ruby. Last time I
         | made a fuss about this on HN someone pointed out rbs-inline
         | which might make it into the core rbhs gem itself soon! This
         | would be huge for the Ruby community imo
         | 
         | https://github.com/soutaro/rbs-inline
        
       | to-too-two wrote:
       | With talk here of Ruby stagnating, has anyone checked out
       | Crystal? I have not but have been curious about it.
        
         | princevegeta89 wrote:
         | I checked out crystal. It's a nice little language, but it has
         | a very, very long way to go. IDE support is still quite shaky
         | and the developer community is not large enough yet. There are
         | some few good packages and frameworks that work very well
         | though. I think it's still not supported on Windows as of
         | today.
        
         | wmoxam wrote:
         | It has similar syntax, but adding explicit types and macros
         | it's a very different language in practice.
         | 
         | IMO the two languages can be quite complimentary, I've been
         | exploring using Crystal + MRuby to create apps, it's been fun
         | so far.
        
         | jazzyjackson wrote:
         | One man's stagnation is another's stability, no?
        
       ___________________________________________________________________
       (page generated 2025-11-18 23:01 UTC)