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

41–50 of 182 posts

Re: Rewriting the Ruby parser

#41

Post by graypegg »

d3nj4l wrote: post #36
clairity wrote: post #28

Earlier quoted context omitted.

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…

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…

I’ve had the exact same experience! I’m getting to use some new JS SSR frameworks at work (Remix) but I keep using rails for my own things. Gets out of my way.

Re: Rewriting the Ruby parser

#42

Post by noelwelsh »

d3nj4l wrote: post #36
clairity wrote: post #28

Earlier quoted context omitted.

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…

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.

Re: Rewriting the Ruby parser

#44

Post by sergiotapia »

ljm wrote: post #40
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.

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

#45

Post by fareesh »

I use ruby/rails for professional consulting work. It helps get startups off the ground and into a MVP stage quite quickly, and there is high productivity.

You can also use whatever React/Vue on the frontend if you really need to.

I would like to use some Typescript framework but none are "there yet" with regard to productivity.

Scaling rails in some scenarios is quite challenging, but in most cases you can leverage caching to solve performance challenges.

Re: Rewriting the Ruby parser

#47

Post by kddeisz »

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…

The templating is definitely an effort to keep the maintainability in check. It's also because we're planning on keeping a grammar around to generate test cases for us with fuzzing/other algorithms.

The encodings is a bit historical, to my knowledge Ruby is the only major language that was developed by someone whose language did not work with ASCII. So the first encodings written in Ruby were the old Windows pages.

Re: Rewriting the Ruby parser

#48

Post by kddeisz »

davexunit wrote: post #33

I think Ruby is a pretty good language and I spent many years using it professionally but I can't imagine having enough motivation to work on the language implementation when it's so difficult to even parse the code. The amount of engineering time spent on this topic is bonkers!

Maybe I'm a masochist, but to be honest it's a dream job. Working on such a complex language and history is really really fun.

Re: Rewriting the Ruby parser

#49

Post by justanother_guy »

fareesh wrote: post #45

I use ruby/rails for professional consulting work. It helps get startups off the ground and into a MVP stage quite quickly, and there is high productivity. You can also use whatever React/Vue on the frontend if you really need to. I would like to use some Typescript framework but none are "there yet" with regard to productivity. Scaling rails in some scenarios is quite challenging, but in most cases you can leverage…

Nest.Js seems to be promising, but like you said, it has a long way to go.

Re: Rewriting the Ruby parser

#50

Post by soulbadguy »

ecshafer wrote: post #12
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…

(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 scalable infrastructure (or scaling up infra): Keep the bulk of the existing code and invest in making the underlying compiler/interpreter/tool chain better or progressively migrate the code to a tool chain with better scaling capabilities from the get go.

From experience, the nature and semantic of a language severely what is "reasonably" possible in the runtime in term of safety (like code loader in java), performance (both CPU and memory) and tooling. Now improvement are possible, but they tend become exponentially expensive as time goes on.

Now, obviously there is always a tension between developer productivity and infra concerns, but i do believe that we have better compromise point on that line with newer language and framework.

I totally agree that in the 2000's the experience of most "enterprise framework" sucked very hard, and the emergence of language such ruby/python etc... was a god send : a response to the overly rigid and ceremonial way of the past. But with time, we have been able to understand better what makes a good programming experience, distill that into better designed languages and framework which offer "better" compromises. For example :

- Instead of dynamic vs static type , we have progressively typed and type inference - Instead of GC vs non-GC we have rust borrow-checker - Instead of runtime meta programing with have DSL and macro's

Even more important, i believe that a lot of the experience come from the tooling around the language, and there again the "cargo/dotnet/go" cli approach with a single coherent entry point for both package management and framework scaffolding ease a lot of the pain of the old way.

With all of that we now have languages which offer a better compromise on the dev. prod vs infra/performance...

> JVM is blazingly fast

I would say blazingly faster... But compared to C++ (or even rust) java is still quite slow. Especially for anything compute intensive.

Post reply on HN