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

81–90 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#81

Post by pdimitar »

inferiorhuman wrote: post #68
pdimitar wrote: post #62

Earlier quoted context omitted.

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

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

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.

Re: Why We Chose Rails to Build Gitlab

#82

Post by majewsky »

stock_toaster wrote: post #56
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 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.

Re: Why We Chose Rails to Build Gitlab

#83

Post by sytse »

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…

GitLab is using a lot of memory for various reasons, all of the big ones (like adding multi-threading which I proposed 3 years ago https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 ) can be solved without a rewrite. I've failed to make this a priority within the company. We had people work on it for some time but the day to day of shipping features, keeping GitLab secure, and other tasks took over. I'll advocate for a dedicated performance team to solve this. Until that team is formed people like Stan are making steady progress https://news.ycombinator.com/item?id=18973499

Re: Why We Chose Rails to Build Gitlab

#84

Post by Legogris »

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…

If we're talking memory usage, I don't think Node is necessarily a significant improvement over Ruby.

Re: Why We Chose Rails to Build Gitlab

#85

Post by sytse »

unilynx wrote: post #14
ambentzen wrote: post #12

Earlier quoted context omitted.

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.

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

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

If I recall correctly 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... Great work by our content team.

Re: Why We Chose Rails to Build Gitlab

#86

Post by yannovitch »

sytse wrote: post #83
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…

GitLab is using a lot of memory for various reasons, all of the big ones (like adding multi-threading which I proposed 3 years ago https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 ) can be solved without a rewrite. I've failed to make this a priority within the company. We had people work on it for some time but the day to day of shipping features, keeping GitLab secure, and other tasks took over. I'll advocate fo…

Thanks, VERY much appreciated !

Re: Why We Chose Rails to Build Gitlab

#87

Post by nothrabannosir »

rrix2 wrote: post #22
woolvalley wrote: post #18

Earlier quoted context omitted.

The advantages of typed languages are too great to not work in them.

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

Re: Why We Chose Rails to Build Gitlab

#88

Post by [deleted] »

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…

[deleted]

Re: Why We Chose Rails to Build Gitlab

#89

Post by anonyfox »

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…

Crystal it is. Combined with the amber framework, porting the Ruby Code should be straightforward. Yes stuff isnt even 1.0 yet, but I would seriously bet on it right now.

Re: Why We Chose Rails to Build Gitlab

#90

Post by inferiorhuman »

pdimitar wrote: post #81
inferiorhuman wrote: post #68

Earlier quoted context omitted.

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

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

Post reply on HN