
Why We Chose Rails to Build Gitlab - joelbluminator
https://about.gitlab.com/2018/10/29/why-we-use-rails-to-build-gitlab/
======
yingw787
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 features with fast changing requirements.

~~~
dcosson
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 certain index would take so long to
create, etc.

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. It doesn't actually make things as simple
as they seem at first, and you're on your own to figure out which of its
niceties are actually helpful and which are dangerous to use that you need to
build your own workarounds for.

~~~
noir_lord
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 that the tooling around RDBMS in 2019 is still so shit.

Prime example, try to find a halfway reasonable way to debug a badly written
MySQL sproc you inherited.

~~~
adamson
I’ve used Flywheel ([https://flywaydb.org/](https://flywaydb.org/)) for this
exact problem on personal projects before and been fairly happy with it. It’s
intended for use in JVM-based projects, but ships with a CLI that gets you a
long way.

------
yannovitch
"Ruby was optimized for the developer, not for running it in production," says
Sid. "For the things that get hit a lot and have to be very performant or
that, for example, have to wait very long on a system IO, we rewrite those in
Go … We are still trying to make GitLab use less memory"

Honestly, I think that Go is beginning to be where Rails was few years ago,
and lots of developer friends want to hop on the Go train because everybody is
doing the same.

In the same time, I'm thinking about switching to Gitea or Gogs + Drone.io,
because Gitlab takes just too.damn.much.memory ! Seriously, 8GB RAM to even
just begin with ? (Because yes, 4GB RAM + 4GB Swap is not viable). Even my
biggest website is not consuming as much.

So if I could suggest something, it would be a global rewrite in Go or
something like that, to lower the requirements, not just one or two parts
(excuse me, microservices ;)).

Just my 2 cents

~~~
rapind
Or Elixir, or Rust, or Node. Having spent time with all of these options,
Rails is still really really good for a lot of use cases. Go comes nowhere
near Ruby's readability for me (but I like the lack of surprise).

Personally I'd love something typed, performant, and as readable as Ruby with
a convention focused platform like Rails. Elixir + Phoenix is probably the
closest I can find, but not a perfect fit. Maybe close enough though.

~~~
jamescostian
> Go comes nowhere near Ruby's readability for me

I am not fluent in either, and I'm not looking to change that, but I have read
code in both. I feel the exact opposite way, and I'm not trying to start a war
or anything, but I was wondering if you'd be open to talking about what things
in Go you find hard to read (and what things in Ruby you find very easy to
read). Or is this about libraries (are Go libraries providing lower-level APIs
than Ruby ones?)? Or have you read/written a lot more code in Ruby than Go?

~~~
hazz99
I agree - Go has issues, but they're not related to readability. Perhaps if
you include "familiarity with the standard interfaces" (like using io.Reader)
which is different to other languages, and took a while for me to get used to.

------
altmind
I used to be RoR developer a while ago. Working with gitlab is a breeze
because I can apply all the knowledge I have - by the virtue of being a RoR
app i know how can i apply migrations, how to call interactive console, how to
monitor and clear work queues, how to add middleware. Gitlab using RoR is a
great win for /me/

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

~~~
ambentzen
As an aside, when companies are doing these interview-style pieces are they
actually interviewing the CEO? I always just assume they pull the quotes out
of their ass.

~~~
unilynx
I don't know about other companies, but given that gitlab's CEO is the type to
be regularly active on HN (and will probably be reading this) it seems safe to
assume that he would actively cooperate with such an article

~~~
sytse
Correct, this was an interview with me. We keep a list of topics that might be
a CEO interview [https://gitlab.com/gitlab-com/www-gitlab-
com/issues?scope=al...](https://gitlab.com/gitlab-com/www-gitlab-
com/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name\[\]=CEO%20interview)

If I recall correctly [https://gitlab.com/gitlab-com/www-gitlab-
com/issues/2887](https://gitlab.com/gitlab-com/www-gitlab-com/issues/2887) was
part of a 1 hour interview that generated 4 articles
[https://gitlab.com/gitlab-com/www-gitlab-
com/issues?scope=al...](https://gitlab.com/gitlab-com/www-gitlab-
com/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name\[\]=CEO%20interview)
Great work by our content team.

------
hyfgfh
"Why GitLab are stuck with Ruby on Rails"

~~~
sytse
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...](https://docs.gitlab.com/ee/development/architecture.html#components)
for more information on what parts are Go.

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

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

------
Roritharr
My biggest issue with GitLab is support.

After using it for our test pipelines for a year we've switched to GitLab CI
completely with our deployments and right after we've started running into
issues on our selfhosted instance where for about three weeks now we're
fighting with stuck pipelines where runners won't pick up jobs until you
manually restart them. We've been paying customers for GitLab Enterprise (now
Starter) for years and the recurring theme is that our tickets go unanswered
for basically ever.

We're having performance issues on AWS, trying to run on ECS with an EFS
Filesystem underneath, have basically done everything to rule out the EFS as
the issue and now because our tickets go unanswered migrating to a dedicated
EC2 Instance to see if this makes things run faster...

From a product perspective we're starting to love GitLab, but from a technical
& business pov it's getting increasingly painful to work with if you rely on
it for too much.

I wonder if Ruby is the reason it's hard for them to run reliably as a self-
hostable solution, but as I have 0 Ruby experience I wouldn't know.

~~~
lkozloff
Hi @Roritharr - Support Manager at GitLab here.

I'd like to follow up on this to see where we dropped the ball and how (or if)
we can make things right. Feel free to email me at lyle[at]gitlab.com and I'll
look into your ticket history and move things along.

For others, performance issues with EFS and GitLab have been frequent enough
that we specifically call EFS out in our documentation:
[https://docs.gitlab.com/ee/administration/high_availability/...](https://docs.gitlab.com/ee/administration/high_availability/nfs.html#avoid-
using-awss-elastic-file-system-efs)

This isn't to say that EFS doesn't have its place, it's just that git
operations quickly exhaust burst credits and many of our users on EFS end up
with difficult to diagnose performance problems.

This may or may not have anything to do with @Roritharr's problems, but it's
worth noting!

~~~
Roritharr
Hi, mail is out, if for some reason this doesn't reach you:

Our Ticketnumber is 111794 for the pipeline issue and the other one is 104887
for the Performance Issue.

------
vaer-k
> Ruby was optimized for the developer, not for running it in production,"
> says Sid. "For the things that get hit a lot and have to be very performant
> or that, for example, have to wait very long on a system IO, we rewrite
> those in Go

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.

~~~
inferiorhuman
> 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). Personally I think
that Elixr is an interesting language but it's not one I'd want to mess with
in a production environment.

