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

31–40 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#31

Post by drawkbox »

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…

Python SQLAlchemy/Alembic and Django has db/schema migrations.

.NET has db/schema migrations in Entity Framework.

Node/javascript has sequelize/umzug, node-db-migrate and others for db/schema migrations.

Migrations are pretty common now for ORMs, or any code first schemas, but are definitely a killer feature and needed with ORMs to see what is being changed/iterated on.

Re: Why We Chose Rails to Build Gitlab

#34

Post by Osmose »

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/

Re: Why We Chose Rails to Build Gitlab

#35

Post by pwaivers »

This really strangely sounds like an advertisement for Ruby on Rails. It doesn't even give any specific advantages of RoR.

> If you look at GitLab, it has an enormous amount of functionality. Software development is very complex and to help with that, we need a lot of functionality and Ruby on Rails is a way to do it.

You could say this about almost any framework.

Re: Why We Chose Rails to Build Gitlab

#36

Post by lettergram »

sytse wrote: post #27
hyfgfh wrote: 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.

I’ve utilized inline C quite a few times to replace sections of code. Specifically to do some of the server side computations for my applications:

e.g. https://hnprofile.com

The full system is built in rails and I query and generate information on a million or so accounts and tens of millions of comments. Haven’t really hit a bottleneck yet.

Re: Why We Chose Rails to Build Gitlab

#37

Post by orwin »

cutety wrote: post #10
tschellenbach wrote: post #4

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…

I wrote a small supervisord ripoff in go just after its launch, it was at the same time frustrating and enjoyable. I will have a week off in less than a month, do you think i should build a similar elixir app just to learn the language? Or do you have any idea of a better well known programm to build to "learn" the language in a week?

Re: Why We Chose Rails to Build Gitlab

#38

Post by darkr »

freehunter wrote: post #25
ppeetteerr wrote: post #8

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

Re: Why We Chose Rails to Build Gitlab

#39

Post by mbesto »

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…

> language patterns of Ruby but want better performance for concurrent processes

But then take on the disadvantages of acquiring talent and less adopted programming paradigms (e.g. functional programming)? Elixir/Phoenix is awesome, but it's not a panacea for everything.

Language/framework choices aren't done in a vacuum.

Re: Why We Chose Rails to Build Gitlab

#40

Post by weberc2 »

cutety wrote: post #10
tschellenbach wrote: post #4

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…

> the lack of generics

Earnest question: isn't Elixir dynamically typed? If so, how is Go's type system worse? You can always drop down to `interface{}` (the dynamic type) if you like, after all.

> And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example.

I haven't used Elixir, but I suspect this is true. Elixir/Erlang are probably the only two languages that probably have a better concurrency story than Go; however, there are other facets (tooling, deployment story, learning curve, etc) to consider in choosing a programming language, and I think Go is a really strong language on balance.

Post reply on HN