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”?
Rewriting the Ruby parser
51–60 of 182 posts
Re: Rewriting the Ruby parser
#52It 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…
> - 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
#53Will this change impact Solargraph / Rubocop? They are painfully slow / unusable in their current state on large-ish projects
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
#54With 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…
Re: Rewriting the Ruby parser
#55It 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 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
#56It feels to me like Shopify is single-handedly keeping Ruby alive. A little bit like Jane Street and O'Caml.
Re: Rewriting the Ruby parser
#57It feels to me like Shopify is single-handedly keeping Ruby alive. A little bit like Jane Street and O'Caml.
The demand for Ruby developers is higher than the supply.
Re: Rewriting the Ruby parser
#58Will this change impact Solargraph / Rubocop? They are painfully slow / unusable in their current state on large-ish projects
Re: Rewriting the Ruby parser
#59Re: Rewriting the Ruby parser
#60I'm glad to see big steps towards this.