Live data from Hacker News

Why We Chose Rails to Build Gitlab

about.gitlab.com

21–30 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#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 features with fast changing requirements.

Re: Why We Chose Rails to Build Gitlab

#23

Earlier quoted context omitted.

What would you prefer?

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

The advantages of some particular insight into a business problem far outweigh the particulars of programming languages, for most problem domains.

Re: Why We Chose Rails to Build Gitlab

#24

Earlier quoted context omitted.

What would you prefer?

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

We're coming dangerously close to holy war territory here. I don't think that assumption holds true in your average web app.

Re: Why We Chose Rails to Build Gitlab

#25

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

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.

Re: Why We Chose Rails to Build Gitlab

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

Re: Why We Chose Rails to Build Gitlab

#27
post #2

"Why GitLab are stuck with Ruby on Rails"

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.

Re: Why We Chose Rails to Build Gitlab

#28
post #23

Earlier quoted context omitted.

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

The advantages of some particular insight into a business problem far outweigh the particulars of programming languages, for most problem domains.

If you’re in the business of developing enterprise apps (and that’s where the money for dev tools resides) then moving quickly without breaking things is critical in your formative years. Static typing goes a long way to facilitate that.

It’s by no means a panacea but it does eliminate an entire class of error and obviate a related class of unit testing.

Re: Why We Chose Rails to Build Gitlab

#30
post #10

Earlier quoted context omitted.

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

Would you be able to give an example or two where you would reach for go vs elixir and vice-versa? I’ve tinkered with Go, and while it was fairly enjoyable to work with on the small scale, but the lack of generics and constant err != nil checks, and Go 2 on the horizon, I decided to hold off on building anything non-trivial with it. I’m currently rewriting a Rails app into smaller elixir components, the Rails app is…

Sure, here's a few, personal opinions:

- Some programmers don't like functional programming (I'm not one of them)

- Go has static typing and I find it really cuts away bugs

- Go is backed by giants and has the horse power to push forward regardless of "Github stars"

- Go is easy to compile and run on most/many platforms

- I find myself more able to understand third party code

As a web developer, would I use Go as opposed to Phoenix/Elixir? Yes, I am actually using it in production on a fairly big project [1]. I tried Phoenix and I found it "weird" for my liking. The authentication part of a web app was a real deal-braker for me = too complicated to implement (not bad, just too complicated).

I'm the type of guy that brainstorms (90% of my projects are always "close to completion" though) a lot of ideas and wants to go up and running really fast. I can't do that with Python/Elixir/Ruby without many tests written because I don't trust the code/myself all that much.

Where would I use Elixir/Phoenix:

- a chat/support app or anything that relies heavily on websockets

- real-time apps (related to first point)

- apps that rely heavily on distributed tasks

[1] https://typely.com

Post reply on HN