Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building GitHub with Ruby on Rails

github.blog

Post reply on HN
Print view View original

41–50 of 332 posts

Re: Building GitHub with Ruby on Rails

#41

Post by wg0 »

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…

I have yet to see a tech stack that's not locked up into a framework version.

That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top.

And yes, have seen Django shops locked into 0.9x release patched right into the core and running for a very long time, impossible to upgrade and all the horror stories.

EDIT: Added Django

Re: Building GitHub with Ruby on Rails

#42

Post by charcircuit »

jack_riminton wrote: post #31
Zanfa wrote: post #16

It's been interesting looking into their "leaked" source to see how the application is architected. It's surprisingly accessible given the overall size.

Do you have a link? Sounds interesting

He's probably just referring to the self hosted version of Github.

https://enterprise.github.com/trial

Re: Building GitHub with Ruby on Rails

#43

Post by winrid »

wg0 wrote: post #40
winrid wrote: post #19

Earlier quoted context omitted.

I imagine it wouldn't be too hard, since Django only has one dependency - Django itself (NodeJS developers weep). Is rails the same way dependency wise?

That's not correct. Django isn't independent, depends on lot many packages but that's not the issue. Issue is the frameworks own Interface: Existing Interface getting removed OR behavior or defaults changing for an already existing Interface. That's usually the upgrades are about.

Yes the framework's interface can change. But this is usually a piece of cake compared to hundreds of disjoint libraries and leaky abstractions that would be in use in the Node world.

Re: Building GitHub with Ruby on Rails

#44

Post by danjac »

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…

I remember working on projects that did this in the early days of Django, particularly when there were badly needed features that took too long to land in the stable release.

Nowadays most projects I've seen use the latest stable release or at least the latest LTS - maybe some legacy projects lagging behind.

Re: Building GitHub with Ruby on Rails

#45

Post by Gasp0de »

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.

If anything that's a fault in the Frontend though, which is not what the article is about, right?

Re: Building GitHub with Ruby on Rails

#46

Post by mo_po2 »

Going a bit of topic, Arch Linux does mostly the same, and thanks to it all of its users are direct testers/reporters of unpatched projects, with the exception of a few minor patches related to chore in projects that don't allow to customize it (mostly paths). I guess that this has probably improved the overall health of Linux beyond Arch itself during the last 2 decades for similar reasons to the ones provided in this article.

Re: Building GitHub with Ruby on Rails

#49

Post by danielheath »

winrid wrote: post #19
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…

I imagine it wouldn't be too hard, since Django only has one dependency - Django itself (NodeJS developers weep). Is rails the same way dependency wise?

Rails has dependencies, but not like node apps; last time I counted create-react-app vs a new rails app, there was nearly 10x as many distinct maintainers with access to push new releases to the default dependency tree.

I consider that a better measure of dependency risk than absolute count, since different ecosystems have different ideas about how large a library should be.

Re: Building GitHub with Ruby on Rails

#50

Post by black3r »

procinct wrote: post #32
winrid wrote: post #19

Earlier quoted context omitted.

I imagine it wouldn't be too hard, since Django only has one dependency - Django itself (NodeJS developers weep). Is rails the same way dependency wise?

Wait is this true? Doesn’t it also use SQLAlchemy at least? Which then likely has its own dependencies? I’d be really surprised if Django had no dependencies at all.

Django doesn't use SQLALchemy, they have their own ORM system. And it's true that Django used to have 0 real dependencies (now it has 2), but even now many of its "optional builtins" do require some additional external packages, and some of them are really useful.

For example you need an external package to use builtin postgresql, mysql or oracledb support. You need tblib to run tests in parallel using the built-in test runner. You need external packages to use argon2 or bcrypt as password hashers in the builtin auth system, and I'm sure there are others, since Django is very much batteries included, but modular.

The modularity also means you can also use any 3rd party database, use pytest to run tests, make your password hashing on your own, ... so I can understand that these are not listed as dependencies on pypi, but I don't really like that I have to list packages I don't directly import in my code as direct dependencies...

Post reply on HN