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

131–140 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#131

Post by jashmatthews »

inferiorhuman wrote: post #47
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…

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

> But ruby is painfully slow and I've learned to push as much logic into the database as possible.

Since you said you like Rails, have you tried using Ruby with Sequel instead of AR? AR is incredibly convenient but performance isn't a strong point.

Re: Why We Chose Rails to Build Gitlab

#132

Post by Roritharr »

lkozloff wrote: post #104
Roritharr wrote: post #93

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

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

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.

Re: Why We Chose Rails to Build Gitlab

#134

Post by Roboprog »

amm wrote: post #78
ppeetteerr wrote: post #8

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

It depends on the project. Java is the goto language in more conservative environments (e.g. insurance, banking, government) and I never had to justify using it there. In small shops/startups it’s different. Hype is a real thing and running your backend on “25 year old tech” often does not attract the right kind of people you need to have in this space ;^). That being said, I’ve been shipping stable and performant ba…

I don’t understand why you got voted down.

I don’t have the enthusiasm for Java I did 20 years ago (the alternate for employment in Sacramento was largely C++ back then, mind you), but I think what you said is accurate.

Personally, I want to see Java retire, but downvoting people who are pointing out legitimate benefits, even if there are counter points to be made, seems rude.

Re: Why We Chose Rails to Build Gitlab

#135

Post by james-mcelwain »

dam5s wrote: post #100
majewsky wrote: post #82

Earlier quoted context omitted.

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

If you're using an ORM, it can be an easy way to ensure that no vendor specific stuff sneaks in. Also, until recently it was difficult to run, e.g., SQL Server in Docker, so Postgres might be easier to test with. Agreed SQLite is a weird choice, but not all integration tests are robust enough to test characteristics of the underlying db, i.e. focus on business logic not performance.

Re: Why We Chose Rails to Build Gitlab

#136

Post by mustardo »

Roboprog wrote: post #115

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

https://kotlinlang.org/

Re: Why We Chose Rails to Build Gitlab

#137

Post by jjeaff »

lixtra wrote: post #111
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…

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

I'm having trouble understanding how one could run into a bottleneck only after you reach Facebook or Google or levels. Surely if you have performance issues when you are running on 10,000 machines, you would also have a bottleneck when you start to outgrow your single machine.

Re: Why We Chose Rails to Build Gitlab

#138

Post by jjeaff »

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/

Also laravel and CodeIgniter for PHP.

Re: Why We Chose Rails to Build Gitlab

#139

Post by hopler »

jjeaff wrote: post #137
lixtra wrote: post #111

Earlier quoted context omitted.

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

I'm having trouble understanding how one could run into a bottleneck only after you reach Facebook or Google or levels. Surely if you have performance issues when you are running on 10,000 machines, you would also have a bottleneck when you start to outgrow your single machine.

Why would you need more than a single machine to serve a request? You need multiple machines to serve many requests concurrently.

Re: Why We Chose Rails to Build Gitlab

#140

Post by evanelias »

mythrwy wrote: post #46
mey wrote: post #26

Earlier quoted context omitted.

I suggest checking out https://flywaydb.org/ It doesn't have the ORM-ness mapping rails migrate does, but it makes it really simple to organize sql scripts to move/update schema configs.

I sometimes suspect a folder full of sql scripts would be better than black box migrations (which are a folder full of sql scripts or similar anyway). Migrations are great, until they aren't. Sometimes if you actually manually do the thing you know how it works better and can adjust. I suppose the drawback to that is everyone else doesn't.

Another option is a schema management tool that doesn't rely on migrations at all. I'm the author of one, Skeema [1], for MySQL/MariaDB. Others include migra [2] for Postgres, and sqldef [3] for MySQL or Postgres.

These all use a declarative approach [4], where the user just specifies the desired new state, by adding or changing the set of CREATE statements. The tool knows how to run the correct DDL to reach that new state.

[1] https://github.com/skeema/skeema

[2] https://github.com/djrobstep/migra

[3] https://github.com/k0kubun/sqldef

[4] https://www.skeema.io/blog/2019/01/18/declarative/

Post reply on HN