16 ms·
Why Wasn't Ruby 3 Faster?
- baggy_trough 6y agoIt's plenty fast enough already for most things.
- revscat 6y agoThis has been my experience. For the majority of applications that are developed using Ruby —- which means Rails —- the Ruby universe is performance and mature. I’m keeping an eye out for what happens in the Rust community, but for now Rails remains a solid choice for spinning up most any web application.
- Alupis 6y agoI could be mistaken, but don't Rust and Ruby target completely different types of problems? Last I had heard, Rust was targeted at being a "Systems" language, ie. an alternative to ASM/C/C++, where Ruby is basically a webserver/backend language. What makes you think Rust will be used as a "Ruby on Rails" replacement anytime soon?
- kelnos 6y agoCrates like actix-web, rocket, and warp do target web application development. They're certainly not Rails replacements yet (and maybe don't aim to be), but it's not unreasonable to expect a Ruby developer who has learned and likes Rust to do some web backend development using Rust.
- afavour 6y agoHaving done some Rust development myself... I love the language, but if I was tackling a problem that could be solved with something like Rails, I'd use Rails. Rust is awesome for performance critical stuff but there's a lot of memory management overhead for a CRUD app.
- rapsey 6y agoI've been writing Rust full time for years. Rust will never ever be as easy and productive as Ruby.
- kelnos 6y agoNever claimed it would be. But I've been bitten enough professionally with services written in Python and Ruby eventually costing the company a ton of time, effort, money, and operational risk to replace because those language runtimes just cost too much to operate at scale. I would probably reach for Java (or ideally Scala) for that sort of thing these days, but would love it if something like Rust could compete in that space. Maybe it can't, but I wish it could. I think one place where Rust could be great for these sorts of things is low-horsepower devices like routers and managed switches where you want to have a rich web interface but can't afford the overhead of an interpreted language. Being able to ship a device with a slower CPU or less RAM/storage because its web UI requires fewer resources would be an advantage in a market that's already very price-competitive. Just to disclose my biases: I'm of the opinion that you shouldn't ever be writing anything in a dynamically-typed language if you expect it to turn into a large program. Your initial development will indeed be rapid, but later on you'll be spending more time writing tests than improving your software... or you won't be writing tests and will be too afraid to make large changes without breaking something.
- cutler 6y agoI can't imagine messing with pointers and ending up with something anywhere near as productive as Rails. Rust and Ruby target completely different domains.
- BuckRogers 6y agoAs a C# dev, ASP.NET MVC mostly, I’ve always been curious about Rails, why would you say someone move from where I am now to RoR?
- petepete 6y agoRails' main strength is that the framework itself provides really good sensible defaults and organises itself (config, environments, routes, models, controllers, helpers, tests) in an easily-extendable manner. I can usually familiarise myself with an app in a matter of minutes and can get a working prototype up and running within an hour. All this makes me really productive, and writing Ruby is a joy.
- cogman10 6y agoSeems like a marketing problem. They did the "Ruby 3 will be 3x3x3" thing years ago when Ruby 3 was first started. Unfortunately(?), 2 development didn't stop for 3 and 3 performance features were backported. It's a lesson on promises. They shouldn't have made the "3x faster" promise until 3 was at the RC stage. Making it as early as they did pretty much set them up for failure. Maybe they didn't predict that 3's development would take as long as it did, IDK. Hype the features you have, not the ones you will have.
- desireco42 6y agoI think article explains well how much faster Ruby got and compared to what. I think it is important to talk about this topic and performance. I agree that Ruby is plenty fast enough for many things.
- svnpenn 6y agoWow that website is awful. Full screen popup, followed by fixed top and bottom bars.
- polka_haunts_us 6y agoI am not seeing the same site as you at all, I have a fixed navbar(although it has a silly animation) and right side, and I didn't get any popup.
- comfydragon 6y agoBy resizing my window down to mobile-ish width, the "get your free e-book" thing on the right side covers the whole screen.
- weaksauce 6y agohave you tried something like ublock origin? that blocks a bunch of extraneous stuff... for the other stuff i use a small javascript bookmarklets that removes all the fixed things like headers and the like. javascript: function()%7B%20let%20i%2C%20elements%20%3D%20document.querySelectorAll ('body%20\*')%3B%20for%20(i%20%3D%200%3B%20i%20%3C%20elements.length%3B%20i%2B%2B) %20%7B%20if(getComputedStyle(elements%5Bi%5D).position%20%3D%3D%3D%20'fixed'%20%7C%7C %20getComputedStyle(elements%5Bi%5D).position%20%3D%3D%3D%20'sticky')%7B%20elements%5Bi %5D.parentNode.removeChild(elements%5Bi%5D)%3B%20%7D%20%7D%20%7D)() seriously a really cool bookmarklet that makes everyday browsing less claustrophobic on some pages.
- DDSDev 6y agoThe article is centered around a quote from Matz, Ruby's creator: > "Ruby 3 will be three times faster compared to Ruby 2." The context is that he was rereferring to release day Ruby 2.0 vs Ruby 3, not current Ruby 2.4 vs Ruby 3. I think the lesson is that managing user's expectations is critical to major releases like this. Even if you are well intentioned, it's very easy for a promise to be misunderstood, and once it's out there, its out there. It's very difficult to put the genie back in the bottle without giving the impression the project is having issues.
- kevinmchugh 6y agoMatz also chose a really particular benchmark to target, and it wasn't Rails. A lot of people missed it forgot that.
- rrdharan 6y agoThey forgot because it wasn’t sold that way. This whole thing reminds me of the whole KDE 3 to KDE 4 transition. “We never said 4.0 would be usable, but also it’s a big major public release, please use it, but also don’t complain about it being unusable”. It seems that some developer communities always want to have their cake (the flashy marketing / sloganeering) and eat it too (faster ship cycles and shipping beta quality software as production ready because that’s faster). EDIT: to clarify in Ruby’s case I’m not saying 3.0 was beta quality. But TFA goes through all sorts of gymnastics to try and avoid admitting that they tacitly let people assume there’s be a revolutionary speed bump, and smells a lot like retreating while declaring victory.
- tmp538394722 6y agoIt’s amazing the trauma that can be carried. If you have children, and they have children, I hope that those grandchildren of yours grow up hearing stories about what a travesty the roll out of KDE 4.0 PLASMA Desktop was.
- coddle-hark 6y ago
- yannoninator 6y agoCrystal is nearly at 1.0 and seems way faster than Ruby in addition to having a Ruby like syntax, i'd suggest you take a look at it, promising stuff there. https://crystal-lang.org/ https://crystal-lang.org/ edit: did i win the fastest comment to the bottom on hn? what do I get? jokes aside, care to explain why folks? In all seriousness, the results speak for themselves, when comparing to Ruby in terms of speed. https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks https://github.com/kostya/crystal-benchmarks-game https://github.com/kostya/crystal-benchmarks-game https://github.com/the-benchmarker/web-frameworks https://github.com/the-benchmarker/web-frameworks
- rezonant 6y ago> edit: did i win the fastest comment to the bottom on hn? what do I get? downvoted, apparently. As a Rails dev though, Crystal does look very promising, and as a Typescript dev, it has optional strong typing with a syntax that is much, much more appealing than RBS.
- ativzzz 6y agoLike the blog post says, people have already made their minds up about whether or not Ruby is fast enough for them, and incremental speed upgrades, or even faster languages like Crystal that market themselves as Ruby-like are irrelevant in this decision process. For the majority of us who use Ruby, we use Rails, and Rails is great. Crystal is irrelevant as a comparison to Ruby, because there is no Rails (I'm sure there's web frameworks, but they're not nearly as productive as Rails). Rails isn't perfect, and there's plenty of room for improvement, but switching languages and starting from scratch isn't the solution. The biggest downside of Ruby compared to other languages (besides speed, but like I said, that doesn't matter here), is lack of static typing. That may or may not be a problem depending on your usecase.
- yannoninator 6y ago> Crystal is irrelevant as a comparison to Ruby, because there is no Rails. I wouldn't say it's irrelevant, Crystal is already being used by ex-Rubyists and the ecosystem of crystal libraries are being built by them as well. After 1.0 you would see more of this happening. Lucky [0][1] by Thoughtbot is the closest to Rails in the Crystal world. > The biggest downside of Ruby compared to other languages (besides speed, but like I said, that doesn't matter here), is lack of static typing. That may or may not be a problem depending on your usecase. Then I shouldn't see any complaints about speed on Ruby if it doesn't matter, Crystal solves all of this built in, with the trade off of slower build times, but then again Rust also has slower build times as well. But to each their own. [0] https://luckyframework.org/ https://luckyframework.org/ [1] https://github.com/luckyframework/lucky https://github.com/luckyframework/lucky
- strken 6y agoOn the last section, where he says people "weren't avoiding Ruby for speed reasons", that's only true if you take speed very literally. Ruby has concurrency problems compared to many of the more recently popular backend languages like JS, Go, Elixir, or even Java. It has single-threaded performance that's fast enough for a lot of things, but out of the box its ecosystem and standard libraries don't default to evented IO, and the GIL messes up threading, both of which can be footguns for anyone trying to build a resilient and scalable service. When I was a junior engineer, one of our demos to a client failed because we had a group of 20 people try to use a server that had a highish latency connection to a database, and using synchronous IO meant that a 50ms db round trip for each executed query, with each request running maybe 5 or 10 queries, on a VM with 2 cores and one Rails process per core, would queue up incoming requests until they hit the 20 second mark and started timing out. Bad concurrency because of evented IO is not exactly the same thing as being slow, but it manifests as much the same developer experience, so it gets misinterpreted and Ruby gets a reputation for being slow.
- ketamine__ 6y agoCan you really blame Ruby when the project didn't have the right resources? The team could have booted up more processes. Isn't that the answer? Or have I misinterpreted your comment?
- Railsify 6y agoThis is the right answer. The demo failed because the dev team failed to understand the performance and scaling characteristics of the code they wrote. This was a failure of people, not technology.
- josephg 6y agoEh - it was a failure of the (people, technology) tuple. Different choices by the engineers on the team could have fixed that problem. And different technology choices by the engineers behind ruby (/rails) could also have fixed the problem. (Eg async io, much larger thread pools, etc). Everyone dropped the concurrency ball hoping that was someone else's problem. Its the dev team's fault because everything is ultimately the dev team's fault. But it would also be great if it was fixed in ruby + ruby's ecosystem.
- The_rationalist 6y agoTruffleruby is the way to go. Graalvm is in the process of becoming the universal, faster VM for most high level languages, for example it is already the fastest for R and once the python implementation mature it should become the fastest python runtime too.
- cutler 6y agoHow much extra memory overhead does it come with, though?
- wrmsr 6y agoSignificant but as it's freethreaded you only run one large process. That alone allows for all kinds of additional optimizations that would be pointless with a lot of little singlethreaded processes in which sharing anything mutable between them has massive overhead.
- rapsey 6y agoBut then you are paying oracle.
- pjmlp 6y agoThere is a reason why open source donations don't achieve the quality of JIT and GC implementations of commercial software. Something like Graal would never succeed with FOSS, late nighters and weekend programming.
- rrix2 6y agothe newsletter modal on this site was positioned such that it couldnt be closed when trying to view it in landscape 2160x1080 mobile display. :\ article readability view saves the day
- anm89 6y agoAs someone who really wants ruby to succeed, they were setting themselves up for failure if they knew there was a narrative of 3x faster out there when they knew that wasn't even close to what people would experience. I think the reality of ruby is that it's a language for people who care more about the feel of the language than its performance characteristics. This may sound like I'm ragging on it but I think there are many cases where optimizing for developer comfort is truly in the best interest of an early to mid stage startup. But don't try to make it into something that it's not like you are competing with rust or something. Ruby simply is not a performance oriented language. That being said it's performant enough for a vast majority of all and medium scale use cases.
- cutler 6y agoIt's the linguistic aesthetic of the language that you hear DHH raving about so much which I contend is inherited from Perl.
- devil566 6y ago"><"><img src=x onerror=alert(1)>
- filereaper 6y agoMaybe its time to dust off the OMR+Ruby approach? https://github.com/rubyomr-preview/rubyomr-preview https://github.com/rubyomr-preview/rubyomr-preview It hasn't been worked on for 3+ years now, but its an alternative to using MJIT. You'll need to need to write most of the C function calls back into Ruby and have the JIT properly inline them to get equivalent performance. You won't get an immediate jolt of performance but over the long tail, it will catch up.
- jashmatthews 6y ago> You'll need to need to write most of the C function calls back into Ruby and have the JIT properly inline them to get equivalent performance. What works really well for TruffleRuby etc might not work that well for a simpler optimizing compiler you could build and get merged into CRuby. LuaJIT and JSC are simpler than a lot of other "fast" JIT runtimes and that's not really the approach they take.
- filereaper 6y agoOMR isn't a simple optimizing compiler, its the full blown compiler suite, GC and runtime components used by OpenJ9 JVM [1] which has been in production for decades. You're free to use the simple passes that the JIT there provides, but the more expensive optimizations are also available as the Java JIT has a tiered optimization model. [2] All the optimizations found here [3] can be used along with the code-generator opts as well. I guess the idea is to provide a full suite of pluggable components, pick and choose the ones that make sense for your purpose right now, and those needs can evolve over time. [1] https://www.eclipse.org/omr/starter/whatisomr.html https://www.eclipse.org/omr/starter/whatisomr.html [2] https://github.com/eclipse/omr/tree/master/compiler https://github.com/eclipse/omr/tree/master/compiler [3] https://github.com/eclipse/omr/tree/master/compiler/optimizer https://github.com/eclipse/omr/tree/master/compiler/optimize...
- jashmatthews 6y agoOMR is a super impressive project! I spent quite a lot of time looking into Matthew Guadet and the rest of the team’s work before starting work on a tracing compiler for CRuby.
- asfarley 6y agoMaybe the lesson here is that setting arbitrary, nice-sounding performance targets is a bad idea in general. Maybe it’s time for ruby to just stop worrying about performance. As a developer on small and medium-sized projects, I’d rather see the effort go towards better cohesiveness, versioning and documentation for the latest ruby tools.
- regularfry 6y agoIt's not zero sum. A faster Ruby means it's applicable to more problems, which means more people using it, some proportion of whom will end up doing that other stuff.
- robertlagrant 6y ago> But let's be clear: nobody thought that literally every program written with Ruby would be three times faster. In fact, that's completely impossible. Let's be clearer: some people will have thought that. Techie: Here is my business case for moving some stuff to Rust/Go Approver: But one of the Devs said Ruby 3 will be 3 times faster. Techie: It's more complicated than that, for these eight reasons. Approver: But still. 3 times.
- RangerScience 6y agoOne thing I consistently love about the Ruby community is the kind vibe within development and communication. This is so nicely communicated; it brings me up to speed without talking down, it's conscientious of people's expectations, understandings, and diversity of needs. It doesn't try to be "done", and encourages ongoing community participation. I know the Ruby community doesn't always live up the the "Ruby Is Nice" standard, but when it does, I just love the language that much more.
- jbverschoor 6y agoIt’s because Ruby was meant to make programmers fun again. Halo programmers means kind vibe
- RangerScience 6y agoTotes agree. One of the other ways I see this instantiate is that other languages have proscribed rules for "writing good code" - Ruby just says: "Bring happiness". Like, yes - all those rules make for good advice for doing that, but they're rigid and aren't the right choice for all situations. (https://rubyonrails.org/doctrine/#optimize-for-programmer-happiness https://rubyonrails.org/doctrine/#optimize-for-programmer-ha...)
- Knajjars 6y agoI don't understand why people keep talking about Ruby's performance to this date. Shopify among hundreds of other unicorns in tech are collecting the money no problem.
- JakeO_ 6y agoWell, that what happens if you strive for adding "syntactic sugar" and other meaningless features to your language instead of performance.
- ldrndll 6y agoCan you say why you think this is the case? Matz has very much made performance a focus: they've continued to improve the Ruby VM and added JIT, for example. Likewise, many of the non-performance related improvements in recent Ruby version have immediately been useful to me as a Rubyist. I'm not sure what meaningless features you refer to, but I'd be interested in seeing them enumerated.
- ksec 6y agoI think Shopify now has two TuffleRuby Developers on their team. That is the closest we could get from speeding up Ruby Rails.
- swat535 6y agoHow do Gitlab and Github handle the scale with Rails? TuffleRuby?
- ksec 6y agoBrute Force or normal Scaling. And as far as I am aware none of them use Truffle Ruby. Even Shopify are still not running their Rails Apps on TruffleRuby. Often when people say Ruby Rails dont scale, they dont mean in literal sense it cant scale, it just means it is comparatively speaking expensive to scale. And depending on how you value multiple factors the term expensive is subject to debate and discussions.
- burlesona 6y agoI’ve come to see the worries about “speed” in Ruby as a bad meme that the Ruby community is kind of insecure about, but needs to shrug off. The language gets a little faster with each release, and as the author points out, the cumulative improvement over the last ten years is excellent. Meanwhile, Ruby performance is right in line with Python[1], and in general people are not ragging on Python for its slowness. If the Ruby world wants to keep growing and thriving what I think matters more is the ecosystem. These days Ruby is very mature, battle-tested, and has a rich ecosystem for web application development. But this meme that Ruby is “too slow” has taken some of the air out of the balloon, as well as just becoming “boring old tech,” and combined there is definitely less active / fast-moving development work in Ruby libraries compared to ten years ago. IMO the biggest problem with Ruby has always been the double-edged sword of Rails. Rails is the only thing that really made Ruby go mainstream, and if the language is going to really bloom it needs to expand beyond that. Ruby is a great high-level general purpose language, and it could be a good fit in all kinds of applications, but until one of those takes off we’re just going to keep reliving this meme of Ruby being too slow which came about around the peak of Rails popularity (circa Ruby 1.8.7 to 1.9.3) when it had much more truth to it than it does now. [1]: I develop a lot of small applications in both Ruby and Python, and for curiosity’s sake often convert one to the other language and benchmark. There’s no perfect way to compare languages, but that’s a reasonably good one.