14 ms·

Why We Chose Rails to Build Gitlab

126 points by joelbluminator 8y ago

vaer-k 8y ago
> 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 they considered it.
- tschellenbach 8y ago
  quite a big gap between Elixir & Go though for most use cases.
  - dpeck 8y ago
    I don't disagree, but Im curious of the ones you're referring to
    - wrestlerman 8y ago
      Not OP, but I've been interested in both technologies for a while. Elixir with Phoenix feels like modern RoR, so it's probably best suited for startups that want to build their products fast and want to scale easily and cheaper. IMO Go is perfect for big companies and somewhat middle companies where they have some heavy traffic that needs to be addressed. I guess Golang is also easier to start with and craft something very fast as opposed to Elixir. (You can check multiple topics on elixirforum.com where people ask why their first-iteration code is slower than that in ruby/python.) I can be wrong, but I haven't found any golang opinioned-matured web framework, because most of the community is okay with building from the ground up. This may suggest that golang would be preferable in complex/enterprise systems? I'd choose Elixir for something that has to be done fast and be reliable and open for a lot of modifications that can be introduced without sweating. My point of view is based on building some simple product in Elixir and doing research. Also, a previous company I worked for had Golang and Ruby stack.
  - cutety 8y ago
    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 mostly consists of several potentially long running processes that gathers large amounts of data from various sources, does some light transformations, and then combines it and outputs it in various forms. Elixir has been immensely more pleasurable to write in, as OTP, along with things like GenStage and Flow, seem like a perfect fit for this task. And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example. The one advantage of Go I can immediately think of is using it for some networking heavy app, which is an area Elixir/Erlang has room for improvement, as making some simple outside http requests isn’t nearly as dead simple, iirc.
    - chimen 8y ago
      Sure, here's a few, personal opinions: - Some programmers don't like functional programming (I'm not one of them) - Go has static typing and I find it really cuts away bugs - Go is backed by giants and has the horse power to push forward regardless of "Github stars" - Go is easy to compile and run on most/many platforms - I find myself more able to understand third party code As a web developer, would I use Go as opposed to Phoenix/Elixir? Yes, I am actually using it in production on a fairly big project [1]. I tried Phoenix and I found it "weird" for my liking. The authentication part of a web app was a real deal-braker for me = too complicated to implement (not bad, just too complicated). I'm the type of guy that brainstorms (90% of my projects are always "close to completion" though) a lot of ideas and wants to go up and running really fast. I can't do that with Python/Elixir/Ruby without many tests written because I don't trust the code/myself all that much. Where would I use Elixir/Phoenix: - a chat/support app or anything that relies heavily on websockets - real-time apps (related to first point) - apps that rely heavily on distributed tasks [1] https://typely.com https://typely.com
    - orwin 8y ago
      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?
- dragonwriter 8y ago
  > 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. Elixir does not have the language patterns of Ruby, though it has a deceptive visual similarity.
- mbesto 8y ago
  > 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.
  - _asummers 8y ago
    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.
- inferiorhuman 8y ago
  > 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 they considered it. The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community). Ecto is still going through some massive changes (ActiveRecord is comparatively stable). Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment. The big win for Go is that it compiles down to a single binary. Ruby you get a single point of entry (script with a shebang). But Elixr/Phoenix? You get a handful of bash (not even POSIX sh!) scripts and binaries and a whole VM to deploy. As a BSD user, I gave up on Elixr/Phoenix after trying to debug the nightmarish deployments that had been broken for months. I couldn't tell if it was an issue in the rat's nest of bash scripts or a VM bug. Sure, ruby-bcrypt is broken on FreeBSD too with a similar head-in-sand mentality from the bcrypt gem maintainer (which could make Rails deployments a non-starter) but that's easy to fix and has been fixed out-of-band. Elixr? Well there's one maintainer for the deployment tool and he's stopped responding to bug reports of any sort. That said, I like Rails. A lot. But ruby is painfully slow and I've learned to push as much logic into the database as possible. So there's a compelling case to be made for an alternative. Unfortunately I've never had any other language give me that much trouble as Elixr has. Personally, I detest Go dependency and build management (and the Google involvement), but the simplicity of concurrency and deployment combined with the breadth of the standard library make a very compelling case for Go IMO. Hell, I would reach for Clojure before Elixr because at least then you're dealing with the comparatively mature Java VM. Personally I've gone down the Rust road, but even then I'm not sure I'd want to deploy a Rust web app in production just yet (although I really do like Rocket).
  - pdimitar 8y ago
    > The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community) What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind. > Ecto is still going through some massive changes (ActiveRecord is comparatively stable) As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said they will not do breaking API changes [0]; this part in particular: "With the release of Ecto 3.0, I would like to announce that I finally consider Ecto to provide a stable API. This means no more new features, although we will continue providing bug fixes and updates. For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today." So the first part of your statement is factually false. For ActiveRecord being stable... subjective, I'll give you this much. Try and migrate a Rails 4.0 app to 5.x and come cry with me over a dozen beers. ;) > Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment. Many people and organizations are "messing" with Elixir in production with great -- and increasing -- success. Phoenix at the moment is one of the very few frameworks that delay your scalability problems much farther into the future than most me and many others have worked with. Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot. I am not attacking you and I hope I don't sound that way -- but you seem to have a non-factually supported negative bias against Elixir. It gets more mature by the day and is quite capable of very serious work in pretty tough environments. Positive case studies spring into existence often. [0] https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/17306 https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/173...