The big win for Go is that it compiles down to a single binary. Ruby you get a
single point of entry (script with a shebang). But Elixr/Phoenix? You get a
handful of bash (not even POSIX sh!) scripts and binaries and a whole VM to
deploy. As a BSD user, I gave up on Elixr/Phoenix after trying to debug the
nightmarish deployments that had been broken for months. I couldn't tell if it
was an issue in the rat's nest of bash scripts or a VM bug. Sure, ruby-bcrypt
is broken on FreeBSD too with a similar head-in-sand mentality from the bcrypt
gem maintainer (which could make Rails deployments a non-starter) but that's
easy to fix and has been fixed out-of-band. Elixr? Well there's one maintainer
for the deployment tool and he's stopped responding to bug reports of any
sort.

That said, I like Rails. A lot. But ruby is painfully slow and I've learned to
push as much logic into the database as possible. So there's a compelling case
to be made for an alternative. Unfortunately I've never had any other language
give me that much trouble as Elixr has. Personally, I detest Go dependency and
build management (and the Google involvement), but the simplicity of
concurrency and deployment combined with the breadth of the standard library
make a very compelling case for Go IMO. Hell, I would reach for Clojure before
Elixr because at least then you're dealing with the comparatively mature Java
VM.

Personally I've gone down the Rust road, but even then I'm not sure I'd want
to deploy a Rust web app in production just yet (although I really do like
Rocket).

~~~
pdimitar
> _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 they will not do breaking API changes [0]; this
part in particular:

 _" With the release of Ecto 3.0, I would like to announce that I finally
consider Ecto to provide a stable API. This means no more new features,
although we will continue providing bug fixes and updates. For everyone
running Ecto in production, rest assured that Ecto will continue to be a well
maintained project with the same production quality and polish that it has
today."_

