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

71–80 of 277 posts

Re: Ruby 3.3

#71

Post by wscourge »

IshKebab wrote: post #25
ciconia wrote: post #18

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

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

[flagged]

Re: Ruby 3.3

#72

Post by rjzzleep »

pmontra wrote: post #43
rjzzleep wrote: post #13

Earlier quoted context omitted.

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

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#

Re: Ruby 3.3

#74

Post by [deleted] »

cactusplant7374 wrote: post #56
f6v wrote: post #55

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Ruby 3.3

#75

Post by burlesona »

999900000999 wrote: post #57

Worth it to learn Ruby if you already know Python and NodeJS ? I find Ruby fascinating yet difficult.

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.

Re: Ruby 3.3

#76

Post by nerdponx »

pjmlp wrote: post #70
tnecniv wrote: post #67

Earlier quoted context omitted.

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.

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.

Re: Ruby 3.3

#78

Post by tomlin »

IshKebab wrote: post #25
ciconia wrote: post #18

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

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

Re: Ruby 3.3

#79

Post by nerdponx »

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…

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?

Re: Ruby 3.3

#80

Post by ric2b »

wscourge wrote: post #71
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++.

[flagged]

Java trades blows with Golang, depending on the use case.
Post reply on HN