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

111–120 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#111

Post by lixtra »

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…

> As is so often the case in Rails, it's set up to be nice and simple for a hello world example but little more.

This is just wrong. Rails works very well for 90% of the situations. When it stops working that’s great news:

You’ve won!

You’re Twitter, Facebook or the next big thing. You’ll find talent and money to replace your rails app.

Re: Why We Chose Rails to Build Gitlab

#112

Post by purple_ducks »

freehunter wrote: post #25
ppeetteerr wrote: post #8

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

Yes. I work for a company that used to build almost everything in Java and people are constantly asking why the hell we used Java for it and we're constantly apologizing and saying how quickly we're moving to a more modern solution. Before this, I worked for a company that build almost everything in Java and we had to constantly explain why things were in Java and what we were doing to move things to a more modern so…

> we're moving to a more modern solution

What exactly qualifies as a modern solution that Java(/jvm?) is disqualified?

Syntax, library eco-system, paradigm, type system, cruft? Is "modern solution" some function of blog post count? A social blade type score for how many early-20 somethings are using it?

Or is it going to be something "simplistic" & "clear" which will eventually inherit the cruft all other large languages do?

Re: Why We Chose Rails to Build Gitlab

#113

Post by Roboprog »

Dirlewanger wrote: post #61
ppeetteerr wrote: post #8

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

It's nitpicky, but Java is just so fucking ugly and verbose. Does Kotlin extend beyond the Android ecosystem? I'd totally consider that if the case.

Kotlin runs on the standard JVM, not just android.

Re: Why We Chose Rails to Build Gitlab

#114

Post by Scarbutt »

dieblur wrote: post #98
sytse wrote: post #92

Earlier quoted context omitted.

I think a rewrite in Go would greatly increase our line-count. I think Elixir is very interesting but Phoenix still has some way to go before the ecosystem matches that of Rails. Our Gemfile.lock https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile.... is more than 1000 lines!

Line-count really isn't a great way to measure developer productivity either though...

It does measure bug count though.

Re: Why We Chose Rails to Build Gitlab

#115

Post by Roboprog »

I find the whole library/framework existing functionality thing to be vastly overrated. There’s a certain minimum you need, but once you hit it, OK.

For me, what I liked about Ruby when I played with it years ago was how expressive and concise the language was. There is joy in NOT having to read through a mountain of drivel when you go to dive in and maintain a feature.

I realize I am in a minority, though. Most of the industry seems to insist that we are doomed, DOOOOMED (!!!), without static types, no matter what the cost to have them. For me, mutable data seems like a much bigger evil and impediment to comprehension than dynamic types. Of course, to have something that had types and type inference, but also allowed dynamic types with minimum ceremony would be nice. Maybe someday (but until Typescript groks partial function application, and maybe type inference of object literals, that’s not yet the answer)

Anyway, back to work on a big fugly mountain o Java code...

Re: Why We Chose Rails to Build Gitlab

#116

Post by Scarbutt »

pdimitar wrote: post #62
inferiorhuman wrote: post #47

Earlier quoted context omitted.

> Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if they considered it. The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community). Ecto is still going through some massive changes (ActiveRecord is comparatively stable). Persona…

> The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community) What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind. > Ecto is still going through some massive changes (ActiveRecord is comparatively stable) As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said…

Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot.

Phoenix doesn't hold a candle to anything JVM or Golang though: https://www.techempower.com/benchmarks/

Re: Why We Chose Rails to Build Gitlab

#117

Post by Xeronate »

sytse wrote: post #27
hyfgfh wrote: post #2

"Why GitLab are stuck with Ruby on Rails"

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.

Re: Why We Chose Rails to Build Gitlab

#118

Post by jashmatthews »

ambentzen wrote: post #9

No offense, but this is just a really weak PR fluff piece. The with only interesting thing is that they use Go for the hit access part. Oh, and Ruby and multithreading don’t mix, who knew? I like that if you preface your offending remarks with “no offense” you’re excused.

> Oh, and Ruby and multithreading don’t mix, who knew?

Modern Ruby has great support for threading. Rails has been threadsafe since 2008 and Ruby has a huge advantage over Python in JRuby: no GIL, JIT, parallel GC etc.

Re: Why We Chose Rails to Build Gitlab

#119

Post by sytse »

pdimitar wrote: post #109
sytse wrote: post #107

Earlier quoted context omitted.

I agree Go produces great software. But for the same amount of functionality it tends to require more lines than ruby. I tend to favor the more expressive language http://www.paulgraham.com/avg.html Another thing is that there isn't a web framework like Rails in Go. Although I'm keeping an eye on go-micro and we plan to add that as a template soon.

Yeah, fully agreed on that. Go just doesn't have as productive a framework like Rails. That's why I only use it for very small websites or even smaller API gateways. Or CLIs. Or network daemons. I am not disputing your choices. Just wanted to give you the quick and intuitive (and likely misinformed) immediate reaction that I had from the article. Keep making GitLab awesome. <3

Thank you! <3

Re: Why We Chose Rails to Build Gitlab

#120

Post by sytse »

richardwhiuk wrote: post #48
sytse wrote: post #32

Earlier quoted context omitted.

I can't find the quoted part in the article. Anyway, we met online a year after GitLab started, so by the time we met it was already decided to many it in Ruby.

Sorry, I paraphrased as part of forming a TLDR - the actual article is much more loquacious > Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time. GitHub, a source of inspiration for GitLab, was also based on Rails, making it a logical pick considering his interest in the framework. By co-founders, I meant why GitHub chose RoR, not GitLab.

Ah, thanks for explaining.
Post reply on HN