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

111–120 of 182 posts

Re: Rewriting the Ruby parser

#111

Post by pcthrowaway »

Rauchg wrote: post #106
pcthrowaway wrote: post #89

Earlier quoted context omitted.

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

I mean those are fair points, though respectfully I think there are cases for SPAs where SSR won't do. But that's not what we're talking about.

Referring to SPAs as a "zero-interest-rate phenomenon" implies that SSG/SSR models are more efficient in terms of financial cost of deployment. I don't agree this is necessarily the case, and I think SPAs can be developed and deployed sanely and cheaply also.

Vercel is doing some amazing things, but it's also innovating in ways that occasionally lead to "lock-in", in the sense that moving away from Vercel would involve a lot of friction. So I think it's fair to point out that you have a financial interest in convincing people to adopt delivery models that your business streamlines.

Re: Rewriting the Ruby parser

#112

Post by soulbadguy »

AtlasBarfed wrote: post #109
soulbadguy wrote: post #50

Earlier quoted context omitted.

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

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

Why ?

Re: Rewriting the Ruby parser

#113

Post by soulbadguy »

byroot wrote: post #82
soulbadguy wrote: post #50

Earlier quoted context omitted.

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…

> re-platforming a large organization like Shopify would take years I am not sure what re-platforming means here, but "slowly transitioning" to a different stack is not the same as stop and rewrite everything.

> That probably explain your surprise

While i don't write "business logic", i have been involved in a lot of project to babysit, maintain, refactor and/or improve business code bases. Sometime the runtime can only do so much and you have to adjust the user level code. And from experience it's never as bad as some make it to be.

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

Again i see this very often as well. Software engineering seem to over emphasizes the cost of platform transition while downplaying the operating burden of not modernizing.

Re: Rewriting the Ruby parser

#114

Post by soulbadguy »

ecshafer wrote: post #100
soulbadguy wrote: post #50

Earlier quoted context omitted.

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

Hard to comment in the abstract, but i think this just showed that the organization did have a defined strategy and things just grew on a had-hoc fashion. Seems like an orthogonal problems.

Re: Rewriting the Ruby parser

#115

Post by ljm »

ezekg wrote: post #107
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.

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)

Yeah, I feel like there was a bit of an expectation mismatch around that. `using` makes a lot more semantic sense than `include` or `extend` in a lot of cases but it didn’t play out that way and we’re still living with the unusual convention of making ‘x-able’s and writing ‘concerns’. Not to mention that they were file-scoped and not lexical in their first version so had limited utility for library devs.

As far as I know the teething issues around refinements are ironed out but they remain an obscurity.

Re: Rewriting the Ruby parser

#116

Post by ljm »

zverok wrote: post #90
freedomben wrote: post #84

Earlier quoted context omitted.

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

This would be more elegant if there was a better way to do `&object.method(:method_name, …)`. Unbound method support has been around for a long time but converting a method call with arguments to a prod is still not simple to do… unless you start currying methods and writing obscure code.

Re: Rewriting the Ruby parser

#117

Post by ljm »

supernikio2 wrote: post #97
freedomben wrote: post #84

Earlier quoted context omitted.

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

I’ve had a lot of fun with Ruby’s support for functional paradigms but that stuff is unlikely to get through code review when the status quo tends towards ‘Clean Code’ style OOP over-abstraction.

Ruby being a type 2 lisp is a fun one - creating a class and and a factory function with the same name, with argument forwarding:

    class Animal; …; end
    def Animal(…); Animal.new(…); end

Re: Rewriting the Ruby parser

#118

Post by weaksauce »

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…

with the improvements to hotwire you might not even need to get to a heavy frontend like react

Re: Rewriting the Ruby parser

#119

Post by ramesh31 »

So Shopify spends millions of dollars in engineering salary to get a substandard performing language up to par with a dozen other contemporary better choices? The choice to stick so hard with Ruby just doesn't seem reasonable at all with their scale. It must be something dogmatic from the top.

Re: Rewriting the Ruby parser

#120

Post by cultofmetatron »

arp242 wrote: post #18
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…

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…

twitter was never a good fit for rails anyway. twitter is basically a human pubsub at scale. Rail's bread and butter are simple crud based apps with nonlinear use patterns.
Post reply on HN