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

101–110 of 182 posts

Re: Rewriting the Ruby parser

#101

Post by craigmcnamara »

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…

The story you're telling sounds like a you guys problem, not a Ruby or Rails problem. I've been building and running Rails apps since 2007 and have not experienced what you've described.

My current app runs on AWS ECS. Upgrades are largely just updating my Dockerfile or merging a pull request from Dependabot. We have pagerduty and it only goes off when a 3rd party API is down, usually resolving itself.

Re: Rewriting the Ruby parser

#102

Post by nsajko »

Tangential:

> Over the years, processors and C compilers have gotten much better using a couple of techniques. These include pipelining, inlining functions, and branch prediction. Unfortunately, the parsers generated by most parser generators make it difficult for any of these techniques to apply. Most generated parsers operate with a combination of jump tables and gotos, rendering some of the more advanced optimization techniques impotent. Because of this, generated parsers have a maximum performance cliff that is extremely difficult to overcome without significant effort.

Although generating parsers, and finite automata in general, using a table-based approach is common, it has long been recognized that using tables/data for this purpose (as opposed to generating executable source code directly) is not a good idea, precisely because it inhibits compiler optimizations. I think the current situation is simply a consequence of the fact that parsing abruptly stopped being sexy multiple decades ago.

Much better parser generators are possible, and LR, specifically, has much untapped potential left.

Re: Rewriting the Ruby parser

#104

Post by bamfly »

kubectl_h wrote: post #98
bamfly wrote: post #52

Earlier quoted context omitted.

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

If you're having to poke around in running code to find out WTF some symbol even is and where it comes from, and that's not a very uncommon thing to have to do, that's unacceptable IMO.

> that seems to be a pre-requisite for any senior engineer in any language

In many languages and language-ecosystems, there's little point to memorizing e.g. method names and signatures that you're not using so often that memorization happens naturally, because your tools can remind you when you, fairly seamlessly, when you need to know. A lot less memorization goes a lot farther in those worlds, than it does in Rails, and the pain of encountering something one is not familiar with is near-zero. Coming back to them after a year or two—or five—away's not a big deal. The brain-space required for Rails is unusually large, and the rate of rot in Rails skill is high. Ramp-up time in an unfamiliar Rails codebase is rough, and requires assistance from those already "read in" to avoid a bunch of wasted time tracking down which gem provides such-and-such dynamically-named object or method or what-have-you. "Which library is this even from?" is not a question that ever reaches the level of conscious thought, in many other languages & frameworks.

Getting up-to-speed on an unfamiliar Rails codebase is full of little side-quests that simply aren't needed elsewhere, and you have to hold a lot more in your head to remain productive in it, than other systems require. This is obviously not impossible, but... oof, why?

All that written out... there's a chance I'd still pick it for a new, solo project, depending on the task. It's fine as long as you are very-familiar with the entire codebase, and some of its gems are major time-savers. I get why companies, and especially move-fast prototyping startups, end up with it, I'm just very done onboarding to existing Rails codebases, personally, without some serious pain & suffering compensation.

Re: Rewriting the Ruby parser

#105

Post by G3rn0ti »

PaulHoule wrote: post #74

It’s little appreciated how much current parser generators are holding the industry back. That is, LISP maintains a lead in metaprogramming because it bypasses Chomskyism alltogether. It really should be a few lines of code to add an “unless(X) {}” statement to “if(!X) ()” to Java, Python, Ruby but the very idea that you could patch an existing grammar with a separate file is like technology that fell off a UFO. Also…

If you’re into language parsing and how its patterns could be used in a modern programming language you should take look on Raku (fka Perl 6): It has native support for „Grammars“ [1] which are basically specialized classes to put Regexes in for defining tokens and also combinations of such tokens. Once you‘re done you can use a grammar object to parse text returning an AST object. Raku‘s own syntax is defined in Grammars being a subset of Raku‘s syntax.

So in a nutshell Raku‘s „Grammar“ construct is like RegExes on steroids and renders defining DSLs or other special purpose languages so much easier than in any other modern language.

[1] https://docs.raku.org/language/grammars

Re: Rewriting the Ruby parser

#106

Post by Rauchg »

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.

Except my preference for SSR as the default dates as far back as 2014 and is rooted in the laws of physics[1] Downloading an empty shell, downloading code to render a bunch of spinners, to then incur in a bunch of waterfalls of data and more code to the server is not gonna make it.

[1] https://rauchg.com/2014/7-principles-of-rich-web-application...

Re: Rewriting the Ruby parser

#107

Post by ezekg »

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.

Refinements would be more useful if you could expose the refinements, but currently you can't.

    module HashExts
      refine Hash do
        def symbolize_values = transform_values { _1.to_sym }
      end
    end
      
    module Test
      using HashExts
      
      def self.new_h = Hash.new
    end
      
    puts Test.new_h.symbolize_values
    # => undefined method `symbolize_values' for {}:Hash (NoMethodError)

Re: Rewriting the Ruby parser

#108

Post by pulisse »

soulbadguy wrote: post #7

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…

The number of engineer years required for the parser rewrite was probably in the low double digits. Migrating a platform like Spotify to a new framework in a different language would take hundreds.

Re: Rewriting the Ruby parser

#109

Post by AtlasBarfed »

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…

It is a lie to say java is faster than c/c++ due to runtime optimization

It is also a lie to say java is "quite slow" compare to c/c++

Re: Rewriting the Ruby parser

#110

Post by Dylan16807 »

revscat wrote: post #11
SushiHippie wrote: post #2

Somewhat fitting xkcd: https://xkcd.com/927/

While this xkcd is frequently germane, in this case it is not particularly apt. The core CRuby team, who maintain the current “standard”, are in agreement that YARP — the new “standard” — will one day replace it.

Even putting the word "standard" in quotes is buying too much into the argument.

This is a new implementation of an existing standard.

Post reply on HN