- sytse 8y ago
  We are watching Elixir closely ever since visiting Krakow, Poland for the Railsberry conference in 2013. This is also where my co-founder Dmitriy and I first met in real life. As for the reasoning please see https://news.ycombinator.com/item?id=18973348 https://news.ycombinator.com/item?id=18973348
ppeetteerr 8y ago
Does anyone ever have to justify using Java for their backend?
- mrath 8y ago
  mostly in the industry (finance) I work Java is the default. You need to justify and seek approvals for using anything else.
  - Iwan-Zotow 8y ago
    even things like scala or kotlin?
    - johannes1234321 8y ago
      I'm not in that industry, but in general yes, even other JVM languages, since one of the reasons is that using a common language makes it simpler to move people between projects. If there is a sole kotlin developer or small group of kotlin devs and they leave it's harder to replace. Also integrating new members coming frommother teams is harder. The more architectures, libraries, coding styles, ... are standardized the higher are the chances that others can take over which is beneficial even if individual productivity might be lower.
- freehunter 8y ago
  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 solution. But you don't read blog posts about those companies because they choose not to write them. The blog posts you see about the backend technologies are from companies who are proud to use those technologies and want to promote their use of that technology. The companies who use Java (mostly) are companies who aren't going to write blog posts about their backend technology choices.
ambentzen 8y ago
No offense, but this is just a really weak PR fluff piece. The with only interesting thing is that they use Go for the hit access part. Oh, and Ruby and multithreading don’t mix, who knew? I like that if you preface your offending remarks with “no offense” you’re excused.
- ambentzen 8y ago
  As an aside, when companies are doing these interview-style pieces are they actually interviewing the CEO? I always just assume they pull the quotes out of their ass.
  - unilynx 8y ago
    I don't know about other companies, but given that gitlab's CEO is the type to be regularly active on HN (and will probably be reading this) it seems safe to assume that he would actively cooperate with such an article
    - sytse 8y ago
      Correct, this was an interview with me. We keep a list of topics that might be a CEO interview https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=CEO%20interview https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=al... If I recall correctly https://gitlab.com/gitlab-com/www-gitlab-com/issues/2887 https://gitlab.com/gitlab-com/www-gitlab-com/issues/2887 was part of a 1 hour interview that generated 4 articles https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=CEO%20interview https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=al... Great work by our content team.
  - richardwhiuk 8y ago
    I suspect that a PR person writes the piece with rough quotes, which the CEO then puts into their own words.
