121–130 of 277 posts
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 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++.
The 100x to 200x mainly comes from Rails.
Earlier quoted context omitted.
Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. In any case, it's still early to determine the impact on performance from upgrading to Ruby 3.3. I guess we'll be able to tell more in the coming months.
> Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. Hardly relevant, I'd think at least 80% of all Ruby usage everywhere is in Ruby on Rails applications.
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…
If I’m going to give it even a second glance, I can’t be seeing “ruby 10,000% slower than Java” for measured use cases.
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.
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.
“Why would I pointlessly accept this clear case of massive technical debt for literally no reason what-so-ever?”
Rails does not present any sort of promise that go does not also present, so just saying “yeah, I’ll handcuff my app like this cause I feel like using Ruby” is, frankly, absurd.
When you ask the right questions, you never land on Ruby, and that’s why Ruby continues to decline.
Earlier quoted context omitted.
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.
On an average mobile connection, it’s maybe a second or so.
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.
a nice ide integrated experience:
https://code.visualstudio.com/docs/languages/ruby#_debugging...
https://github.com/ruby/vscode-rdbg
https://code.visualstudio.com/docs/editor/debugging
heavy metaprogramming in any language is going to be a pain to debug so i'm not sure what you're expecting but there are tools to help. you can also call source_location on some method to figure out where things exist.
Earlier quoted context omitted.
> Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. Hardly relevant, I'd think at least 80% of all Ruby usage everywhere is in Ruby on Rails applications.
How much of the time in a given request is even spent in Ruby code? The majority of web apps that were slow and I got a chance to analyze were spending much of the time in DB queries and slowness was usually due to unoptimized DB queries. Even endpoints that were fast, still spent a large percentage of their time not in Ruby but in DB and service requests
Also I remember Rails' ActiveRecord having some pretty egregious performance footprint (we're talking 10ms to 100ms on top of DB waiting) but I hear that was fixed a while ago.
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.
This is not just “pretend database IO” problem. This is actual cost that no business should accept on the basis of “but but but database IO (that I’ve never actually measured, but it’s an easy cop out because I read it on medium once).