News for hackers. Stuff that matters.
Re:Benchmarking Ruby 2.6 to 3.2 by alberth on Monday December 26, 2022 @09:00AM (#34137670)
I’m surprised to see how little speed-up have happened over the years. Especially when you compare it to something like PHP which has massive gains.

Seems like most of the Ruby gains are related to memory usage.

Re:Benchmarking Ruby 2.6 to 3.2 by nickjj on Monday December 26, 2022 @09:34AM (#34137871)
> Seems like most of the Ruby gains are related to memory usage.

That would be a welcome addition, especially with Rails where you typically end up running your web app, background worker and action cable as separate processes. That's (3) running services each booting up your application to some degree.

Combine that with most apps using very little CPU and more and more memory, it's nice to be able to reduce memory when you can to optimize the machines you host things on. It always feels dirty having a server using 60% memory and 5% CPU.

Re:Benchmarking Ruby 2.6 to 3.2 by influx on Monday December 26, 2022 @11:23AM (#34138998)
Can those processes fork and save memory on duplicate pages? (I’m not a rails person)
Re:Benchmarking Ruby 2.6 to 3.2 by gettalong on Monday December 26, 2022 @11:34AM (#34139158)
Yes, COW was implemented a few versions ago and the garbage collector also supports it to avoid unnecessary copying.
Re:Benchmarking Ruby 2.6 to 3.2 by noyoudumbdolt on Monday December 26, 2022 @09:20AM (#34137769)
PHP had the benefit of Facebook pouring money into it. Same with JS and Google. No company has done something comparable for Ruby.
Re:Benchmarking Ruby 2.6 to 3.2 by Doctor_Fegg on Monday December 26, 2022 @09:33AM (#34137862)
YJIT, Ruby's new JIT compiler, is from Shopify.
Re:Benchmarking Ruby 2.6 to 3.2 by alberth on Monday December 26, 2022 @10:20AM (#34138257)
Let’s not forget that GitHub is a giant Rails app that Microsoft runs.

Microsoft is also one of the best language/compiler company in the world.

Re:Benchmarking Ruby 2.6 to 3.2 by chucke on Monday December 26, 2022 @01:29PM (#34140313)
Microsoft didn't start pouring bucks into improving ruby yet. Their focus has recently been on JS, C# and python.
Re:Benchmarking Ruby 2.6 to 3.2 by theappsecguy on Wednesday January 04, 2023 @12:13PM (#34248357)
Really wish Microsoft would contribute/donate to ruby/rails platform even more than Github does already. They can afford to.
Re:Benchmarking Ruby 2.6 to 3.2 by osrec on Monday December 26, 2022 @09:31AM (#34137838)
I believe Stripe use Ruby. Perhaps they'll fund its improvement...
Re:Benchmarking Ruby 2.6 to 3.2 by iloveitaly on Monday December 26, 2022 @11:09AM (#34138833)
Stripe has done a lot of work on a ruby type system (https://sorbet.org) and has been working on a ruby compiler as well (https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-comp...)
Re:Benchmarking Ruby 2.6 to 3.2 by alberth on Monday December 26, 2022 @09:44AM (#34137956)
That’s not exactly accurate. FB went off and did their own thing.

PHP gains were independent of FB.

Re:Benchmarking Ruby 2.6 to 3.2 by yucky on Monday December 26, 2022 @10:03AM (#34138115)
This is surprising to hear, considering how big Shopify has gotten and how much resources they've put into Ruby.
Re:Benchmarking Ruby 2.6 to 3.2 by weaksauce on Monday December 26, 2022 @12:36PM (#34139783)
shopify is putting up a lot of money and resources into ruby.
Re:Benchmarking Ruby 2.6 to 3.2 by theredfury on Monday December 26, 2022 @01:20PM (#34140247)
Re:Benchmarking Ruby 2.6 to 3.2 by skrtskrt on Monday December 26, 2022 @09:12AM (#34137725)
I don’t have a ton of love for Python now that I’ve moved on to static typing but it’s hard for me to see myself choosing Python over Ruby for anything.

Python has gotten significantly faster, has static typing built in with an ecosystem of static typecheckers, and async is an ergonomic first class language feature - sure async can have rough edges but the 99.9% case is dead simple with no surprises.

Obviously packaging for Python is still a pain but I don’t see Ruby being better

Re:Benchmarking Ruby 2.6 to 3.2 by joshspankit on Monday December 26, 2022 @09:25AM (#34137798)
> it’s hard for me to see myself choosing Python over Ruby for anything.

Did you mean this the other way around?

Re:Benchmarking Ruby 2.6 to 3.2 by skrtskrt on Monday December 26, 2022 @10:34AM (#34138379)
yep fixed
Re:Benchmarking Ruby 2.6 to 3.2 by foxandmouse on Monday December 26, 2022 @11:03AM (#34138771)
I've only ever known Javascript/ Typescript. I've been thinking of picking up ruby to learn "practical" functional programming and maybe see what the infatuation with rails is, but I'm starting to think it might be more "valuable" to learn python.
Re:Benchmarking Ruby 2.6 to 3.2 by sodapopcan on Monday December 26, 2022 @11:24AM (#34139018)
I wouldn’t recommend python or ruby if you’re trying to learn more about functional programming… you may as well stick with JS in that case (imo, at least). I’d choose a language that has at least had native immutability. Something like Elixir/Erlang, OCaml, Clojure, or F#.
Re:Benchmarking Ruby 2.6 to 3.2 by skrtskrt on Monday December 26, 2022 @11:40AM (#34139221)
I’m seeing a pretty significant amount of Elixir job listings these days even in areas where you used to see all Ruby or Python
Re:Benchmarking Ruby 2.6 to 3.2 by sodapopcan on Monday December 26, 2022 @05:04PM (#34142402)
I've actually been having a tough time finding another job in Elixir. Sooooo many companies who use it are in crypto and I just have no interest.
Re:Benchmarking Ruby 2.6 to 3.2 by skrtskrt on Monday December 26, 2022 @11:06AM (#34138807)
Python and Ruby are both only really as functional as you choose to use them. You’ll see more imperative code in the wild for both, though the big data stuff in Python leans more functional.

Rails and Django are both still super popular from scanning job listings, so e-commerce employment wise they’re both great.

FastAPI is also growing a lot.

Big Data leans heavily Python

Re:Benchmarking Ruby 2.6 to 3.2 by freedomben on Monday December 26, 2022 @01:51PM (#34140548)
Purely my opinion after learning and professionally doing both Ruby and Python. If elegance and consistency in APIs matter, Ruby is by far the preference. Generally speaking (again from my own experience which should be taken with a grain of salt) the Ruby community tends to value readability/maintainability of code a lot higher, so working in the codebases is typically a lot more pleasant.

IIWM I'd go with Ruby hands down.

Re:Benchmarking Ruby 2.6 to 3.2 by satvikpendem on Monday December 26, 2022 @04:05PM (#34141868)
If you already know TypeScript, just use a functional approach to your programs, and/or use libraries like fp-ts and io-ts. Ruby is definitely not more FP based than TS.
Re:Benchmarking Ruby 2.6 to 3.2 by harshreality on Monday December 26, 2022 @07:52PM (#34143657)
Python would be the most popular option, but, for an OO language, Ruby feels clean and intuitive to me in a way that other languages, especially Python, don't. It has a performance cost, though. The languages' performance may be roughly equivalent, but Python has more native-code libraries for a lot of things. You don't see many ML projects in Ruby. :) There's crystal-lang, but that has a much smaller community behind it.

Julia, though, if you're looking for a language that isn't OO in addition to functional.

Re:Benchmarking Ruby 2.6 to 3.2 by bhaak on Monday December 26, 2022 @11:34AM (#34139159)
> Python has gotten significantly faster

All the synthetic benchmarks I've seen claim that Ruby is at least on par with Python's speed if not faster. Like this https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

But then speed in a dynamic language is often very context dependent. If I want to do Rails I won't choose Python. If I want to do machine learning, Python is the obvious choice.

> Obviously packaging for Python is still a pain but I don’t see Ruby being better

Ruby packaging just works whereas Python's is a pain. Can't see how you don't see it being better.

Re:Benchmarking Ruby 2.6 to 3.2 by skrtskrt on Monday December 26, 2022 @11:43AM (#34139266)
Those benchmarks are with Python 3.10 - the big recent speedups are in 3.11, with more to come

> The Python 3.11 release announcement cites 10~60% improvements over Python 3.10 and a 1.22x speed-up for its standard benchmark suite.

Re:Benchmarking Ruby 2.6 to 3.2 by igouy on Friday January 27, 2023 @03:34PM (#34551457)
Re:Benchmarking Ruby 2.6 to 3.2 by lraktr on Monday December 26, 2022 @11:50AM (#34139326)
Yeah, the Debian benchmarks are independent.

The recent Python benchmarks all seem to use the same benchmark suite (which is incredibly complex to the point that it's unclear what is actually being measured) or hype the Microsoft involvement.

Even if you believe them, it is just 10-60% speedup for a very slow language. It won't show up in web applications.

Re:Benchmarking Ruby 2.6 to 3.2 by chucke on Monday December 26, 2022 @01:22PM (#34140264)
Python improvements are on par with ruby, and ruby has a JIT, which means that upside fir real world improvement is much higher.

Python has no static typing. It has type annotations, which a few 3rd party static analysers such as mypy use. Ruby has had the same since 3.0 with rbs. The ecosystem may be less mature, but it exists, and Python's isn't necessarily perfect.

Python async is terrible. You have to colorize functions, opt out from a significant part of the ecosystem which either does not support async, or is very unstable, and completely relearn how to do debugging / performance measurement. Ruby has smth better since ruby 3.0, via the fiber scheduler, which supports running network related code asynchronously with *no changes or special function annotations*.

Ruby packaging has been figured out since 2007, and has been influencial for other ecosystems, being the first mainstream language adopting lockfiles.

If you prefer using Python, you are entitled to your opinion and choice. But those arguments are all FUD.

Re:Benchmarking Ruby 2.6 to 3.2 by tmountain on Monday December 26, 2022 @10:17AM (#34138245)
Pure speculation—Ruby has a deeper OOP story (everything is an object), and that comes with a builtin performance impact. I also feel like performance was never a top priority with the language (ergonomics instead), so certain aspects of the core design may not lend themselves to optimization as easily.
Re:Benchmarking Ruby 2.6 to 3.2 by jwcooper on Monday December 26, 2022 @11:31AM (#34139120)
I think these charts are more informative, especially for Rails apps: https://speed.yjit.org/

Ruby 3.2 and production-ready YJIT feel like a big deal as someone who has been in the Rails and Ruby ecosystem for 15 years.

Rails in particular has seemed to be very difficult to optimize for performance in Ruby, and YJIT seems to have done it.

Re:Benchmarking Ruby 2.6 to 3.2 by brasic on Monday December 26, 2022 @12:44PM (#34139863)
Re:Benchmarking Ruby 2.6 to 3.2 by mrinterweb on Tuesday January 03, 2023 @11:53PM (#34242169)
Every time I try to get a project going with truffleruby, I get all kinds of dependency problems. I haven't had the patience to resolve all of the library problems yet, so I give up.