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

51–60 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#51

Post by wrestlerman »

orwin wrote: post #37
cutety wrote: post #10

Earlier quoted context omitted.

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?

Don't want to be that guy, but imo one week is not enough to even "learn" Elixir. To be honest it depends on your previous experience, of course. But the problems is, that there a lot of books, but there are not that much code examples in the world. There are some Phoenix open sourced projects, but I didn't see that much OTP in them.

Re: Why We Chose Rails to Build Gitlab

#53

Post by emilycook »

btmiller wrote: post #33

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

(gitlab employee here) what is it you find particularly painful? It's definitely not intended to make it seem like people should go with hosted, so any feedback you have would be really appreciated

Re: Why We Chose Rails to Build Gitlab

#54

Post by _asummers »

mbesto wrote: post #39
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.

We've had good success teaching team members with no FP or Elixir experience and training them to be productive Elixir developers. It takes investment, but so does having an employee.

Re: Why We Chose Rails to Build Gitlab

#55

Post by vips7L »

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 really enjoy modern java. Its extremely performant and the ecosystem is amazing.

Re: Why We Chose Rails to Build Gitlab

#56

Post by stock_toaster »

mey wrote: post #26
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…

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

Re: Why We Chose Rails to Build Gitlab

#57

Post by icedchai »

itslennysfault wrote: post #52
ppeetteerr wrote: post #8

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

IMO yeah. I can't stand Java and for someone to sell me on building any of my backend in Java it'd have to be one hell of a compelling argument.

What is your preferred language for backend?

Re: Why We Chose Rails to Build Gitlab

#58

Post by yannovitch »

"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 train because everybody is doing the same.

In the same time, I'm thinking about switching to Gitea or Gogs + Drone.io, because Gitlab takes just too.damn.much.memory ! Seriously, 8GB RAM to even just begin with ? (Because yes, 4GB RAM + 4GB Swap is not viable). Even my biggest website is not consuming as much.

So if I could suggest something, it would be a global rewrite in Go or something like that, to lower the requirements, not just one or two parts (excuse me, microservices ;)).

Just my 2 cents

Re: Why We Chose Rails to Build Gitlab

#59

Post by drinchev »

richardwhiuk wrote: post #15

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

I was looking for a comment like this. I also assume the decision was influenced by GitHub which put RoR at it's high as well as what the original author ( Dmitriy ) decided to do so.

Anyway, why they stick to RoR these days is probably because they have invested too much into it ( same reason as of why FB is kinda stuck with PHP ).

This article doesn't make a lot of sense btw, since "they" ( hundreds+ people org ) did not choose anything as the reality is probably that one person ( Dmitriy Zaporozhets ) woke up one day and said "Hey let's see how far I can go with this."

Re: Why We Chose Rails to Build Gitlab

#60

Post by aczerepinski »

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'm not the parent poster, but I love both Elixir and Go and have both in production at work. My two cents:

Phoenix is a joy to work with, so I like Elixir for the full-stack crud apps that you might otherwise do in Rails. The server-rendered HTML experience is every bit as painless as it is in Rails (this is not a selling point for Go), you get very good tooling for free, Elixir is fun to write, depending on the application the channels/websocket stuff can be a huge lift, etc.

I like Go for stuff that doesn't have a web front end - APIs, CLI tools, background services that need to be fast, etc. In my personal experience based on the small number of Elixir & Go apps I've written (only a few of each), Go gets the edge for performance and server cost. It isn't as quick to prototype in Go as it is in Elixir, but the type system pays off over the long haul.

Again just my quick take - both are really great IMO.

Post reply on HN