Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.3

ruby-lang.org

Post reply on HN
Print view View original

41–50 of 277 posts

Re: Ruby 3.3

#41

Post by [deleted] »

Alifatisk wrote: post #28
IshKebab wrote: post #25

Earlier quoted context omitted.

> 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++.

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.

[deleted]

Re: Ruby 3.3

#42

Post by riffraff »

nirvdrum wrote: post #8
phaedryx wrote: post #3

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

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

I had missed this. Six times faster? Wow!

Re: Ruby 3.3

#43

Post by pmontra »

rjzzleep wrote: post #13
ksec wrote: post #2

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 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…

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.

Re: Ruby 3.3

#44

Post by pjmlp »

rfoo wrote: post #37
ksec wrote: post #2

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 wo…

> 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.

Re: Ruby 3.3

#45

Post by trealira »

Alifatisk wrote: post #28
IshKebab wrote: post #25

Earlier quoted context omitted.

> 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++.

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.

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).

Re: Ruby 3.3

#46

Post by dejv »

rfoo wrote: post #37
ksec wrote: post #2

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 wo…

> 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.

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.

Re: Ruby 3.3

#47

Post by Alifatisk »

byroot wrote: post #36
Alifatisk wrote: post #35

Earlier quoted context omitted.

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

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

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

Re: Ruby 3.3

#48

Post by chucke »

Alifatisk wrote: post #35
xpressvideoz wrote: post #31

> 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…

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

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)

Re: Ruby 3.3

#49

Post by pdimitar »

Alifatisk wrote: post #28
IshKebab wrote: post #25

Earlier quoted context omitted.

> 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++.

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.

> 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.

Re: Ruby 3.3

#50

Post by pdimitar »

ciconia wrote: post #40
IshKebab wrote: post #25

Earlier quoted context omitted.

> 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++.

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.

> 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.

Post reply on HN