return to table of content

Ruby 3.3

ciconia
50 replies
10h3m

I 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 performance improvements.

Personally I'm really excited about Ruby and its future. I can't wait to start working with Ruby 3.3 and using it on my client's production sites...

[1] https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...

Edit: add percentage to performance improvements.

IshKebab
28 replies
9h10m

double digit performance improvements

You mean like 10% faster, or 10x faster?

Edit: clicked the link; it's 10%. I don't think that's going to make any difference to the perception of Ruby's slowness given that it's on the order of 50-200x slower than "fast" languages like Rust, Java, Go and C++.

ciconia
10 replies
7h10m

Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. In any case, it's still early to determine the impact on performance from upgrading to Ruby 3.3. I guess we'll be able to tell more in the coming months.

pdimitar
9 replies
6h25m

Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime.

Hardly relevant, I'd think at least 80% of all Ruby usage everywhere is in Ruby on Rails applications.

Alifatisk
6 replies
5h28m

It is relevant if the cause of the slowness is due to the framework rather than the language itself.

The performance can vary drastically depending on which Ruby framework you use, so it's not due to the language but the upper layer instead.

Note, even if Rails is the most popular framework, there is still other alternatives which makes it even more relevant to the performance impact.

resonious
5 replies
4h26m

I suspect there's not just one cause of slowness here. Pure language benchmarks also tend to rank Ruby very low. So I'd wager that a fast Ruby framework would still lose to a fast Go framework.

cutler
3 replies
1h53m

Apples to oranges again. A more relevant comparison would be Ruby to Python and in recent years Ruby has edged ahead in performance if you factor-out Python's C-based libraries such as Numpy.

csjh
2 replies
1h23m

Isn’t factoring out C based libraries ignoring a large part of the Python ecosystem?

cutler
0 replies
49m

Yes, but if you're comparing language performance that's important.

Alifatisk
0 replies
57m

I haven’t used Python in years but from what I’ve understood by reading other comments, factoring out C-based libraries would rule out a large portion of what makes Python so popular. Especially on the scientific side.

So I think you’re right.

Alifatisk
0 replies
4h17m

Absolutely, I should maybe clarify that I did not mean to say that we can fully rule out the language itself as a cause of the poor performance, Ruby always perform worse than Go in this example for obvious reasons.

But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion! And that is what I was trying to point out.

ajmurmann
1 replies
32m

How much of the time in a given request is even spent in Ruby code? The majority of web apps that were slow and I got a chance to analyze were spending much of the time in DB queries and slowness was usually due to unoptimized DB queries. Even endpoints that were fast, still spent a large percentage of their time not in Ruby but in DB and service requests

pdimitar
0 replies
16m

That is true, yes, but still comparing e.g. Rust vs. Ruby I'd think Rust spends anywhere from 10ns to 100ns (outside of waiting on DB) and Ruby no less than 10 ms. Still pretty significant and can add up during times of big load.

Also I remember Rails' ActiveRecord having some pretty egregious performance footprint (we're talking 10ms to 100ms on top of DB waiting) but I hear that was fixed a while ago.

Alifatisk
10 replies
8h41m

I seriously don’t think it’s worth comparing Ruby to languages like C++ and the rest.

One is scripting language, the other compiled, the difference is huge already there.

pdimitar
8 replies
6h25m

I seriously don’t think it’s worth comparing Ruby to languages like C++ and the rest.

It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends.

Anything and everything that has a web backend is a fair game for comparison.

ric2b
3 replies
2h22m

Building a web backend with C++ is a very dangerous and complex ordeal, you're extremely likely to expose memory based vulnerabilities to the entire world.

pdimitar
1 replies
2h12m

I agree but people are doing it anyway. So technically Ruby on Rails and C++ are competitors in the web backend space.

Alifatisk
0 replies
50m

RoR and whatever C++ based web backend there is count as a valid comparison in my book. But comparing the languages itself is maybe a bit off.

On a side note, you can actually compare their performance here if you’re really curious. But take it with a grain of salt since these are synthetic benchmarks.

