I hope Ruby 4.0 could allow explicit import and avoid implicit, global namespace gem import mechanism like nowsdays.
You won't see Ruby 4.0 until 2030.
https://youtu.be/4MM5b2F9zrM?si=UT3aUbD6p_uBZehS&t=2347
Ruby 3.3
61–70 of 277 posts
Re: Ruby 3.3
#62I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years. I never thought Ruby would have a shipping and production ready JIT before Python. And Prism, Lrama, IRB. A lot of these were discussed in previous HN submissions. But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async. Especially in the context of Rails. I am wo…
The one thing I genuinely don't understand is why there is no single task queue that works across ruby and python. I get that at some point people just started making http based microservices to pass information around, but at the end of the day a simple task queue that has a unified storage format across both is a better way to connect ruby(rails) based with the ml stack. There are probably thousands of custom rabbi…
There is Perl Directory::Queue / Python dirq which also has implementations in Go, Java, and C.
A Ruby implementation would probably not be hard.
I don't how much people use this in serious or high performance work but it might be an option.
Re: Ruby 3.3
#63Friendly reminder that Ruby 3.0 will now go EOL in 3 months, so you have 12 weeks to upgrade.
I don’t think I will.
Re: Ruby 3.3
#64I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years. I never thought Ruby would have a shipping and production ready JIT before Python. And Prism, Lrama, IRB. A lot of these were discussed in previous HN submissions. But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async. Especially in the context of Rails. I am wo…
The one thing I genuinely don't understand is why there is no single task queue that works across ruby and python. I get that at some point people just started making http based microservices to pass information around, but at the end of the day a simple task queue that has a unified storage format across both is a better way to connect ruby(rails) based with the ml stack. There are probably thousands of custom rabbi…
There's beanstalkd, it has a few Python libraries and it works out of the box with ActiveJob via Backburner.
Re: Ruby 3.3
#65Worth it to learn Ruby if you already know Python and NodeJS ? I find Ruby fascinating yet difficult.
If you're productive in Node or Python, then learning Ruby would just be educational in that it's something else to use. Personally, I've found Ruby to be a great language in which I can be productive quickly, which is why I stick with it, but I've written Ruby code off and on for the last 15 years in various forms of production code. I think it's great to learn, but I wouldn't switch to it (or anything) if you're already productive elsewhere.
Re: Ruby 3.3
#66Worth it to learn Ruby if you already know Python and NodeJS ? I find Ruby fascinating yet difficult.
I worked with ruby, ruby in rails(RoR) more specifically, a bit more than ten years ago(2011-2013). At that time it was already the afterglow of RoR, the framework for web development that had come to life in 2005 and raged between 2007 and 2009. The latest-technology-addicted crowd was jumping into the boat of node.js, that was crazy fast compared to anything done RoR, and API oriented development with angularjs. In 2013 RoR already showed its age as the standard ways of doing things with it was still the monolithic way and the framework was not transitioning very well to the new paradigm of frontend/backend development.
This introduction about a framework built with ruby and not ruby itself was necessary because even today, I would guess that 95% of all development with ruby is RoR applications. It's my understanding that ruby rose to prominence mostly because of ruby on rails, now that RoR is in a downward trend I think ruby will follow the same trend until it's reduced to a small community of enthusiasts in the same way that happened to perl.
As for the language itself I can't think of a single reason to opt for ruby over python or typescript. Ruby doesn't do anything better both in terms of language or platform than its already better established competitors.
Re: Ruby 3.3
#67Earlier quoted context omitted.
> I never thought Ruby would have a shipping and production ready JIT before Python. This is entirely predictable - Ruby does not have a big scientific computing community which happened to depend on every implementation detail of the hosting interpreter.
Python has a culture that sees writing C libraries as "Python" code, hence why. It is quite common to see "Python" libraries that are just thin bindings layers, they could just as well be "Tcl" libraries for that matter.
I should start doing numerical work in TCL and see how long it takes for me to get set to the mad house
Re: Ruby 3.3
#68Worth it to learn Ruby if you already know Python and NodeJS ? I find Ruby fascinating yet difficult.
I think Ruby is much better at shell script like tasks and interactive / exploratory programming for system tasks compared to Python or Node. Use it as “better bash” or “better Perl” and it’s worth it. I primarily work in a Typescript codebase, but regularly reach for it as a tool to wrangle log data, semi-structured text, or do regex rewrites of a bunch of files. Ruby is also very fun, probably the most fun language…
This is very intriguing, could you please elaborate? I have been looking for a better bash for scripting stuff without all the bash and sh-isms and gotchas.
Re: Ruby 3.3
#69I believe with version 3.3 Ruby is back in a big way! The language focused on developer happiness and derided for its slowness is slow no more. YJIT is an amazing technology, and together with other innovations like object shapes and various GC optimizations, Ruby is becoming seriously fast! Big Ruby shops such as Shopify [1] have been running 3.3 pre-release with YJIT and reporting double digit percentage performanc…
I don't know if a slight performance increase is going to sell anyone on ruby but I'm glad they're making incremental improvements on things. Being overly concerned about performance is almost always premature optimization, and ruby is more than fast enough for everything I've ever asked of it (including the binding glue between our redis DNS record storage and PowerDNS, where the entire stack serves half a billion queries a month across 14 tiny VPSes without even a blip on htop). I probably could have just used ruby instead of PowerDNS but it's generally not great to roll-your-own on public facing encryption, HTTP, DNS, etc. It wasn't really a performance consideration for me.
The recent irony of the web is anyone that implemented a web app with "slow" ruby and backend rendering now has the fastest page loads compared to bloated front-end web apps backed by actually slow eventually consistent databases that take seconds to load even the tiniest bits of information. I see the spinner GIF far too often while doing menial things on the "modern" web.
Re: Ruby 3.3
#70Earlier quoted context omitted.
Python has a culture that sees writing C libraries as "Python" code, hence why. It is quite common to see "Python" libraries that are just thin bindings layers, they could just as well be "Tcl" libraries for that matter.
I should start doing numerical work in TCL and see how long it takes for me to get set to the mad house
Well, first step is to create bindings to the same libraries Python uses.