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

101–110 of 277 posts

Re: Ruby 3.3

#101

Post by cutler »

aantix wrote: post #88
tomlin wrote: post #78

Earlier quoted context omitted.

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.

Ruby and Python are the only two ecosystems that seem to prioritize developer happiness. They're a pleasure to work with. So they're not going to die anytime soon.

Python might be popular but developer happiness isn't a concept I'd associate with the language. There's no joy in being limited to single statements in lambdas, for example.

Re: Ruby 3.3

#102

Post by gls2ro »

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 and Ruby on Rails are not in a downward trend. There were maybe some year where the interest was decreased but in the last 2 years a lot of things happened: Ruby has a lot new features, Rails 7 is out and comes with a new approach to web apps like for example Horwire with the just released Turbo 8.

And there is a lot more: new conferences, new books and new gems.

(Shameless plug: I curate a newsletter called Short Ruby that covers news from Ruby world every week).

Maybe Ruby is not at the level where is was in 2007-2009 but it is also NOT in a downward trend.

Re: Ruby 3.3

#103

Post by pjmlp »

nerdponx wrote: post #76
pjmlp wrote: post #70

Earlier quoted context omitted.

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

Who singled out Numpy?

Still, your lengthy explanation only confirms how much C and how little Python, that specific case happens to be.

Re: Ruby 3.3

#104

Post by pdimitar »

cutler wrote: post #95
pdimitar wrote: post #49

Earlier quoted context omitted.

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

Web backends in Rust and C++? Not saying web frameworks in these languages don't exist but to claim they're anything other than curiosities is misleading. In any case, good luck with the fraction of a millisecond such languages gain you while waiting on database i/o. There are use cases for switching to a compiled language like Rust or C++. Web back-ends isn't one of them.

I am not interested in being put in a corner where I have to defend web backend creation that I don't even practice. I only said it's being done by people. Feel free to reject it or degrade it as being "a curiosity", from where I am standing reality disagrees with you though.

Re: Ruby 3.3

#105

Post by TheAceOfHearts »

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…

One area where Ruby could help improve developer experience is by providing a better debugging experience. I feel incredibly spoiled with Chrome Dev Tools. Meanwhile the last time I tried debugging heavy metaprogramming Ruby code it was a pain to figure out what was happening.

Re: Ruby 3.3

#106

Post by choilive »

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.

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.

Re: Ruby 3.3

#107

Post by csjh »

cutler wrote: post #93
resonious wrote: post #58

Earlier quoted context omitted.

I suspect there's not just one cause of slowness here. Pure language benchmarks also tend to rank Ruby very low. So I'd wager that a fast Ruby framework would still lose to a fast Go framework.

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?

Re: Ruby 3.3

#108

Post by the_gastropod »

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.

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.

Re: Ruby 3.3

#109

Post by riffraff »

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…

What's wrong with Django's orm? Does it have something particularly bad compared to others?

Re: Ruby 3.3

#110

Post by kjsthree »

wolfgang42 wrote: post #96
kyledrake wrote: post #69

Earlier quoted context omitted.

I don't know if a slight performance increase is going to sell anyone on ruby but I'm glad they're making incremental improvements on things. Being overly concerned about performance is almost always premature optimization, and ruby is more than fast enough for everything I've ever asked of it (including the binding glue between our redis DNS record storage and PowerDNS, where the entire stack serves half a billion q…

> half a billion queries a month across 14 tiny VPSes For reference: $ units -1v '1|2 billion reqs/month / 14 servers' 'req/sec/server' 1|2 billion reqs/month / 14 servers = 13.580899 req/sec/server I always do this when I see large-sounding query counts; a month has a lot of seconds in it, and it’s easier to visualize only one at a time: I can imagine hooking a speaker up to the server and getting a 14Hz buzz, or do…

I also like to double check these kind of numbers and basically agree with your take. Although, I like to use a 28 day month and an 8-10 hour day rather than assuming smooth traffic over 24 hours. Even with all that, 1/2 a billion is well under 50 req/sec which is not a big deal for the rendering servers. All that traffic coming together on a database server might be a bottleneck though.
Post reply on HN