- jashmatthews 8y ago
  > Oh, and Ruby and multithreading don’t mix, who knew? Modern Ruby has great support for threading. Rails has been threadsafe since 2008 and Ruby has a huge advantage over Python in JRuby: no GIL, JIT, parallel GC etc.
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 :(
altmind 8y ago
I used to be RoR developer a while ago. Working with gitlab is a breeze because I can apply all the knowledge I have - by the virtue of being a RoR app i know how can i apply migrations, how to call interactive console, how to monitor and clear work queues, how to add middleware. Gitlab using RoR is a great win for /me/
elephantum 8y ago
It's amusing, that you can substitute every reference from Ruby to Python and Rails to Django and article would still make sense. Except for the part about running in production. Seems like Python is a bit ahead there.
- deleted 8y ago
  [deleted]
richardwhiuk 8y ago
> Because GitHub did. Which was because two of the co-founders met at a Ruby meetup.
- sytse 8y ago
  I can't find the quoted part in the article. Anyway, we met online a year after GitLab started, so by the time we met it was already decided to many it in Ruby.
  - richardwhiuk 8y ago
    Sorry, I paraphrased as part of forming a TLDR - the actual article is much more loquacious > Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time. GitHub, a source of inspiration for GitLab, was also based on Rails, making it a logical pick considering his interest in the framework. By co-founders, I meant why GitHub chose RoR, not GitLab.
    - sytse 8y ago
      Ah, thanks for explaining.
- drinchev 8y ago
  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."
yingw787 8y ago
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 features with fast changing requirements.
- mey 8y ago
  I suggest checking out https://flywaydb.org/ 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.
  - mythrwy 8y ago
    I sometimes suspect a folder full of sql scripts would be better than black box migrations (which are a folder full of sql scripts or similar anyway). Migrations are great, until they aren't. Sometimes if you actually manually do the thing you know how it works better and can adjust. I suppose the drawback to that is everyone else doesn't.
    - gwillz 8y ago
      Yeah I've thought the exact same thing before and I've actually tried both. The clear difference is that migrations are easily reversible. Good migration libraries can also reverse data migrations. A folder of SQL scripts was very refreshing, but no way could I use that system in a production environment. There's just too many edge cases to keep in your head.
    - mey 8y ago
      Manually migrating has the issue of testability and hit by the bus. I don't believe every migration needs a roll back, sometimes the better strategy is restore from a snapshot/backup.
    - evanelias 8y ago
btmiller 8y ago
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#components https://docs.gitlab.com/ee/development/architecture.html#com...
- ownagefool 8y ago
  It's fairly easy to host in my opinion. Either you use the omnibus installer for a single server, or the helm chart for a distributed kubernetes install.
- emilycook 8y ago
  (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
pwaivers 8y ago
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.
yannovitch 8y ago
"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
- rapind 8y ago
  Or Elixir, or Rust, or Node. Having spent time with all of these options, Rails is still really really good for a lot of use cases. Go comes nowhere near Ruby's readability for me (but I like the lack of surprise). Personally I'd love something typed, performant, and as readable as Ruby with a convention focused platform like Rails. Elixir + Phoenix is probably the closest I can find, but not a perfect fit. Maybe close enough though.
  - dmlittle 8y ago
    FWIW Elixir isn't necessarily lightweight. Memory will stay pretty flat (even during high workloads) but it's not lightweight.
  - Legogris 8y ago
    If we're talking memory usage, I don't think Node is necessarily a significant improvement over Ruby.
  - anonyfox 8y ago
    Crystal it is. Combined with the amber framework, porting the Ruby Code should be straightforward. Yes stuff isnt even 1.0 yet, but I would seriously bet on it right now.
choadrocker 8y ago
i just assumed it was becasue "we didnt know better"
dominotw 8y ago
because it was the "the thing" at that time, just admit it.
Roritharr 8y ago
My biggest issue with GitLab is support. After using it for our test pipelines for a year we've switched to GitLab CI completely with our deployments and right after we've started running into issues on our selfhosted instance where for about three weeks now we're fighting with stuck pipelines where runners won't pick up jobs until you manually restart them. We've been paying customers for GitLab Enterprise (now Starter) for years and the recurring theme is that our tickets go unanswered for basically ever. We're having performance issues on AWS, trying to run on ECS with an EFS Filesystem underneath, have basically done everything to rule out the EFS as the issue and now because our tickets go unanswered migrating to a dedicated EC2 Instance to see if this makes things run faster... From a product perspective we're starting to love GitLab, but from a technical & business pov it's getting increasingly painful to work with if you rely on it for too much. I wonder if Ruby is the reason it's hard for them to run reliably as a self-hostable solution, but as I have 0 Ruby experience I wouldn't know.
- lkozloff 8y ago
  Hi @Roritharr - Support Manager at GitLab here. I'd like to follow up on this to see where we dropped the ball and how (or if) we can make things right. Feel free to email me at lyle[at]gitlab.com and I'll look into your ticket history and move things along. For others, performance issues with EFS and GitLab have been frequent enough that we specifically call EFS out in our documentation: https://docs.gitlab.com/ee/administration/high_availability/nfs.html#avoid-using-awss-elastic-file-system-efs https://docs.gitlab.com/ee/administration/high_availability/... This isn't to say that EFS doesn't have its place, it's just that git operations quickly exhaust burst credits and many of our users on EFS end up with difficult to diagnose performance problems. This may or may not have anything to do with @Roritharr's problems, but it's worth noting!
  - Roritharr 8y ago
    Hi, mail is out, if for some reason this doesn't reach you: Our Ticketnumber is 111794 for the pipeline issue and the other one is 104887 for the Performance Issue.
Roboprog 8y ago
I find the whole library/framework existing functionality thing to be vastly overrated. There’s a certain minimum you need, but once you hit it, OK. For me, what I liked about Ruby when I played with it years ago was how expressive and concise the language was. There is joy in NOT having to read through a mountain of drivel when you go to dive in and maintain a feature. I realize I am in a minority, though. Most of the industry seems to insist that we are doomed, DOOOOMED (!!!), without static types, no matter what the cost to have them. For me, mutable data seems like a much bigger evil and impediment to comprehension than dynamic types. Of course, to have something that had types and type inference, but also allowed dynamic types with minimum ceremony would be nice. Maybe someday (but until Typescript groks partial function application, and maybe type inference of object literals, that’s not yet the answer) Anyway, back to work on a big fugly mountain o Java code...
- mustardo 8y ago
  https://kotlinlang.org/ https://kotlinlang.org/
SilverSlash 8y ago
Because Rails was all the hype in 2011?
joelbluminator 8y ago
Haters gonna hate. Shopify, Stripe, Github, Gitlab, AirBNB, Fiverr, Bloomberg, Hulu, Kickstarter, Deliveroo, Zendesk, New Relic, etc etc etc. How many more companies does it take to prove the point that Ruby/Rails is a viable option to base a company on?
- pry86 8y ago
  Same with PHP and its frameworks (lots of haters comes from RoR side, isn't it?) So let's leave this aside :)
  - joelbluminator 8y ago
    I agree, PHP is more than viable to build companies, and has proved it again and again. As did Ruby :) The fact that PHP isn't my favorite language is really besides the point. Those vocal Ruby/Elixir/Go/Node enthusaists who crap all over other battle tested stacks are very immature individuals.

> 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 they considered it.

tschellenbach 8y ago
quite a big gap between Elixir & Go though for most use cases.
- dpeck 8y ago
  I don't disagree, but Im curious of the ones you're referring to
  - wrestlerman 8y ago
    Not OP, but I've been interested in both technologies for a while. Elixir with Phoenix feels like modern RoR, so it's probably best suited for startups that want to build their products fast and want to scale easily and cheaper. IMO Go is perfect for big companies and somewhat middle companies where they have some heavy traffic that needs to be addressed. I guess Golang is also easier to start with and craft something very fast as opposed to Elixir. (You can check multiple topics on elixirforum.com where people ask why their first-iteration code is slower than that in ruby/python.) I can be wrong, but I haven't found any golang opinioned-matured web framework, because most of the community is okay with building from the ground up. This may suggest that golang would be preferable in complex/enterprise systems? I'd choose Elixir for something that has to be done fast and be reliable and open for a lot of modifications that can be introduced without sweating. My point of view is based on building some simple product in Elixir and doing research. Also, a previous company I worked for had Golang and Ruby stack.
- cutety 8y ago
  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 mostly consists of several potentially long running processes that gathers large amounts of data from various sources, does some light transformations, and then combines it and outputs it in various forms. Elixir has been immensely more pleasurable to write in, as OTP, along with things like GenStage and Flow, seem like a perfect fit for this task. And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example. The one advantage of Go I can immediately think of is using it for some networking heavy app, which is an area Elixir/Erlang has room for improvement, as making some simple outside http requests isn’t nearly as dead simple, iirc.
  - chimen 8y ago
    Sure, here's a few, personal opinions: - Some programmers don't like functional programming (I'm not one of them) - Go has static typing and I find it really cuts away bugs - Go is backed by giants and has the horse power to push forward regardless of "Github stars" - Go is easy to compile and run on most/many platforms - I find myself more able to understand third party code As a web developer, would I use Go as opposed to Phoenix/Elixir? Yes, I am actually using it in production on a fairly big project [1]. I tried Phoenix and I found it "weird" for my liking. The authentication part of a web app was a real deal-braker for me = too complicated to implement (not bad, just too complicated). I'm the type of guy that brainstorms (90% of my projects are always "close to completion" though) a lot of ideas and wants to go up and running really fast. I can't do that with Python/Elixir/Ruby without many tests written because I don't trust the code/myself all that much. Where would I use Elixir/Phoenix: - a chat/support app or anything that relies heavily on websockets - real-time apps (related to first point) - apps that rely heavily on distributed tasks [1] https://typely.com https://typely.com
  - orwin 8y ago
    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?
dragonwriter 8y ago
> 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. Elixir does not have the language patterns of Ruby, though it has a deceptive visual similarity.
mbesto 8y ago
> 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.
- _asummers 8y ago
  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.
inferiorhuman 8y ago
> 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 they considered it. The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community). Ecto is still going through some massive changes (ActiveRecord is comparatively stable). Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment. The big win for Go is that it compiles down to a single binary. Ruby you get a single point of entry (script with a shebang). But Elixr/Phoenix? You get a handful of bash (not even POSIX sh!) scripts and binaries and a whole VM to deploy. As a BSD user, I gave up on Elixr/Phoenix after trying to debug the nightmarish deployments that had been broken for months. I couldn't tell if it was an issue in the rat's nest of bash scripts or a VM bug. Sure, ruby-bcrypt is broken on FreeBSD too with a similar head-in-sand mentality from the bcrypt gem maintainer (which could make Rails deployments a non-starter) but that's easy to fix and has been fixed out-of-band. Elixr? Well there's one maintainer for the deployment tool and he's stopped responding to bug reports of any sort. That said, I like Rails. A lot. But ruby is painfully slow and I've learned to push as much logic into the database as possible. So there's a compelling case to be made for an alternative. Unfortunately I've never had any other language give me that much trouble as Elixr has. Personally, I detest Go dependency and build management (and the Google involvement), but the simplicity of concurrency and deployment combined with the breadth of the standard library make a very compelling case for Go IMO. Hell, I would reach for Clojure before Elixr because at least then you're dealing with the comparatively mature Java VM. Personally I've gone down the Rust road, but even then I'm not sure I'd want to deploy a Rust web app in production just yet (although I really do like Rocket).
- pdimitar 8y ago
  > The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community) What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind. > Ecto is still going through some massive changes (ActiveRecord is comparatively stable) As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said they will not do breaking API changes [0]; this part in particular: "With the release of Ecto 3.0, I would like to announce that I finally consider Ecto to provide a stable API. This means no more new features, although we will continue providing bug fixes and updates. For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today." So the first part of your statement is factually false. For ActiveRecord being stable... subjective, I'll give you this much. Try and migrate a Rails 4.0 app to 5.x and come cry with me over a dozen beers. ;) > Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment. Many people and organizations are "messing" with Elixir in production with great -- and increasing -- success. Phoenix at the moment is one of the very few frameworks that delay your scalability problems much farther into the future than most me and many others have worked with. Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot. I am not attacking you and I hope I don't sound that way -- but you seem to have a non-factually supported negative bias against Elixir. It gets more mature by the day and is quite capable of very serious work in pretty tough environments. Positive case studies spring into existence often. [0] https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/17306 https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/173...
