Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.2’s YJIT is Production-Ready

shopify.engineering

Post reply on HN
Print view View original

281–290 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#281

Post by lmm »

vidarh wrote: post #265
lmm wrote: post #187

Earlier quoted context omitted.

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.

If there's an ML-family language that reads similar to Ruby I'd love to use it. I'm not being facetious - I still love the notion of as much static testing as I can, but I'm not willing to give up the pleasantness of Ruby for it, so if there's something that can get me there I'd love to see, even if it's not "good enough" to replace Ruby for everything. But keep in mind this includes run-time dynamic meta-programming…

I was a huge dynamic language fan (although admittedly more Python than Ruby) until I found Scala. It has a reputation for incomprehensible arcane symbolic code, which certain libraries do, but you can write ruby-like code if you avoid doing that.

I've done "generate a whole CRUD backend from a single source of truth for what my domain looks like", although I've done it by defining the model classes, generating the database schema from them, and deriving everything else from them. All the building blocks are there but I haven't found a framework/library that puts it all together (that's one of those projects I keep meaning to get around to). I've heard there are some database access libraries that let you use a macro to derive model classes from the schema, but I haven't used them yet.

Re: Ruby 3.2’s YJIT is Production-Ready

#282

Post by hbrn »

mpd wrote: post #204
hbrn wrote: post #202

Earlier quoted context omitted.

Unfortunately static typing has turned into a religion. IIRC someone looked at Github issues a while ago to understand the impact of dynamic typing on defect rate. What he found was that around ~1% of bugs in JS/Python/Ruby enterprise systems were type-related.

Did that include bugs due to encountering unexpected nulls?

My understanding is that he was looking for instances of TypeError, AttributeError, undefined is not a function and so on. So yeah, nulls should've been included.

Re: Ruby 3.2’s YJIT is Production-Ready

#283

Post by v3ss0n »

maxime_cb wrote: post #26
psychoslave wrote: post #7

Earlier quoted context omitted.

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: htt…

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 f…

Yeah , it was because Guido himself was not promoting that project . PyPy team really tried hard to be compatible , now almost all c-extensions including DS libraries worked. I am using PyPy in production for 8 years and - it reduce memory load by a lot , ( 80 MB vs over 300 MB for tornado web service running) - it is so much faster than python that is comparable to node in high load peformance. - it would be compatibile with every lib if Main Stream Python community had even tried it and work on it.

Re: Ruby 3.2’s YJIT is Production-Ready

#284

Post by v3ss0n »

Alir3z4 wrote: post #162
v3ss0n wrote: post #158

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

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.

They didn't update their website often , that is the main problem of people not knowing much about PyPy . But they had made CPyext compatible and works fine with several Data-science Libs over past 2-3 years . Even anaconda have a miniconda for pypy called pypyforge where many of CPyext are building fine with it and they have same performance comapre to CPython. ( Can't make C-Extension faster since they are already C anyways.)

Re: Ruby 3.2’s YJIT is Production-Ready

#285

Post by stevebmark »

pdntspa wrote: post #230
stevebmark wrote: post #71

Earlier quoted context omitted.

irb > def method irb > 'yes' irb > def method irb > 'it is not' irb > end irb > end irb > method => :method irb > method => "it is not"

yeah don't nest your methods. When have I ever needed that anyway?

That’s true, method_missing is both much more common and much worse

Re: Ruby 3.2’s YJIT is Production-Ready

#286

Post by IMTDb »

lmm wrote: post #232
IMTDb wrote: post #222

Earlier quoted context omitted.

Their licensing does not ban benchmarking; it only bans publishing the results. A subtle but important point. By all means, run benchmarks on your workload profile and choose the technology that works best for you - that is perfectly OK. But not make claim that xxx beats oracle in yyy. Oracle goal here is to make a good enterprise ready DB solution; not to fight the open-source community on hundreds of different perf…

> Oracle goal here is to make a good enterprise ready DB solution Maybe. Or maybe it's to soak naive clients for all they're worth. The remedy for bad benchmarks is good benchmarks, not no benchmarks. > Just look at the « independent and fair review » that Top Gear made about Tesla. What about it? It was accurate and informative (unless you think Tesla lied about their range stats). The good points about electric car…

It was later shown that the whole part were the Tesla goes out of power was staged.

The car did inform them it would run out of battery on the way. They made a segment about it and failed to inform the viewer that they had ignored several warnings given by the car before reaching the « oh no we are out of battery in the middle of nowhere » point.

This is not what I would qualify as a « fair review ». There are no « false claims » (they did run out of battery, after all !) but the information are given and presented in a way that paints the reviewed product in a specific light.

Re: Ruby 3.2’s YJIT is Production-Ready

#287

Post by vidarh »

