32 ms·
Why we're sticking with Ruby on Rails
- bovermyer 4y agoI feel like I've read this before July 6th. Is this a repost or something?
- MatthiasPortzel 4y agoLooks like it was previously posted on a different site and only posted to the GitLab blog July 6th. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=why%20we%27re%20sticking%20with%20Ruby%20on%20Rails&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
- philliphaydon 4y agohttps://about.gitlab.com/blog/2018/10/29/why-we-use-rails-to-build-gitlab/ https://about.gitlab.com/blog/2018/10/29/why-we-use-rails-to... You're prob thinking of this one.
- hoppyhoppy2 4y agohttps://news.ycombinator.com/item?id=31726825 https://news.ycombinator.com/item?id=31726825 posted 24 days ago was the same article as today's post.
- philliphaydon 4y agoThanks for the correction.
- pxeger1 4y agoFound it: https://news.ycombinator.com/item?id=31726825 https://news.ycombinator.com/item?id=31726825 It was by GitLab, but not on their own site: https://thenewstack.io/why-were-sticking-with-ruby-on-rails-at-gitlab/ https://thenewstack.io/why-were-sticking-with-ruby-on-rails-...
- revskill 4y agoI think people think about microservice because they themselves failed to achieve modular monothlic.
- deleted 4y ago[deleted]
- gitfan86 4y agoThe big advantage of microservices is organizational not technical. You can hire teams and tell them that they are responsible for an API that receives specific data and should return specific data. These teams can operate independently. You don't have to force all the teams to use the same language or dev process. That could be good or bad depending on the circumstances, but at least you have the option with microservices.
- quickthrower2 4y agoDo you need services though to achieve this? How about libraries?
- adra 4y agoLibraries are great, but you can't deploy new versions of library without needing to step on toes. If your dev teams are just "shove this at ops" and done, then it may not make a difference, but if you need to be responsible for the code running in the real world, just library segregation doesn't cut it.
- quickthrower2 4y agoI can’t get my head around that though. I agree to split into services where “you’r have to do that anyway”. But adding services where part A of the monolith needs to use part B where a library would do the job seems odd. If you are trying to solve a specific scaling issue, then sure, but this is rare.
- magicalhippo 4y ago
- vassilevsky 4y agoIt doesn't matter what the backend is written in. What matters is user experience. And GitLab's problem is a total lack of any usability. Bloated and full of inconsistencies.
- hoppyhoppy2 4y agoDiscussed a month ago at https://news.ycombinator.com/item?id=31726825 https://news.ycombinator.com/item?id=31726825 And also https://news.ycombinator.com/item?id=32004219 https://news.ycombinator.com/item?id=32004219 , https://news.ycombinator.com/item?id=31684529 https://news.ycombinator.com/item?id=31684529
- oxff 4y ago> You need a fairly sophisticated DevOps organization to successfully run microservices. This doesn't really make a difference if you run at a scale that requires that sophistication anyhow, but it is very likely that you are not Google Correct. Don't use tools aimed for Google levels of complexity if you're not dealing with Google levels of complexity.
- pid-1 4y agoThat said, gitlab.com itself runs on K8s.
- mooreds 4y agok8s isn't only for microservices. You can containerize up normal applications (12 factor or otherwise architected) and run them on k8s. Is it a good idea? Depends. On the plus side: You have one underlying runtime and orchestration layer, with a lot of useful primitives (including and especially around deployments). On the negative: You introduce yet another layer of complexity and abstraction.
- james_marks 4y agoYALCA
- Spivak 4y agoYou just described the counter to “don’t run things designed for Google if you’re not Google.” The real advice is “don’t run stacks that make trade-offs or give up guarantees to be able to scale to a size you’re not at or solve problems you don’t have.”
- prescriptivist 4y agoThe systems in kubernetes for horizontal auto scaling are extremely nice and work very well for our large monolith. At this point I can't imagine deploying any system with significant batch or online workloads any other way. We switched to k8s early on in the company and that little bit of work to get it operating with HPAs, etc has paid off in dividends over time.
- cardanome 4y agoGood for them for sticking with Rails I guess. I am just not sure who asked or what the value of the article is supposed to be. Sure it is interesting to see the historic reasons for Ruby but these days PHP is a very different language with an arguably much better optional typing story than Ruby. The community has matured quite a bit and there is lot's of people doing "enterprise-level" work. The whole comparison doesn't hold true for modern PHP. In fact it would be interesting to reflect on the promises that Ruby on Rails made. Approachability and developer productivity it absolutely delivered but "not messy" ugh not exactly. It requires quite a bit of discipline and experience for projects to not get messy. I don't mean to say Ruby on Rails is a bad choice. If you are invested in the ecosystem there is no reason to change (except when you want something like Elixir maybe). On the other hand other languages have long caught up and have their own rails-style frameworks that are not much worse. It is not that much of a unique selling point anymore. Fully agree on the microservice part though.
- haolez 4y agoI'm in the process of transferring from being the CTO of one company to CTO in another one and I'm wondering if I should just start with Rails this time. I get a little uneasy given the popularity of the JavaScript ecosystem, and Rails seems a little harder to share code between the web app and mobile apps, but I don't know... It feels extremely productive to work on Rails.
- number6 4y agoMostly work with Django but have some expire with Rails: the speed you have with rails is insane compared with JS. Authentification, Routing, management of state, SSR. It's all done for you. Mobile App. Start with Service Workers and PWA and decide then if you need an app.
- jonesnc 4y agoI'm mainly a Django dev, and I'm curious how the productivity of Rails compares to Django. Do you have anything conclusions about their relative productivity, given a reasonable competency in both frameworks?
- tomc1985 4y agoI've worked with both extensively, though my experience with Django is mostly with very old versions. In my opinion Rails is definitively "higher velocity" than Django (recent versions of Rails have an answer to nearly everything you would need for a modern midsize web app), but I admired how simple Django was architecturally. Stack traces in Django were, at least then, easy to digest and you could comprehend most of the routing system by reading a few files, for example. Whereas with Rails your stack traces are much longer and there's a lot more machinery each request has to go through. Rails has a lot more abstraction in general (you can blame Ruby's powerful reflection capabilities on that), but I found that I have to go delving into Rails' internals very little.
- powersurge360 4y agoHey there! I've done a lot more Django than I've done rails, but have had both in my job title at different points in my career. My favorite language is python but my favorite development platform is Rails. They're mostly comparable but Rails wins for me. Rather than type it all out in prose I'll just give a short little blurb about what you get and don't get with one and leave the rest as an exercise to the reader: What you get with Django but not with Rails: - An admin panel out of the box - Python (which is a big win for me personally) - Authentication out of the box, but still fairly basic - A robust library of third party packages that benefits from python being used much broader than the web space. - Class based views (this is the biggest thing I miss, by _far_) - Better LSP support - Django REST framework (rails isn't _quite_ as good but you can get kinda close by leveraging resourceful routing and the serializers that ship with rails) What you get with Rails but not with Django: - Websocket support out of the box (but not the greatest performance. A third party drop in replacement [Anycable] makes it much better) - First party API for background jobs (but it requires a third party background job system to wrap, like sidekiq) - First party integration of a JS solution (import maps) - Second party integration of a JS bundler (js-bundling, written by rails authors but not included by default) - Hotwire (although Django trivially integrates w/ a comparable technology, htmx, Hotwire is still pretty dope) - Rspec and the rest of the Rails testing ecosystem (guard, VCR, factory_bot, capybara). Python has ports of some but not all. In my mind, Django adopted just two things, I'd be very happy. I'd love to see a better async story in Django that would enable web sockets and stuff. And the second thing I'd love to see is a better story out of the box for playing nice with frontend build chains. And, as a distant third, I'd like to see an html-over-the-wire technology like HTMX favored and some light integration in Django to recognize some headers so it can switch between sending just template segments or if it should send one w/ the layout included. The testing ecosystem I don't think is possible for Django to lift on it's own and I'm prepared to miss it while I'm away. That other stuff, though, is unfairly aging Django imo.
- kinduff 4y agoThe hardest part of using Ruby on Rails is hiring, in my experience and opinion. There are lots of Ruby developers, but there's a lot more with experience in other languages.
- TheRealDunkirk 4y agoThat's the beauty of it. You need less "experience" with Rails because it curb-stomps Javascript for productivity.
- EduardoBautista 4y agoI disagree. It is much easier to make big changes, especially refactors, using a language such as TypeScript. The amount of `undefined method 'example_method' on NilClass` errors in Ruby on Rails projects is astounding. After working with a typed language on the backend, I am confident it is easier to more quickly ship correct code with a typed language, while Ruby on Rails makes it easier to quickly ship incorrect code.
- mokkol 4y agoYou might want to check out Sorbet by Stripe if you want that with Ruby. https://sorbet.org/ https://sorbet.org/
- jaredsohn 4y agoIf you don't have static typing, you just need to make sure you have good test coverage. I work in ruby/rails and don't run into this problem.
- triyambakam 4y agoSounds like a lot of extra work.
- quesera 4y agoStatic typing requires good test coverage too. Tests confirm correct results. The fact that they also confirm expected types is a free side effect.
- manchmalscott 4y agoI was running a self hosted gitlab instance on my homelab, but got annoyed with rails (and especially sidekiqs) runaway memory usage. In my own rails projects I’ve helped mediate this by compiling ruby from source with jemalloc, but honestly I don’t have the mental bandwidth to hack into their whole omnibus thing, so I just switched over to gitea instead.
- corrral 4y agoWhen I was evaluating options for a self-hosted web git service, I ruled out GitLab because I regard such high resource use as a serious architecture smell. Just asking for trouble. Also went with gitea. Runs on a potato. If you have few enough users you can stick with SQLite to make it stupid-easy to deploy and administrate.
- bityard 4y agoTo be fair, gitlab is designed for enterprise-scale deployments not a homelab or even a small team. It's like deploying an openstack cluster when you just need a few VMs. I'm on the tools team of a mid-size company and gitlab works very well for our 200ish developers. The only real pain point for us is the difficulty of upgrading combined with the high tempo release cadence.
- Spivak 4y agoOh hey, another jemalloc user! We just LD_PRELOAD it.
- beardedman 4y agoAll I read was "why we're okay with it being slow". EDIT: This is also not really a Rails issue per se, but maybe architectural.
- andrewmutz 4y agoRails being slow is usually not something that the user can perceive. Instead, it's just something that increases your operating costs (more servers). For most online businesses, the operating cost of servers is small relative to the costs of support, sales, marketing and R&D. So, yes rails is slower, but it usually isn't slow in a way that is much of a negative for the business.
- stevebmark 4y agoRails costs 2-3x more $ than other servers because of its poor performance. I think this is a significant tradeoff to make, as well as trading developer familiarity with the hardest and most dangerous software to upgrade and refactor. Maybe for Gitlab, which is a relatively small and straightforward piece of software with limited surface area, the sting won't be quite as strong.
- andrewmutz 4y agoI agree rails costs 2-3x on servers, I just think that tends to not matter in a business context because those costs are small relative to everything else. What really moves the needle is R&D effectiveness. If your servers cost 2x with rails but your devs also produce 2x, that is a trade that is a good one for many businesses (especially startups and saas companies)
- ericb 4y ago> Rails costs 2-3x more $ than other servers because of its poor performance. That's just not true. The vast majority of time for most web apps is spent in database calls. A typical runner up on time spent is remote system calls, which, if you accept the monolith tenet that maybe you don't need those, are minimised in a Rails app. If your app does anything meaningful, typically, that "meaningful stuff" so massively dwarfs the part of the time "in Rails" that worrying about the framework time is optimizing the wrong order of magnitude. I base this claim on looking at multiple real-world Java, Node, and Rails apps in New Relic, and during performance testing. Hint: the rails app outperformed both. Oh, wait--do you mean server costs? If you are talking about 2-3x more in servers, perhaps. Have you compared dev salaries to server costs, though? Here again, you'd be optimizing a small cost when you should be optimizing the big costs that matter.
- newaccount2021 4y ago
- ransom1538 4y agoIf you want the full modern rails setup: rails7+docker+mysql+ruby3 this will get you off the ground in a few minutes. https://github.com/james-ransom/rails7-on-docker-mysql https://github.com/james-ransom/rails7-on-docker-mysql
- caseyohara 4y agoWhy MySQL and not Postgres? Most modern Rails apps use Postgres in production (at least according to this survey https://rails-hosting.com/2022/#databases https://rails-hosting.com/2022/#databases)
- ransom1538 4y agoYou can use the parent fork! It is Postgres. I just personally hate Postgres and have a huge mysqldb i need to support.
- twicetwice 4y agoWhy do you hate Postgres? I think that's the first time I've ever heard someone say that.
- draw_down 4y ago
- HansLambda 4y agoI don't see any reasoning for Ruby or Rails, just why they are sticking to a modulith rather than decomposing into (micro)services.
- cutler 4y agoBecause it works for them, presumably.
- whynotkeithberg 4y agowhat I hear here is "i've never worked with an actually complex application built over a span of decades + & have no idea what it takes to make it into a microservice. I also believe everything I read on every article so every single persons application must be as simple as mine to deconstruct"
- Sparkyte 4y agoIt is cringe to see people defend overly complicated code and infrastructure. I agree with you.
- tomc1985 4y agoAs someone who suffered under a Rails-powered microservice architecture: ew. Ew ew ew ew ew ew EW!!
- Sparkyte 4y agoA tiny kubernetes stack would do them wonders.
- Sparkyte 4y agoNothing wrong with using Ruby, but if this is a justification build something that doesn't scale you're incredibly wrong and complacent. Scale creeps and when it creeps it quickly takes over. You should always build infrastructure with scalability in mind from day 1. If you're writing in Ruby it shouldn't matter if you container it, but what surrounds that application is what matters. It also matters if you build a monolith or not.
- mmcnl 4y agoAre you sure there is no survivorship bias at play here? I've seen more projects fail due to overengineering for future scenarios that never materialized than due to lack of scalability.
- rawoke083600 4y agoExactly!
- Sparkyte 4y agoUm what are you smoking?
- rawoke083600 4y agoDefinitely not "unfiltered scalability day one" cigars
- Sparkyte 4y agoIf you think about planning scalability as over engineering you're greatly mistaken. Probably also a terrible engineer. In fact you are likely to save money with a scalable solution. Because if a particular load is not required and it scales back as well as out with limits it prevents an over exertion of budget.
- kaliszad 4y agoNormal VPSes and other relevant offerings are pretty cheap these days if you don't consider one of the big three clouds. They will cover most use cases and loads just fine for a long time also and there are practically no autoscaling issues, budget overruns etc. You could of course show some concrete examples from you experience. In my experience, you save the most time and money when you work with a solution that is less dynamic and more general purpose, like a VPS instead of specific scalable services without fixed price. Also, it is quite easy to switch providers with a VPS. With specific scalable services less so.
- projectazorian 4y agoI think Rails is great and it makes sense for most companies established on it to stick with it. But for individual engineers, going all in on Rails is likely a poor career move, in the US at least. It's rapidly becoming a commodity skill and salaries seem stagnant.
- Sparkyte 4y agorails is fine as long as it stays small and within a container no monolithic design or throw turds on a wall to see what sticks fact is K.I.S.S and everything will be fine rails will just mean it the container will be as bloated as python containers don't and I mean it don't post deploy load rails... always compile
- deleted 4y ago[deleted]
- danschumann 4y agoI still think it's funny that the ruby on rails creator didn't have enough experience for a job in ruby on rails in a jobpost that required a temporally impossible number of years experience.
- forgotloginonp4 4y agoDid that happen to Hannson? The most recent instance I’ve heard of was Ramirez and FastAPI.
- ValentineC 4y agohttps://gist.github.com/dhh/1285068 https://gist.github.com/dhh/1285068
- EternalFury 4y agoYou can stick with something for the wrong reasons just as well as you can shun something for the wrong reasons. Is Java hard to use? I don't think so. Is PHP messy? Before the restructuring that happened from PHP 7, not so much. In fact, it's pretty good now. Are Ruby and RoR easy to use and well structured? They can be, if you are careful and stay on the well beaten path. As always, for small applications, RoR is a breeze to use. But once you leave toy land, the heavy amount of helpful magic comes around to kill you. Oh you thought you were calling this function with that name in that file over there? Nope, magic code loading decided to pass your call to that implementation instead. (a.k.a. monkey patching is evil) Let's not talk about dependency management and the constant shuffles due to abandoned gems. Let's not talk about nasty upgrades from one major release of Rails to another. But of course, I am being mean. The truth is that we, developers, make a mess of anything and when it becomes unbearable, we blame the tool and move on to another tool that grew from the ashes of other tools we abandoned previously. And hence, things like Laravel are born and grow out of the lessons learned with RoR (among others). As for Java, my Lord, the archeology of web frameworks based on it makes the archeology of life on earth seems simplistic. I survived servlets, JSPs, Spring, JSF, Struts, GWT, yada, yada, yada, generations of attempts at getting it right, growing on the putrefied corpses of failed attempts at not getting wrong. I think it's progress at work, but sometimes it looks like a pendulum.
- metadat 4y agoAnd then there's Rust and Go, substantially less insane for the moment. But Node.js, sweet node, how I love and detest thee.
- rawoke083600 4y agoHaha you right. I love how node is slowwwwly becoming the new php. Where everyone say is crap and awful but half the internet runs on it.
- gitgud 4y ago> microservices do nothing to reduce complexity. This is such a dogmatic statement, showing a very biased opinion here. And it also depends what perspective you have. The reduction of complexity for developers writing and reading the system, is at the expense of an increase complexity when running the system... Which is a trade-off a lot of companies are fine with.
- therealdrag0 4y agoAlso higher code delivery throughout via higher development parallelism. Only so many people can ship changes in a single deployable before stepping on each other’s toes.
- eddd-ddde 4y agoBut is there a difference ? You can have a monolith and still develop in independent enough components. No need for a complex infrastructure if all you want is modularized code.
- Spivak 4y agoTwo of my coworkers got into a really nasty fight about exactly this. We had a monolith codebase that was extremely modular, it was all one artifact with multiple entrypoints that might as well have been ships in the night except for a few common libraries to handle logging, tracing, metrics, and connection pooling to external services like mysql and rabbit. But we had one senior developer go on an entire crusade that our app wasn’t modular enough and what it boiled down to was in his mind is that if it wasn’t separate repos, separate artifacts, and a network boundary passing JSON or similar instead of serialized objects between them it wasn’t really modular.
- eddd-ddde 4y agoI hate this kind of thought, if we go for his definition, literally every single application could be made '100% modular' by converting every single function into its own service, but instead of an ABI like stdcall you get an ABI that is json over the network. At the end of the day modularity should _not_ be defined in terms of the interface between modules.
- gitgud 4y agoGitlab have a self-hosted version of their product too. I wonder if that has influenced this perspective too?
- SkyPuncher 4y agoCaveat. I did not read the article. --- Our team is based on Ruby on Rails. A bunch of us lament "still being on Rails". We have a few small services in alternative languages. However, everyone we serious consider moving off rails, the list of things we'd lose just grows exponentially. We can never justify it. Starter list: * Built in blog/binary storage * Built in migrations * Built in models and relationship management. Seriously, it's so freaking easy to define rails models. * Standards for segmentation * Gems for just about everything * Admin panel ---- I hope we'll eventually be out-scaling Rails - but for now I'd much rather pay an extra $100/month for the next server up.
- deleted 4y ago[deleted]
- plantwallshoe 4y agoLove rails, hate ruby. A rails framework written in Go would be pretty cool.
- kyriakos 4y agoNot 100% related to the topic but as someone using self hosted gitlab daily performance is not its biggest issue but UX is. There are hundreds of small annoyances in the UI from minor details in merge request review interface to the fact that settings ui feels randomly organised. You really need to know where to look to find a setting. Gitlab is very feature rich and powerful but it feels that as it evolved, things in its UI were just glued together randomly.