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

Ruby 3.4.0

ruby-lang.org

Post reply on HN
Print view View original

131–140 of 282 posts

Re: Ruby 3.4.0

#131

Post by phoronixrly »

ksec wrote: post #125
phoronixrly wrote: post #112

Earlier quoted context omitted.

> You will need to sign the Oracle Contributor Agreement (using an online form) for us to able to review and merge your work. Read my lips: N. O. Read the CLA. This is a trap, do not get yourself or your company caught in it. It is open-source for now, until it gets enough traction. Then the rug will be pulled, the code will be relicensed as well as any further development or contributions. This is insane , I cannot…

I mean Java and MySQL are from Oracle as well.

MySQL was forked and the fork is the defacto standard shipped by linux distros. To me the only MySQL that existed was the one by Sun, now MariaDB has completely succeeded it.

Do you see the licensing/distrubution clusterfuck with Java as a good example of open-source stewardship by Oracle? Which Java disto are you using?[1]

Do you see the Google v. Oracle Java API copyright case as a good example of open-source stewardship by Oracle?

You know what else is prudently (/s) stewarded by Oracle? ZFS. That is why it is still not a part of the Linux kernel. A company that is basically a meme with the amount of lawyers it imploys would easily find a safe way to allow integration into the Linux kernel if only they wanted to contribute.

The examples above show exactly why Oracle has a decidedly bad reputation. On top of that, their CLA enshrines their shit treatment of the open-source movement and their free slave labour^W^W^W open-source contributors.

[1] https://en.wikipedia.org/wiki/OpenJDK#OpenJDK_builds

Re: Ruby 3.4.0

#134

Post by Malp »

htunnicliff wrote: post #123
tuananh wrote: post #10

Shopify strategy aka the story of YJIT If I cannot refactor my services, I shall refactor Ruby instead.

For a stranger to the Ruby ecosystem, what are the benefits of YJIT?

Just-in-time compilation of Ruby allowing you to elide a lot of the overhead of dynamic language features + executing optimized machine code instead of running in the VM / bytecode interpreter.

For example, doing some loop unrolling for a piece of code with a known & small-enough fixed-size iteration. As another example, doing away with some dynamic dispatch / method lookup for a call site, or inlining methods - especially handy given Ruby's first class support for dynamic code generation, execution, redefinition (monkey patching).

From https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...,

> In particular, YJIT is now able to better handle calls with splats as well as optional parameters, it’s able to compile exception handlers, and it can handle megamorphic call sites and instance variable accesses without falling back to the interpreter.

> We’ve also implemented specialized inlined primitives for certain core method calls such as Integer#!=, String#!=, Kernel#block_given?, Kernel#is_a?, Kernel#instance_of?, Module#===, and more. It also inlines trivial Ruby methods that only return a constant value such as #blank? and specialized #present? from Rails. These can now be used without needing to perform expensive method calls in most cases.

Re: Ruby 3.4.0

#135

Post by koshersalt »

bendangelo wrote: post #116
cssanchez wrote: post #115

I want to try Ruby since the news of Rails 8 came out, but it's been so difficult that I just gave up. Installing Ruby on Mac and Windows and actually getting the 3.3 version required for Rails 8 was a huge mission and test of patience because every installer defaulted to older versions of both Ruby and Rails even one month after the release. And yes, even Docker required tweaking to get the versions and I had issues…

Use rvm to install ruby. Ruby dev sucks on Windows, mac only.

I think this is a major reason Ruby had trouble taking off compared to Python. Most desktops were Windows, especially for businesses.

Re: Ruby 3.4.0

#136

Post by sosodev »

ksec wrote: post #43
pjmlp wrote: post #35

I am liking all the performance improvement goodies on JIT and GC level.

1. Wondering 3.4 JIT performance vs 3.3 JIT on production rails. 2. Also wondering what upside could Ruby / Rails gain on a hypothetical Java Generational ZGC like GC? Or if current GC is even a bottleneck anywhere in most Rails applications.