So the first part of your statement is factually false.

For ActiveRecord being stable... subjective, I'll give you this much. Try and
migrate a Rails 4.0 app to 5.x and come cry with me over a dozen beers. ;)

> _Personally I think that Elixr is an interesting language but it 's not one
> I'd want to mess with in a production environment._

Many people and organizations are "messing" with Elixir in production with
great -- and increasing -- success.

Phoenix at the moment is one of the very few frameworks that delay your
scalability problems much farther into the future than most me and many others
have worked with. Phoenix can easily give you thousands of requests per second
on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot.

I am not attacking you and I hope I don't sound that way -- but you seem to
have a non-factually supported negative bias against Elixir. It gets more
mature by the day and is quite capable of very serious work in pretty tough
environments. Positive case studies spring into existence often.

[0] [https://elixirforum.com/t/ecto-3-0-is-out-and-stable-
api/173...](https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/17306)

~~~
inferiorhuman
> but you seem to have a non-factually supported negative bias against Elixir.

If deployments are broken for months[1] with no fix in sight, what do you
expect? I'm currently seeing zero requests per second with Elixr. If the sole
maintainer of the sole deployment tool is too disengaged to reply to bug
reports I don't care one way or another what sort of performance a product (or
its fanbase) are claiming. If the product can't be deployed it's not going to
scale. Period.

It's a bit silly to talk performance comparisons between Ruby and Elixr as the
premise of this article was that Ruby is simply too slow. Are you going to
have a harder time scaling Go or Rust than Elixr? I doubt it. I have no idea
if you're going to have a harder time scaling Java than Erlang, but Java is
popular enough in the enterprise space that finding people with that sort of
experience isn't so difficult. The only time I've seen Erlang at scale was
with Megacorp's Enterprise Chef deployment. There was easily tens of thousands
of dollars in hardware there and the Chef server was still regularly brought
to its knees with well less than a thousand total users (and well fewer than
that at any given time).

1:
[https://github.com/bitwalker/distillery/issues/561](https://github.com/bitwalker/distillery/issues/561)

~~~
pdimitar
Open source maintainers burn out. It's a fact of life that's hardly specific
to Elixir though, wouldn't you agree?

As for deployments, I've setup several of them in the last 2 months -- from
scratch, and successfully. There's an initial learning curve that might be way
too annoying for many. The deployment story is one of the weaker parts of
Elixir -- I am not running away from that.

As for scaling, you might be mistaken. Erlang/Elixir can be scaled with almost
zero effort up to 50 or so machines before you need to introduce special
libraries or any extra tooling at all.

Of course, you can do the same with many other languages if you put Kubernetes
or HAProxy in the picture. Point is, with Erlang/Elixir, it is 99% effortless
up to a certain scale which most projects won't ever hit.

If you were talking about raw speed however, I can't argue that Erlang/Elixir
are just a little faster than a very optimized JS (and still plenty faster
than Python, Ruby or PHP). But nobody advocates Elixir for raw number
crunching.

~~~
inferiorhuman
> Open source maintainers burn out. It's a fact of life that's hardly specific
> to Elixir though, wouldn't you agree?

Of course. How many languages have a single deployment story maintained by a
single person though? That level of fragility is something I wouldn't put in
production. Period. Not even on Linux.

And, yes, you could just compile the app in production (and watch the security
team lose their shit). Or you can blow everything away for each deployment. Or
you could use a tool that's simply less tedious to deploy (e.g. Rust, Go,
Java, Clojure, ClojureScript, Javascript).

To put it another way, if deploying is a pain, scaling is a pain.

~~~
pdimitar
> _To put it another way, if deploying is a pain, scaling is a pain._

I can't understand that argument. Would you please expand?

\---

I agree it doesn't look very trustworthy that the only viable deployment
option in Elixir is kind of stalled lately. Of course. What I am saying is,
what we have at the moment works plenty well -- if you can get over the fact
that enabling deployment in an Elixir app is needlessly complex.

As is said many times here in HN, judging an open-source project by its
frequency and recency of commits is quite a flawed strategy.

~~~
inferiorhuman
> I can't understand that argument. Would you please expand?

See the Github issue linked (and the related issues). Distillery is known
broken. Who cares if Elixr or Erlang scales really well if you can't even get
it deployed? That Distillery is, for all intents and purposes, abandoned is
secondary. It wasn't left in a usable state.

