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

Rewriting the Ruby parser

railsatscale.com

Post reply on HN
Print view View original

81–90 of 182 posts

Re: Rewriting the Ruby parser

#81

Post by arp242 »

freedomben wrote: post #72
arp242 wrote: post #18

Earlier quoted context omitted.

Looking for a job right now, not limited to any specific language, and I see Ruby mentioned plenty of times. Based on that, it seems the reports of Ruby's decline are not as bad as sometimes claimed. If you look at PostgreSQL then a lot of dev work comes from EnterpriseDB and a handful of companies too. The thing with Rails is that it doesn't scale terrible well to "Twitter scale" (if I'm not mistaken Twitter has dro…

> The thing with Rails is that it doesn't scale terrible well to "Twitter scale" It's true that Twitter switch to JVM langs, but it's not true that Ruby doesn't scale (or couldn't have to Twitter's level if they'd kept it). Twitter was early days for Ruby and things have improved a lot, but the only scaling challenge with Ruby is the cost of app instances. I use Elixir/Phoenix now and run 1/4 of the app instances I u…

Isn't "it's comparatively slow" what people usually mean with "doesn't scale"? You can scale anything with enough hardware, but as you mentioned at some point is just becomes very expensive.

Re: Rewriting the Ruby parser

#82

Post by byroot »

soulbadguy wrote: post #50
ecshafer wrote: post #12

Earlier quoted context omitted.

(Disclaimer: Shopify employee but not part of this team) Ruby is my favorite language so far to write "business logic" in, and Rails is a very developer friendly web framework that makes it very easy to set up websites. So I think this is a pretty great strategy overall. The end of the day I think the way to get tech too scale, is for companies / academics / etc to really just put the work in. Java was very slow on r…

Disclaimer : my career has mainly been on compiler/runtime and other infrastructure related stuff, so not much of a business logic/web dev kind of guy. > The end of the day I think the way to get tech too scale, is for companies / academics / etc to really just put the work in. This is true in the abstract, but my point is mainly about the comparative effectiveness of different strategies when it come to building sca…

> Disclaimer : my career has mainly been on compiler/runtime and other infrastructure related stuff, so not much of a business logic/web dev kind of guy.

That probably explain your surprise. This question comes up extremely often on HN, the answer is that even if you were to stop all feature development, re-platforming a large organization like Shopify would take years, not even considering all the re-training, lost knowledge etc.

And you'd spend these years having to support multiple platforms so that would only pay off much later, and in the meantime your competitors continue iterating.

In general it's best to stick with the devil you know, unless the new platform interoperate very well with the old one.

Re: Rewriting the Ruby parser

#83

Post by twic »

clairity wrote: post #28
brightball wrote: post #17

Earlier quoted context omitted.

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…

i think if rails continues to push hotwire (turbo + stimulus, and perhaps strada?) and get a coherent story on view components, it will continue to take mindshare from the js hype of the last decade. mobile dev is in decline, and browser makers just released web notifications, web app support, webtransport, page transitions, etc., so the backend has largely reached parity for cross-platform development. no longer is…

> mobile dev is in decline

This is news to me. Is this really true?

Re: Rewriting the Ruby parser

#84

Post by freedomben »

ljm wrote: post #78
freedomben wrote: post #66

It's been really great watching Ruby over the last few years. I had the privilege of having dinner with Matz several years ago near the beginning of Ruby 3.0 work. I was giving a talk about Elixir at a Ruby conference, and he was interested in things I (as a self-professed fanboy of both languages) liked better about Elixir than Ruby. We talked for quite some time, and it became very clear to me that he knew that Rub…

Pattern matching alone is a huge feature and an absolute delight to use when the opportunity presents itself. I’d love to see where Ractor goes but I worry it will remain niche, like with Refinements.

Agreed. Pattern matching and pipe operator were the two that I hoped for most.

The pipe operator implementation proposal that they team came up with was wrong though and I'm glad they didn't do it. We don't need alternate syntax for `.`, we need ability to chain arguments together in a syntactically pleasant way in a functional style so we don't have to write `first(second(third(arg)))` we can write `arg |> third() |> second() |> first` which is much cleaner and reads left to right like it should

Re: Rewriting the Ruby parser

#85

Post by ksec »

johnisom2001 wrote: post #57
noelwelsh wrote: post #3

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.

Your parent is talking about investing in Ruby the language and its ecosystem. Not just using it.

The new GC, and JIT, along with a few Ruby Cores are all Shopify employees.

Re: Rewriting the Ruby parser

#86

Post by pcthrowaway »

noelwelsh wrote: post #55
ljm wrote: post #40

Earlier 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 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…

I'm a bit surprised that Github isn't doing work on Ruby, since they're probably the largest RoR deployment

Re: Rewriting the Ruby parser

#87

Post by munificent »

e4m2 wrote: post #26

Interestingly, the actual syntax tree and related structures/functions are generated from the config.yml file and the templates inside the bin directory. They are using a custom template language written in Ruby, here's an example of how they do enum stringification: https://github.com/ruby/yarp/blob/main/bin/templates/src/tok... . Obviously this isn't a novel idea, but IMO this kind of design goes a long way to supp…

> Interestingly, the actual syntax tree and related structures/functions are generated from the config.yml file and the templates inside the bin directory.

That makes a lot of sense. ASTs tend to be a very dumb but fairly verbose data structure. And, in C in particular where everything is more verbose, there ends up being a ton of boilerplate in the AST nodes.

In a language like Ruby with a very rich syntax, you end up needed a ton of different AST nodes.

Generating those from a simple declarative format makes maintaining that much easier.

Re: Rewriting the Ruby parser

#89

Post by pcthrowaway »

LapsangGuzzler wrote: post #63
brightball wrote: post #17

Earlier quoted context omitted.

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…

> I don't know why, there are tons of smaller companies using it. 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 s…

> Guillermo Rauch tweeted a few months back that SPAs were a zero interest-rate phenomenon

Guillermo Rauch is selling Vercel, whose strategy includes first-class tooling for SSR, convincing people to move their SPA to SSR, and then locking them in on their platform.

Re: Rewriting the Ruby parser

#90

Post by zverok »

freedomben wrote: post #84
ljm wrote: post #78

Earlier quoted context omitted.

Pattern matching alone is a huge feature and an absolute delight to use when the opportunity presents itself. I’d love to see where Ractor goes but I worry it will remain niche, like with Refinements.

Agreed. Pattern matching and pipe operator were the two that I hoped for most. The pipe operator implementation proposal that they team came up with was wrong though and I'm glad they didn't do it. We don't need alternate syntax for `.`, we need ability to chain arguments together in a syntactically pleasant way in a functional style so we don't have to write `first(second(third(arg)))` we can write `arg |> third() |…

Ruby-idiomatic pipe operator is Object#then. After a lot of design proposals and discussions it is more or less evident no solution other than method would integrate naturally with the rest of the code. So it is just `arg.then{ third(_1)}.then{ second(_1)}.then{ first(_1)}`

Would've been a bit more concise with method references, almost introduced in 2.7, but alas.

(But, well, people tend to want "something that looks like operator, preferably something that looks exactly like |>" and reject every other possibility)

Post reply on HN