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

181–190 of 282 posts

Re: Ruby 3.4.0

#181

Post by Gigachad »

prh8 wrote: post #179
Gigachad wrote: post #171

Earlier quoted context omitted.

I started at a company 3 years ago that was on Rails 5.1. After 3 years on and off work I've managed to get it to Rails 6.1. The process is such an incredible nightmare on a large app. Currently stuck on trying to get Ruby 3 working.

Same thing for me—4 years ago, Rails 4.2. Now on 6.0, work for 6.1 is wrapped up. I did just finish going from Ruby 2.7 to 3.3. Any particular issues you’re having, or just working through the process?

Don’t have the exact details on me but it was just the change for the method params hash thing. The stack trace seems to be pointing places that aren’t the source of the issue, just where it got triggered in some dynamic way.

Probably just need to spend more time understanding exactly what changed and how to convert stuff.

Re: Ruby 3.4.0

#182

Post by ljm »

viraptor wrote: post #67
omoikane wrote: post #2

I am most excited about the parser change, previously discussed here: https://news.ycombinator.com/item?id=36310130 - Rewriting the Ruby parser (2023-06-13, 176 comments) I remember being taught to use yacc in our compiler course because "writing it by hand is too hard". But looks like Ruby joins the growing list of languages that have hand-written parsers, apparently working with generated parsers turned out to be e…

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…

Ruby's syntax is also not trivial to parse and isn't set in stone either. At some point it was simply decided that trying to maintain the status quo was worse than attempting a rewrite which could bring in some extra gains, either through performance or having an easier time tweaking the grammar.

Re: Ruby 3.4.0

#183

Post by int_19h »

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?

Arbitrary backtracking in a recursive descent parser is very easy with exceptions.

However, there's also an argument here that if the grammar is too complicated to be parsed with recursive descent, it's probably just too complicated in general and should be simplified if possible. Obviously you don't always have this option when you're dealing with an external grammar, but for your own PL, you can design around that. Most Wirth's languages are good examples; Pascal is famously LL(1).

Re: Ruby 3.4.0

#184

Post by int_19h »

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…

Everything is an object in Python, as well.

Stuff like map() is generic iteration, over any structure that exposes iteration. When it's a member function, it means that every collection has to implement map itself basically. When it's separate, the collections only need to provide the interface needed to iterate over it, and the generic map() will just use that.

Re: Ruby 3.4.0

#185

Post by ljm »

neonsunset wrote: post #169
phoronixrly wrote: post #167

Earlier quoted context omitted.

Just to reiterate stuff said in the other comments because your comment is maybe deliberately misrepresenting what was said in the thread. Their entire cluster was 2.4 million CPU cores (without more info on what the cores were). This includes not only Ruby web applications that handle requests, but also other infrastructure . Asynchronous processing, database servers, message queue processing, data workflows etc, et…

> It does not tell you much about the performance of the Ruby part of the equation in isolation. Indeed, it doesn't. However, it would be a fairly safe bet to assume it was the slowest part of their architecture. I keep wondering how the numbers would change if Ruby were to be replaced with something else.

Shopify invest heavily in Ruby and write plenty of stuff in lower level languages where they need to squeeze out that performance. They were heavily involved in Ruby's new JIT architecture and invested in building their own tooling to try and make Ruby act more like a static language (Sorbet, Bootsnap).

Runtime performance is just one part of a complex equation in a tech stack. It's actually a safe bet that their Ruby stack is pretty fucking solid because they've invested in that, and hiring ruby and JS engineers is still 1000x easier than hiring a C++ or Rust expert to do basic CRUD APIs.

Re: Ruby 3.4.0

#186

Post by empthought »

latexr wrote: post #173
yyyyz wrote: post #96

Earlier quoted context omitted.

Can you name one way Ruby has parity with Python? Ruby is a dead language that uses sponsored posts here. Nobody actually uses this since like 2018 but some people are paid to hype it up. Just look at the empty praise. No real applications mentioned.

> Nobody actually uses this since like 2018 but some people are paid to hype it up. What’s the conspiracy theory here? Why would anyone be paying people to hype Ruby? What could possibly be the end goal?

> Why would anyone be paying people to hype Ruby? What could possibly be the end goal?

Hiring increasingly disinterested junior devs.

Re: Ruby 3.4.0

#187

Post by ljm »

Gigachad wrote: post #171
tan-z-tan wrote: post #108

Every year-end, I update my Rails app. Lately, it's been stable, and the updates just improve performance, so it's gotten easier.

I started at a company 3 years ago that was on Rails 5.1. After 3 years on and off work I've managed to get it to Rails 6.1. The process is such an incredible nightmare on a large app. Currently stuck on trying to get Ruby 3 working.

At some point you just have to rip the bandaid off and put any ongoing work on pause until the upgrade is done. Otherwise it'll be another 3 years on and off while you try to do the upgrade but the codebase keeps changing underneath you.

And if that isn't happening and there's no other development on the codebase, why bother upgrading it?

Re: Ruby 3.4.0

#189

Post by weaksauce »

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?

it makes ruby code faster than c ruby code so they are moving toward rewriting a lot of the core ruby stuff in ruby to take advantage of it. run time performance enhancing makes the language much faster.

Re: Ruby 3.4.0

#190

Post by liprais »

koshersalt wrote: post #135
bendangelo wrote: post #116

Earlier quoted context omitted.

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.

typical hn comments,ignoring elephant in the room.
Post reply on HN