Live data from Hacker News

Rewriting the Ruby parser

railsatscale.com

51–60 of 182 posts

Re: Rewriting the Ruby parser

#51
post #14

I love how pragmatic the approach is here. We still don't have parser generators which generate human understandable/readable recursive descent parser with good error recovery baked in. But i am guessing the ruby syntax is too complicated/irregular anyway. On a macro side, i am always surprised with the length and effort company will go to keep working with solution design and selected at their young age, and try to…

Where is the “more bang for the engineering buck”?

?

Re: Rewriting the Ruby parser

#52

It feels to me like Shopify is single-handedly keeping Ruby alive. A little bit like Jane Street and O'Caml.

You're going to incur the wrath for saying the silent part, but you're not wrong. People have the same 5 rails example corps every time someone says one of these two things: - without rails nobody would use ruby - without X corp, ruby's dead Fact is, we're seeing less and less usage, and more and more distillation of the current userbase along the golden paths laid out by DHH. Is it wrong for rails and thus ruby adop…

> - rails is mostly needed for prototyping and crud apps

> - this work is typically done by juniors

> - rails devs are at this point largely seniors, not juniors

> - rails devs pay the bills with other tech or by maintaining legacy rails apps.

- and those prototyping apps have very often gone through multiple teams, some or all of them probably outsourced. Potentially true of any codebase, but it's true of an exceptionally high proportion of Rails codebases.

I'm at the point where I'd want a stupid premium to come in on an existing Rails codebase, and I'd want a day or two with it before saying "yes" even at that. They're great if they've been maintained by professional, expert teams their whole life, but god-awful messes remarkably resistant to analysis, otherwise.

I like Ruby a lot but most of the jobs are in Rails, and after initial infatuation followed by repeated exposure over 15ish years, I've come around to pretty much hating Rails. Too much implicit magic, too much memorization, too opaque to tools that might help overcome those first two problems.

Re: Rewriting the Ruby parser

#53
post #43

Will this change impact Solargraph / Rubocop? They are painfully slow / unusable in their current state on large-ish projects

Depends on what you mean by Solargraph, because it's kind of a large project. If you mean their typechecking, then definitely not, because it's not using a Ruby parser. If you mean the general feedback, then yeah potentially.

Rubocop yes if it ends up using YARP as a new backend.

Either way, I would suggest you check out ruby-lsp, which is definitely going to benefit from this speed, and soon.

Re: Rewriting the Ruby parser

#54
post #39

With the mention of the parser's performance, I am reminded of Rich Kilmer's 2004 RubyConf presentation. Rich used Ruby to test reliability of a distributed system with hundreds of Java VMs. Some of the serialized data was stored as XML (over 1M lines!), which was slow to parse and load. Rich modified the program to serialize the data as Ruby code, which loaded much faster ( https://www.infoq.com/news/2007/06/infoq-i…

Nice cover story to hide your ~totally existing~ time machine ;)

Re: Rewriting the Ruby parser

#55
post #40

It feels to me like Shopify is single-handedly keeping Ruby alive. A little bit like Jane Street and O'Caml.

I think ‘is Ruby dying?’ is little more than a meme that has stuck around for longer than it deserves. The continuing work on the language and its performance is impressive, but Ruby (and Rails) themselves have the honour of being stable, tried-and-tested solutions for rapid application development. Is it as exciting as the latest and greatest serverless lambda framework in Typescript? Not really. Is it a dependable…

I don't deny the utility of Rails for building a certain class of web site. But I think there is a difference between Rails and Ruby, and a difference between use of a technology and improvements to that technology.

I think a technology must continue to change and adapt to remain relevant. I see Shopify as the main driver of current improvements to Ruby (the core features of the most recent release, and the upcoming release, were mostly due to Shopify as I understand it). I don't see smaller companies doing these improvements and I think without them Ruby will (slowly, because it's used in some big places) fade away.

Re: Rewriting the Ruby parser

#57

It feels to me like Shopify is single-handedly keeping Ruby alive. A little bit like Jane Street and O'Caml.

This couldn't be further from the truth. There are so many people using Ruby, so many modern companies deciding to use it and so many large companies that continue to use it.

The demand for Ruby developers is higher than the supply.

Re: Rewriting the Ruby parser

#58
post #43

Will this change impact Solargraph / Rubocop? They are painfully slow / unusable in their current state on large-ish projects

The article mentions that they are building a compatibility layer around YARP that tools can use to transform its new tree format into the legacy Ripper format. They don't call out Rubocop specifically but I can't think of another OSS tool that so prominently uses the parser APIs.
Post reply on HN