[HN Gopher] Ruby 3.2's YJIT is Production-Ready
___________________________________________________________________
Ruby 3.2's YJIT is Production-Ready
Author : onnnon
Score : 368 points
Date : 2023-01-17 14:50 UTC (8 hours ago)
(HTM) web link (shopify.engineering)
(TXT) w3m dump (shopify.engineering)
| Alifatisk wrote:
| That's some good news
| AcerbicZero wrote:
| I'm still a shameless ruby fanboy at heart. To be fair, its
| almost all devops type tasks but there is something about that
| language that just clicks with me, and while I def have to use
| python more than ruby, I still love ruby.
| [deleted]
| hardwaregeek wrote:
| It's been a sec since I've used Ruby. How's the typing story?
| Seems like Sorbet is doing quite well, but are there
| comprehensive typings for the ecosystem, like TypeScript? Because
| with ergonomic, comprehensive type checking and a JIT, Ruby might
| be a tempting option again.
| jrochkind1 wrote:
| No, I'm afraid I'd say Sorbet/RBS haven't really been catching
| on widely.
| treis wrote:
| The problem, I think, is the restrictions that not having a
| compilation step places on what typing you can do without a big
| breaking change. Typescript didn't have this problem because
| everyone already used bundlers/minifiers/etc. Adding another
| compiler like step to that process was pretty natural.
|
| Ruby doesn't have that and adding it in poses problems for REPL
| development. They chose to go with a separate file for types.
| Which gets around the breaking change problem but the
| ergonomics are terrible. Think the hope is that IDE support
| eventually gets around that issue. But thus far not a whole lot
| of adoption.
| jacobsenscott wrote:
| Speaking for sorbet - no compilation step is a feature, not a
| bug. Imagine adding some kind of build step to every ruby app
| out there! Sorbet annotations are just valid ruby code you
| add to your files (you don't need to write separate type
| files - the sorbet system might do this for you though).
|
| Sorbet also provides a gradual typing system where you can
| start adding types to a large code base and gradually make
| the checking more strict. Stripe claims to be using it on a
| huge ruby code base and that their developers generally like
| it.
|
| However I think many devs _don 't_ want static types on Ruby.
| We like our duck typing!
| letmeinhere wrote:
| Sure, this is an advantage that Typescript has, but it
| doesn't explain Ruby's lagging progress compared to Python
| and PHP.
|
| Some of that can probably pinned on the greater dynamism of
| Ruby, making all manner of static analysis quite challenging.
|
| But from what I've seen, it seems like the main reason is
| indifference or even mild hostility from the language
| maintainers. It looks a lot like they saw Sorbet taking off
| and slapped together a competing spec (without any associated
| tooling) that would ensure all type information stays outside
| of the `.rb` file.
|
| It seems like the only impact it has had is to dissuade
| people who would like some static types from adopting it, in
| favor of this vaporware. Contrast this with Python's embrace
| gradual extension of mypy type hints.
|
| I'd love to be proven wrong, that there are thriving projects
| building atop RBS. I'd still _prefer_ a system that allowed
| me to type a function signature so that anyone inspecting it
| could immediately know its shape, but at least the shadow
| types would be _something_.
| treis wrote:
| I agree that Sorbet is a better solution but it's also a
| breaking change. It's a relatively small breaking change
| and, IMHO, would have been more than worth it but alas it
| was not my decision to make.
| michaelcampbell wrote:
| I've seen more than one ruby dev proclaim they specifically
| don't want types; if you want a language that has it, there
| are plenty to choose from.
|
| My take here is that typed-ruby is something SOME people
| want (I'm one), but a lot don't.
|
| I'm not sure what level of force that provides to anyone
| who has either tried or is considering adding it to the
| language.
| reducesuffering wrote:
| Ruby's typing story is still the worse-than-modern-Java
| boilerplate of writing loads of unit tests just to make sure an
| object is the type that you think it is.
| fxn wrote:
| This is not true.
|
| In Ruby, tests are the same you'd write in any other
| language. You test that things do what they are supposed to
| do, not the types of parameters or return values.
| v3ss0n wrote:
| Python have a 99% compatible jit implementation called PyPy and
| nobody much know about it. It was production ready since 5 years
| ago but ignored by mainstream. It is 400% faster than vanilla
| python on average and Guido and MS is working on for a few
| percent gain instead of promoting it or eventually making it
| default. PyPy.org
| [deleted]
| Alir3z4 wrote:
| Even if GvR promotes it fully, it won't be adopted unless c
| extensions work out of the box.
|
| Python without its crazy amount of extensions in c-api won't
| survive.
| whizzter wrote:
| This is something that's up to the community really. The PyPy
| developers early on made a new FFI that is also available for
| CPython, sadly not entirely as easy as the classic API but
| completely functional and if there was a push to rewrite
| extensions to use that FFI (or provide dual-paths) then the
| gap could be bridged.
| theLiminator wrote:
| Are you referencing https://github.com/hpyproject/hpy?
|
| I do hope it takes off.
| hawski wrote:
| I wonder how much of it is related to how Python is being used
| for short running scripts more than Ruby, at least in my
| experience. In such cases startup time is more important than
| being faster in a long run.
| Twirrim wrote:
| pypy is pretty well publicised and known about in the python
| community. Lots of popular libraries specifically call out
| compatibility etc.
|
| For quite a while it used to have some terrible performance if
| you ever reached out to C libraries in a hot loop. It's still a
| bit iffy on the C / FFI front, though the performance issues
| are much improved
|
| It's certainly good enough for production use, with careful
| evaluation.
| eigenvalue wrote:
| I've tried multiple times to use PyPy on real projects and it
| was totally unusable if you rely on stuff like pandas, sklearn,
| keras, fastapi, etc. I found similar issues with Numba as well.
| These things only work if you keep to a relatively small subset
| of Python and stick to "pure python" functions. Which basically
| no one does (that I can see) except in toy projects and
| tutorials. Improving cpython by 1% (without breaking
| compatibility, which python 3.10+ did a poor job of in my view)
| would do more for the world than making PyPy even faster.
| erikrothoff wrote:
| I'm pretty sure (there isn't a lot of info on how to enable it in
| production workloads) we're running YJIT in production and didn't
| notice any improvement in load times, CPU usage or anything
| really. If any slightly higher metrics across the board.
|
| We're using Rails as API and web frontend with a pretty high
| number of requests per second, so I was hoping we'd see
| something. Does anyone have any experience rolling it out?
| jrochkind1 wrote:
| > I'm pretty sure (there isn't a lot of info on how to enable
| it in production workloads
|
| The YJIT is not on by default in ruby 3.2, you have to
| specifically enable it. If you aren't sure if you have enabled
| it... what makes you pretty sure you have enabled it? It seems
| possible you have not enabled it, if you aren't confident you
| know how to do so?
|
| I am not using it yet myself, and don't want to put any
| possibly incorrect info here about how to enable it. I agree
| that it's not clear to me where to find this documented. I am
| pretty sure it is not on by default.
| JohnBooty wrote:
| The gist of it is that you need to build Ruby with
| `RUBY_CONFIGURE_OPTS=--enable-yjit` true and verify it is
| enabled with `ruby --enable-yjit --version` and then finally
| run your code with `ruby --enable-yjit foo.rb`. For Rails
| you'd want to just edit the executable Rails scripts like
| `bin/rails` to include that flag.
| MSkog wrote:
| You can also set RUBY_YJIT_ENABLE=1 to enable it.
| erikrothoff wrote:
| That's what I ended up using:
|
| passenger_env_var RUBY_YJIT_ENABLE 1;
| jrochkind1 wrote:
| Thanks! Is there a "canonical" place to find this
| documented, like with the ruby distro?
|
| > For Rails you'd want to just edit the executable Rails
| scripts like `bin/rails` to include that flag.
|
| Alternately, you can edit your shell init scripts to put
| the correct thing in `RUBY_OPTS` ENV variable, yes?
|
| I would consider this preferable to editing executable
| rails scripts with implementation-specific stuff (and then
| hoping that the app is always launched with those edited
| shell scripts, which I'm not sure eg `bundle exec rails`
| will do). I don't think editing Rails scripts is probably
| the "right" or recommended way to do this.
|
| But I'm not going to try to specify what you put in
| `RUBY_OPTS` since i haven't done it myself and don't want
| to spread misinformation! (Again, is this documented in a
| centralized trustworthy place? As I try to google it... I
| am somewhat frustrated with the ruby documentation
| situation!)
| jwcooper wrote:
| We're using puma and set the RUBYOPT=--yjit in a systemd
| environment variable for our puma service.
|
| The performance impact of enabling yjit was quite obvious
| in our charts. Another giveaway that it's properly
| enabled is the servers will use consume more memory.
| MSkog wrote:
| Perhaps this is what you are looking for:
|
| https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md
| jrochkind1 wrote:
| thank you!
| erikrothoff wrote:
| Yes, I'm pretty sure because:
|
| 1. Compiled with jyjit confrmed (ruby --yjit) returns the
| correct value
|
| 2. RubyVM::YJIT.enabled? returned true
|
| I didn't notice any improvements at basically so I can't
| really say _for sure_ if it was working as intended.
| jrochkind1 wrote:
| RubyVM::YJIT.enabled? returning true does seem to settle
| it, and no need to say "pretty sure" with qualifications!
| simantel wrote:
| Also worth noting that the Ruby 3.2 Docker image can't run
| with YJIT yet, so if your production setup is in a container,
| it's most likely not using YJIT.
|
| GitHub issue link here: https://github.com/docker-
| library/ruby/pull/398
| ufuk wrote:
| That's not correct: $ podman run -it -e
| RUBYOPT="--yjit" ruby:3.2 irb(main):001:0> puts
| RUBY_DESCRIPTION ruby 3.2.0 (2022-12-25 revision
| a528908271) +YJIT [aarch64-linux] => nil
| byroot wrote:
| There might be a number of reasons why YJIT isn't effective in
| your application.
|
| The best way to know it to enable YJIT runtime statistics [0]
| to see whether YJIT is doing a lot of side exits and if so why.
| But it requires a bit of YJIT knowledge to interpret them.
|
| It's also entirely possible that your application isn't CPU
| bound in the first place, or that it's bottlenecked by things
| YJIT can't do anything about (e.g. GVL).
|
| That's close to impossible to guess what it might be without
| being able to instrument the application.
|
| [0]
| https://github.com/ruby/ruby/blob/df6b72b8ff7af16a56fa48f3b4...
| JohnBooty wrote:
| Does anyone have any experience rolling it out?
|
| FWIW, the linked article has prod benchmarks.
| I'm pretty sure (there isn't a lot of info on how to
| enable it in production workloads) we're running YJIT
| in production
|
| Sure you're running it? You have to compile with YJIT support,
| and then pass the command line arg. (It doesn't support YJIT
| out of the box because, I presume, they didn't want to force a
| Rust dependency on everybody?)
|
| Here's how on MacOS + asdf, others will be similar. Note that I
| think --enable-yjit might work (but do nothing) even if you
| don't have support compiled in. # if you
| already installed 3.2.0 asdf uninstall ruby 3.2.0
| # install Rust asdf plugin-add rust asdf...
| # now install Ruby 3.2 asdf plugin-update ruby
| export RUBY_CONFIGURE_OPTS=--enable-yjit asdf install
| ruby 3.2.0 asdf global ruby 3.2.0 # verify
| it's installed and ready ruby --enable-yjit --version
| # now run your workload ruby --enable-yjit foo.rb
| erikrothoff wrote:
| Yes, I'm pretty sure because:
|
| 1. Compiled with jyjit confrmed (ruby --yjit) returns the
| correct value
|
| 2. RubyVM::YJIT.enabled? returned true
|
| But the information available on how to confirm YJIT is
| running is not super clear. Since I didn't notice any
| improvements I started wondering.
| JohnBooty wrote:
| Sounds like you're running it! Since I
| didn't notice any improvements I started wondering.
|
| It only speeds up Ruby itself. In a "real world" web app
| performance, performance is mostly dominated by
| Ruby/PHP/Java/whatever sitting around and waiting for
| database queries to execute.
|
| So for a lot of web workloads the perf increase won't be
| huge. If your average endpoint is e.g. 5ms of Ruby and
| 500ms of DB queries, your max speedup will be negligible if
| you switch to YJIT... or even if you rewrite the whole app
| in hand-optimized assembler.
|
| (Also gets to the root of why perf-based criticism of Ruby
| is usually dumb, IMHO. It's usually not the problem)
| why-el wrote:
| The top comment in HN is one where the poster is not 100% is
| using the thing we are discussing.
| asim wrote:
| It shows that Ruby still has life left in it yet. The language
| itself is wonderful, there's a great ecosystem of tooling but the
| performance was always lagging. Hopefully some of this makes it a
| choice for people once more over other more esoteric languages.
| My only concern here would be the time and sunk cost fallacy of
| someone like a Shopify working on a Ruby JIT. It reminds me of
| when Facebook was working on the HipHop VM for PHP code and
| compiling PHP to large C++ binaries. I mean I get it, you have
| millions of lines of code, you don't want to rewrite it, but I
| often wonder, is there a better solution to this? Is there just a
| natural path towards, write new things in a new language and
| leave the old behind? Genuine question, because I'm not talking
| about rewriting the stack, I'm just talking about not investing
| significant amounts of time in low level infrastructure that's
| totally unrelated to business priorities. Yes fast code means
| better user experiences but often there's alternative ways around
| this than doing some literal JIT compiler work.
| ljm wrote:
| I think it's almost a cliche that Ruby is dying, is dead, or is
| outdated and uncool. It comes up in almost every post about
| Ruby.
|
| It's going as strong as ever and, if anything, it's stabilised
| into a robust, expressive and powerful language and in many
| cases that's a pretty acceptable trade-off. The fact it has
| long since matured into 'boring' technology (as in 'choose
| boring technology') is nothing but a good thing.
|
| It's great that so much work is going into performance, though.
| I've been excited to try this new JIT out in prod, and I'm
| excited to see how Ractor, for example, evolves.
| jack_riminton wrote:
| Indeed. Oh well, while people keep spouting these cliches
| Ruby will continue running the worlds code bases (Github), a
| lot of the world's payments (Stripe) and a lot of the worlds
| e-commerce (Shopify)
| ryanianian wrote:
| You can often solve ~70% of this with language interop.
| Bindings and FFIs are in my opinion very under-appreciated.
| This is the approach taken by PHP+HipHop, Apple with
| Swift/ObjC, and many Python bindings over C++ internals (TF
| etc).
|
| There is no magic bullet. You can't do an overnight transition.
| If you decide to make a language shift (or equivalently large
| architecture shift), you need an interop. Old and new have to
| coexist. The remaining 30% (where interop fails) is where
| engineering happens and is often where you had hidden technical
| debt anyway.
| [deleted]
| [deleted]
| msie wrote:
| I think you don't like Ruby and would want investment in the
| your favourite language. Because why would you care what a
| corporation does with their money?
| jrochkind1 wrote:
| The JVM is as performant as it is because so much resources
| were invested in optimization (including various forms of JIT
| etc). It's an amazingly performant VM because of so much
| invested in tuning it. Or same about various Javascript VMs.
|
| This kind of performance comes from lots of resources invested
| in tuning. Lots of resources are invested, generally, when
| there are lots of entities relying on a thing; that's a very
| good reason people invest in improving a thing, right?
|
| So I'm not really sure what you mean -- you say "sunk cost", I
| say "Well, those who are using a thing are those who invest in
| improving it, how is it ever any different? And that there are
| people with current investments in ruby who will continue to
| invest to improve it is what will make ruby continue to thrive
| -- and how is it ever any different with any technology?"
|
| What would make it "sunk cost", i suppose, is if you think ruby
| is a poor technology and everyone using it should switch to
| something else. I guess it is popular to hate on ruby right
| now, but that seems to be an orthogonal debate. Ironically, one
| of the most popular reasons to hate on ruby is "performance"
| (rightly or wrongly), so it seems especialy weird to me to show
| up with an argument like "Sure, they're drastically improving
| ruby performance, but is ruby the right choice of thing to
| improve it's performance? After all, ruby has such bad
| performance!"
|
| To be fair, you didn't specifically say "because ruby has such
| bad performance", you didn't say anything about why ruby might
| be the wrong thing to invest in at all -- which makes it all
| the more just weird FUD, intentionally or not.
|
| You are suggesting that just in general we should prefer
| switching to new languages over investing in the existing ones?
| Since you didn't supply any specific arguments, it makes it
| seem as if you suggest this as a general principle, regardless
| of details? I think many of our experiences is that this leads
| to always using immature technology; to reach the stability and
| performance of (say) the JVM or V8 requires... investing in the
| thing, not constantly chasing a new immature thing hoping it
| will be different this time.
| xoac wrote:
| Someone has to do this work, and I this is a good example of a
| company giving back to what was originally a non-industry
| project (Ruby).
| asim wrote:
| Yes, I'm just asking whether that needs to be Shopify? And
| whether their time is best spent elsewhere.
| xal wrote:
| Creating and sharing powerful tools for people to build the
| things that they want to exist is kinda in Shopify's DNA.
|
| It's also important to me to give back to open source. It's
| done so much for us.
| olau wrote:
| The loss of human time in big corporations is immense.
| Coordination overhead and losses due to information
| logistics problems. I'd imagine a project like this with no
| dependencies on the rest of the stack can be run
| efficiently. From a bang per buck point of view it might
| beat other means (rewrite, using multiple languages,
| redoing ops to run on cheaper backbone) by a huge factor.
|
| I get your sunk cost objection, but it's a bit depressing
| to hear people worry about someone doing genuinely useful
| work. Nobody wants to take responsibility or get their
| hands dirty. There's still plenty of low-hanging fruit in
| both language implementations and databases. The world
| today is just mountains upon mountains of bullshit.
| bastawhiz wrote:
| The big difference compared to HHVM is that this is part of
| Ruby. It's not a separate project. Shopify is sponsoring much
| of the effort, but it's owned by the community.
|
| At Stripe, there are millions of lines of Ruby. Lots of it
| would be better off in a different language--if it had been
| written in another language initially. Ruby is easy to hire
| for, there are tens of thousands of pages of documentation for
| the code written in it, and there's a ton of operational
| knowledge about how to use it well. Switching is possible, but
| the cost to replace it is half a decade or more. During that
| time, you're not building new features, you're worrying about
| compatibility and making sure there's no downtime. Instead of
| making incremental improvements, your infra folks are worrying
| about migration paths.
|
| At the end of the day, the major arguments against Ruby is lack
| of native type checking (solved with tooling) and performance.
| For Shopify, you can either undertake a major engineering
| effort to rewrite your stack (years of effort, incidents, no
| real feature development, morale killing) or kick a few million
| dollars at making the thing your engineers like faster. The
| cost of replacing Ruby is tens of millions of dollars: not just
| engineers putting pen to paper, but lost business from putting
| the company on hold, breakages, and throwing out immense
| amounts of operational knowledge and experience.
|
| Said another way, telling a thousand+ people to drop what
| they're doing, learn a new language, and redo all their work is
| an expensive way to end up with a worse version of what you
| already have. It's not a sunk cost fallacy if you literally
| can't afford to change.
| JohnBooty wrote:
| Love this post, although: Ruby is easy to
| hire for
|
| I've always had the opposite experience!
| config_yml wrote:
| As someone experienced in Ruby (and Rails), I've also
| always had the opposite experience. Very little options!
| JohnBooty wrote:
| There haven't been a ton of choices when I've looked for
| Ruby/Rails jobs, but I never had much trouble landing
| one. They usually seem pretty relieved to have found
| somebody.
|
| When I've been on the hiring side of the equation, it's
| been very tough to find candidates.
| bastawhiz wrote:
| In my time at Stripe, few of the candidates were fluent in
| Ruby, but it almost always took less than a couple weeks to
| get spun up with it. If you're looking for Ruby talent,
| it's more challenging.
| JohnBooty wrote:
| I've worked at places that hire folks with Ruby
| experience only (more difficult) and places that just
| hired the best available engineer and let them learn Ruby
| (easier but EXTREMELY mixed results - specifically lots
| of Java ppl insisting on writing Ruby that looks like
| Java and insisting upon using e.g. Spring conventions in
| Rails)
| dosethree wrote:
| This is super common, (and the mark of a bad programmer
| if you program the same in every language). What's funny
| is the opposite - people who get so into ruby that
| everything they write is cute and overthought - is
| actually worse.
|
| Ruby is so powerful but simplicity is the best if other
| people are going to read and maintain your code. Go is
| great for this.
| JohnBooty wrote:
| Ruby is so powerful but simplicity is the best if
| other people are going to read and maintain your code.
|
| Amen. Keep it simple for a large shared Ruby application,
| such as a Rails app.
|
| More advanced Ruby (writing your own
| operators/iterators/whatever, metaprogramming, extending
| the language itself, whatever) is best reserved for Ruby
| frameworks, not applications.
| onlyrealcuzzo wrote:
| > Switching is possible, but the cost to replace it is half a
| decade or more.
|
| I would imagine if you're going to switch millions of lines
| from one language to another - you wouldn't do it by hand -
| you'd write something transpile it?
|
| Has any company actually done something like this before -
| especially somewhat recently?
|
| I can't imagine anyone doing it by hand...
| cguess wrote:
| That doesn't really work in practice at scale. There's
| "Ruby" ways of doing things that don't just transpile over.
| It's also the entire Rails framework that would have to be
| ported then, which is beyond a monumental undertaking.
|
| That's not to even mention the massive amounts of new bugs
| that would be put into the code that have been ironed out
| over years of debugging and testing in the Ruby base.
| There's a reason so many legacy operators still run COBOL
| despite even C being a better candidate, it was just
| created twenty years too late and the costs of moving it
| over is well outside of the savings of not doing that.
|
| "If it ain't broke, don't fix it" is very much the key
| here.
| bastawhiz wrote:
| You need to produce code that not just runs, but is
| idiomatic in the target language. I'm not aware of ANY
| transpilers that do this for target and source languages
| that run in different runtimes (i.e., not coffeeacript to
| JS). You need every language _feature_ to translate
| cleanly, and that means that a translation failure makes it
| impossible to convert a logical unit (module, package, etc)
| at once. Simply having a translated version of the code
| without making it idiomatic means it 's impossible to read
| or modify.
| mprovost wrote:
| How is hiring a few people to write a transpiler any
| different than hiring a few engineers to write a JIT
| compiler? Isn't a JIT just transpiling code at a different
| level (bytecode instead of source code)?
| r-s wrote:
| Many many years ago I was hired to convert a Fortran app to
| C. The first person to try it ran it through a software
| called "f2c". It worked fine - but the code was totally non
| human readable so it couldn't be extended later, so it
| provided almost no value in this case.
| psychoslave wrote:
| I see the point to make a parallel with HipHop, but here YJIT
| is directly integrated in CRuby, the main implementation of the
| language, and it's just a matter of command line flag whether
| you enable or disable it -- at least from what I remember that
| I red.
|
| From what I remember, HipHop was distributed in a different
| toolchain than the vanilla PHP interpreter. Ruby also have
| other interpreters available by the way:
| https://github.com/codicoscepticos/ruby-implementations
| maxime_cb wrote:
| Yes. Not only is YJIT directly integrated into CRuby, it's
| also 100% compatible with your existing Ruby code, which is
| why we chose to go that route.
|
| We didn't want to independently reimplement Ruby because we
| knew that this would lead to a situation where we wouldn't be
| 100% compatible, which would stop people from using YJIT. If
| you think about PyPy for example, they have great performance
| numbers, but relatively few people are using it.
| pdntspa wrote:
| I am sooooooooooo sick of all this language churn. Ruby is a
| fantastic language, full stop.
| stevebmark wrote:
| irb > def method irb > 'yes' irb > def method
| irb > 'it is not' irb > end irb > end
| irb > method => :method irb > method => "it
| is not"
| giraffe_lady wrote:
| I think thinking of the "sunk cost" as being only or even
| primarily code is incomplete.
|
| It's internal expertise in that language, understanding of its
| strengths and weaknesses and how they fit into your business
| needs, custom tooling around dev, debugging & deployment,
| practice evaluating candidates for expertise in it, particular
| strengths of that language not guaranteed to be in a
| replacement, just all of the "unknown unknowns" that you now
| know through bitter experience.
|
| Surely there will still be a point where it's worth throwing
| all that out and starting fresh, but some of those are very
| hard to quantify or even _see_ , when you have them, so the
| conservative choice is to stay put in the system that works.
| patientplatypus wrote:
| [dead]
| tinglymintyfrsh wrote:
| I use Ruby and Chef at work (MAANG).
|
| For side projects, I use Rails 7 to get things going and replace
| components selectively with native extensions and separate
| processes.
|
| It's all about productivity, especially when small, because
| performance is rarely an issue.
| [deleted]
| kawsper wrote:
| I'm so grateful for these geniuses working tirelessly on
| improving the language and runtime, and it allows me to just add
| an argument and magically my code runs faster.
|
| It's been fascinating following Maxime working on Yjit.
| [deleted]
| revskill wrote:
| For anyone thinking Ruby is dying or slow, it's not the reason
| people like me used it and sticked with it in first place! It's
| about the experience when you write the code itself. It's
| natural, like a flow of water, and you're suddenly in Zen mode,
| where your thought just naturally flow without even you're aware
| or not.
|
| I first time learn Ruby from zero to "hero" in production
| confidently is in just under a week. And as far as i know, no
| other language could bring me such experience.
| Thaxll wrote:
| The main issue I have with Ruby / Python is the fact that it's
| duck typed, it makes the maintenance and refactor pretty
| hazardous.
|
| You get objects you don't know what's in there, 6 month later
| someone changed it, no compile error but it will break when you
| run it.
|
| And so to overcome those major issues they added really ugly
| stuff that is not core to the language, linters, annotations
| etc ...
| pantulis wrote:
| It's not like strong typing came after Ruby. In fact, duck
| typing was a _feature_ of Ruby on its days. At the end of the
| day, you choose your battles, it's not a black-or-white
| decision.
| JamesSwift wrote:
| Ruby is one of the few successors to smalltalk with "true"
| everything is an object and message passing. As such, duck
| typing is in fact a feature and if you can internalize how
| it differs from traditional OOP then it becomes very
| powerful. It is a double edged sword however, and can be
| wielded poorly.
| JW_00000 wrote:
| No, but gradual/optional typing did come after Ruby. Back
| in 2005, you could choose between static typing with type
| checking but lots of verbosity (e.g. Java "Point point =
| new Point();" or C++ "for (std::map<int, BlaBla>::iterator
| it = myMap.begin(); it != myMap.end(); it++)") or dynamic
| typing without type checking but also without the
| verbosity. Since optional typing, dynamically typed
| languages got the guarantees of type checking, and
| JavaScript/TypeScript and Python have embraced this. With
| type inferencing, statically typed languages lose their
| verbosity, and Java and C++ have embraced that (as have
| newer languages like Rust, Go, and Swift). It feels like
| Ruby hasn't progressed on this front...
| pantulis wrote:
| Isn't RBS for Ruby a way of having optional typing? (Not
| challenging here, honest question :P)
| Gigachad wrote:
| I'm not aware of anyone using it, we evaluated it at work
| and decided it wasn't worth using despite us making heavy
| use of TypeScript and Rust.
| FpUser wrote:
| >"for (std::map<int, BlaBla>::iterator it =
| myMap.begin(); it != myMap.end(); it++)")"
|
| All you really needed is: for (auto it :
| myMap)
|
| and you still get compile type safety
| Yoric wrote:
| Well, in 2005, you didn't.
| FpUser wrote:
| Well we are not discussing 2005 version of Ruby. Why
| limit C++ to that particular time?
| Yoric wrote:
| I'll pedantically remind the audience that type inference
| dates back to the 70s and has been present in the
| industry at least since the 90s.
|
| But in truth, you're right. Very few people know/cared
| about type inference at the time.
| JeremyNT wrote:
| Ruby does have optional type annotations, if you want
| them:
|
| https://github.com/ruby/rbs
| munificent wrote:
| _> Since optional typing, dynamically typed languages got
| the guarantees of type checking_
|
| Optional typing, at least in TypeScript, will not give
| you the guarantees of type checking. It finds many of
| your type errors, but not all of them because the type
| system is deliberately unsound.
| jerf wrote:
| Static typing was a nightmare (by modern standards) in the
| 1990s. Dynamic scripting languages were such a breath of
| fresh air that we were willing to pay the steep performance
| penalties without hardly a thought. Sort of like the saying
| "deleted code is debugged code", code that you actually
| write always performs better than the code you didn't write
| because it was too soul-sucking.
|
| But static typing languages, library stacks, and
| environments have come a long way in the last 30 years. Now
| I prefer even to "prototype" in static languages because
| the crossover to when they start providing me net benefit
| is around a week or so into my development process.
|
| I will not claim one is completely better than the other,
| but the balance is a lot more even than I would say it was
| ~20 years ago.
| lmm wrote:
| Actually almost all the stuff that's gone mainstream in
| the last 30 years was already around in the '90s if you
| used OCaml (or indeed Haskell). But in fairness not many
| people did.
| davidw wrote:
| What are you using that's strongly typed _and_ as quick to
| get stuff done with as Ruby?
| bastardoperator wrote:
| Nothing, it was just an opportunity to use buzzwords and
| inject negativity.
| vidarh wrote:
| Ruby.
|
| (Ruby is strongly typed in the "doesn't automatically
| coerce types" and "maintains a fixed type for an object"
| sense; using the term "strong typing" is inherently
| ambiguous because it has so many partially conflicting
| meanings)
| jetpackjoe wrote:
| I think TypeScript, especially with a full stack framework
| such as Remix or Next, satisfies these two constraints.
| reducesuffering wrote:
| Yep, Next / Typescript
| itake wrote:
| Even in dev, you have to basically code in irb in order to
| verify everything works.
| jeltz wrote:
| Nonsense. I used to be a professional Ruby developer and
| that is nowhere close to the truth. While I prefer static
| typing it is not hard at all to code in Ruby once you have
| learned the basics and I almost never used IRB other than
| when I was a beginner.
| pantulis wrote:
| It's good practice to use irb to quickly check stuff or
| inspect the programmatic surface of a new library. But
| that's a Ruby feature that you don't have in other
| languages! In no way its mandatory to code inside irb.
| Most of my time was spent in Textmate or Emacs.
| tinglymintyfrsh wrote:
| rbs / steep, and sorbet.
|
| Monkeypatching is evil.
|
| Rubocop custom cops to reign-in what's allowed in CI/CD.
| zitterbewegung wrote:
| Python now has an optional type system and if you add one of
| them such as mypy or pyre to your CI process and you can
| configure GitHub to refuse the pull request until types are
| added you can make it somewhat strongly typed.
|
| If you have a preexisting codebase I believe the way you can
| convert it is to add the types that you know on commits and
| eventually you will have enough types that adding the missing
| ones should be easy. For the missing ones Any is a good
| choice.
|
| https://pyre-check.org and https://github.com/python/mypy are
| popular.
| Slippery_John wrote:
| Python's type hints are definitely an improvement and
| they're getting better all the time, but they're still
| frustrating to use at anything approaching the edge. I long
| for something as elegant and functional as TypeScript.
|
| One hurdle I've stumbled over recently is the question
| "what is a type?", the answer can be surprising. Unions,
| for example, are types but not `Type`s. A function that
| takes an argument of type `Type` will not accept a Union.
| So if you want to write a function that effectively "casts"
| a parameter to a specified type, you can't. The best you
| can do is have an overload that accepts `Type` and does an
| actual cast, and then another that just turns it into
| `Any`. This is, in fact, how the standard library types its
| `cast` function [1]. The argument I've seen for the current
| behavior is that `Type` describes anything that can be
| passed to isinstance, but that's not a satisfying answer.
| Even then, `Union` _can_ be passed to isinstance and still
| does not work with `Type`. Talk currently is to introduce a
| new kind of type called `TypeForm` or something to address
| this, which is certainly an improvement over nothing, but
| still feels like technical debt.
|
| [1]: https://github.com/python/typeshed/blob/main/stdlib/ty
| ping.p...
| Yoric wrote:
| My experience of mypy is that, even with the most
| restrictive settings, it's still quite weak with respect to
| all reasonably strongly typed languages I've used (e.g.
| anything at least as strongly typed as Java).
|
| YMMV
| vidarh wrote:
| I used to have that attitude. Then I wrote my first Ruby
| project as an experiment. That was 17 years ago, and the
| majority of the code I've written since has been Ruby. What
| clinched it was that the first Ruby project I wrote involved
| trying to reimplement a piece of C code we had. It ended up
| 10% the size with _more_ functionality, and it took me a tiny
| fraction of the time to write.
|
| If you write code the way you write statically typed code,
| then sure, you're in for a world of hurt. I could imagine
| using a statically typed language again if it made me as
| productive as Ruby, but most statically types languages have
| near useless type systems that I wouldn't wish on my worst
| enemy.
| mostlysimilar wrote:
| I don't know if I'm just a bad programmer and everyone
| knows something I don't, but it seems to be the benefits of
| a strongly typed language are wildly overblown. It's a
| different way of thinking about building software and it
| saves you from a few mistakes you could otherwise make, but
| you'd think I was writing code with a hammer and chisel the
| way people on HN talk about languages like Ruby. It feels a
| lot like the people who used to try to convince everyone
| functional programming was the only way to go and object-
| oriented programming was for dinosaurs.
| Gene_Parmesan wrote:
| For me, it comes down to the fact that static typing
| completely eliminates large classes of bugs. It therefore
| dramatically lowers the testing load. The compile step
| essentially performs its own tests. Think about all the
| test cases I save myself from having to write...
|
| Beyond that, it also forces me to think structurally from
| the start. But I tend to be working on rather complex
| applications, I almost certainly wouldn't use a static
| lang for data processing or similar tasks.
|
| > It feels a lot like the people who used to try to
| convince everyone functional programming was the only way
| to go and object-oriented programming was for dinosaurs.
|
| What do you mean "used to"?? Haha
| [deleted]
| bcrosby95 wrote:
| Its all guts, feels, and "everybody knows" - but afaik
| there's been no hard proof about statically typed
| languages being superior to dynamically typed ones, or
| vice versa.
| treis wrote:
| It comes down to project size. Small projects with a
| small team tend to be fine. Bigger ones tend to break
| down a bit and the application becomes ossified because
| there's no safety when changing things. You can power
| through it but productivity takes a nose dive. The big
| ones that stay on Ruby tend to invent typing like things
| to solve the issue.
| Yoric wrote:
| Strongly and statically typed languages are not very
| common. Most languages that pretend to be strongly +
| statically typed aren't, by a fairly large margin (I'm
| looking at you, C++, Objective C or Dart).
|
| However, once you have strongly + statically typed
| languages, you can very often create safe-by-design (tm)
| APIs, APIs that are simply impossible to misuse (for some
| definition of misusing). A trivial example (which among
| industrial languages works only in Rust and perhaps Ada)
| is a file system API in which the compiler detects that,
| in some codepaths, you're attempting to try to write to a
| file after closing it.
|
| Exactly how much value this has for your programming
| depends on how many invariants you need to guarantee. If
| you're writing (for instance) a CRUD for non-critical
| data, that's usually not many. If you're writing a
| network protocol or a garbage collector, this can save
| you from worlds of pain. I have had to fix data loss and
| privacy issues in Firefox that would have been detected
| _years_ earlier if we had used a strongly-typed language
| such as TypeScript (which didn 't exist at the time)
| instead of JavaScript for the front-end.
|
| In fact, I wear a large number of scars from fixing
| Firefox bugs in JavaScript (or C++) code. These days, I
| prefer strong, static typing. I sleep more soundly :)
|
| But, as usual, we're not in a one-size-fits-all industry.
| There are developments for which static typing gets in
| the way of zero-to-deployment.
|
| As usual, tradeoffs everywhere!
|
| Note: Strongly + statically typed languages also
| typically offer strong support for other forms of static
| analysis (e.g. model checking, abstract interpretation,
| etc.) that are considered critical in some industries
| (e.g. aeronautics - or writing Windows device drivers).
| But we're getting into something of a niche.
| munificent wrote:
| _> Most languages that pretend to be strongly +
| statically typed aren 't, by a fairly large margin (I'm
| looking at you, C++, Objective C or Dart)._
|
| What about Dart doesn't feel sufficiently typed for you?
| lmm wrote:
| C is barely statically typed. In an ML-family languge you
| can write pretty much the same code you'd write in Ruby,
| just it'll be typesafe.
| pak9rabid wrote:
| Have you looked into Crystal? It's supposed to be a
| statically-typed language, with the syntax of Ruby.
|
| https://en.wikipedia.org/wiki/Crystal_(programming_language
| )
| vlunkr wrote:
| I still think it's a great choice for smaller projects. I
| can't imagine it at the scale of shopify.
| blacksmith_tb wrote:
| Apparently they couldn't imagine it either[1].
|
| 1: https://sorbet.org/
| badrequest wrote:
| This is built by Stripe, not Shopify.
| eric-hu wrote:
| It is, but Shopify uses it as well and maintains the
| companion tool, tapioca.
|
| https://github.com/Shopify/tapioca
|
| Tapioca is used to generate type signatures on gems and
| code that creates functions at runtime. Sorbet ships with
| some of that behavior, but they updated their docs to
| recommend tapioca over sorbet where the behavior
| overlaps.
| blacksmith_tb wrote:
| Oops, my bad, I should have doublechecked that!
| Gigachad wrote:
| I've been doing Rails development for 10 years now and I just
| don't think it's possible to safely update anything in Ruby.
| Our app has 20,000 rspec unit tests and 5,000 cypress browser
| automation tests and basically every ruby patch version
| creates breakages that somehow slip through all of that
| despite nothing being mentioned in the changelogs.
| xiphias2 wrote:
| What about recording and replaying traffic to the servers?
| It's not a magical solution, but it should catch
| regressions.
| Gigachad wrote:
| Replicating the production env to do that sounds beyond
| our capabilities tbh. We are slowly replacing Ruby with
| typed languages like TS and Rust which is working wonders
| for reliability.
| xiphias2 wrote:
| Great, it's just a usual extra tool, although RoR is
| amazing, I fell in love with SvelteKit
| phaedryx wrote:
| The solution is to be religious about testing and writing
| tests. If you've done it well, refactors are pretty safe and
| your objects are pretty well understood.
| pantulis wrote:
| Also, you need to be religious about testing and writing
| tests _anyway_.
| lmm wrote:
| You really don't. You need to test the business logic,
| but for the "plumbing" (which is often 90%+ of the code)
| often if you have a decent type system and use it
| effectively there's only one way to write it that would
| compile.
| ajmurmann wrote:
| As someone who spent a good chunk of their career
| teaching TDD, I agree and disagree. Yes, tests are
| crucial. However, which tests to write varies among other
| things by language. When I write Ruby, I benefit from
| testing even the simplest things. When I write Rust or
| even Type Script or Swift I'll focus much more on tests
| for complex logic and on integration and acceptance
| tests. Static typing eliminates an entire, larger
| category of issue I need to address with tests.
| vidarh wrote:
| When I write Ruby, I test expected behaviours, and if
| there are type errors in there those tends to fall out
| from tests I needed anyway. If you need to test
| specifically for errors due types, then generally that
| suggests that either your application does not normally
| exercise those code paths at all and/or you fail to test
| behaviours of your application.
| Yoric wrote:
| Does this include writing libraries for use by third-
| parties?
| pantulis wrote:
| Sure! But you need to be a testing practitioner anyway. I
| agree that perhaps the number of tests is different, but
| the teams processes and cultures should already be there.
|
| But to counter myself, the perceived lack of developer
| speed and flexiblity of a strongly typed language (with
| Rust, I always get the feeling that I'm fighting with the
| compiler!) is also solved in the long run with practice
| and tooling.
| Salgat wrote:
| The point is that compilation automates all this. It's just
| one more failure point you have to devote man hours to.
| ptnxlo wrote:
| Compilation won't tell you whether your code follows the
| business logic it's intended to do. You do need to rely
| on tests even if the implementation of the programming
| language compiles it or not.
| Salgat wrote:
| I'm not talking about business logic tests, and never
| implied that compilation removes the need for them.
| Yoric wrote:
| Actually, very often, with a strongly, statically-typed
| language, in a well-designed API, it actually can.
|
| Unfortunately, most people got a taste of static typing
| with Java and the initial language and library design
| were done in such a way that types were well, if not
| entirely useless, then certainly under-used. But if you
| look at many libraries for languages such as Rust, Scala,
| OCaml, Haskell, F#, ... (I haven't looked at Java in a
| while, but I don't hold high hopes on this specific
| front) you'll find many examples in which the API and the
| type system cooperate to guarantee that high-level
| protocols are enforced.
|
| That being said, I absolutely agree that strong static
| typing does not mean that you don't need tests. As
| everything, if you want to be safe, you need a defense in
| depth, with good API design and many test layers.
| [deleted]
| reducesuffering wrote:
| People often say this but it's nowhere close to universal. Ruby
| is 24/42 of most loved langs.
|
| https://survey.stackoverflow.co/2022/#technology-most-loved-...
| Gigachad wrote:
| This survey shows that slightly over 50% of ruby users dread
| using it.
| abvdasker wrote:
| Ruby was probably my "first love" as a programming language for
| the reasons you described, but nowadays I prefer statically
| typed compiled languages. Ruby is still my preferred scripting
| language, though I've seen the way large projects can start to
| suffer from high maintenance overhead when it comes to dynamic
| languages like Ruby.
| theLiminator wrote:
| Definitely, it gets extremely frustrating when you have
| runtime bugs that would've been trivially caught by a
| compiler.
| wilg wrote:
| Same. I wish I was always writing Swift.
| setheron wrote:
| Ruby definitely optimizes for the writer but it fails for the
| reader (a saying I say quite frequently at work).
| richardlblair wrote:
| It _can_. Much like any other language, if you're not careful
| you can write some very convoluted Ruby code. What makes Ruby
| different is when you invest in readability you get far
| greater returns for much less effort.
| [deleted]
| itake wrote:
| I've been coding for 10+ years and I would argue that ruby is
| not kind to the writer.
|
| Ruby requires you to be aware of much more "state" than any
| other language that I have coded in, because all assumptions
| about methods cannot be confirmed until the code is run. For
| example, a gem might modify the default_scope of a portion of
| active record models. You have to memorize all these tweaks
| and even then you don't know if the code you've written will
| do what you want until it is actually been run.
| jeltz wrote:
| That is a Rails issue, not a Ruby issue. Outside some Rails
| libraries this is not a thing. Virtually all non-Rails
| libraries try hard to avoid modifying global state.
| weatherlite wrote:
| Glad to see Ruby still going strong it will forever be the 1st
| programming language I actually loved working with, and the
| combination of it with Rails was amazing. Had to move to the
| other side (Typescript, Django) but I think unless ChatGPT will
| write all the code 10 years from now - Rails and Ruby will still
| be there, providing teams with a lot of power and a lot of fun.
| [deleted]
| panzi wrote:
| What does 10% speedup mean? Doing 10% more work in the same time
| or needing 10% less time for the same amount of work?
| the_sleaze9 wrote:
| I have to admit my brain seems to be short circuiting on this
| one. Aren't these 2 ways of saying the same thing?
| JohnBooty wrote:
| At it's heart they seem to be asking kind of a latency vs.
| throughput question. The answer is frustratingly "it depends"
| but for some real world Rails benchmarks, Shopify has
| published quite a few benchmarks including the ones in the
| linked article.
| uluyol wrote:
| At 10% it's approximately the same. But say 50% instead.
|
| If it takes 1/2 the time to do something, you can do double
| the work in that time.
|
| If on the other hand, you can do 1.5x the work in the same
| time, it means you've made it use 33% less time than before.
|
| With 10% less time you're taking 1/0.9 = 1.11111x more work
| in the same time.
| rrgok wrote:
| The percentage is applied to two different things. One for
| work and the other for the time.
|
| It took sometime to me too.
| masklinn wrote:
| Not exactly, "doing 10% more work in the same time" means
| needing 9(.1)% less time to do the same work (100 / 110
| versus 90 / 100).
|
| Needing 10% less time for the same amount of work means you
| can do 11(.1)% more work in the same time.
| ufuk wrote:
| 10% less time for the same amount of work, since we are
| measuring the total response time of the workload in question
| and looking at median (p50), p90 and p99 numbers.
| sergiotapia wrote:
| Man that is a terrible graph. Why use tiny fonts and smush them
| together, them make the image small as well. I wish I could read
| the charts...
| ufuk wrote:
| You can see this chart and all the numbers and more at
| https://speed.yjit.org/, which this chart was taken from.
| sergiotapia wrote:
| Thank you!
| [deleted]
| cdiamand wrote:
| You love to see the continued investment in this language. I've
| been using Ruby for about a decade and I'm still enjoying writing
| code in it. I hope the language continues to improve and the
| community stays vibrant.
|
| I can remember about 8 years ago someone telling me how they were
| worried Ruby (and Rails) was dying. At this point the community
| could dry up and I think I'd still stick with it.
| [deleted]
| [deleted]
| frou_dh wrote:
| Does this work put Ruby into a faster category than Python until
| if/when Python gets a JIT in its official implementation?
| maxime_cb wrote:
| If you believe the language benchmark game, Ruby is faster than
| Python on many of the microbenchmarks: https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
|
| And the benchmark game is using Ruby 3.1, whereas 3.2 is
| significantly faster. YMMV though, it is going to depend on
| your use case, but we are always working on making Ruby faster,
| and if you run into a use case where Python is a lot faster,
| you can ping me on twitter @Love2Code and tell me about it.
| We'll take a look.
| gvalkov wrote:
| Python 3.11 also claims [1] to be 10-60% faster than 3.10,
| which is the version that the benchmarks game is using at
| this time. The difference in used RSS is also quite
| interesting in this comparison. [1]: https://
| docs.python.org/3/whatsnew/3.11.html#whatsnew311-faster-
| cpython
| byroot wrote:
| > The difference in used RSS is also quite interesting in
| this comparison.
|
| YJIT 3.1 was eagerly allocating it's executable memory
| region regardless of whether it was needed or not. With the
| default settings that meant an extra 256M of RSS right at
| boot.
|
| As mentioned in TFA that's no longer the case in 3.2, so
| expect this RSS number to go down by at least a good 200MB
| once they upgrade to 3.2.
| jeltz wrote:
| Ruby was already slightly faster than Python in many micro
| benchmarks before 3.2 and YJIT, so maybe? It depends on your
| workload.
| pantulis wrote:
| I'm wondering about what impact would this have in Basecamp's
| hosting bills...
| byroot wrote:
| If you look at the breakdown per service, EC2 (assuming mostly
| Ruby) seem to be at best 20% of the bill:
| https://twitter.com/dhh/status/1613508201953038337
|
| So if you are to make Ruby ~10% faster, you might reduce
| Basecamp hosting bill by 2% at best.
| pantulis wrote:
| Thanks for spotting that, I had missed it! This goes to show
| (again) that the "Ruby/Rails does not scale" myth is
| fictional.
| earthnail wrote:
| There are organisational scaling issues that you may hit
| with a language like Ruby that strongly typed languages
| like Java can solve.
|
| And so Ruby may scale in cpu performance, but not with your
| number of teams.
|
| That's why Spotify switched to Java (I think they were a
| heavy Python user before that, not Ruby, but not sure
| anymore - but the organisational problem is the same for
| those two).
|
| Note that I still choose Rails for all my projects, but my
| company is small.
| DoctorOW wrote:
| > Remember, this excludes the current Basecamp and Basecamp
| 2, which use our own hardware for this
|
| https://dev.37signals.com/our-cloud-spend-in-2022/
| stevebmark wrote:
| Is there a name for this syndrome? The same thing happened at
| Github. Ruby and Rails are slow enough in production that they
| dedicate a specialized, long-running internal team to it. This
| team doesn't contribute directly to the product. They hire core
| Ruby and Rails maintainers, also not to contribute to the
| product, just to try to help improve their slow software. It's a
| dream job that shouldn't exist.
|
| If you tell me that Ruby and Rails scaled for Github and Shopify,
| be careful using that as an argument for choosing Rails for your
| company. Rails definitely didn't scale for Github, and doesn't
| appear like it scaled for Shopify, until a manager greenlit a
| year long JIT project unrelated to Shopify. If your company has
| as many resources, free cash, klout to hire core Ruby
| maintainers, and enough downtime you can throw a few engineers at
| a non-product problem for a few years, then sure, go ahead and
| use that reasoning.
| bcrosby95 wrote:
| Languages don't scale (out), architecture does.
|
| Well, maybe Elixir and Erlang scales out, since architecture is
| baked in.
|
| Depending on how performant a language is, it can put off
| (sometimes forever) your need to scale out, which can simplify
| things. But both Github and Shopify are beyond the level of
| traffic that would allow you to get away with only scaling up
| rather than out.
| xutopia wrote:
| Shopify like many other successful Ruby shops were successful
| because of the speed of development. The cost of hosting is
| secondary and any company the size of Shopify can afford to
| involve a small team to reduce hosting costs... with impact for
| the developers happiness to boot.
| ezekg wrote:
| I wonder if YJIT actually did decrease infrastructure costs
| for Shopify, seeing as it requires ~3x more memory. For my
| business, it's come out about even. But a >30% decrease in
| response time is worth it, for me at least.
|
| I run many small servers (2 processes each), but IIRC,
| Shopify runs beefy servers. So may be different for them.
| nirvdrum wrote:
| Don't most large products have teams working on performance?
| With a VM-based language like Ruby, speeding up the VM is a
| sound strategy because it works across all of your
| applications. There are teams embedded in corporations working
| on the JVM, the Python VM, the PHP VM, and so on (sometimes
| brand new VM implementations). There are teams working on
| improving performance of the standard library and compiler in
| C, C++, Rust, and Go. There are teams working improving
| performance of applications in all of those languages.
|
| Sure, if you're a startup and you can't afford it, you probably
| shouldn't be spending time speeding up your language. But,
| you're also unlikely to experience performance issues under
| your lighter load that can't be attributed to your application.
| djur wrote:
| Can you give some examples of companies that "scaled" without
| dedicating at least some engineering work to improving their
| runtime?
| lakomen wrote:
| > Multiple large clusters of servers distributed across the
| world, capable of serving over 75 million requests per minute
|
| That doesn't say anything at all sadly.
|
| Ruby people seem to be sensitive when someone asks them about
| performance, my last question about that was downvoted heavily
| here.
|
| I don't know any Ruby, I know how much Go can handle with the
| stdlib, a single non-parameterized route, returning "hello
| world". On my machine xeon e3-1275v5 with 8 threads 1000
| concurrent wrk about 220k/ rps. Errors start appearing (aka
| non-200 results) between 5000 and 6000 concurrent. Don't forget
| to ulimit -n 10000 or more before you start wrking.
|
| Alternatively can you provide a simple single route hello world
| in Ruby so I can bench it myself with this Ruby 3.2 YJIT? Maybe
| also how to build and run?
|
| Yes, I'm being serious. I'm also guessing that Ruby with Rails
| has a large overhead compared to Go and just the stdlib. So that
| comparison wouldn't be fair, but I guess it is what it is, since
| we're talking semi real world scenarios (yeah don't get your ocd
| panties in a bunch) and Rails AFAIK is the standard for Ruby web
| development while the stdlib in Go is also used quite often.
| jrochkind1 wrote:
| > since we're talking semi real world scenarios
|
| A single non-parameterized route returning "hello world" is a
| real-world scenario? You have an interesting business domain!
| claudiug wrote:
| he has a saas that return hello world.
| [deleted]
| djur wrote:
| Complaining about downvoting, demanding that other people do
| work for you, and preemptively using demeaning language about
| people who might disagree with you are all ways to reliably get
| downvoted.
| acchow wrote:
| I thought Shopify wanted to migrate to TruffleRuby which would
| likely give them at least a 2x speedup?
| the-alchemist wrote:
| I don't quite understand the YJIT excitement. A few benchmarks
| show that TruffleRuby generally beats YJIT, sometimes by a 10x
| margin.
|
| [0]: https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-
| yj... says
| merb wrote:
| i'm pretty sure eregon is biased...
| nateberkopec wrote:
| TruffleRuby can't run production Rails traffic today, and
| YJIT can.
| kenhwang wrote:
| And by many accounts Oracle makes the fastest database yet
| everyone still uses Postgres.
|
| Also our experience with truffleruby is death by a thousand
| subtle differences. It might be 97% compatible but chasing
| down that 3% undocumented behavior difference on every minor
| version update for every gem got exhausting fast. Everyone
| uses and tests against cruby.
| v3ss0n wrote:
| What? When was oracle free or opensource?
| merb wrote:
| and when was oracle the fastest database? You are not
| allowed to even publish that metric....
| Spivak wrote:
| I do have some sympathy for companies who don't want to
| have to deal with a constant barrage of benchmarks that
| are egregiously wrong.
|
| HN has been host to quite a few of these spats over the
| years and I wouldn't want to deal with it, there are
| pretty much only downsides to letting people poorly
| benchmark your product and have every incentive to get it
| wrong.
| merb wrote:
| well to be fair, most benchmarks are of course not
| comparable with the real world. People should always use
| what works best for them.
| lmm wrote:
| > by many accounts Oracle makes the fastest database
|
| I've never seen that credibly claimed. Why would their
| license ban benchmarking if their performance was any good?
| JohnBooty wrote:
| Tragically, one of the principals behind TruffleRuby (and
| researcher at Shopify) was Chris Eaton and he passed away a few
| months ago.
|
| I'm not sure where this leaves TruffleRuby itself, or plans to
| implement it at Shopify.
|
| (Rest in peace, Chris, and may your memory be a blessing to
| those who knew you)
| jacques_chester wrote:
| There are still folks working on TruffleRuby at Shopify.
| the-alchemist wrote:
| so sad, I had no idea. We lost a brilliant mind...
| eddsh1994 wrote:
| Looks like it's still a WIP
|
| https://github.com/oracle/truffleruby/commits?author=eregon
| xfalcox wrote:
| You can enable YJIT and get a ~30% speedup by passing an extra
| environment variable to your Docker container. Moving away from
| CRuby to an alternative Ruby is a lot harder than that.
|
| Also Oracle.
| jacques_chester wrote:
| Shopify invests in both.
|
| Source: I work in a team that's nearby as the org chart flies.
___________________________________________________________________
(page generated 2023-01-17 23:00 UTC)