https://www.techempower.com/benchmarks

jupp0r
0 replies
2h1m

Google, Facebook, Amazon and Twitter beg to differ (not completely C++, but for services where it makes sense). Also nginx, passenger and other parts of your Ruby app.

cutler
2 replies
1h49m

Web backends in Rust and C++? Not saying web frameworks in these languages don't exist but to claim they're anything other than curiosities is misleading. In any case, good luck with the fraction of a millisecond such languages gain you while waiting on database i/o. There are use cases for switching to a compiled language like Rust or C++. Web back-ends isn't one of them.

wredue
0 replies
15m

Nah. One rust based server can power the same number of connections as 10-100 ruby based servers.

This is not just “pretend database IO” problem. This is actual cost that no business should accept on the basis of “but but but database IO (that I’ve never actually measured, but it’s an easy cop out because I read it on medium once).

pdimitar
0 replies
1h32m

I am not interested in being put in a corner where I have to defend web backend creation that I don't even practice. I only said it's being done by people. Feel free to reject it or degrade it as being "a curiosity", from where I am standing reality disagrees with you though.

Alifatisk
0 replies
5h37m

It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends.

Right I see your point, but in this case it’s about Ruby, the language itself, not RoR.

trealira
0 replies
7h3m

It may be worth comparing this new JIT to fast implementations of dynamic languages, like LuaJIT or SBCL for Common Lisp (SBCL is an AOT compiler and not a JIT though).

tomlin
3 replies
2h25m

I'm so glad that you said this and weren't downvoted into the ground. Honestly, Ruby needs to die. It performs like a go cart in a Formula 1 race. I'm actually just exhausted watching smart people tell me this is a language and toolchain worth dedicating brain cells to.

aantix
1 replies
2h2m

Ruby and Python are the only two ecosystems that seem to prioritize developer happiness. They're a pleasure to work with. So they're not going to die anytime soon.

cutler
0 replies
1h39m

Python might be popular but developer happiness isn't a concept I'd associate with the language. There's no joy in being limited to single statements in lambdas, for example.

the_gastropod
0 replies
1h14m

What a bizarre take. Ruby is primarily used in web applications, where round-trip http requests, database queries, and other 10s-of-ms things are commonplace. Ruby is very rarely the bottleneck in these applications. Choosing to make your job significantly more challenging in order to maximize the performance of a small portion of the total response time of a web application is not, in my estimation, a smart decision.

ksec
0 replies
36m

If you compare pure Ruby without Rails to fast language like Rust, Go and Java. It is probably closer to 10-20x.

The 100x to 200x mainly comes from Rails.

cutler
0 replies
1h55m

Apples to oranges, no?

jupp0r
10 replies
1h45m

Ruby the language may be fast but the whole ecosystem is painfully slow. Try writing a server that serves 1mb of json per request out of some db query and some calls to other services. I get 100 requests per second in Rails. Same service rewritten in go serves 100k requests/s.

the_gastropod
5 replies
1h22m

But, like, why do you need a 1MB json response? That’s probably either a bad design or a use-case Rails is not designed for.

jupp0r
3 replies
1h14m

It's a paginated list of 1000 objects of 1kb size each. Any nontrivial API will have responses like that.

My entire point was that Rails is not designed for this.

the_gastropod
2 replies
1h8m

But you could return the 1000 objects (or less? 1000 records sounds like a lot for any UI to show at once) of 1kb size and allow the clients to request specific pages with a request parameter. There may be applications where you need to ship the full 1M records I guess, but that seems like very much an edge case as far as web apps go.

wredue
0 replies
22m

1,000 records is absolutely not a lot on modern computers or connections. On a business LAN, this request should take well under a second full latency.

On an average mobile connection, it’s maybe a second or so.

tauchunfall
0 replies
6m

True, you would not return 1000 objects at once to the frontend.

I first thought it's just a backend use-case, where processing 1000 records in a paginated result is common, but the parent mentions "rails", so it sounds like a frontend use-case.

wredue
0 replies
25m

The better question is