~~~
pdimitar
I agree it doesn't look well but you simply can't claim that Distillery is
broken. The last stable version works just fine.

Interesting to see an outside take on the situation though. Thank you.

 _(EDIT: Also, in the issue it 's pointed out that a newer Erlang OTP release
fixes the problem.)_

~~~
inferiorhuman
Uh, there's also a suggestion that setting NODE_NAME will fix the solution.
Unfortunately the issue remains open because Distillery has been abandoned in
a non-working (which, by definition, is broken) state.

I would compare Elixr to Go, Java (OpenJDK), Javascript (node) and Rust here.
All have passive support for the BSDs, and yet all three have actively
maintained native packages (rustup and/or ports tree). That neither the
Distllery author nor the BSD users have managed to come up with a solution is
quite telling — deployments on Elixir are nightmarishly complex. I'm most
familiar with Rust, so in contrast if you look at the the BSD specific issues
you'll find a very engaged userbase.

Deploying unmaintained software in production is sometimes a necessity with
legacy stuff but is almost always a bad idea for new deployments. Elixir has
plenty of passionate advocates but no good deployment or support stories.
That's just a long-winded way of saying Elixir/Phoenix, unfortunately, aren't
things I would be comfortable deploying in production (Linux or not) no matter
how many compelling ideas they dangle in front of you. And, as has been
pointed out, Elixr doesn't offer significant (if any performance benefits)
over modern Ruby (and by extension Java, Go, or Rust).

vOv

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

~~~
mustardo
[https://kotlinlang.org/](https://kotlinlang.org/)

------
richardwhiuk
> Because GitHub did.

Which was because two of the co-founders met at a Ruby meetup.

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

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

~~~
sytse
Ah, thanks for explaining.

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

~~~
freehunter
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 solution.

But you don't read blog posts about those companies because they choose not to
write them. The blog posts you see about the backend technologies are from
companies who are proud to use those technologies and want to promote their
use of that technology. The companies who use Java (mostly) are companies who
aren't going to write blog posts about their backend technology choices.

~~~
darkr
I used to hate Java, but years of experience later, I would gladly inherit a
well maintained/architected and modern Java codebase over anything written in
Python or Ruby (even a well maintained one)

~~~
postalrat
So the only thing you would trade ruby or python for is something that doesn't
exist.

~~~
darkr
Oh but it does. And even when it’s not great, it’s usually a less horrendous
task to refactor into something better.

~~~
zbentley
That, actually, is one of the the largest selling points of Java as a
platform: when it's bad, it's not that bad, and even when it is, the tools to
clean it up are better than anyone else's.

------
joelbluminator
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?

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

~~~
joelbluminator
I agree, PHP is more than viable to build companies, and has proved it again
and again. As did Ruby :) The fact that PHP isn't my favorite language is
really besides the point. Those vocal Ruby/Elixir/Go/Node enthusaists who crap
all over other battle tested stacks are very immature individuals.

------
btmiller
I really enjoy Gitlab's UI/UX, but I wish it were easy to manage a self-hosted
Gitlab presence. The architecture diagrams[1] frankly read as supporting
justification to go with the hosted solution.

[1]
[https://docs.gitlab.com/ee/development/architecture.html#com...](https://docs.gitlab.com/ee/development/architecture.html#components)

~~~
ownagefool
It's fairly easy to host in my opinion.

Either you use the omnibus installer for a single server, or the helm chart
for a distributed kubernetes install.

------
SilverSlash
Because Rails was all the hype in 2011?

------
choadrocker
i just assumed it was becasue "we didnt know better"

------
dominotw
because it was the "the thing" at that time, just admit it.

------
elephantum
It's amusing, that you can substitute every reference from Ruby to Python and
Rails to Django and article would still make sense.

Except for the part about running in production. Seems like Python is a bit
ahead there.

------
pwaivers
This really strangely sounds like an advertisement for Ruby on Rails. It
doesn't even give any specific advantages of RoR.

> _If you look at GitLab, it has an enormous amount of functionality. Software
> development is very complex and to help with that, we need a lot of
> functionality and Ruby on Rails is a way to do it._

You could say this about almost any framework.

