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

141–150 of 277 posts

Re: Ruby 3.3

#141

Post by dragonwriter »

nerdponx wrote: post #82
burlesona wrote: post #75

Earlier quoted context omitted.

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

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.

> but I found it difficult to work with the lack of first-class functions and iterators/generators, as well as the general iteration protocol.

Ruby has iterators/generators. It doesn't have first-class functions because it doesn't have functions at all, but blocks/procs serve the same purposes.

Re: Ruby 3.3

#142

Post by jupp0r »

tauchunfall wrote: post #134
the_gastropod wrote: post #116

Earlier quoted context omitted.

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.

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.

It's a backend use case.

Re: Ruby 3.3

#144

Post by x86x87 »

jupp0r wrote: post #115
choilive wrote: post #106

Earlier quoted context omitted.

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.

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

Are you actually going to the DB or is that json synthetically generated? Is it the same json? What exactly are we testing here?

Re: Ruby 3.3

#145

Post by harshreality »

jupp0r wrote: post #97
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…

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.

Why Rails, instead of a lighter-weight framework, if performance is such a priority? Obviously that wouldn't get you to [anywhere near] the performance of compiled Go code, but Rails has a lot of overhead.

What database is on the backend, and is that db serving cached content? What happens if you cache it with e.g. redis to avoid the heavyweight rails ORM stuff?

Do you have granular benchmarks for the db query, requests to other services, and the web processing itself (using artificially pre-cached responses from db and those other services)?

Re: Ruby 3.3

#146

Post by bluerooibos »

nerdponx wrote: post #82
burlesona wrote: post #75

Earlier quoted context omitted.

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

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.

I find the opposite. Ruby has a longer list of String, Array and Hash methods/functions and they're also more useable.

Another issue I had was that Python's test frameworks like PyTest were just so weak compared to the likes of MiniTest and RSpec.

Re: Ruby 3.3

#147

Post by byroot »

ksec wrote: post #122
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++.

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.

Can we stop with these useless comparisons? 10x-20x, 100x, 200x out of context means absolutely nothing.

All these micro-benchmarks shootouts means nothing either. Is anyone running a mandelbrot or pi-digits SaaS company? I'd think not.

Similarly saying Rails is slow out of context, means nothing, Rails is "slower" than Ruby micro-frameworks X because it does useful things the other doesn't like CSRF protection etc. If you don't need these features, turn them off and Rails will be about as fast as these frameworks.

If anything annoys me more than clueless people shitting on Ruby for bad reasons it's Rubyists spreading FUD about Rails.

Re: Ruby 3.3

#148

Post by bluerooibos »

lp4vn wrote: post #66
999900000999 wrote: post #57

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

> Ruby doesn't do anything better

I'll bite.

Even at the most basic level of built in functions/methods (String, Array, Hash) - I found Ruby's to blow Python's out of the water.

https://ruby-doc.org/core-2.5.1/String.html

https://www.w3schools.com/python/python_ref_string.asp

Even Python's choice of naming and syntax to use these basic functions just hasn't been thought through as much as Ruby's implementation. There's a reason it's called the language of Developer happiness.

Ruby's community I've found is more focused on best engineering practices (like testing) than others, which is perhaps why RSpec and MiniTest are fantastic frameworks. The likes of PyTest doesn't even compare to what those two offer.

Plenty of reason above to use Ruby, and we haven't even got to Rails yet.

Re: Ruby 3.3

#149

Post by byroot »

mortallywounded wrote: post #118

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.

This number is from a production workload with a significant chunk of IOs.

If you look at CPU bound micro-benchmarks like most similar announcements uses, you easily get into the 3x territory: https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...

Re: Ruby 3.3

#150

Post by alberth »

byroot wrote: post #149
mortallywounded wrote: post #118

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.

This number is from a production workload with a significant chunk of IOs. If you look at CPU bound micro-benchmarks like most similar announcements uses, you easily get into the 3x territory: https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...

> “get into the 3x territory”

Where are you seeing 3x improvement?

Because even this graph from your article doesn’t show that, unless you’re comparing JIT vs non-JIT. But JIT has existed for awhile now (not new in 3.3).

https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...

Post reply on HN