“Why would I pointlessly accept this clear case of massive technical debt for literally no reason what-so-ever?”

Rails does not present any sort of promise that go does not also present, so just saying “yeah, I’ll handcuff my app like this cause I feel like using Ruby” is, frankly, absurd.

When you ask the right questions, you never land on Ruby, and that’s why Ruby continues to decline.

choilive
1 replies
1h26m

You're pushing 100Gb/s of JSON (1Mb*100k/s)? AND your calling other services + a DB per request on a single server? I'm skeptical.

jupp0r
0 replies
1h12m

The test was local, ie using the loopback interface on a large server.

SkyPuncher
1 replies
15m

Why does that matter?

You’re likely in one of two situations as a businesss:

* You’re a struggling startup. Development velocity trumps literally everything. Your server costs are trivial, just turn them up.

* You’re a successful business (maybe in part because you moved fast with Ruby), you can pay down the debt on that absurdly large response. Chunk it, paginate it, remove unnecessary attributes.

jupp0r
0 replies
2m

1MB is "absurdly large"? This is not the Todo app industry sorry.

This is paginated (page size of 1000) and the caller chooses only the attribute they need already, thanks.

TheAceOfHearts
4 replies
1h28m

One area where Ruby could help improve developer experience is by providing a better debugging experience. I feel incredibly spoiled with Chrome Dev Tools. Meanwhile the last time I tried debugging heavy metaprogramming Ruby code it was a pain to figure out what was happening.

SkyPuncher
1 replies
14m

Meta programming is my largest complaint with Ruby. It creates huge surprises that are very difficult to inspect and debug.

jweir
0 replies
1m

We ban most meta programming in our own code. While the meta programming solutions are fun and clever they are often more code than a functional version and hard to maintain.

We do allow the occasional use of “send” but try to avoid it. Dynamic method definitions are strictly banned.

weaksauce
0 replies
16m

what is ruby debug not able to do that you want it to do?

https://github.com/ruby/debug

a nice ide integrated experience:

https://code.visualstudio.com/docs/languages/ruby#_debugging...

https://github.com/ruby/vscode-rdbg

https://code.visualstudio.com/docs/editor/debugging

heavy metaprogramming in any language is going to be a pain to debug so i'm not sure what you're expecting but there are tools to help. you can also call source_location on some method to figure out where things exist.

volkk
0 replies
25m

that's surprising considering `pry`[1] is such an amazing debugger IMO.

[1] https://github.com/pry/pry

kyledrake
2 replies
3h31m

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.

wolfgang42
1 replies
1h47m

> half a billion queries a month across 14 tiny VPSes

For reference:

  $ units -1v '1|2 billion reqs/month / 14 servers' 'req/sec/server'
        1|2 billion reqs/month / 14 servers = 13.580899 req/sec/server
I always do this when I see large-sounding query counts; a month has a lot of seconds in it, and it’s easier to visualize only one at a time: I can imagine hooking a speaker up to the server and getting a 14Hz buzz, or do a quick mental arithmetic and conclude that we have ~70ms to serve each request. (Though peak RPS is usually more relevant when calculating perf numbers; traffic tends to be lumpy so we need overhead to spare at all other times which makes the average much less impressive-sounding.)

kjsthree
0 replies
1h21m

I also like to double check these kind of numbers and basically agree with your take. Although, I like to use a 28 day month and an 8-10 hour day rather than assuming smooth traffic over 24 hours. Even with all that, 1/2 a billion is well under 50 req/sec which is not a big deal for the rendering servers. All that traffic coming together on a database server might be a bottleneck though.

wredue
0 replies
29m

Unless those “double digits” are 98+%, ruby is still going to be quadruple digit percentage points behind strong competitors in terms of performance.

If I’m going to give it even a second glance, I can’t be seeing “ruby 10,000% slower than Java” for measured use cases.

acchow
0 replies
1h16m

I was pretty excited hearing “double digit” thinking 50 or 80%.

The link shows 13-15%.

ksec
24 replies
10h51m

