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.
Rewriting the Ruby parser
61–70 of 182 posts
Re: Rewriting the Ruby parser
#62Nice article! In this sentence ... open parenthesis character is ambiguous in this context. To get around it they made their grammar more ambiguous and then enforced that the actual grammar was enforced in their tree builder. I'd change the second "more ambiguous" to "more lenient" i.e. lenient meaning "grammar accepts more strings", ambiguous meaning "grammar is invalid" I have seen this issue in Python's grammar as…
Ambigious does not mean invalid
Fast parsers that use a schema are also doing model checking.
Re: Rewriting the Ruby parser
#63It feels to me like Shopify is single-handedly keeping Ruby alive. A little bit like Jane Street and O'Caml.
I don't know why, there are tons of smaller companies using it. I have a lot of languages and experience on my resume and the one that consistently gets me the most inquiries at the highest pay grades is still Ruby. Anecdotal I know, but from the moment that it appeared on my resume in 2012 it's been non-stop. Probably 80% of everything I hear about. Ruby and it's ecosystem brings the closest thing to natural Aspect…
Longtime rails dev here. The reason smaller companies are using it is because you can move much faster working on a full stack rails app that gives you SPA-like functionality without needing to incur the performance or operational cost of a dedicated front end.
I've worked for both rails shops and JS shops, and the productivity achieved with Rails is staggering compared to React in a small team environment. Guillermo Rauch tweeted a few months back that SPAs were a zero interest-rate phenomenon and I completely agree. Just because a bunch of companies jumped on the JS hype train doesn't mean that they were all making the right decision.
Re: Rewriting the Ruby parser
#64Re: Rewriting the Ruby parser
#65Earlier quoted context omitted.
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 used to get invites for jobs and see listings for jobs for Ruby and Rails a lot. Now I don't see any at all. There's most definitely a "dead" feeling to the platform. I hardly hear about new projects being started with Rails as well...
Re: Rewriting the Ruby parser
#66Flash forward several years, and the amount of changes in Ruby are huge! Ruby is as fit as ever for modern development, and I'm really happy about that.
Re: Rewriting the Ruby parser
#67It 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
#68Earlier quoted context omitted.
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 used to get invites for jobs and see listings for jobs for Ruby and Rails a lot. Now I don't see any at all. There's most definitely a "dead" feeling to the platform. I hardly hear about new projects being started with Rails as well...
It's used in many companies, new and legacy.
Re: Rewriting the Ruby parser
#69Earlier quoted context omitted.
I've been building a webapp with Rails on and off over weekends. Several times over this process, I thought through some of the architectural decisions and naturally realized that the "Rails way" was the best option to pursue. It's not just because I'm using Rails - my most recent webdev experience was with a SPA driven by a Java backend. I'm sure there are tradeoffs involved (what doesn't?) but with every passing da…
Can you recall some of these architectural decisions? I think that would be interesting.
- I wanted to make an index page where a user could make edits to the items being displayed and make regular show/edit pages for the item so if a user was on that page they could edit it. This is actually really useful: a user can bookmark the page for a specific item, or open it in a new tab, or in general do things browsers let you do but apps struggle with. Making two different edit components would be stupid, and I thought this would be one of those things that I could do better in React than in Rails. After looking around a bit I quickly found that if I used standard REST-y routes and wrapped the key parts of the view with turbo frames I could get exactly what I wanted, and it worked out seamlessly. In general, I've found that Rails' heavy emphasis on REST was a good architectural choice, and every time I disagreed with it and went another way I ended up regretting that choice and reverting to REST.
- In the Java world, you typically have thin models + a service layer which has the business logic. This is apart from other layers such as Repo/DAO etc, which I was already replacing with ActiveRecord, but I was initially resistant to putting all of my business logic in the models, especially if it involved logic across them. But it also hurt discoverability. I was working on a project I was expecting other people to work on with me, and I wanted to make it easy for them to figure out what they could do with a model object. The solution to this came from DHH himself. I've lost a link for this, but he said that if you make service objects, you should add a method on the model that acts as a way to reach the service. This keeps the model "fat" while also separating out logic into simple, unit-testable classes.
One of the smaller things I appreciate is keeping all of the routing details in rails routes. I know other frameworks like Django also do this, but I really didn't like this about most Java frameworks and microframeworks in other languages.
In general, if you're interested in seeing how to architect Rails apps, I say study how 37Signals does it. Playing around with Basecamp convinced me of the practicality of the Rails way and taught me a lot of interesting and useful patterns.
Re: Rewriting the Ruby parser
#70Earlier quoted context omitted.
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 used to get invites for jobs and see listings for jobs for Ruby and Rails a lot. Now I don't see any at all. There's most definitely a "dead" feeling to the platform. I hardly hear about new projects being started with Rails as well...
I don’t think this makes it dead or dying though. It’s stable and entrenched while JS has taken the place of the golden child.
One complaint I’ll grant myself is that library development is a little less prolific this days. Again, there are well-established solutions to a lot of problems in Ruby so you’ll have a go-to collection of gems, but it’s more often the case these days that something doesn’t have much library support and you’ve got to roll your own.