[HN Gopher] Ruby 3.3
___________________________________________________________________
Ruby 3.3
Author : dduugg
Score : 543 points
Date : 2023-12-25 07:01 UTC (16 hours ago)
(HTM) web link (www.ruby-lang.org)
(TXT) w3m dump (www.ruby-lang.org)
| ksec wrote:
| I think Ruby 3.3 is perhaps one of the most important and feature
| rich Ruby release in the past 10 years. I never thought Ruby
| would have a shipping and production ready JIT before Python. And
| Prism, Lrama, IRB. A lot of these were discussed in previous HN
| submissions.
|
| But one thing that is not mentioned or discussed enough, is
| Ractor, M:N thread scheduler, Fibre and Async. Especially in the
| context of Rails. I am wondering if any one are using these
| features in productions and if you could share any thoughts on
| the subject.
| rjzzleep wrote:
| 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 rabbitmq
| or redis based private company solutions out there.
| byroot wrote:
| Mike Perham (the sidekiq maintainer) also maintains the less
| well known faktory[0] which is language agnostic and has
| runners for both Ruby and Python
|
| [0] https://github.com/contribsys/faktory
| rjzzleep wrote:
| That's awesome. Any idea why he doesn't just supersede
| Sidekiq with that? I spent quite some time hacking my own
| solution.
|
| I just looked at the source, I guess Mike has been mostly
| working on both projects on his own for the last 4 years,
| so Faktory has a lot of features that require the
| enterprise license.
|
| I wonder if he could change the situation it he markets a
| bit more to the python and more specifically Django
| community.
| f6v wrote:
| Because people running sidekiq with their Ruby app on
| production don't care about cross-language queue. If you
| pay for Pro or Enterprise you don't want any major
| changes that are potentially breaking.
| cactusplant7374 wrote:
| The only reason we pay is because the pro version doesn't
| lose jobs if a worker crashes. You would think that would
| be a core feature.
| aaronbrethorst wrote:
| A man's gotta eat.
| ckolkey wrote:
| Sounds like Mike found a good feature that would
| encourage companies to purchase a license. I have a
| tremendous admiration for the business he's built.
| keithalewis wrote:
| This relies on the Go runtime scheduler. Sometimes that is
| not good enough.
| akvadrako wrote:
| Because it's a rare need and easy to write your own based on
| postgres or redis.
|
| External systems come with a cost, especially if it's more
| than a library.
| pmontra wrote:
| 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" by using Django's ORM inheritance (my suggestion:
| never use it) so nothing can interact effectively with it
| except Python code using the same models.
|
| By the way, celery was born as a protocol spec to support
| multiple languages but never moved past Python. I can't
| google a quote for that, I remember I saw it years ago in the
| documentation somewhere.
| rjzzleep wrote:
| I can see that it was born that way, but nowadays most job
| queues say, don't touch the wire protocol, it's not
| intended to be used directly.
|
| I still think Rails has the best ORM design I've ever seen,
| iterated with practical applications. Django's ORM and
| migrations are, for lack of a better word, odd.
|
| I'm a bit surprised that people here argue that no one
| using Rails would ever want to interface with other
| languages. Most big companies do. How can you not interface
| with python these days.
|
| Looks to me like celery might just be the only job queue
| left like that. Might be worth writing a current ruby en-
| queuing library for it. Retracting my previous statement
| about ActiveJob since it would probably be too much effort
| to execute anything bidirectionally.
|
| https://docs.celeryq.dev/en/stable/internals/protocol.html#
| riffraff wrote:
| What's wrong with Django's orm? Does it have something
| particularly bad compared to others?
| cdcarter wrote:
| I think the poster is specifically referring to using
| _inheritance_ in Django ORM, where if you had e.g. a
| model Book and then a model Novel that inherits from it.
| In python these are modeled as a class inheritance
| hierarchy, and Django (at least, by default) creates a
| database table per class in the hierarchy. If you have
| 3-4 levels of inheritance, that 's 3-4 extra joins per
| query.
| mixmastamyk wrote:
| We use that, a base model and some mixins, but we use
| Meta.abstract=True (or similar, not at my desk) on the
| parents and have not noticed any issues, though have not
| looked for them either! Should I be concerned?
| cdcarter wrote:
| That works fine. It's when you inherit from a non-
| abstract model that you end up with the trickier data
| model.
| pmontra wrote:
| This. That customer of mine started a project a few years
| before hiring me. They used inheritance and each model is
| scattered around a number of tables. No external tool can
| sensibly access that database, except that very Django
| app and its manage.py commands. Add a similarly
| enthusiastic use of apps under the same main directory
| and the database is a mess of long named tables with a
| tangle of relationships between them.
|
| We started another project later on and we planned the
| database first. We wrote one model per table, no
| inheritance, only a few cleanly delimited apps. We still
| use makemigrations and migrate but if we want we can
| write a piece of software on any language to access that
| database.
| emmelaich wrote:
| There is Perl Directory::Queue / Python dirq which also has
| implementations in Go, Java, and C.
|
| A Ruby implementation would probably not be hard.
|
| I don't how much people use this in serious or high
| performance work but it might be an option.
| petepete wrote:
| There's beanstalkd, it has a few Python libraries and it
| works out of the box with ActiveJob via Backburner.
|
| https://beanstalkd.github.io/
| jsjohnst wrote:
| > The one thing I genuinely don't understand is why there is
| no single task queue that works across ruby and python.
|
| Not sure I can recommend it, but Gearman does fit the bill.
| There's client and worker libraries for a dozen languages,
| including Python3 and Ruby.
| Alifatisk wrote:
| > I think Ruby 3.3 is perhaps one of the most important and
| feature rich Ruby release in the past 10 years.
|
| Really? What's so significant with this release?
|
| > But one thing that is not mentioned or discussed enough, is
| Ractor, M:N thread scheduler, Fibre and Async.
|
| Yes! Ractors deserve more highlighting! It's a huge feature.
| Lio wrote:
| > _Really? What's so significant with this release?_
|
| I think the Prism parser update is a standout highlight for
| me. This is the start of many new static analysis tools for
| ruby.
|
| It's also significant that RBS type information is starting
| to be used in IRB autocompletion. Previously RBS has been an
| interesting experiment but hasn't had much practical use
| compared to Sorbet.
|
| Ruby seems to now have good answers to non-blocking IO (async
| fibers) and tooling questions (ruby-lsp). We're starting to
| see YJIT performance improvements starting to compound with
| more to come too.
|
| That all seems significant to me. Thanks to everyone
| involved.
| rfoo wrote:
| > I never thought Ruby would have a shipping and production
| ready JIT before Python.
|
| This is entirely predictable - Ruby does not have a big
| scientific computing community which happened to depend on
| every implementation detail of the hosting interpreter.
| byroot wrote:
| I don't see how it's relevant given that YJIT didn't cause
| any compatibility issue whatsoever.
| pjmlp wrote:
| Python has a culture that sees writing C libraries as
| "Python" code, hence why.
|
| It is quite common to see "Python" libraries that are just
| thin bindings layers, they could just as well be "Tcl"
| libraries for that matter.
| tnecniv wrote:
| I should start doing numerical work in TCL and see how long
| it takes for me to get set to the mad house
| pjmlp wrote:
| Well, first step is to create bindings to the same
| libraries Python uses.
| nerdponx wrote:
| 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 implementation of Python was a challenge
| that took a long time to reach baseline usability.
|
| You could forego Numpy and call out to a library like
| Eigen, but even then you have a huge amount of work ahead
| to achieve anything resembling feature parity.
| pjmlp wrote:
| Who singled out Numpy?
|
| Still, your lengthy explanation only confirms how much C
| and how little Python, that specific case happens to be.
| dejv wrote:
| There are huge apps (such as Shopify) which will safe a lot
| of money by having more performant BE so they do invest
| heavily into it.
|
| Python workloads, with deep pocketed backers, do spend more
| time inside GPU or C runtime.
| pvg wrote:
| There's a talk from a couple of years ago by one of the YJIT
| developers that discusses this in some detail and it's more
| interesting/complicated than that. The whole thing is worth
| checking out but the specific section starts here
|
| https://youtu.be/vucLAqv7qpc?t=937
| phaedryx wrote:
| Prism is interesting. Any Ruby code analysis tools that use it?
| I've been looking for ways to analyze my code at work.
| nirvdrum wrote:
| The Ruby LSP uses Prism. Kevin Newton has implemented a Prism-
| based backed for the white quark/parser gem [1] that can be
| used with Rubocop.
|
| [1] https://github.com/kddnewton/parser-prism
| riffraff wrote:
| I had missed this. Six times faster? Wow!
| alberth wrote:
| Every Christmas, like clockwork, Ruby Lang drops a new release.
| quickthrower2 wrote:
| It is a cute thing about Ruby
| mberning wrote:
| You love to see it.
| revskill wrote:
| I hope Ruby 4.0 could allow explicit import and avoid implicit,
| global namespace gem import mechanism like nowsdays.
| t-writescode wrote:
| I'm feeling a bit ignorant, but isn't this a Rails thing and
| not a Ruby thing? I know that for most projects that's a
| distinction without a difference; but, that may be a decision
| from the Rails devs and unrelated to what Ruby's devs do?
|
| Or I'm speaking out of my ear and completely wrong (and I don't
| know which :D)
| byroot wrote:
| It's a Ruby thing. Ruby only has a single global namespace,
| no imports.
|
| If anything Rails autoloading (Zeitwerk really) make it much
| easier to find where constants come from as it enforce a
| constant name -> file name convention, so all you need is
| fuzzy file search.
| Calavar wrote:
| You're right, implicit import (autoload) is an opt-in
| feature. Rails used to use autoload by default as of 3.x/4.x.
| It's been quite a while since I used Rails, so I'm not sure
| if this is still the case.
|
| Ruby imports have always used a single global namespace. I'm
| not convinced that this is an issue in practice - it's worked
| just fine for several other languages.
| hetman wrote:
| I mean, only because it's possible to learn to live with
| doesn't make it pleasant. Especially for managing large
| projects it can get unwieldy. Most high level languages I
| can think of have moved away from this approach.
|
| I used to be a huge Ruby fan but having exposure to Python
| where this isn't an issue, life is just easier.
| oleg_antonyan wrote:
| It's a matter of personal preference and/or which one
| you've learnt to live with first.
|
| I like how Ruby's imports work - just load a file,
| similar to C. On the other hand, modules in Python always
| felt like something to overcome rather than "just works
| as you expect".
| ckolkey wrote:
| To each their own, I guess. After working with
| python/lua, I really appreciate not needing to do manual
| imports all over. I'm glad ruby makes this so easy :)
|
| Oh, and not needing __init__.py files in order to import
| something. Goodness, what an absolute pain.
| nerdponx wrote:
| I really like the Python/Lua module system. To each their
| own...
| mypalmike wrote:
| I agree, but Ruby folks seem to consider C style
| transitive inclusion to be a feature. I found it and
| several other aspects of Ruby to be maddening (and
| productivity-sapping) for the 1.5 years I spent with an
| otherwise pretty nice language.
| lloeki wrote:
| There's a big difference between Rails autoloading and Ruby
| autoload, in that Rails is implicit and conventional from
| the constant name plus load paths, whereas Ruby is explicit
| as one declares where to find each constant.
| jhealy wrote:
| Implicit or explicit, I'm OK with the global namespace.
|
| On paper it's awkward, but in reality convention and social
| norms make it rarely an issue.
|
| The global namespace only supporting exactly one version of
| each gem encourages a health culture of stable ABIs and
| deprecation periods too. An absolute dream compared to some
| language ecosystems
| tomstuart wrote:
| You might be interested in Chris Salzberg's Im [0], already
| usable on Ruby 3.2, or the discussion about the speculative
| "namespace on read" feature [1].
|
| [0] https://github.com/shioyama/im
|
| [1] https://bugs.ruby-lang.org/issues/19744
| Alifatisk wrote:
| You won't see Ruby 4.0 until 2030.
| https://youtu.be/4MM5b2F9zrM?si=UT3aUbD6p_uBZehS&t=2347
| pgib wrote:
| Very much looking forward to upgrading our application to ensure
| 3.3 compatibility.
| ciconia wrote:
| 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-
| sho...
|
| Edit: add percentage to performance improvements.
| IshKebab wrote:
| > 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 wrote:
| I 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.
| trealira wrote:
| It 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 wrote:
| > _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 wrote:
| > 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.
| ric2b wrote:
| 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.
| pdimitar wrote:
| I agree but people are doing it anyway. So technically
| Ruby on Rails and C++ are competitors in the web backend
| space.
| Alifatisk wrote:
| 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
| hello_moto wrote:
| Who builds web backend in C++?
| jupp0r wrote:
| Google, Facebook, Amazon and Twitter beg to differ (not
| completely C++, but for services where it makes sense).
| Also nginx, passenger and other parts of your Ruby app.
| hello_moto wrote:
| _shrug_ the companies you mentioned do not use C++ for
| web-app.
|
| Amazon is a huge Java shop.
|
| Twitter used to be huge Rails app with Java/Scala
| services.
|
| NGINX and Passenger are infrastructure pieces just like
| Memcached so I think you need to understand the context
| here...
| cutler wrote:
| 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.
| pdimitar wrote:
| 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.
| wredue wrote:
| Nah. One rust based server can power the same number of
| connections as 10-100 ruby based servers.
|
| 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).
| cutler wrote:
| But you factored-out developer productivity. What you
| gain in reduced server costs is lost many times over in
| developer productivity. Companies who chose Rails for
| decades knew it was slower and more memory-hungry than
| rolling everything yourself in Rust or C++. They did the
| math and the business case for Rails was more compelling.
| wredue wrote:
| Rails is no more productive than go, and a developer
| taking 20 extra minutes (frankly, not likely, even if
| we're talking rust) to write go rather than Ruby is not
| going to cost more than the $1000 a month the extra Ruby
| servers cost you just to run.
|
| "But but but developer productivity" is a myth.
| cutler wrote:
| Rails is a framework. Go is a programming language. Show
| me a Go command line which sets up a fully-baked MVC app
| complete with data model, migrations, CORS, caching,
| asset pipeline, mailer, mailbox, chat(Action Cable), job
| queue and a Hotwire equivalent. While you're baking all
| of that yourself I'm off to the races. There's Buffalo
| but you compared Go with Rails so I assume you meant
| rolling your own using just the Go standard library.
| hello_moto wrote:
| I'd choose Go and Java any given day before Rust.
|
| That language with C++ mindset is just... horrible.
| ciconia wrote:
| 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.
| pdimitar wrote:
| > _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 wrote:
| It 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 wrote:
| 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.
| Alifatisk wrote:
| Absolutely, 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.
| cutler wrote:
| 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.
| csjh wrote:
| Isn't factoring out C based libraries ignoring a large
| part of the Python ecosystem?
| Alifatisk wrote:
| 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.
| cutler wrote:
| Yes, but if you're comparing language performance that's
| important.
| ajmurmann wrote:
| 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
| pdimitar wrote:
| That is true, yes, but still comparing e.g. Rust vs. Ruby
| I'd think Rust spends anywhere from 10ns to 100ns
| (outside of waiting on DB) and Ruby no less than 10 ms.
| Still pretty significant and can add up during times of
| big load.
|
| 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.
| ajmurmann wrote:
| My point was that if we look at Rails performance going
| up 10%, what does that mean for time spent in Ruby. I'd
| believe anything from a 15% to a 80% reduction of time
| spent in Ruby code
| tomlin wrote:
| 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.
| aantix wrote:
| 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.
| cutler wrote:
| 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.
| the_gastropod wrote:
| 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.
| seabrookmx wrote:
| There'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.
| ochoseis wrote:
| Further, with a lot of the batteries-included web
| frameworks you end up with a ton of suboptimal database
| queries (e.g. unintentional query-in-loop). Some would
| argue that you can just profile your code and optimize
| the hot spots, but I would tend to think it still slows
| you down quite a bit overall.
| seabrookmx wrote:
| So common that apps like sentry have special logic to
| detect these "N+1" queries. We find DRF is awful for
| this.
| neonsunset wrote:
| One of the biggest breaking changes that EF Core did was
| to explicitly disallow such generated queries that
| required application-side evaluation and could not get
| compiled to pure SQL (you can get other behavior back
| with a toggle but it is discouraged).
|
| I strongly believe it is wrong to do otherwise and is a
| source of numerous footguns unless you invest in tracking
| them down.
| cutler wrote:
| Apples to oranges, no?
| ksec wrote:
| If 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 wrote:
| Can 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 wrote:
| Perhaps 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 wrote:
| "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?
| kyledrake wrote:
| 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 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 wrote:
| _> 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 wrote:
| 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.
| serial_dev wrote:
| TIL there is units command line tool.
| dexwiz wrote:
| The reverse is good also. 0.00005 vs 0.005 cents/request
| seems very close as a human. But considering that times the
| seconds in a day or month results in very different values.
| jupp0r wrote:
| 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.
| choilive wrote:
| 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.
| jupp0r wrote:
| The test was local, ie using the loopback interface on a
| large server.
| x86x87 wrote:
| Are you actually going to the DB or is that json
| synthetically generated? Is it the same json? What
| exactly are we testing here?
| jupp0r wrote:
| Sorry 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 wrote:
| 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.
| jupp0r wrote:
| 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.
| the_gastropod wrote:
| 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.
| wredue wrote:
| 1,000 records is absolutely not a lot on modern computers
| or connections. On a business LAN, this request should
| take well under a second full latency.
|
| On an average mobile connection, it's maybe a second or
| so.
| tauchunfall wrote:
| True, you would not return 1000 objects at once to the
| frontend.
|
| I first thought it's just a backend use-case, where
| processing 1000 records in a paginated result is common,
| but the parent mentions "rails", so it sounds like a
| frontend use-case.
| jupp0r wrote:
| It's a backend use case.
| wredue wrote:
| The better question is
|
| "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.
| SkyPuncher wrote:
| Why does that matter?
|
| You're likely in one of two situations as a businesss:
|
| * You're a struggling startup. Development velocity trumps
| literally everything. Your server costs are trivial, just
| turn them up.
|
| * You're a successful business (maybe in part because you
| moved fast with Ruby), you can pay down the debt on that
| absurdly large response. Chunk it, paginate it, remove
| unnecessary attributes.
| jupp0r wrote:
| 1MB is "absurdly large"? This is not the Todo app industry
| sorry.
|
| This is paginated (page size of 1000) and the caller
| chooses only the attribute they need already, thanks.
|
| Even successful companies care whether they need to run
| 1000 servers or one for something.
| harshreality wrote:
| Why Rails, instead of a lighter-weight framework, if
| performance is such a priority? Obviously that wouldn't get
| you to [anywhere near] the performance of compiled Go code,
| but Rails has a lot of overhead.
|
| What database is on the backend, and is that db serving
| cached content? What happens if you cache it with e.g. redis
| to avoid the heavyweight rails ORM stuff?
|
| Do you have granular benchmarks for the db query, requests to
| other services, and the web processing itself (using
| artificially pre-cached responses from db and those other
| services)?
| jupp0r wrote:
| First implementation was in Rails because the company is a
| Rails shop and the monolith was the easiest place to get
| something that works.
|
| If you rewrite it anyway, might as well use something else
| than ruby.
|
| The db (mysql) is not the problem in the scenario I
| described.
| KerrAvon wrote:
| Why not something like Sinatra so it's easy to prototype
| and move on from there if it's still not good enough?
| What you're describing isn't that complex and the base
| Ruby language is so much better than Go.
| TheAceOfHearts wrote:
| 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.
| volkk wrote:
| that's surprising considering `pry`[1] is such an amazing
| debugger IMO.
|
| [1] https://github.com/pry/pry
| weaksauce wrote:
| what is ruby debug not able to do that you want it to do?
|
| https://github.com/ruby/debug
|
| 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.
| SkyPuncher wrote:
| Meta programming is my largest complaint with Ruby. It
| creates huge surprises that are very difficult to inspect and
| debug.
| jweir wrote:
| We 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.
| acchow wrote:
| I was pretty excited hearing "double digit" thinking 50 or 80%.
|
| The link shows 13-15%.
| wredue wrote:
| Unless 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 wrote:
| I've never met literally anyone who saw ruby and was happy.
| It's always "but it's written in ruby"
| samtheprogram wrote:
| Pleasure to meet you.
| nextaccountic wrote:
| > RUBY_MAX_CPU=n environment variable sets maximum number of N
| (maximum number of native threads). The default value is 8.
|
| Shouldn't the default be the number of logical cores? Like Rust's
| Tokio and countless other M:N runtimes
| MoOmer wrote:
| That's an optimization that can be added later, with some
| nuance. IIRC Go had a similar situation for years; I remember
| setting GO_MAX_PROCS in my init() or main()!
| Alifatisk wrote:
| Yeah, setting a hard cap on the maximum cpu count doesn't feel
| right? Why not depend on the available cores?
| SkyPuncher wrote:
| It's a safe choice. Some systems won't report cores correctly
| which can lead to reallllllly bad performance.
| captn3m0 wrote:
| Friendly reminder that Ruby 3.0 will now go EOL in 3 months, so
| you have 12 weeks to upgrade.
| awestroke wrote:
| I don't think I will.
| pmdr wrote:
| The perfect Christmas gift!
| xpressvideoz wrote:
| > Name resolution such as `Socket.getaddrinfo` can now be
| interrupted. Whenever it needs name resolution, it creates a
| worker pthread, and executes `getaddrinfo(3)` in it.
|
| Do other language runtimes do similar things? Creating a thread
| sounds too heavy, though it might not matter in practice. As per
| their own benchmark, the overhead is minimal but still not zero.
| 10000.times { Addrinfo.getaddrinfo("www.ruby-
| lang.org", 80) } # Before patch: 2.3 sec. # After
| ptach: 3.0 sec. 100.times {
| URI.open("https://www.ruby-lang.org").read } # Before
| patch: 3.36 sec. # After ptach: 3.40 sec.
| Alifatisk wrote:
| Wouldn't a fiber be more lightweight than having to create a
| new thread?
| byroot wrote:
| A fiber doesn't have a dedicated execution context, so it
| would be just as blocking.
| Alifatisk wrote:
| Is there really no other way than creating a whole thread
| for this?
| viraptor wrote:
| You can use a pure ruby resolver if you want. For example
| https://github.com/socketry/async-dns
|
| But that way your sacrificing integration into your
| system's nsswitch which may want to do something
| completely different with your requests.
|
| You could also query over dbus which can be async https:/
| /www.freedesktop.org/software/systemd/man/latest/org....
| (if you can depend on systemd)
| byroot wrote:
| There is a few alternatives like getaddrinfo_a(3) but
| they have other downsides (fork safety concerns).
|
| If you want more context, you can read:
| https://bugs.ruby-lang.org/issues/19430
| chucke wrote:
| The getaddrinfo interface does not expose the fd so you can
| monitor for readiness. Several languages have the same
| problem with it, some with similar solutions (go outsources
| getaddrinfo calls to a thread pool)
| nerdponx wrote:
| Is this because all of the I/O operations in the standard
| library have to support async/fibers?
|
| My impression is that everything was migrated to be
| asynchronous by default, unlike in Python where all of these
| operations were reimplemented in the async "color". Is that
| true?
| 999900000999 wrote:
| Worth it to learn Ruby if you already know Python and NodeJS ?
|
| I find Ruby fascinating yet difficult.
| jitl wrote:
| I think Ruby is much better at shell script like tasks and
| interactive / exploratory programming for system tasks compared
| to Python or Node. Use it as "better bash" or "better Perl" and
| it's worth it. I primarily work in a Typescript codebase, but
| regularly reach for it as a tool to wrangle log data, semi-
| structured text, or do regex rewrites of a bunch of files.
|
| Ruby is also very fun, probably the most fun language I've used
| regularly. That makes it its own reward.
| eddieroger wrote:
| If you're productive in Node or Python, then learning Ruby
| would just be educational in that it's something else to use.
| Personally, I've found Ruby to be a great language in which I
| can be productive quickly, which is why I stick with it, but
| I've written Ruby code off and on for the last 15 years in
| various forms of production code. I think it's great to learn,
| but I wouldn't switch to it (or anything) if you're already
| productive elsewhere.
| lp4vn wrote:
| 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 2013 RoR already
| showed its age as the standard ways of doing things with it was
| still the monolithic way and the framework was not
| transitioning very well to the new paradigm of frontend/backend
| development.
|
| This introduction about a framework built with ruby and not
| ruby itself was necessary because even today, I would guess
| that 95% of all development with ruby is RoR applications. It's
| my understanding that ruby rose to prominence mostly because of
| ruby on rails, now that RoR is in a downward trend I think ruby
| will follow the same trend until it's reduced to a small
| community of enthusiasts in the same way that happened to perl.
|
| As for the language itself I can't think of a single reason to
| opt for ruby over python or typescript. Ruby doesn't do
| anything better both in terms of language or platform than its
| already better established competitors.
| gls2ro wrote:
| 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.
| lp4vn wrote:
| >Maybe Ruby is not at the level where is was in 2007-2009
| but it is also NOT in a downward trend.
|
| It's not only that ruby and ruby on rails are trending
| down, this has been the case for at least 10 years.
|
| https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/
|
| This is only an article, but you will find the same point
| of view in many other places. The decline of ruby and RoR
| is obvious for anyone doing web development. Python is only
| getting stronger, Typescript the same, not to mention the
| statically typed competitors like Java with Spring Boot.
|
| I wouldn't doubt that even languages like Go and Rust might
| surpass ruby soon in web development because as general
| purpose languages they are already more relevant.
|
| I'm a former RoR developer and I took off the keywords ruby
| and ruby on rails from my curriculum because for me
| professionally it makes no sense to invest time in them.
| hello_moto wrote:
| Hi-tech are cyclical.
|
| Ruby got nothing else bigger than Rails unfortunately no
| matter how people in that community is hyping Ruby out.
|
| It's okay if Ruby and Rails on a downward trend it might
| pick up again in the future.
|
| C'mon now, we all know that our industry is like a Fashion
| industry.
|
| The only reason why Rails is making a comeback is because
| we're in tough time: no more VC money to hire tons of
| Engineers to build a web-app.
|
| When money was flowing, folks tend to build over-engineered
| solution (microservice, mesos, container, k8s, cloud-y
| orchestration), when money is tight, folks tend to build
| simple stuff because of lack of resources.
| lp4vn wrote:
| Correct.
|
| But now there is another complication to an eventual
| reemergence of ruby on rails: the competition defeated
| the initial comparative advantage - i.e. the simplicity -
| of the RoR platform. The premises that justified RoR in
| the past are too weak today in my opinion. The framework
| was sold on how easy and no-nosense it was setting it up
| and start prototyping your commercial solution in a time
| where the competitors were awkward and epitomized by
| J2EE, where setting up and developing the most basic
| application was time consuming and complicated.
|
| Today with Spring Boot, for instance, you can bootstrap
| and develop your app as quickly and easily as any other
| cool and alternative framework but with the advantage of
| using a really popular and fast language.
|
| Technologies don't die quickly and COBOL and Perl are the
| living proof, but it's really hard to see a bright future
| for RoR and ruby and I think that most of their
| contribution was already given.
| bluerooibos wrote:
| > Ruby doesn't do anything better
|
| I'll bite.
|
| Even at the most basic level of built in functions/methods
| (String, Array, Hash) - I found Ruby's to blow Python's out
| of the water.
|
| https://ruby-doc.org/core-2.5.1/String.html
|
| https://www.w3schools.com/python/python_ref_string.asp
|
| Even Python's choice of naming and syntax to use these basic
| functions just hasn't been thought through as much as Ruby's
| implementation. There's a reason it's called the language of
| Developer happiness.
|
| Ruby's community I've found is more focused on best
| engineering practices (like testing) than others, which is
| perhaps why RSpec and MiniTest are fantastic frameworks. The
| likes of PyTest doesn't even compare to what those two offer.
|
| Plenty of reason above to use Ruby, and we haven't even got
| to Rails yet.
| hello_moto wrote:
| You bite, I'll spit.
|
| Meh. Been in the industry longer enough to not care about
| Developer happiness but more about solving problems
| quickly.
|
| Your developer happiness ain't necessary mine just like
| some people prefer the cuteness of Ruby and other prefers
| the strictness/patterns of Java.
| pmdr wrote:
| > now that RoR is in a downward trend
|
| It's really sad if that's the case. What's replacing it
| (mostly JS/TS everywhere, relying on PaaS) really isn't as
| fun.
| burlesona wrote:
| 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 expressing code, and it's neat to experience
| that.
| nerdponx wrote:
| Having tried to use Ruby for text processing specifically,
| I'm not sure I agree it beats Python at that particular task.
| Maybe I'm just used to the Python way of doing things, but I
| found it difficult to work with the lack of first-class
| functions and iterators/generators, as well as the general
| iteration protocol.
| weaksauce wrote:
| > lack of first-class functions and iterators/generators,
| as well as the general iteration protocol
|
| can you elaborate on what you miss here? ruby has a robust
| enumerable suite of methods so i'm curious what you found
| lacking
| dragonwriter wrote:
| > but I found it difficult to work with the lack of first-
| class functions and iterators/generators, as well as the
| general iteration protocol.
|
| Ruby has iterators/generators. It doesn't have first-class
| functions because it doesn't have functions _at all_ , but
| blocks/procs serve the same purposes.
| bluerooibos wrote:
| I find the opposite. Ruby has a longer list of String,
| Array and Hash methods/functions and they're also more
| useable.
|
| Another issue I had was that Python's test frameworks like
| PyTest were just so weak compared to the likes of MiniTest
| and RSpec.
| e12e wrote:
| > ... lack of first-class functions and
| iterators/generators, as well as the general iteration
| protocol.
|
| I'd love to hear what makes you say this - none of it is
| meaningfully true (ruby doesn't have functions, but it has
| blocks and callables).
|
| It has:
|
| https://docs.ruby-lang.org/en/master/Enumerator.html
| djur wrote:
| What is the distinction between a function and a proc? I
| would say that a proc is a (first-class) function.
| gls2ro wrote:
| > 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.
| riffraff wrote:
| Stripe is a big "ruby but not rails" shop, iirc.
| xivusr wrote:
| 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 for me. I've grown
| to appreciate Python indents and find it nice to read, but that
| was also annoying at first.
| tjpnz wrote:
| 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.
| jshen wrote:
| 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.
| SkyPuncher wrote:
| I'm primarily a Ruby dev, but still find most languages
| easier to work with.
|
| Ruby itself is not the issue. The way people and frameworks
| (looking at you Rails) abuse its mechanics in pursuit of
| "clean code" drives me crazy. An incredible number of things
| are downright challenging to debug because of the insane
| flexibility of Ruby.
| block_dagger wrote:
| Use Rubocop to give you hints about improving your code as you
| learn. It' s a wonderful linter and teacher!
| ufmace wrote:
| Depends on what you're looking to get from it.
|
| The most interesting part IMO is how it's so similar to Python
| along many categories, but also so different.
|
| Biggest example is how Ruby just loves Blocks. They're all over
| the place in the std lib, tons of syntax sugar for them, and
| countless DSLs built around them. All the standard functional
| stuff is there in the std lib and has been from very early on,
| so doing functional-style stuff is really smooth and reads
| well. In Python, you can technically do most of the same stuff,
| but it all seems a lot more awkward to write and to read
| (though maybe just my opinion from doing Ruby first). Python
| has lambdas, but it doesn't seem to like them much for more
| than trivial things. But instead functions are first-class
| everywhere.
| hello_moto wrote:
| Only if you want to build web-app that fit Rails.
|
| I wouldn't use NodeJS to build web-app that fits Rails. NodeJS
| ecosystem feels like building on a house of cards though.
| 999900000999 wrote:
| NodeJS is probably my strongest language. But it's horribly
| unstable, the sheer amount of legacy code is overwhelming.
|
| Python feels alot cleaner, but I wouldn't pick it over Node
| for web UI automation or Rest API testing.
| Exuma wrote:
| Just enabled YJIT this morning. Merry CHristmas!
| schneems wrote:
| Available on Heroku https://devcenter.heroku.com/changelog-
| items/2772
| olivierlacan wrote:
| Thanks Richard.
| mortallywounded wrote:
| 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.
| byroot wrote:
| This number is from a production workload with a significant
| chunk of IOs.
|
| If you look at CPU bound micro-benchmarks like most similar
| announcements uses, you easily get into the 3x territory:
| https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...
| alberth wrote:
| > "get into the 3x territory"
|
| Where are you seeing 3x improvement?
|
| Because even this graph from your article doesn't show that,
| unless you're comparing JIT vs non-JIT. But JIT has existed
| for awhile now (not new in 3.3).
|
| https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-
| faster-w...
| byroot wrote:
| In the yjit-bench suite, there are a number of micro
| benchmarks that had a 2-3x gain between 3.2 and 3.3:
| https://speed.yjit.org/stats-timeline.html
|
| But my point is that the YJIT team never really communicate
| numbers from synthetic benchmarks, it's very focused on
| real world workloads.
|
| Synthetic benchmarks are used internally, but mostly to
| optimize a specific pattern that was identified as a common
| hotspot.
|
| All this to say this figure you quote is not to be directly
| compared to many similar announcements from other projects
| or benchmark suites.
|
| Now if you still think it's not good enough, I encourage
| you to try your hand at it to see how much of an
| accomplishment that really is.
| nixpulvis wrote:
| Anyone have a link to some good examples of using Prism? I was
| disappointed to not really see anything other than the "Notable
| API" from this release page.
___________________________________________________________________
(page generated 2023-12-25 23:02 UTC)