I 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 wondering if any one are using these features in productions and if you could share any thoughts on the subject.

rjzzleep
12 replies
10h14m

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 rabbitmq or redis based private company solutions out there.

byroot
5 replies
10h10m

Mike Perham (the sidekiq maintainer) also maintains the less well known faktory[0] which is language agnostic and has runners for both Ruby and Python

[0] https://github.com/contribsys/faktory

rjzzleep
3 replies
10h2m

That's awesome. Any idea why he doesn't just supersede Sidekiq with that? I spent quite some time hacking my own solution.

I just looked at the source, I guess Mike has been mostly working on both projects on his own for the last 4 years, so Faktory has a lot of features that require the enterprise license.

I wonder if he could change the situation it he markets a bit more to the python and more specifically Django community.

f6v
2 replies
5h14m

Because people running sidekiq with their Ruby app on production don’t care about cross-language queue. If you pay for Pro or Enterprise you don’t want any major changes that are potentially breaking.

cactusplant7374
1 replies
4h59m

The only reason we pay is because the pro version doesn't lose jobs if a worker crashes. You would think that would be a core feature.

aaronbrethorst
0 replies
1h55m

A man’s gotta eat.

keithalewis
0 replies
8h26m

This relies on the Go runtime scheduler. Sometimes that is not good enough.

pmontra
2 replies
7h7m

My customers are using Celery for Python and Sidekiq for Ruby. Those are parts of Django and Rails web apps. Those customers don't mix languages so they don't need workers able to run code in multiple languages. One of them is also using SQS though so we could receive a JSON in a server written in any language, do some processing and return the result. However the database of that app has been "destroyed by design" by using Django's ORM inheritance (my suggestion: never use it) so nothing can interact effectively with it except Python code using the same models.

By the way, celery was born as a protocol spec to support multiple languages but never moved past Python. I can't google a quote for that, I remember I saw it years ago in the documentation somewhere.

rjzzleep
0 replies
3h11m

I can see that it was born that way, but nowadays most job queues say, don't touch the wire protocol, it's not intended to be used directly.

I still think Rails has the best ORM design I've ever seen, iterated with practical applications. Django's ORM and migrations are, for lack of a better word, odd.

I'm a bit surprised that people here argue that no one using Rails would ever want to interface with other languages. Most big companies do. How can you not interface with python these days.

Looks to me like celery might just be the only job queue left like that. Might be worth writing a current ruby en-queuing library for it. Retracting my previous statement about ActiveJob since it would probably be too much effort to execute anything bidirectionally.

https://docs.celeryq.dev/en/stable/internals/protocol.html#

riffraff
0 replies
1h21m

What's wrong with Django's orm? Does it have something particularly bad compared to others?

petepete
0 replies
4h1m

There's beanstalkd, it has a few Python libraries and it works out of the box with ActiveJob via Backburner.

https://beanstalkd.github.io/

emmelaich
0 replies
4h8m

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.

akvadrako
0 replies
8h39m

Because it's a rare need and easy to write your own based on postgres or redis.

External systems come with a cost, especially if it's more than a library.

rfoo
8 replies
7h43m

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.

pjmlp
4 replies
7h7m

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.

tnecniv
3 replies
3h37m

I should start doing numerical work in TCL and see how long it takes for me to get set to the mad house

pjmlp
2 replies
3h30m

Well, first step is to create bindings to the same libraries Python uses.

nerdponx
1 replies
2h30m

The problem is that Numpy is not in fact anything close to a thin wrapper around BLAS/LAPACK like people seem to think it is.

First of all, it contains a ton of custom C code, which to some extent could be extracted to a separate library in theory, but isn't. Second, a lot of that custom code interacts deeply with the Python C API, which historically was very open-ended. Even getting it to work on another implementation of Python was a challenge that took a long time to reach baseline usability.

You could forego Numpy and call out to a library like Eigen, but even then you have a huge amount of work ahead to achieve anything resembling feature parity.

pjmlp
0 replies
1h32m

Who singled out Numpy?

Still, your lengthy explanation only confirms how much C and how little Python, that specific case happens to be.

