Building GitHub with Ruby on Rails • Hacker News Board

Re: Building GitHub with Ruby on Rails

#161

Post by skeeter2020 » Fri, Apr 07, 2023, 2:00 PM UTC

AeroNotix wrote: post #76

dagorenouf wrote: post #61

I built my startup 4 years ago with a combination of react + aws + gatsby + hasura. I thought this would be great for performance and scale. Fast forward to today, I spend at least 2x as much time to code a feature than if I had just stuck with a simple rails stack, and the scale I imagined never happened. Now rebuilding everything with rails so I can ship faster and focus on growing the product, not making engineeri…

Building for scale from day 0 is a recipe for disaster. You should've seen that coming.

this absolute is a little ignorant. For some products the scalability is the core competitive advantage. He can't engineer it in after the fact.

Re: Building GitHub with Ruby on Rails

#162

Post by nomilk » Fri, Apr 07, 2023, 2:02 PM UTC

> Instead of telling your team you found something in Rails that will be fixed in the next release, you can work on something in Rails and see it the following week!

That's awesome. Not only fixing it for your team but the entire rails world.

Re: Building GitHub with Ruby on Rails

#163

Post by ativzzz » Fri, Apr 07, 2023, 2:03 PM UTC

Alifatisk wrote: post #128

AeroNotix wrote: post #76

Earlier quoted context omitted.

Building for scale from day 0 is a recipe for disaster. You should've seen that coming.

You suggest people should refactor later on when needed?

Yea, you identify bottlenecks and refactor those as needed (with something like rails it's pretty easy to change out parts of your system while retaining the rails core). Every business will have different bottlenecks and it's very hard to identify them before you start accumulating customers and see how they are using your app

Re: Building GitHub with Ruby on Rails

#164

Post by jack_riminton » Fri, Apr 07, 2023, 2:03 PM UTC

compumike wrote: post #112

Even as a much smaller team, building Heii On-Call [0] as a lightweight alerting/monitoring/on-call rotations SaaS based on Ruby on Rails has basically been a pleasure! And as the article highlights, perhaps the key reason for smooth deployments and upgrades is that the CI testing story is so, so good: RSpec [1] plus Capybara [2] for us. That means we have decently extensive tests of just about all behavior. The few…

My startup is using minitest (mainly for running tests in parallel I believe) and capybara.

Crystal looks great, are you using it mainly for type checking? If so why not Sorbet?

Re: Building GitHub with Ruby on Rails

#165

Post by ativzzz » Fri, Apr 07, 2023, 2:07 PM UTC

snemvalts wrote: post #34

Github is one of the few webapps where I can feel daily that the framework used isn't enough. So many things get out of sync/not up to date, which are fixed by refreshing the page.

I think it's a tradeoff - rails makes live frontend updating challenging because you need to maintain a separate system to manage that, especially when you have a large app. JS frameworks have this built in, but their backend is lacking compared to rails IMO

Re: Building GitHub with Ruby on Rails

#166

Post by ativzzz » Fri, Apr 07, 2023, 2:10 PM UTC

surteen wrote: post #137

Are there other languages where the dominant web framework changes so much? Will Rails ever be "done"?

It can never be done as long as the web keeps evolving and the web shows zero signs of slowing down evolution

And those changes are the reason rails is still really good, modern, and not considered legacy software almost 20 years later

Re: Building GitHub with Ruby on Rails

#167

Post by mattmcknight » Fri, Apr 07, 2023, 2:12 PM UTC

skeeter2020 wrote: post #160

dagorenouf wrote: post #61

I built my startup 4 years ago with a combination of react + aws + gatsby + hasura. I thought this would be great for performance and scale. Fast forward to today, I spend at least 2x as much time to code a feature than if I had just stuck with a simple rails stack, and the scale I imagined never happened. Now rebuilding everything with rails so I can ship faster and focus on growing the product, not making engineeri…

doubling down on premature optimization and chasing the new hotness with a ground-up rebuild... I hope that works out.

The "new hotness" of 2005?

Re: Building GitHub with Ruby on Rails

#168

Post by mousetree » Fri, Apr 07, 2023, 2:12 PM UTC

alberth wrote: post #144

> Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day. That’s a bold move to do as opposed to being end of week or weekend.

Are people still doing major releases on Friday or the weekend?

Re: Building GitHub with Ruby on Rails

#169

Post by weatherlight » Fri, Apr 07, 2023, 2:12 PM UTC

tiffanyh wrote: post #135

samwillis wrote: post #9

GitHub running off the main branch is fascinating, and initially sounds mad, but makes so much sense. Assuming they have very high test coverage, running against mainline Rails isn't really any different to having the fork they had before, but they have more influence on future development. It must also be a massive boon for the Rails ecosystem to have such a large property running off the head. Doesn't anyone know o…

> “It must also be a massive boon for the Rails ecosystem to have such a large property running off the head.” I would have expected Microsoft to focus on developer efforts into speeding up Ruby as a language given they are one of a small few large companies that have deep language/compiler expertise.

It's usually I/O and dDB calls that are the bottle neck, not the speed of the language. Although, Ruby and be a bit of a memory hog,Ii did hear though, that this got better with the new YJIT in Ruby 3.x.

Re: Building GitHub with Ruby on Rails

#170

Post by vidarh » Fri, Apr 07, 2023, 2:17 PM UTC

Alifatisk wrote: post #128

AeroNotix wrote: post #76

Earlier quoted context omitted.

Building for scale from day 0 is a recipe for disaster. You should've seen that coming.

You suggest people should refactor later on when needed?

Cost of capital for a startup that is succeeding is almost always far higher early on, so you want to focus on moving fast over scaling as long as you can scale enough to get to big enough raise to throw far more resources at the problem.