Hacker News Reader

Comment by hyfgfh | Hacker News Reader

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

To me, the article reads like "We REALLY don't want to abandon Rails so we rewrite the hot paths to Go". I mean no offense; I just wasn't able to find good argumentation in it for sticking with Rails. To me, the article kind of makes the argument for Go.

"Developer productivity" is not a myth and it does exist. But Rails is very far from the only framework that gives you that.

IMO you should seriously evaluate making your web + API gateway in either Elixir or Go, outline a migration plan and get on with it.

I think a rewrite in Go would greatly increase our line-count.

I think Elixir is very interesting but Phoenix still has some way to go before the ecosystem matches that of Rails. Our Gemfile.lock https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile.... is more than 1000 lines!

Line-count really isn't a great way to measure developer productivity either though...

It does measure bug count though.

Well, that complexity is yours to evaluate -- what I am saying is that you are seriously underestimating the Elixir community. And our forum is full of people making this same admission and saying they regret not reaching for Elixir earlier! :)

In the end, it's your call of course. But line-count doesn't say anything about a project's complexity. Go is quite verbose but with rigorous CI, tests, code reviews and linters, teams produce pretty hardcore and good software in Go, regularly.

I agree Go produces great software. But for the same amount of functionality it tends to require more lines than ruby. I tend to favor the more expressive language http://www.paulgraham.com/avg.html

Another thing is that there isn't a web framework like Rails in Go. Although I'm keeping an eye on go-micro and we plan to add that as a template soon.

Yeah, fully agreed on that. Go just doesn't have as productive a framework like Rails. That's why I only use it for very small websites or even smaller API gateways. Or CLIs. Or network daemons.

I am not disputing your choices. Just wanted to give you the quick and intuitive (and likely misinformed) immediate reaction that I had from the article.

Keep making GitLab awesome. <3

Thank you! <3

Serious question. Why do so many companies choose to rewrite in Go? I tried to like it, but it just felt so painful to use.

It seems that every few years a new backend language comes to the forefront and becomes a popular for greenfield projects or rewrites. First people moved from PHP to Ruby, then Node, and now Go.

Of course, Go's popularity is helped a great deal by Google using it, as well as the huge amount of devops software written in Go (docker, terraform, kubernetes). But at some point the hype for those will settle and they'll just become more tools. At the same time there'll be more and more legacy Go projects at various companies that won't be very exciting. Around about this time we'll probably see the next language start rising in popularity.

>"Our mission is that everyone can contribute," he explains. "Because Ruby on Rails is really opinionated about which pieces go where, it's much easier for new developers to get into the codebase, because you know where people have put stuff. For example, in every kitchen you enter, you never know where the knives and plates are located. But with Ruby on Rails, you enter the kitchen and it's always in the same place, and we want to stick to that.

Sounds like they have no desire to switch away.

you win the "most hacker newsiest comment" on this thread award!

What would you prefer?

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

I took it as rrix2 were pointing out a tragedy :)

That’s a far better way of looking at it. I now regret not having seen it that way.

I guess you see what you want to see :(

fwiw I completely understand! I have also regretted what seems to be an instinct or habit to go for that same perspective. I’m not sure I can explain in a way that makes sense.

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.

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

Reply on news.ycombinator.com