Live data from Hacker News

Why We Chose Rails to Build Gitlab

about.gitlab.com

41–50 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#41

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…

https://github.com/diesel-rs/diesel

This type checks all ORM operations, and type checks against the actual schema at compile time. It's pretty cool and made by one of the long-time developers of ActiveRecord.

Re: Why We Chose Rails to Build Gitlab

#42

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…

Analog in python: https://docs.djangoproject.com/en/2.2/topics/migrations/

Re: Why We Chose Rails to Build Gitlab

#43
post #5

Earlier quoted context omitted.

quite a big gap between Elixir & Go though for most use cases.

I don't disagree, but Im curious of the ones you're referring to

Not OP, but I've been interested in both technologies for a while. Elixir with Phoenix feels like modern RoR, so it's probably best suited for startups that want to build their products fast and want to scale easily and cheaper.

IMO Go is perfect for big companies and somewhat middle companies where they have some heavy traffic that needs to be addressed. I guess Golang is also easier to start with and craft something very fast as opposed to Elixir. (You can check multiple topics on elixirforum.com where people ask why their first-iteration code is slower than that in ruby/python.)

I can be wrong, but I haven't found any golang opinioned-matured web framework, because most of the community is okay with building from the ground up. This may suggest that golang would be preferable in complex/enterprise systems?

I'd choose Elixir for something that has to be done fast and be reliable and open for a lot of modifications that can be introduced without sweating.

My point of view is based on building some simple product in Elixir and doing research. Also, a previous company I worked for had Golang and Ruby stack.

Re: Why We Chose Rails to Build Gitlab

#44
post #38

Earlier quoted context omitted.

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…

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)

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

Re: Why We Chose Rails to Build Gitlab

#45

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

Re: Why We Chose Rails to Build Gitlab

#46
post #26

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…

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.

Re: Why We Chose Rails to Build Gitlab

#47
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). 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).

Re: Why We Chose Rails to Build Gitlab

#48
post #32

> Because GitHub did. Which was because two of the co-founders met at a Ruby meetup.

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.

Re: Why We Chose Rails to Build Gitlab

#49

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…

The activerecord-migrations gem allows you to use Rails migrations with other languages too—I’ve used it with node, clojure, and others where the community migration libs aren’t as good.

Re: Why We Chose Rails to Build Gitlab

#50

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

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.

Post reply on HN