sytse 8y ago
We are watching Elixir closely ever since visiting Krakow, Poland for the Railsberry conference in 2013. This is also where my co-founder Dmitriy and I first met in real life. As for the reasoning please see https://news.ycombinator.com/item?id=18973348 https://news.ycombinator.com/item?id=18973348

ppeetteerr 8y ago

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

mrath 8y ago
mostly in the industry (finance) I work Java is the default. You need to justify and seek approvals for using anything else.
- Iwan-Zotow 8y ago
  even things like scala or kotlin?
  - johannes1234321 8y ago
    I'm not in that industry, but in general yes, even other JVM languages, since one of the reasons is that using a common language makes it simpler to move people between projects. If there is a sole kotlin developer or small group of kotlin devs and they leave it's harder to replace. Also integrating new members coming frommother teams is harder. The more architectures, libraries, coding styles, ... are standardized the higher are the chances that others can take over which is beneficial even if individual productivity might be lower.
freehunter 8y ago
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 solution. But you don't read blog posts about those companies because they choose not to write them. The blog posts you see about the backend technologies are from companies who are proud to use those technologies and want to promote their use of that technology. The companies who use Java (mostly) are companies who aren't going to write blog posts about their backend technology choices.

ambentzen 8y ago

No offense, but this is just a really weak PR fluff piece. The with only interesting thing is that they use Go for the hit access part. Oh, and Ruby and multithreading don’t mix, who knew? I like that if you preface your offending remarks with “no offense” you’re excused.