Yoric wrote: post #280
vidarh wrote: post #278

Earlier quoted context omitted.

The "Ruby way" in this respect tends to be to avoid being over-prescriptive. That doesn't mean "do no checks", but "do only the checks actually needed" with a very different expectation of "what is needed" than in many other languages. Hence don't check for an IO object when what you care about is the presence of a "#read" method. Or don't check if something is an Array if what matters is that it supports "#map". Ins…

This makes sense, although there are downsides to not naming types, as these serve as documentation. Python documentation has a strong tendency to using descriptions to avoid giving names to types, which imho makes the documentation needlessly confusing. Note that I'm writing "types" and not "classes". Interfaces do just as well, if not better! For what it's worth, in the static realm, OCaml introduce features that l…

The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise.

When there is a meaningful name to give, in Ruby you might define a module, and include it and use that as an interface:

   module HelloWorld
      def hello
        raise "Not implemented"
      end
   end

   class Foo
     include HelloWorld
   end

   Foo.new.hello # Raises an exception

   Foo.new.kind_of?(HelloWorld) # Returns true
(And anytime you want something that behaves somewhat like an ordered collection, you typically just want object.kind_of?(Enumerable)).

There are plenty of contract-checking frameworks for Ruby [1] but they see little use, because most of our contracts tend to be extremely simple. Along the line of "implements method X" or "includes module Y".

Sorbet w/inference tools and optionally storing the types in a separate files (it supports inline too) might slowly change that (and effectively let you use modules as "proper" interfaces), since the biggest opposition to types in Ruby tends to be visual noise and forcing refactoring, and if it can be turned on/off in your IDE and regenerated, a lot of the objections fall away. It's not that we (well many of us) don't want the extra type checks, but that we don't want to pay the cost of making the code less readable.

[1] Here's one: http://egonschiele.github.io/contracts.ruby/ and of course there's Sorbet: https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet

Re: Ruby 3.2’s YJIT is Production-Ready

#288

Post by vidarh »

lmm wrote: post #281
vidarh wrote: post #265

Earlier quoted context omitted.

If there's an ML-family language that reads similar to Ruby I'd love to use it. I'm not being facetious - I still love the notion of as much static testing as I can, but I'm not willing to give up the pleasantness of Ruby for it, so if there's something that can get me there I'd love to see, even if it's not "good enough" to replace Ruby for everything. But keep in mind this includes run-time dynamic meta-programming…

I was a huge dynamic language fan (although admittedly more Python than Ruby) until I found Scala. It has a reputation for incomprehensible arcane symbolic code, which certain libraries do, but you can write ruby-like code if you avoid doing that. I've done "generate a whole CRUD backend from a single source of truth for what my domain looks like", although I've done it by defining the model classes, generating the d…

Scala to me is unreadable. It reads like an unholy mix of Python and Java, with a lot of the ceremony of Java still hanging in there coupled with introducing partial significant whitespace. It's not bad - it's better than most alternatives - but it's not good enough to meet my standards.

If you see static typing as essential, then I can see the appeal. But my starting point is that it's not essential to me (and we're increasingly getting part of the value via optional and gradual typing via things like Sorbet which also let us keep the clutter out of sight, reducing the gap even further), and so losing even some of what brought me to Ruby is too much of a sacrifice.

Re: Ruby 3.2’s YJIT is Production-Ready

#289

Post by pantulis »

gtirloni wrote: post #229
earthnail wrote: post #153

Earlier quoted context omitted.

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 Rail…

> There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. Such as?

This also interested me.

I'd guess that the idea parent is trying to convey is that for a given size of a Ruby codebase the engineering organization needs to be structured like successful cases like Github, Shopify or whatever, but I'd be interested in the technical aspect to this. I agree with this idea when reasoning about microservices, but this is the first time I've seen it applied to the choice of language. It's intriguing.

Re: Ruby 3.2’s YJIT is Production-Ready

#290

Post by Yoric »

vidarh wrote: post #287
Yoric wrote: post #280

Earlier quoted context omitted.

This makes sense, although there are downsides to not naming types, as these serve as documentation. Python documentation has a strong tendency to using descriptions to avoid giving names to types, which imho makes the documentation needlessly confusing. Note that I'm writing "types" and not "classes". Interfaces do just as well, if not better! For what it's worth, in the static realm, OCaml introduce features that l…

The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise. When there is a meaningful name to give, in Ruby you might define a module, and include it and use that as an interface: module HelloWorld def hello raise "Not implemented" end end class Foo include HelloWorld end Foo.new.hello # Raises an exception Foo.new.kind_of?(HelloWorld) # Returns true (And…

> The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise.

Do you have examples? That's not my experience.

Of course, we may simply be working on very different types of code :)

Post reply on HN