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

111–120 of 277 posts

Re: Ruby 3.3

#111

Post by riffraff »

gls2ro wrote: post #99
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…

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

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

Re: Ruby 3.3

#112

Post by acchow »

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…

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

The link shows 13-15%.

Re: Ruby 3.3

#113

Post by the_gastropod »

tomlin wrote: post #78
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'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.

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.

Re: Ruby 3.3

#114

Post by jupp0r »

the_gastropod wrote: post #108
jupp0r wrote: post #97

Earlier quoted context omitted.

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.

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.

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.

Re: Ruby 3.3

#115

Post by jupp0r »

choilive wrote: post #106
jupp0r wrote: post #97

Earlier quoted context omitted.

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.

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.

Re: Ruby 3.3

#116

Post by the_gastropod »

jupp0r wrote: post #114
the_gastropod wrote: post #108

Earlier quoted context omitted.

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.

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.

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.

Re: Ruby 3.3

#117

Post by jshen »

tjpnz wrote: post #100
xivusr wrote: post #90

Earlier quoted context omitted.

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…

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.

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.

Re: Ruby 3.3

#118

Post by mortallywounded »

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.

Re: Ruby 3.3

#119

Post by Alifatisk »

csjh wrote: post #107
cutler wrote: post #93

Earlier quoted context omitted.

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.

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

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.

Re: Ruby 3.3

#120

Post by Alifatisk »

pdimitar wrote: post #84
ric2b wrote: post #81

Earlier quoted context omitted.

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.

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

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

Post reply on HN