pvg
0 replies
2h8m

There's a talk from a couple of years ago by one of the YJIT developers that discusses this in some detail and it's more interesting/complicated than that. The whole thing is worth checking out but the specific section starts here

https://youtu.be/vucLAqv7qpc?t=937

dejv
0 replies
6h53m

There are huge apps (such as Shopify) which will safe a lot of money by having more performant BE so they do invest heavily into it.

Python workloads, with deep pocketed backers, do spend more time inside GPU or C runtime.

byroot
0 replies
7h38m

I don't see how it's relevant given that YJIT didn't cause any compatibility issue whatsoever.

Alifatisk
1 replies
8h29m

I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years.

Really? What’s so significant with this release?

But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async.

Yes! Ractors deserve more highlighting! It’s a huge feature.

Lio
0 replies
7h39m

Really? What’s so significant with this release?

I think the Prism parser update is a standout highlight for me. This is the start of many new static analysis tools for ruby.

It's also significant that RBS type information is starting to be used in IRB autocompletion. Previously RBS has been an interesting experiment but hasn't had much practical use compared to Sorbet.

Ruby seems to now have good answers to non-blocking IO (async fibers) and tooling questions (ruby-lsp). We're starting to see YJIT performance improvements starting to compound with more to come too.

That all seems significant to me. Thanks to everyone involved.

999900000999
14 replies
4h31m

Worth it to learn Ruby if you already know Python and NodeJS ?

I find Ruby fascinating yet difficult.

burlesona
4 replies
2h36m

Ruby is basically a less popular but more elegant Python. It’s a solid general purpose language, but especially good at shell scripting, data munging, etc.

If you’re fluent in Node and Python it should be quite easy to learn. The downside is it’s not going to do anything fundamentally new for you coming from those languages. The upside is mostly aesthetic, Ruby offers and encourages really beautiful ways of expressing code, and it’s neat to experience that.

nerdponx
1 replies
2h21m

Having tried to use Ruby for text processing specifically, I'm not sure I agree it beats Python at that particular task. Maybe I'm just used to the Python way of doing things, but I found it difficult to work with the lack of first-class functions and iterators/generators, as well as the general iteration protocol.

weaksauce
0 replies
4m

lack of first-class functions and iterators/generators, as well as the general iteration protocol

can you elaborate on what you miss here? ruby has a robust enumerable suite of methods so i'm curious what you found lacking

gls2ro
1 replies
1h42m

but especially good at shell scripting, data munging

Add to this also Shopify, Github, Gitlab, Basecamp and some others and you will see that Ruby can be use for more than shell scripting and data munging. Yes they are Rails but Rails is written in Ruby so they are Ruby.

riffraff
0 replies
1h19m

Stripe is a big "ruby but not rails" shop, iirc.

xivusr
3 replies
2h0m

I’d genuinely love to hear more about what you find difficult about Ruby coming from a heavier Python or NodeJS background.

For me, coming from more of a Ruby background, I found Python and Node to not be too hard to understand, and my only nitpick would be on how eggs/packages were managed and dealing with dependancies.

In particular, Python dependancies compared to Ruby dependancies were more challenging initially for me. I’ve grown to appreciate Python indents and find it nice to read, but that was also annoying at first.

tjpnz
1 replies
1h41m

Not op but compared with Python it's heavier in the syntax department. You would have an easier time going in the other direction and encounter less situations where you have to stop and think about what to use in which situation while learning.

jshen
0 replies
1h2m

Python has far more custom syntax than Ruby. In Ruby an elegant syntax like blocks solves many problems, in Python each problem has custom syntax.

SkyPuncher
0 replies
10m

I’m primarily a Ruby dev, but still find most languages easier to work with.

Ruby itself is not the issue. The way people and frameworks (looking at you Rails) abuse its mechanics in pursuit of “clean code” drives me crazy. An incredible number of things are downright challenging to debug because of the insane flexibility of Ruby.

lp4vn
1 replies
3h40m

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.

gls2ro
0 replies
1h35m

