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

91–100 of 182 posts

Re: Rewriting the Ruby parser

#91

Post by byroot »

arp242 wrote: post #81
freedomben wrote: post #72

Earlier quoted context omitted.

> 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.

> Isn't "it's comparatively slow" what people usually mean with "doesn't scale"?

If that's the case, then they are misguided.

> You can scale anything with enough hardware

No, some architectures or implementations can give you diminishing returns or a hard cap. Not everything can scale horizontally ad infinitum.

Re: Rewriting the Ruby parser

#92

Post by vidarh »

lagniappe wrote: post #8
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.

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…

I've spent the majority of my time on Ruby since 2005, and only about 2 of those years have involved any Rails at all. There are plenty of opportunities to use Ruby in other contexts, but it's often less flashy. Most of my Ruby use have been e.g. in devops behind the scenes where the job description might not list a language.

Re: Rewriting the Ruby parser

#93

Post by vidarh »

arp242 wrote: post #81
freedomben wrote: post #72

Earlier quoted context omitted.

> 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.

Twitters architecture at the time was a textbook example of how not to build a large scale many-to-many social network. Maybe switching would've been worth it for them anyway, but the big thing they needed was fixing architectural choices they never should've made to start with.

Re: Rewriting the Ruby parser

#94

Post by nirvdrum »

IshKebab wrote: post #79

People always say language choice doesn't matter, but how many companies get stuck with a language where they resort to rewriting the parser for it?

No one is "stuck" or "resorting" to anything. It's an effort to improve tooling, performance, error reporting, and working with Ruby in general. We could maintain the status quo (which does indeed work) or we could improve it. If we don't improve the status quo, people call the language stagnant and outdated. If we do, it's considered a criticism of its maturity.

How many languages would even entertain such a contribution? How many languages are so tightly bound to their parser that writing a new one wouldn't even be workable? How many languages have user tooling that works extensively with parsed code snippets? How many languages have multiple implementations? Of those, how many are working together on an effort to share a common parser?

There's plenty of valid reasons to use something other than Ruby. An open source project that grew organically over 25 years deciding that it's time to pay down some technical debt and improve the ecosystem at the same time is probably not one of them.

Re: Rewriting the Ruby parser

#95

Post by vidarh »

abhibeckert wrote: post #30
lagniappe wrote: post #8

Earlier quoted context omitted.

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…

Admittedly I haven't written any ruby code in a very long time, but you only briefly touched on the reason we ran away from it after giving it a serious try: > rails devs pay the bills with other tech or by maintaining legacy rails apps That "maintaining legacy rails apps" job just doesn't exist with our PHP apps. Once properly tested and deployed PHP will generally work perfectly and smoothly for years with zero mai…

Sounds like you know how to build PHP apps and didn't know how to build Ruby apps. That's fine, and a valid reason for you to pick what worked for you. I've had plenty of Ruby apps just run for years without additional work.

Re: Rewriting the Ruby parser

#96

Post by vidarh »

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…

> a custom template language written in Ruby

This makes it sound like it's some template language specific to this project, but ERB is the dominant templating language for Ruby because an ERB implementation is in the standard library.

Re: Rewriting the Ruby parser

#97

Post by supernikio2 »

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() |…

This already exists to some extent, with the >> operator and lambdas.

```

first = ->(x){some code...}

second = ->(x){some code...}

third = ->(x){some code...}

(third >> second >> first).call(arg)

```

I agree it's not as clean as what you propose, but much better imo than traditional nested calls (and Haskell's `.`).

Re: Rewriting the Ruby parser

#98

Post by kubectl_h »

bamfly wrote: post #52
lagniappe wrote: post #8

Earlier quoted context omitted.

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

> Too much implicit magic, too much memorization, too opaque to tools that might help overcome those first two problems.

If you are a senior level Rails developer none of this is true except maybe memorization and that seems to be a pre-requisite for any senior engineer in any language. It's trivial to debug rails applications with debugger and reading the underlying source code. Everything you need to solve problems is a binding.pry or `bundle open` away.

Re: Rewriting the Ruby parser

#99

Post by LapsangGuzzler »

pcthrowaway wrote: post #89
LapsangGuzzler wrote: post #63

Earlier quoted context omitted.

> 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.

Sure, he's trying to create a business that I'm not particularly interested in being tied down as well. That doesn't make him wrong about SPA.

Re: Rewriting the Ruby parser

#100

Post by ecshafer »

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…

I've worked in Orgs with Cobol code written in the 70s and 80s still around. The strategy of moving your business over to a more performant / scalable tech, in essence means you now have two sets of technologies that just end up sitting on top of each other. I worked on a business line that literally had Java, Javascript, Cobol, VBScript, C#, and Smalltalk all working somewhere in the business process counting only in house written code! Businesses never actually modernize everything. They patch old code, write new stuff in new tech, and it grows in complexity. So the invest in core techs we already use is I think a great idea.
Post reply on HN