ambentzen 8y ago
As an aside, when companies are doing these interview-style pieces are they actually interviewing the CEO? I always just assume they pull the quotes out of their ass.
- unilynx 8y ago
  I don't know about other companies, but given that gitlab's CEO is the type to be regularly active on HN (and will probably be reading this) it seems safe to assume that he would actively cooperate with such an article
  - sytse 8y ago
    Correct, this was an interview with me. We keep a list of topics that might be a CEO interview https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=CEO%20interview https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=al... If I recall correctly https://gitlab.com/gitlab-com/www-gitlab-com/issues/2887 https://gitlab.com/gitlab-com/www-gitlab-com/issues/2887 was part of a 1 hour interview that generated 4 articles https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=CEO%20interview https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=al... Great work by our content team.
- richardwhiuk 8y ago
  I suspect that a PR person writes the piece with rough quotes, which the CEO then puts into their own words.
jashmatthews 8y ago
> Oh, and Ruby and multithreading don’t mix, who knew? Modern Ruby has great support for threading. Rails has been threadsafe since 2008 and Ruby has a huge advantage over Python in JRuby: no GIL, JIT, parallel GC etc.

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 :(

altmind 8y ago

I used to be RoR developer a while ago. Working with gitlab is a breeze because I can apply all the knowledge I have - by the virtue of being a RoR app i know how can i apply migrations, how to call interactive console, how to monitor and clear work queues, how to add middleware. Gitlab using RoR is a great win for /me/

elephantum 8y ago

It's amusing, that you can substitute every reference from Ruby to Python and Rails to Django and article would still make sense. Except for the part about running in production. Seems like Python is a bit ahead there.

deleted 8y ago
[deleted]

richardwhiuk 8y ago

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

sytse 8y ago
I can't find the quoted part in the article. Anyway, we met online a year after GitLab started, so by the time we met it was already decided to many it in Ruby.
- richardwhiuk 8y ago
  Sorry, I paraphrased as part of forming a TLDR - the actual article is much more loquacious > Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time. GitHub, a source of inspiration for GitLab, was also based on Rails, making it a logical pick considering his interest in the framework. By co-founders, I meant why GitHub chose RoR, not GitLab.
  - sytse 8y ago
    Ah, thanks for explaining.
drinchev 8y ago
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."

yingw787 8y ago

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 features with fast changing requirements.

mey 8y ago
I suggest checking out https://flywaydb.org/ 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.
- mythrwy 8y ago
  I sometimes suspect a folder full of sql scripts would be better than black box migrations (which are a folder full of sql scripts or similar anyway). Migrations are great, until they aren't. Sometimes if you actually manually do the thing you know how it works better and can adjust. I suppose the drawback to that is everyone else doesn't.
  - gwillz 8y ago
    Yeah I've thought the exact same thing before and I've actually tried both. The clear difference is that migrations are easily reversible. Good migration libraries can also reverse data migrations. A folder of SQL scripts was very refreshing, but no way could I use that system in a production environment. There's just too many edge cases to keep in your head.
  - mey 8y ago
    Manually migrating has the issue of testability and hit by the bus. I don't believe every migration needs a roll back, sometimes the better strategy is restore from a snapshot/backup.
  - evanelias 8y ago

btmiller 8y ago

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#components https://docs.gitlab.com/ee/development/architecture.html#com...

ownagefool 8y ago
It's fairly easy to host in my opinion. Either you use the omnibus installer for a single server, or the helm chart for a distributed kubernetes install.
emilycook 8y ago
(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

pwaivers 8y ago

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.

yannovitch 8y ago

"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

rapind 8y ago
Or Elixir, or Rust, or Node. Having spent time with all of these options, Rails is still really really good for a lot of use cases. Go comes nowhere near Ruby's readability for me (but I like the lack of surprise). Personally I'd love something typed, performant, and as readable as Ruby with a convention focused platform like Rails. Elixir + Phoenix is probably the closest I can find, but not a perfect fit. Maybe close enough though.
- dmlittle 8y ago
  FWIW Elixir isn't necessarily lightweight. Memory will stay pretty flat (even during high workloads) but it's not lightweight.
- Legogris 8y ago
  If we're talking memory usage, I don't think Node is necessarily a significant improvement over Ruby.
- anonyfox 8y ago
  Crystal it is. Combined with the amber framework, porting the Ruby Code should be straightforward. Yes stuff isnt even 1.0 yet, but I would seriously bet on it right now.

choadrocker 8y ago

i just assumed it was becasue "we didnt know better"

dominotw 8y ago

because it was the "the thing" at that time, just admit it.

Roritharr 8y ago

My biggest issue with GitLab is support. After using it for our test pipelines for a year we've switched to GitLab CI completely with our deployments and right after we've started running into issues on our selfhosted instance where for about three weeks now we're fighting with stuck pipelines where runners won't pick up jobs until you manually restart them. We've been paying customers for GitLab Enterprise (now Starter) for years and the recurring theme is that our tickets go unanswered for basically ever. We're having performance issues on AWS, trying to run on ECS with an EFS Filesystem underneath, have basically done everything to rule out the EFS as the issue and now because our tickets go unanswered migrating to a dedicated EC2 Instance to see if this makes things run faster... From a product perspective we're starting to love GitLab, but from a technical & business pov it's getting increasingly painful to work with if you rely on it for too much. I wonder if Ruby is the reason it's hard for them to run reliably as a self-hostable solution, but as I have 0 Ruby experience I wouldn't know.

lkozloff 8y ago
Hi @Roritharr - Support Manager at GitLab here. I'd like to follow up on this to see where we dropped the ball and how (or if) we can make things right. Feel free to email me at lyle[at]gitlab.com and I'll look into your ticket history and move things along. For others, performance issues with EFS and GitLab have been frequent enough that we specifically call EFS out in our documentation: https://docs.gitlab.com/ee/administration/high_availability/nfs.html#avoid-using-awss-elastic-file-system-efs https://docs.gitlab.com/ee/administration/high_availability/... This isn't to say that EFS doesn't have its place, it's just that git operations quickly exhaust burst credits and many of our users on EFS end up with difficult to diagnose performance problems. This may or may not have anything to do with @Roritharr's problems, but it's worth noting!
- Roritharr 8y ago
  Hi, mail is out, if for some reason this doesn't reach you: Our Ticketnumber is 111794 for the pipeline issue and the other one is 104887 for the Performance Issue.

Roboprog 8y ago

I find the whole library/framework existing functionality thing to be vastly overrated. There’s a certain minimum you need, but once you hit it, OK. For me, what I liked about Ruby when I played with it years ago was how expressive and concise the language was. There is joy in NOT having to read through a mountain of drivel when you go to dive in and maintain a feature. I realize I am in a minority, though. Most of the industry seems to insist that we are doomed, DOOOOMED (!!!), without static types, no matter what the cost to have them. For me, mutable data seems like a much bigger evil and impediment to comprehension than dynamic types. Of course, to have something that had types and type inference, but also allowed dynamic types with minimum ceremony would be nice. Maybe someday (but until Typescript groks partial function application, and maybe type inference of object literals, that’s not yet the answer) Anyway, back to work on a big fugly mountain o Java code...

mustardo 8y ago
https://kotlinlang.org/ https://kotlinlang.org/

SilverSlash 8y ago

Because Rails was all the hype in 2011?

joelbluminator 8y ago

Haters gonna hate. Shopify, Stripe, Github, Gitlab, AirBNB, Fiverr, Bloomberg, Hulu, Kickstarter, Deliveroo, Zendesk, New Relic, etc etc etc. How many more companies does it take to prove the point that Ruby/Rails is a viable option to base a company on?

pry86 8y ago
Same with PHP and its frameworks (lots of haters comes from RoR side, isn't it?) So let's leave this aside :)
- joelbluminator 8y ago
  I agree, PHP is more than viable to build companies, and has proved it again and again. As did Ruby :) The fact that PHP isn't my favorite language is really besides the point. Those vocal Ruby/Elixir/Go/Node enthusaists who crap all over other battle tested stacks are very immature individuals.