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

91–100 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#91

Post by johannes1234321 »

Iwan-Zotow wrote: post #71
mrath wrote: post #16

Earlier quoted context omitted.

mostly in the industry (finance) I work Java is the default. You need to justify and seek approvals for using anything else.

even things like scala or kotlin?

I'm not in that industry, but in general yes, even other JVM languages, since one of the reasons is that using a common language makes it simpler to move people between projects. If there is a sole kotlin developer or small group of kotlin devs and they leave it's harder to replace. Also integrating new members coming frommother teams is harder. The more architectures, libraries, coding styles, ... are standardized the higher are the chances that others can take over which is beneficial even if individual productivity might be lower.

Re: Why We Chose Rails to Build Gitlab

#92

Post by sytse »

pdimitar wrote: post #76
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.

To me, the article reads like "We REALLY don't want to abandon Rails so we rewrite the hot paths to Go". I mean no offense; I just wasn't able to find good argumentation in it for sticking with Rails. To me, the article kind of makes the argument for Go. "Developer productivity" is not a myth and it does exist. But Rails is very far from the only framework that gives you that. IMO you should seriously evaluate making…

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!

Re: Why We Chose Rails to Build Gitlab

#93

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

Re: Why We Chose Rails to Build Gitlab

#94

Post by hazz99 »

rapind wrote: post #69
yannovitch wrote: post #58

"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 trai…

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 clo…

Is there a benefit learning Elixir over Erlang? I've working a little bit with Erlang, and I've wondered if its worth the jump.

Re: Why We Chose Rails to Build Gitlab

#95

Post by sytse »

vaer-k wrote: post #3

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

We are watching Elixir closely ever since visiting Krakow, Poland for the Railsberry conference in 2013. This is also where my co-founder Dmitriy and I first met in real life.

As for the reasoning please see https://news.ycombinator.com/item?id=18973348

Re: Why We Chose Rails to Build Gitlab

#96

Post by d3sandoval »

slobotron wrote: post #45
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…

Another option is Sqitch. It's database and framework agnostic. https://sqitch.org/ Postgres Tutorial: https://metacpan.org/pod/sqitchtutorial

Came to this thread to suggest squitch. Glad it's mentioned here. I really enjoy it's three generic concepts - deploy, verify, revert - and not having to tie my migrations to any particular language or ORM. In additon, it's supported on every operating system I've used with it and has got a docker image in case that's not good enough.

Re: Why We Chose Rails to Build Gitlab

#97

Post by jamescostian »

rapind wrote: post #69
yannovitch wrote: post #58

"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 trai…

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 clo…

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

Re: Why We Chose Rails to Build Gitlab

#98

Post by dieblur »

sytse wrote: post #92
pdimitar wrote: post #76

Earlier quoted context omitted.

To me, the article reads like "We REALLY don't want to abandon Rails so we rewrite the hot paths to Go". I mean no offense; I just wasn't able to find good argumentation in it for sticking with Rails. To me, the article kind of makes the argument for Go. "Developer productivity" is not a myth and it does exist. But Rails is very far from the only framework that gives you that. IMO you should seriously evaluate making…

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

Re: Why We Chose Rails to Build Gitlab

#99

Post by pdimitar »

inferiorhuman wrote: post #90
pdimitar wrote: post #81

Earlier quoted context omitted.

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 mist…

> 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 c…

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

Re: Why We Chose Rails to Build Gitlab

#100

Post by dam5s »

majewsky wrote: post #82
stock_toaster wrote: post #56

Earlier quoted context omitted.

I personally tend to prefer migrate[1] as it doesn't require java. [1]: https://github.com/golang-migrate/migrate

Migrate is awesome! My only issue: Since it uses bare SQL for the migrations, you have to do some lifting if you need to support multiple RDBMS with different DDLs. I have some regexes in my project to translate Postgres DDL into SQLite DDL for my test suite.

Why would you not test your code with the same RDBMS you will have in production? Especially if it’s something as easy to install as Postgres? It seems like begging for trouble...
Post reply on HN