https://speed.yjit.org/

Railsbench is 5.8% faster with 3.4 over 3.3

Re: Ruby 3.4.0

#137

Post by uticus »

saghm wrote: post #124
0xferruccio wrote: post #59

Always looking forward to the Christmas tradition of Ruby releases

Years back I took over the ownership of the third-party Arch Linux package for ruby-build because the maintainer at the time wasn't using it anymore and was looking to pass it off. At the time, I had no idea that Ruby did released every Christmas, but I found out a few months later when I got an email mentioning the package was out of date that day. Even though I haven't done much Ruby dev for years now, it's been a…

Thank you for the quiet work, appreciated

Re: Ruby 3.4.0

#138

Post by wenc »

lolinder wrote: post #120
viraptor wrote: post #67

Earlier quoted context omitted.

It seems like you're ignoring the context/environment. Ruby has enough advanced developers, large enough test suite and enough people who care about performance, that it can tackle the parser as a longer project regardless of its complexity. The same thing will apply to other popular languages. But it won't apply to smaller projects with very localised parser use. In those cases writing anything custom would be a was…

Having tried both on solo projects, I disagree: like other commenters here, I've found parser generators to be a big waste of time. Writing a parser by hand requires understanding the theory of parsing and understanding your implementation language. Writing a parser with a parser generator requires understanding the theory of parsing, your implementation language, and a gigantic black box that tries unsuccessfully to…

Parser generators handle a lot of edge cases for you and are battle tested.

Unless I had a relatively simple grammar or had very strict performance requirements (like in the case of Ruby), I would not trust a hand rolled parser on a CFG by someone who isn’t dedicated to the craft. (PEGs are simpler so maybe).

I’ve written recursive descent parsers by hand and they look very simple until you have to deal with ambiguous cases.

Re: Ruby 3.4.0

#139

Post by lolinder »

plranw wrote: post #126
lolinder wrote: post #120

Earlier quoted context omitted.

Having tried both on solo projects, I disagree: like other commenters here, I've found parser generators to be a big waste of time. Writing a parser by hand requires understanding the theory of parsing and understanding your implementation language. Writing a parser with a parser generator requires understanding the theory of parsing, your implementation language, and a gigantic black box that tries unsuccessfully to…

The big plus of parser generators is that they report ambiguities. Handling conflicts is a pain but explicit. Do people who write predictive recursive descent parsers (LL(k)) really calculate first/follow sets by hand? What if the grammar requires backtracking?

There's nothing to stop you from writing out a grammar in some form that is intelligible to a verification tool and then implementing the grammar by hand. I almost always write out the grammar anyway because that's the design—without it I'm flying blind. The cost of the generator isn't writing out the grammar, it's in using the runtime code it generates, which is optional even if you want to use it for verification.

Re: Ruby 3.4.0

#140

Post by psychoslave »

oezi wrote: post #36
shortrounddev2 wrote: post #7

What does ruby do well that other languages don't? What is the niche it's trying to fill?

Ruby has the nicest object-oriented design (everything is an object) outside of smalltalk (IMHO). In contrast to the mess that is Python. For instance, in Ruby it is natural that each or map are methods of Array or Hash rather than global functions which receive an Array or Hash argument. This goes as far as having the not operator '!' as a method on booleans: false.! == true Once you have understood it, it is a very…

Yes, but it is not fully OO. Something like `if.class` generates an error, as opposed to returning some type such as "Syncategoreme".

That might looks really anecdotal, but on practice for example that's is probably the biggest obstacle to providing fully localized version of Ruby for example.

The second biggest challenge to do so would probably be the convention of using majuscule to mark a constant, which thus requires a bicameral writing system. That is rather ironic given that none of the three writing system of Japanese is bicameral (looks fair to exclude romaniji here). Though this can be somehow circumvented with tricks like

``` # Define a global method dynamically Object.send(:define_method, :lowercase_constant) do "This is a constant-like value" end

# Usage puts lowercase_constant ```

Post reply on HN