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

Why We Chose Rails to Build Gitlab

about.gitlab.com

Post reply on HN
Print view View original

141–150 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#141

Post by dagoat »

dcosson wrote: post #67
yingw787 wrote: post #21

What I really liked about Ruby on Rails when I took an online course on it were the schema.rb files and `rake db:migrate` command. I don't know if there's an analog in Python, but honestly I think clean, highly structured, maintainable data is way more important than the backend you use. Having the ability to quickly iterate your SQL schemas and roll them back as necessary is essential to shipping high quality featur…

Just wait til you actually work on some production code... For the most part you don't actually want to roll back schemas as you would lose data. And iterating on SQL schemas in a live app involves all kinds of tricky edge cases and backfills, knowing when to make your changes in multiple steps, being careful not to take down the whole thing because you didn't realize a certain change required a full table lock or a…

> For the most part you don't actually want to roll back schemas as you would lose data

Can you name a framework where you roll back schema changes and don't lose data?

> being careful not to take down the whole thing

You still need this caution if you don't use rails

> a certain change required a full table lock or a certain index would take so long to create, etc.

I feel like you're just describing working with a relational database in a production setting. This isn't rails specific

> Rails, it's set up to be nice and simple for a hello world example

Sure. I'm also pretty sure it's used in production by some great companies whose applications/APIs are a pleasure to use - SendGrid, Github, Stripe, and last time I checked Hulu to name just a few.

Just because it's not the framework of choice for the majority of companies doesn't make it incapable of being used at scale.

Re: Why We Chose Rails to Build Gitlab

#142

Post by FrancoisBosun »

noir_lord wrote: post #101
dcosson wrote: post #67

Earlier quoted context omitted.

Just wait til you actually work on some production code... For the most part you don't actually want to roll back schemas as you would lose data. And iterating on SQL schemas in a live app involves all kinds of tricky edge cases and backfills, knowing when to make your changes in multiple steps, being careful not to take down the whole thing because you didn't realize a certain change required a full table lock or a…

Or you inherit a DB that’s a complete disaster scheme wise and all the nice assumptions go out the window. I’ve mostly found that migrations work best as a structure way to just run normal SQL and know a) what ran b) when. For that they are handy. I’ve even considered how to structure a stand alone migration running tool with a nice API since the good ones for each language tend to be fairly different. It annoys me t…

Sqitch by David Wheeler is a great way to manage database schemas. I haven’t uses it in production, because I mostly use Rails and haven’t felt enough pain to justify the switch.

https://sqitch.org

Re: Why We Chose Rails to Build Gitlab

#143

Post by Scriptor »

Xeronate wrote: post #117
sytse wrote: post #27

Earlier quoted context omitted.

As listed in the article under 'Overcoming challenges' we do replace code in Go and Vue where needed. I do believe Rails is still the most productive framework out there. See https://docs.gitlab.com/ee/development/architecture.html#com... for more information on what parts are Go.

Serious question. Why do so many companies choose to rewrite in Go? I tried to like it, but it just felt so painful to use.

It seems that every few years a new backend language comes to the forefront and becomes a popular for greenfield projects or rewrites. First people moved from PHP to Ruby, then Node, and now Go.

Of course, Go's popularity is helped a great deal by Google using it, as well as the huge amount of devops software written in Go (docker, terraform, kubernetes). But at some point the hype for those will settle and they'll just become more tools. At the same time there'll be more and more legacy Go projects at various companies that won't be very exciting. Around about this time we'll probably see the next language start rising in popularity.

Re: Why We Chose Rails to Build Gitlab

#145

Post by AnthonBerg »

nothrabannosir wrote: post #87
rrix2 wrote: post #22

Earlier quoted context omitted.

And yet large swaths of our profession choose to do so every day

Yes, otherwise we wouldn't be talking about it. That doesn't mean their parallel universe images who chose a statically typed equivalent, ceteris paribus , aren't better off. "Lots of people do it so it must be fine," has to be the weakest form of argument I know. Which is funny, because lots of people use it. Hmm...

I took it as rrix2 were pointing out a tragedy :)

Re: Why We Chose Rails to Build Gitlab

#146

Post by nothrabannosir »

AnthonBerg wrote: post #145
nothrabannosir wrote: post #87

Earlier quoted context omitted.

Yes, otherwise we wouldn't be talking about it. That doesn't mean their parallel universe images who chose a statically typed equivalent, ceteris paribus , aren't better off. "Lots of people do it so it must be fine," has to be the weakest form of argument I know. Which is funny, because lots of people use it. Hmm...

I took it as rrix2 were pointing out a tragedy :)

That’s a far better way of looking at it. I now regret not having seen it that way.

I guess you see what you want to see :(

Re: Why We Chose Rails to Build Gitlab

#147

Post by throwaway9d0291 »

Osmose wrote: post #34
yingw787 wrote: post #21

What I really liked about Ruby on Rails when I took an online course on it were the schema.rb files and `rake db:migrate` command. I don't know if there's an analog in Python, but honestly I think clean, highly structured, maintainable data is way more important than the backend you use. Having the ability to quickly iterate your SQL schemas and roll them back as necessary is essential to shipping high quality featur…

Migrations are rad! Django (the Python equivalent of Rails) has had built-in migrations for several years now: https://docs.djangoproject.com/en/2.1/topics/migrations/

And long before that, it had South: https://south.readthedocs.io/en/latest/about.html

Re: Why We Chose Rails to Build Gitlab

#148

Post by olavgg »

ppeetteerr wrote: post #8

Does anyone ever have to justify using Java for their backend?

Not at all, with Hibernate, Spring, Groovy, building web applications is much faster and more maintainable than other alternatives.

I am a huge fan of the Grails framework, they do a lot of things right. As a developer I can focus on creating business value as most technical challenges are easily solved with Grails. Grails is performant and memory efficient. With Grails 4 which will be released later this year, memory usage will decrease significantly more.

Re: Why We Chose Rails to Build Gitlab

#150

Post by pry86 »

joelbluminator wrote: post #149

Haters gonna hate. Shopify, Stripe, Github, Gitlab, AirBNB, Fiverr, Bloomberg, Hulu, Kickstarter, Deliveroo, Zendesk, New Relic, etc etc etc. How many more companies does it take to prove the point that Ruby/Rails is a viable option to base a company on?

Same with PHP and its frameworks (lots of haters comes from RoR side, isn't it?) So let's leave this aside :)
Post reply on HN