Ruby and Ruby on Rails are not in a downward trend. There were maybe some year where the interest was decreased but in the last 2 years a lot of things happened: Ruby has a lot new features, Rails 7 is out and comes with a new approach to web apps like for example Horwire with the just released Turbo 8.

And there is a lot more: new conferences, new books and new gems.

(Shameless plug: I curate a newsletter called Short Ruby that covers news from Ruby world every week).

Maybe Ruby is not at the level where is was in 2007-2009 but it is also NOT in a downward trend.

jitl
0 replies
4h21m

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 I’ve used regularly. That makes it its own reward.

eddieroger
0 replies
3h47m

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.

block_dagger
0 replies
1h42m

Use Rubocop to give you hints about improving your code as you learn. It' s a wonderful linter and teacher!

revskill
12 replies
10h41m

I hope Ruby 4.0 could allow explicit import and avoid implicit, global namespace gem import mechanism like nowsdays.

t-writescode
8 replies
10h40m

I'm feeling a bit ignorant, but isn't this a Rails thing and not a Ruby thing? I know that for most projects that's a distinction without a difference; but, that may be a decision from the Rails devs and unrelated to what Ruby's devs do?

Or I'm speaking out of my ear and completely wrong (and I don't know which :D)

Calavar
6 replies
10h22m

You're right, implicit import (autoload) is an opt-in feature. Rails used to use autoload by default as of 3.x/4.x. It's been quite a while since I used Rails, so I'm not sure if this is still the case.

Ruby imports have always used a single global namespace. I'm not convinced that this is an issue in practice - it's worked just fine for several other languages.

hetman
4 replies
10h15m

I mean, only because it's possible to learn to live with doesn't make it pleasant. Especially for managing large projects it can get unwieldy. Most high level languages I can think of have moved away from this approach.

I used to be a huge Ruby fan but having exposure to Python where this isn't an issue, life is just easier.

ckolkey
1 replies
10h5m

To each their own, I guess. After working with python/lua, I really appreciate not needing to do manual imports all over. I'm glad ruby makes this so easy :)

Oh, and not needing __init__.py files in order to import something. Goodness, what an absolute pain.

nerdponx
0 replies
2h18m

I really like the Python/Lua module system. To each their own...

oleg_antonyan
0 replies
10h6m

It's a matter of personal preference and/or which one you've learnt to live with first.

I like how Ruby's imports work - just load a file, similar to C. On the other hand, modules in Python always felt like something to overcome rather than "just works as you expect".

mypalmike
0 replies
8h20m

I agree, but Ruby folks seem to consider C style transitive inclusion to be a feature. I found it and several other aspects of Ruby to be maddening (and productivity-sapping) for the 1.5 years I spent with an otherwise pretty nice language.

lloeki
0 replies
8h43m

There's a big difference between Rails autoloading and Ruby autoload, in that Rails is implicit and conventional from the constant name plus load paths, whereas Ruby is explicit as one declares where to find each constant.

byroot
0 replies
10h24m

It's a Ruby thing. Ruby only has a single global namespace, no imports.

If anything Rails autoloading (Zeitwerk really) make it much easier to find where constants come from as it enforce a constant name -> file name convention, so all you need is fuzzy file search.

tomstuart
0 replies
9h22m

You might be interested in Chris Salzberg’s Im [0], already usable on Ruby 3.2, or the discussion about the speculative “namespace on read” feature [1].

[0] https://github.com/shioyama/im

[1] https://bugs.ruby-lang.org/issues/19744

jhealy
0 replies
9h33m

Implicit or explicit, I’m OK with the global namespace.

On paper it’s awkward, but in reality convention and social norms make it rarely an issue.

The global namespace only supporting exactly one version of each gem encourages a health culture of stable ABIs and deprecation periods too. An absolute dream compared to some language ecosystems

Alifatisk
0 replies
4h10m
xpressvideoz
7 replies
8h32m

Name resolution such as `Socket.getaddrinfo` can now be interrupted. Whenever it needs name resolution, it creates a worker pthread, and executes `getaddrinfo(3)` in it.

