6 ms·

"Why GitLab are stuck with Ruby on Rails"

by hyfgfh 8y ago

AnthonBerg 8y ago
What would you prefer?
- woolvalley 8y ago
  The advantages of typed languages are too great to not work in them.
  - rrix2 8y ago
    And yet large swaths of our profession choose to do so every day
    - nothrabannosir 8y ago
      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...
      - deleted 8y ago
        [deleted]
      - AnthonBerg 8y ago
        I took it as rrix2 were pointing out a tragedy :)
        nothrabannosir 8y ago
        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 :(
        AnthonBerg 8y ago
        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.
  - davidw 8y ago
    The advantages of some particular insight into a business problem far outweigh the particulars of programming languages, for most problem domains.
    - koolba 8y ago
      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.
  - Karunamon 8y ago
    We're coming dangerously close to holy war territory here. I don't think that assumption holds true in your average web app.
deleted 8y ago
[deleted]
Karunamon 8y ago
>"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.
sytse 8y ago
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#components https://docs.gitlab.com/ee/development/architecture.html#com... for more information on what parts are Go.
- lettergram 8y ago
  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 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.
- pdimitar 8y ago
  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.
  - sytse 8y ago
    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.lock https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile.... is more than 1000 lines!
    - dieblur 8y ago
      Line-count really isn't a great way to measure developer productivity either though...
ajsharp 8y ago
you win the "most hacker newsiest comment" on this thread award!

"Why GitLab are stuck with Ruby on Rails"

by hyfgfh 8y ago

"Why GitLab are stuck with Ruby on Rails"

AnthonBerg 8y ago

What would you prefer?

woolvalley 8y ago
The advantages of typed languages are too great to not work in them.
- rrix2 8y ago
  And yet large swaths of our profession choose to do so every day
  - nothrabannosir 8y ago
    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...
    - deleted 8y ago
      [deleted]
    - AnthonBerg 8y ago
      I took it as rrix2 were pointing out a tragedy :)
      - nothrabannosir 8y ago
        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 :(
        AnthonBerg 8y ago
        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.
- davidw 8y ago
  The advantages of some particular insight into a business problem far outweigh the particulars of programming languages, for most problem domains.
  - koolba 8y ago
    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.
- Karunamon 8y ago
  We're coming dangerously close to holy war territory here. I don't think that assumption holds true in your average web app.

deleted 8y ago

[deleted]

Karunamon 8y ago

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

sytse 8y ago

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#components https://docs.gitlab.com/ee/development/architecture.html#com... for more information on what parts are Go.

lettergram 8y ago
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 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.
pdimitar 8y ago
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.
- sytse 8y ago
  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.lock https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile.... is more than 1000 lines!
  - dieblur 8y ago
    Line-count really isn't a great way to measure developer productivity either though...

ajsharp 8y ago

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