12 ms·
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 amaz
by ciconia 3y ago
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 performance improvements.
Personally I'm really excited about Ruby and its future. I can't wait to start working with Ruby 3.3 and using it on my client's production sites...
[1] https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-shopify-s-production-code-15-faster/ https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...
Edit: add percentage to performance improvements.
- IshKebab 3y ago> 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++.
- Alifatisk 3y agoI seriously don’t think it’s worth comparing Ruby to languages like C++ and the rest. One is scripting language, the other compiled, the difference is huge already there.
- deleted 3y ago[deleted]
- trealira 3y agoIt may be worth comparing this new JIT to fast implementations of dynamic languages, like LuaJIT or SBCL for Common Lisp (SBCL is an AOT compiler and not a JIT though).
- pdimitar 3y ago> 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.
- Alifatisk 3y ago> It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends. Right I see your point, but in this case it’s about Ruby, the language itself, not RoR.
- pdimitar 3y agoNot denying it, I just struggle to find any non-RoR usage of Ruby out there except maybe for Homebrew.
- CoolCold 3y agoChef? Puppet?
- pdimitar 3y agoOh oops. I used Chef years ago but forgot. Thanks for reminding me.
- Alifatisk 3y agoYou're right about that, and that's something I believe the Ruby team is struggling with, to show where Ruby is useful outside the Web field. Everyones picture of Ruby is web related thanks to Rails, there is no question about it. And I find that bit sad because Ruby is also good at other things like building cli apps (have a look at Metasploit for example) & gluing different moving parts together, creating your own DSL thanks to its flexible language structure. I wouldn't say Ruby is better than any other languge though, all general purpose language could probably achieve the same result, it's just a matter of taste.
- deleted 3y ago[deleted]
- ciconia 3y agoNote 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.
- pdimitar 3y ago> 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.
- Alifatisk 3y agoIt is relevant if the cause of the slowness is due to the framework rather than the language itself. The performance can vary drastically depending on which Ruby framework you use, so it's not due to the language but the upper layer instead. Note, even if Rails is the most popular framework, there is still other alternatives which makes it even more relevant to the performance impact.
- resonious 3y agoI 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.
- Alifatisk 3y agoAbsolutely, I should maybe clarify that I did not mean to say that we can fully rule out the language itself as a cause of the poor performance, Ruby always perform worse than Go in this example for obvious reasons. But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion! And that is what I was trying to point out.
- wscourge 3y ago[flagged]
- ric2b 3y agoJava trades blows with Golang, depending on the use case.
- tomlin 3y agoI'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.
- aantix 3y agoRuby 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.
- cutler 3y agoPython 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.
- tomlin 3y agoPython is somewhat pleasure. Ruby might as well be sandscript as far as I'm concerned. The use of pipes is gross, uncoordinated and lacking direction.
- the_gastropod 3y agoWhat 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.
- seabrookmx 3y agoThere's always this rift between the "language is slow" crowd and the "but it's not the bottleneck" crowd. I think this comes from the types of applications you work on and their scale. I work at what a company that's not particularly large. Our original API is a Django monolith that serves about 1000req/s. While you could argue Python isn't the bottleneck, Django often is. I hear the same feedback from colleagues that work in Rails. Not only do we run into issues with latency per request but we have to run a significant number of Kubernetes pods to serve this workload. With c#, golang, java or a similar language we would only require a handful of pods and drastically cut our compute costs. Even for web workloads, these slow interpreted languages and their developer experience optimized frameworks absolutely do become a bottleneck and claiming they don't (or that you need to be at Google/Facebook scale before they do) is false. Everything is a tradeoff but the way I think of it: speed is a feature.
- cutler 3y agoApples to oranges, no?
- ksec 3y agoIf 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.
- byroot 3y agoCan 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.
- nsajko 3y agoPerhaps it's misleading to throw around specific numbers like 100x, but Ruby is certainly orders of magnitude slower than languages like Go or Java. Both of which are not exactly known for their speed (compared to C++ or Julia, for example).
- byroot 3y ago"speed" thrown without context is meaningless. It's one property of a tool among many others you generally have to trade for. Some use cases with small margins call for the utmost efficiency to be viable business. Some use cases just need decent efficiency and are happy to trade some efficiency for some other properties. Many successful people and companies are happy with Ruby, can we just give them a break? Or is there somehow some moral duty to use the "fastest" language available regardless of whether it makes any kind of business sense that nobody told me about?
- ksec 3y agoOn the other hand, why is it wrong to say Ruby or Rails is slow? Especially in the context of Java or Go? What is wrong with accepting a simple ground truth that is compiled language is and will always be faster than an interrupted language, even with JIT. For Rails I often compare to it another CRUD app, StackExchange [1] using ASP.net And the easiest real world comparison with Rails App would be Cookpad. Are we not seeing at least 10x difference if not more. Is Rails fast enough? That depends on the context. Everyone's business model is different. It is almost definitely fast enough for most SaaS cases. [1] https://stackexchange.com/performance https://stackexchange.com/performance
- kyledrake 3y agoI 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 queries a month across 14 tiny VPSes without even a blip on htop). I probably could have just used ruby instead of PowerDNS but it's generally not great to roll-your-own on public facing encryption, HTTP, DNS, etc. It wasn't really a performance consideration for me. The recent irony of the web is anyone that implemented a web app with "slow" ruby and backend rendering now has the fastest page loads compared to bloated front-end web apps backed by actually slow eventually consistent databases that take seconds to load even the tiniest bits of information. I see the spinner GIF far too often while doing menial things on the "modern" web.
- wolfgang42 3y ago> 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 a quick mental arithmetic and conclude that we have ~70ms to serve each request. (Though peak RPS is usually more relevant when calculating perf numbers; traffic tends to be lumpy so we need overhead to spare at all other times which makes the average much less impressive-sounding.)
- kjsthree 3y agoI 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.
- 3y ago
- jupp0r 3y agoRuby 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.
- choilive 3y agoYou'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.
- jupp0r 3y agoThe test was local, ie using the loopback interface on a large server.
- x86x87 3y agoAre you actually going to the DB or is that json synthetically generated? Is it the same json? What exactly are we testing here?
- jupp0r 3y agoSorry I was oversimplifying. Most of the data for the response comes from the db with some API calls for authorization and some auxiliary data. Benchmark was actually hitting the DB. Quite a bit of the 1mb response size is redundant (json-api format).
- the_gastropod 3y agoBut, 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.
- jupp0r 3y agoIt'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.
- TheAceOfHearts 3y agoOne 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.
- volkk 3y agothat's surprising considering `pry`[1] is such an amazing debugger IMO. [1] https://github.com/pry/pry https://github.com/pry/pry
- weaksauce 3y agowhat is ruby debug not able to do that you want it to do? https://github.com/ruby/debug https://github.com/ruby/debug a nice ide integrated experience: https://code.visualstudio.com/docs/languages/ruby#_debugging-support-with-rdbg https://code.visualstudio.com/docs/languages/ruby#_debugging... https://github.com/ruby/vscode-rdbg https://github.com/ruby/vscode-rdbg https://code.visualstudio.com/docs/editor/debugging 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.
- SkyPuncher 3y agoMeta programming is my largest complaint with Ruby. It creates huge surprises that are very difficult to inspect and debug.
- jweir 3y agoWe ban most meta programming in our own code. While the meta programming solutions are fun and clever they are often more code than a functional version and hard to maintain. We do allow the occasional use of “send” but try to avoid it. Dynamic method definitions are strictly banned.
- mwgalloway 3y agoRuby 3.3 has made major improvements to the debugging experience: https://railsatscale.com/2023-12-19-irb-for-ruby-3-3/ https://railsatscale.com/2023-12-19-irb-for-ruby-3-3/
- acchow 3y agoI was pretty excited hearing “double digit” thinking 50 or 80%. The link shows 13-15%.
- wredue 3y agoUnless those “double digits” are 98+%, ruby is still going to be quadruple digit percentage points behind strong competitors in terms of performance. 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.
- asylteltine 3y agoI’ve never met literally anyone who saw ruby and was happy. It’s always “but it’s written in ruby”
- samtheprogram 3y agoPleasure to meet you.
- riddley 3y agoI have to write awful primitively-obsessed Python at work. I LOVE Ruby.