1. 12
  1. 45

    TL;DR: They’re sticking with Rails because it’s what they’re already using, and it’s not causing them enough pain to change it.

    The same reason any business sticks with any technology.

    This is a sponsored post at thenewstack.io, and it’s content-light, so it’s borderline spam here.

    Offtopic: that’s a bit of an unfortunate stock photo they went with. Looked like a bunch of blood-stained hands to me, at first glance.

    1. 6

      Offtopic: that’s a bit of an unfortunate stock photo they went with. Looked like a bunch of blood-stained hands to me, at first glance.

      Agreed.

      On-topic, I’m not sure Rails works for them considering the stability issues they’ve been seeing and last year they literally stopped working on any features to have all hands on deck to work on those stability problems.

      1. 7

        I don’t think that’s a Rails issue though, there are many companies that have managed to scale with Rails.

        1. 3

          I’d ask how many have also failed to scale with Rails? The dynamic nature of the language has to make larger codebases a giant pain to work in.

          1. 8

            How many fail to scale with a static language?

            Anecdotally I once worked for a company that ran out of runway because we couldn’t fundamentally change how everything worked fast enough to respond to constantly changing customer signals in order to find product fit. The implementation language was Scala.

            Does this mean static languages “can’t scale” because they’re too constraining for early phase startups? People will make that argument.

            But honestly “scaling” is 99% about blundering into market fit and getting lucky – to the extent that tools can help you with that, it’s only by being familiar enough to you that they don’t get in your way.

            Companies that don’t manage to scale tell us nothing in particular about the tools they chose (for that matter, companies that do scale tell us nothing in particular about the tools they chose other than serving as an existence proof that X tool can scale).

            1. 6

              The empirical evidence, at this point in our industry’s history, is that there are a large number of acceptable tech stacks for doing web stuff at sub-(Google, Facebook, etc.) scale. Among which are Ruby and Rails.

              And notice that I say “acceptable” and not “good”, let alone “perfect” — every language, framework, design pattern, typing discipline, or what-have-you has its own set of quirks, tradeoffs and pain points, and exactly zero of them “scale” effortlessly in terms of either traffic or team size. Success, such as it is, is mostly a matter of learning to handle the quirks/tradeoffs/pain points of the particular stack you’ve chosen, because migrating to a different one is largely just exchanging one set of issues for a different set of issues, combined with the enormous cost of doing the migration.

              Thus you can find people who failed to “scale” with Rails. And others who failed to “scale” with whatever tech stack you prefer. This does not generalize usefully to objective “does/does not scale” statements about them.

              1. 5

                Anecdata point:

                I’ve worked with a large Rails codebase (100s of thousands of Ruby SLOC). The pains and problems with it weren’t due to the dynamic nature of Ruby, nor even using Rails itself (which I’ve actually never really liked). The things that needed dealing with were more to do with the line count and head count, and I’d expect many of those things would have been encountered if they used another language and/or another framework, but still grew to the same size.

            2. 4

              Feel free to create a stable alternative. Please don’t let these mere mortals hold you back.

              1. 5

                Your message is devoid of content. Please express what you’re trying to imply more directly.

                1. 4

                  I believe he is saying that talk is cheap.

                  1. 6

                    That would be a strange thing to say here in the comments section of lobste.rs, since we’re all here to talk?

            3. 6

              TL;DR: They’re sticking with Rails because it’s what they’re already using, and it’s not causing them enough pain to change it.

              I think a better TLDR is: they find it approachable as PHP but without PHP’s oddities. And they don’t need microservices as they have huge drawbacks and don’t reduce complexity per se.

              I think the remarks about microservices are spot on.

              1. 3

                Not sure if your use of present tense was intentional but I found it a little odd. Yes, PHP is very much in widespread use (and from what I hear better than ever) but rewrites targeting PHP (coming from a different language) have always been rare since… very long.

                So I guess rewriting in PHP is just as much out as rewriting in Python - the only things that seem to be en vogue would be Go or Rust…

            4. 10

              Gitlab is not a monolith, they have several golang components deployed as separate services where perf matter.

              There are several problems with gitlab but i dont think their language choice is one.

              1. 4

                Fair enough. I wish they would have a shorter turnaround time though - time from reporting to a fix being available in production seems to be typically in the order of months or years. Of my nine reported issues:

                • one was auto-closed after a year with no feedback at all except thumbs up,
                • one was fixed with a couple lines documentation update after three months,
                • one is open since a year with only thumbs up,
                • three unrelated issues are open since 10 months with only thumbs up,
                • one was closed as a duplicate of an issue which is open since a year,
                • one was “solved” with a horrible hack after four months, and
                • the last one is open four months with no feedback.

                Are they understaffed, or are they underestimating how much the architecture is holding them back from change?

                1. 4

                  Are they understaffed, or are they underestimating how much the architecture is holding them back from change?

                  The much more likely possibility would seem to be simply that the bugs you’ve reported aren’t considered to be priorities internally.

                  1. 2

                    IME people are pretty myopic about how much faster they could be going. GitLab has plenty of employees.

                    1. 7

                      IMHO people are pretty good at whining from a safe distance and a high horse.

                      No affiliations to gitlab, but all the commentary in this thread is a bit … “meh”.

                      1. 2

                        True. Still they are a company. And as a user of their product (and admin maintaining a mid-sized instance) I can say that their product feels unbearably slow and annoying to navigate, while their competition (gitea and definitely github) are a much better experience. Sure gitlab has features for everything and the kitchen sink (except when it doesn’t, like required amount of MR approvals). But they’re still the company that is known in my environment for breaking 700 repos with a stable release update.