Do other language runtimes do similar things? Creating a thread sounds too heavy, though it might not matter in practice. As per their own benchmark, the overhead is minimal but still not zero.

  10000.times { 
  Addrinfo.getaddrinfo("www.ruby- 
  lang.org", 80) }
  # Before patch: 2.3 sec.
  # After ptach: 3.0 sec.

  100.times { 
  URI.open("https://www.ruby-lang.org").read }
  # Before patch: 3.36 sec.
  # After ptach: 3.40 sec.

Alifatisk
5 replies
7h50m

Wouldn’t a fiber be more lightweight than having to create a new thread?

byroot
3 replies
7h46m

A fiber doesn't have a dedicated execution context, so it would be just as blocking.

Alifatisk
2 replies
6h50m

Is there really no other way than creating a whole thread for this?

viraptor
0 replies
6h16m

You can use a pure ruby resolver if you want. For example https://github.com/socketry/async-dns

But that way your sacrificing integration into your system's nsswitch which may want to do something completely different with your requests.

You could also query over dbus which can be async https://www.freedesktop.org/software/systemd/man/latest/org.... (if you can depend on systemd)

byroot
0 replies
6h14m

There is a few alternatives like getaddrinfo_a(3) but they have other downsides (fork safety concerns).

If you want more context, you can read: https://bugs.ruby-lang.org/issues/19430

chucke
0 replies
6h26m

The getaddrinfo interface does not expose the fd so you can monitor for readiness. Several languages have the same problem with it, some with similar solutions (go outsources getaddrinfo calls to a thread pool)

nerdponx
0 replies
2h25m

Is this because all of the I/O operations in the standard library have to support async/fibers?

My impression is that everything was migrated to be asynchronous by default, unlike in Python where all of these operations were reimplemented in the async "color". Is that true?

nextaccountic
3 replies
9h34m

RUBY_MAX_CPU=n environment variable sets maximum number of N (maximum number of native threads). The default value is 8.

Shouldn't the default be the number of logical cores? Like Rust's Tokio and countless other M:N runtimes

Alifatisk
1 replies
8h38m

Yeah, setting a hard cap on the maximum cpu count doesn’t feel right? Why not depend on the available cores?

SkyPuncher
0 replies
5m

It’s a safe choice. Some systems won’t report cores correctly which can lead to reallllllly bad performance.

MoOmer
0 replies
9h24m

That’s an optimization that can be added later, with some nuance. IIRC Go had a similar situation for years; I remember setting GO_MAX_PROCS in my init() or main()!

phaedryx
2 replies
10h48m

Prism is interesting. Any Ruby code analysis tools that use it? I've been looking for ways to analyze my code at work.

nirvdrum
1 replies
10h38m

The Ruby LSP uses Prism. Kevin Newton has implemented a Prism-based backed for the white quark/parser gem [1] that can be used with Rubocop.

[1] https://github.com/kddnewton/parser-prism

riffraff
0 replies
7h8m

I had missed this. Six times faster? Wow!

alberth
2 replies
10h46m

Every Christmas, like clockwork, Ruby Lang drops a new release.

quickthrower2
0 replies
10h25m

It is a cute thing about Ruby

mberning
0 replies
3h5m

You love to see it.

captn3m0
1 replies
9h15m

Friendly reminder that Ruby 3.0 will now go EOL in 3 months, so you have 12 weeks to upgrade.

awestroke
0 replies
4h6m

I don’t think I will.

schneems
0 replies
2h3m
pmdr
0 replies
8h56m

The perfect Christmas gift!

pgib
0 replies
10h40m

Very much looking forward to upgrading our application to ensure 3.3 compatibility.

mortallywounded
0 replies
1h1m

It's nice to see improvements to Ruby, but the hype around a ~13% performance boost feels... weird.

It looks like a big leap, but when you compare the actual speed to _any_ other language you realize Ruby still has many, many percent to go to even be in the same game.

Exuma
0 replies
2h29m

Just enabled YJIT this morning. Merry CHristmas!