13 ms·

Anyone find it suspicious how many companies put so much effort into justifying how Rails is still a good tech for a mature company? I think the truth is reall

by brink 4y ago

Anyone find it suspicious how many companies put so much effort into justifying how Rails is still a good tech for a mature company? I think the truth is really something like - we prototyped the app in Rails, because that's what Rails is good at, now we've evolved into a huge and slow application with no type validation, but porting the application and switching the team to something better and faster would be a nightmare, so we're just going to write an article about feeling good about where we're at.

develop7 4y ago
I mean, you have to justify being stuck somehow. While GitLab is certainly not an average Rails project technical debt-wise (I'm a tiny-time contributor to GitLab and my experience was quite amazing), but it's still Rails & Ruby all the way down there which could get you going only so much. You still have to write shitloads of tests, most of which are doing a sum-types-able programming language compiler's job over and over again. One day you realize this and that's the day Ruby is dead for you because there's no chance in hell you can persuade your peers to use measly dry-rb (dry-rb maintainers — no offense, I'm admiring your stellar work), not to mention moving to F#/Ocaml/Haskell/Rust.
malfist 4y ago
Also problematic is that gitlab really really cares what programming languages you've worked in before. I've applied and they've turned me down because I didn't have enough Ruby experience, nevermind that I have plenty of years of experience in development and learning another language isn't that big of a deal. Ruby has had it's heyday. It's 15 minutes of fame was a decade ago. If they persist in using Ruby and only hiring people with extensive Ruby experience, they're going to run out of talent AND have to pay over market rate to get people in their specialization. Like all the banks and governments forking over loads of cash for COBOL and Coldfusion consultants because the refused to modernize.
- capableweb 4y ago
  > Also problematic is that gitlab really really cares what programming languages you've worked in before. I've applied and they've turned me down because I didn't have enough Ruby experience, nevermind that I have plenty of years of experience in development and learning another language isn't that big of a deal. Yeah, I've come across this in loads of companies too. In the end, I think those sort of companies don't understand that once you grok 2-3 languages, the rest of them mostly look/work the same (except the really different ones), and they are just looking for "code-monkeys" to program with them for a year or two.
  - ElectricalUnion 4y ago
    > grok 2-3 languages I don't think most people simply "accidentally grok" or use Smalltalk, Lisp or Raku; therefore I consider most people don't have what takes to grok Ruby either.
    - BlargMcLarg 4y ago
      Oh please, Ruby is not some arcane language. It's really not all that different from Python, JavaScript, Java and C# once you get used to your dev environment. Those languages alone cover way over half all the developers. People here are acting Ruby is anywhere on the same level of difficulty for a regular high-level OOP developer as C++ or Haskell.
      - ElectricalUnion 4y ago
        > It's really not all that different from Python, JavaScript, Java and C# I think that being able to dynamically replace behavior from almost anything at any point in your program is pretty much very different from Python, Java and C#. The only other mainstream language with this capacity is Erlang, and Erlang is not exactly what I would call mainstream language.
        corrral 4y ago
        > I think that being able to dynamically replace behavior from almost anything at any point in your program is pretty much very different from Python, Java and C#. Javascript is pretty popular.
- FpUser 4y ago
  >"Also problematic is that gitlab really really cares what programming languages you've worked in before" I agree that for experienced developer requirement to have extensive experience with particular language may not be all that important. But rewriting perfectly working software just because developers knowing legacy language is too expensive is a big mistake. They would waste way way more trying to implement a perfect copy of the old system with "cheaper" developers.
- latchkey 4y ago
  It could also be that they didn't want to hire you because you aren't a 'believer' in the technology (in that you're not already experienced with it). They have doubled down on Rails, so if they hire people who aren't already in the ballgame, they will either be faced with people who want to change things (which creates conflicts) or have to train people to avoid the speed bumps in the existing system (which also pushes people to want to change things). I'm curious, was your position during the interview that you were beyond excited to pick up Rails as your next technology? Finally, you never know... their feedback might have also just been a kinder let down... maybe they didn't feel your programming chops were up to their required level. Who knows...
- jaredcwhite 4y ago
  > Ruby has had it's heyday Yep, it's right now. > It's 15 minutes of fame was a decade ago. Nope. Just as popular, if not more so, than ever. > If they persist in using Ruby and only hiring people with extensive Ruby experience, they're going to run out of talent The best time to become a Ruby programmer or run a bootcamp teaching Ruby was five years ago. The second best time is now. > Like all the banks and governments forking over loads of cash for COBOL and Coldfusion Ha. > learning another language isn't that big of a deal Actually Ruby has a very specific and long-standing style that is subtle and takes a while to pick up. Any Rubyist worth their salt can instantly spot code that's simply been "ported" over from some other language community. Ruby has a "Ruby way", which in large part inspired the "Rails way". It's frankly insulting to claim you can just pick up Ruby on a whim and it's no big deal. Sure, Ruby isn't hard to learn at first, and I encourage all beginners out there to give it a real try. You won't be disappointed. But Ruby is also a deep language with a rich vocabulary, and it will take you some time to master it. In some ways, if you're an experienced programmer from another language community, it'll take you longer—because you'll need to unlearn the habits you've picked up before that in Ruby might be considered a code smell. I suggest you spend some time gaining actual Ruby experience, and then next time you apply for a job asking for Ruby experience, you'll have some. :)
  - BlargMcLarg 4y ago
    Ruby has been steadily going down as favorite language for years. I have absolutely no beef with Ruby, but GP is pretty clearly pointing out the disjunct between continuing to use a language with a dwindling userbase, and requiring that userbase to have professional experience. In its home country, GitLab is one of the few to use Ruby to begin with. >I suggest you spend some time gaining actual Ruby experience Which requires those people to get jobs. If they can't get jobs in the language, they can't get experience in the language. This is already an issue with the more popular languages which are converging to the same point.
  - digitalsin 4y ago
    >if you're an experienced programmer from another language community, it'll take you longer—because you'll need to unlearn the habits you've picked up before that in Ruby might be considered a code smell. So much this :) I've been a C# developer for over 20 years and I also write quite a bit of Go. I recently decided to write my NFT app in RoR with backend / batch processes in pure Ruby, and having essentially minimal experience with Ruby it has taken a while to unlearn some of the things that are nearly instinctive to me with (particularly) C#. That said, so far I am really glad I did what I did. I love Ruby and I think it's incredibly underrated, especially vs Python (though Python is also a great language on its own). Once you really get a handle on Ruby (and Rails), it makes web dev a fun again.
- corrral 4y ago
  To be fair it takes a ton of memorization to be productive in a Rails codebase, between lack of static types and tons of runtime "magic". Requiring Ruby experience is silly if you've managed to write in several languages productively already—Rails experience, though, I could see requiring that. Recent Rails experience, even. Which is part of why I've pretty much sworn it off forever, after working on several Rails projects over the years. I never, ever want to onboard to a Rails project again, if I can help it.
- ElectricalUnion 4y ago
  > Like all the banks and governments forking over loads of cash for COBOL and Coldfusion consultants because the refused to modernize. COBOL itself it's actually very cheap and simple; in fact "so simple anyone can use it because it's just english" /s What banks and governments fork loads of cash for, it's a highly vertically scalable, performant and redundant system that works (and keeps working) under heavy load and concurrency. A SaaS cloud (including the ludicrous prices you pay for a SaaS when you need to scale your service...) before SaaS clouds were a thing. A mainframe computer with a support contract.
subpixel 4y ago
This isn't about truth-telling, it's about impressing enterprise prospects with the _relative_ and self-described simplicity of a basket they are considering putting some/most/all of their apples in.
- andrew_ 4y ago
  Astute observation (sincerely, this is not sarcasm). I hadn't considered that. It's a puff piece.
- stakkur 4y ago
  Given Gitlab's fairly transparent chronicling of what they've learned and how they work, I disagree. One of the things I like best about Gitlab (as an organization) is their ongoing effort to conduct business and process learnings in public, and share them.
Ataraxic 4y ago
I actually disagree that it's suspicious. I think there are often trends in programming that despite being touted as newer, better, and faster have failed to deliver on that. Ala the amazing amount of churn in JS frameworks in the earlier years of SPA's and such. An article saying y'know what "X is actually good enough" isn't any more suspicious than all the articles saying "Y is the new hot thing". I am biased here because with respect to the products that I've helped create the speed of ruby vs js, python, etc. has never been a dealbreaker. Even if porting an entire application wasn't a nightmare, why would you ever do it unless your organization was going to fail without? Porting entire applications needs to be justified by some critical requirement that (in this case) ruby/rails isn't meeting. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... -- Porting an entire application into a new language can easily be a rewrite and not a "port".
- itake 4y ago
  Organizations rarely port working code to new frameworks, but they launch new products and features with new frameworks. If you're developing and serving ML models, I'd be surprised if they chose to stick with Ruby over Python/Flask. Gitlab could keep everything "rails" and break out service into micro-rails services.
tmp_anon_22 4y ago
Rails has a lot of "magic". Which is fine if you only hire veteran Rails developers who know the magic, but over time it becomes organizationally exhausting because ultimately you will have to train people, you will have people leave the org, and you'll have people coming from other orgs with way less conceptual overhead that keep asking "why don't we just..." to methodologies outside the core rails ecosystem. Rails is perfectly fine but being perfectly fine is an unsatisfactory outcome over time.
- sparker72678 4y ago
  > Rails is perfectly fine but being perfectly fine is an unsatisfactory outcome over time. Perfectly fine over time feels like a tremendous accomplishment in software.
- ipaddr 4y ago
  What would replace Rails?
LordHeini 4y ago
Because Rails is a good technology for a lot of use cases. If you want to develop a simple crud style app, with user login, mail sending and all that stuff it is highly productive. Performance is okay and certainly good enough for the average web project. Just get rid of the weird parts like turbolinks (unnecessary and messes up a lot of js) and don't write APIs using it (can't even rename fields easily). There are similar Frameworks in other languages and they all have pros and cons. Imho when it comes to web frameworks there is way too much emphasis on the startup style company and the ones with huge traffic. Companies doing grunt work style web development don't waste their time on flavor-of-the-month.js. If you build a website for a niche company to sell odd machinery on, you have to get shit done and you will never need to scale. That means reliable, batteries included, highly standardized and easy to use. Rails ticks those boxes really well.
- ravenstine 4y ago
  > Imho when it comes to web frameworks there is way too much emphasis on the startup style company and the ones with huge traffic. That's exactly what is making web development decreasingly enjoyable as the years go on. ~99.5% of the web doesn't need the hyperscalable cool-tech du jour one typically reads about on HN. As long as developers don't fall for footguns, there's a lot that can be accomplished even with a language runtime like MRI. If scale becomes an issue, those things can be solved through horizontal scaling, optimizing database queries, not doing stupid shit that's memory-hogging, and moving expensive algorithms into another language. Ruby is perfectly adequate for serving HTTP requests. Whenever I've worked on a Rails app that everyone was frustrated with, the problems were almost always a compound of a bunch of dumbass shit that various developers piled on without much thought (otherwise I'd have seen them discussed in GitHub or Pivotal stories).
- itake 4y ago
  edit: to down voters: please educate me and not just down vote because you disagree with my question. --- Every tiny rails app that uses rspec ends up with +1hr test times due to tight coupling between activemodel and the db connections. Do you know of any good blog posts the describe how to do rails testing at scale? > Companies doing grunt work style web development don't waste their time on flavor-of-the-month.js. Rails devs have to deal with DHH's-flavor-of-the-month.coffee (coffeescript, asset pipeline, webpacker, import_maps)
ravenstine 4y ago
Companies justify using Rails publicly because it makes financial sense. There's this meme that Rails "just doesn't scale" and is "yesterday's software", but neither are necessarily true. Ruby isn't the fastest language, but it's now competitive enough that the same critics might as well throw Python under the bus while they're at it. There's things I don't like about both Ruby and Rails, but it's a perfectly viable and productive way to build websites. A very scant number of businesses need to be at the scale of Twitter or The Google, in which case Rails can be a great choice. But I imagine Rails is being increasingly dismissed by newbie developers as being obsolete and not-cool. Mature companies may realize it's in their best interest to communicate that their boring-tech works just fine and that they have no plan on changing to cool-tech. If it's true, then someone's got to say it, right? Someone needs to be interested in working with Rails. Not every business has the money to waste converting their old apps to cool-tech like Elixir or a React frontend with microservices.
- dan_quixote 4y ago
  > Not every business has the money to waste converting their old apps to cool-tech like Elixir or a React frontend with microservices. I always ask myself (and the team at large) "how much time/effort will it take to reach parity using the new tool-set?". The answer usually settles the debate immediately.
- munificent 4y ago
  > Ruby isn't the fastest language, but it's now competitive enough that the same critics might as well throw Python under the bus while they're at it. You say that like it's a point in support of Ruby, but, yes, absolutely, Python should be thrown under that same bus. Both languages are dramatically slower than other languages that are available. My little hobby programming language with a bytecode VM I wrote myself in a single C file is faster than Ruby and Python. It would be hard to design a language that isn't easy to make faster than Ruby and Python. They both pay an incredible runtime performance cost for their deep support for dynamic runtime metaprogramming and mutability. If you don't want those features, I don't think it makes sense to use those languages.
  - 4y ago
sodapopcan 4y ago
> Anyone find it suspicious how many companies put so much effort into justifying how Rails is still a good tech for a mature company? No. I would imagine these articles are coming out as a response to people claiming Ruby is outdated tech when it's still perfectly viable. And I say this as someone who has happily moved on from it. And I would hardly consider a blog post or two "a ton of effort".
- weatherlite 4y ago
  > who has happily moved on from it What did you happily move to? I can't find happiness, not in Go at least. Go just doesn't care about developer experience.
  - sodapopcan 4y ago
    Elixir. And it wasn't "because Elixir looks like Ruby"--in fact, I personally found having it look so much like Ruby detrimental at first since the similarities end at syntax. I had a growing interest in functional programming and in improving a multi-user web app we were building. Elixir's (really Erlang's) concurrency model is the first I've ever been comfortable with and able to build a clear mental picture of what's happening. The syntax (for creating concurrent processes) is a wee bit gnarly, of course. There's no perfect world :) As it stands, if I were to ever want to work in OO again, I would go back to Ruby. It's still my local-scripting language of choice for things that are too annoying to do in bash.
    - weatherlite 4y ago
      OK. Elixir is a no go for me, there's zero jobs where I live and I don't see this ever changing. It leaves Python, it was the second most enjoyable (to me) after Ruby, and Django is fine. Node is simply too hectic with new frameworks coming in every week and Go...oh boy.
      - sodapopcan 4y ago
        That's too bad. Not that you'd be for sure happy with Elixir. Where do you live?
dangus 4y ago
At least in Gitlab's case, I think this is spot on. My biggest complaint about it is that it's slow, and as of the last time I used it so many of its functionality didn't auto-update until you hit refresh. I don't know enough about web development to understand whether this was a Ruby on Rails problem or a Gitlab problem.
- asaddhamani 4y ago
  GitHub is also built using Rails and I haven't found it to be slow. Neither the zillions of Shopify stores out there.
weatherlite 4y ago
I don't get the case that Rails is not working out well for them which is implied in your answer. What is the "better and faster" tech here that would have made a big impact on their business?
gepardi 4y ago
No
TheRealDunkirk 4y ago
Counterpoint: I find it suspicious that so many people on this forum take the opportunity to bag on Ruby on Rails every time it comes up. It's almost like they hate the fact that it is, in fact, a perfectly valid choice of language and platform, and they're trying to justify the self-flagellation required to use Java for web apps. I've been around the block a couple of times now, and done projects in PHP, ASP, .NET, and Java. But I've been using Rails whenever possible to make LOB CRUD apps for almost 15 years now, and there's nothing that can even hold a candle to it for productivity. Still. Things that can take just a line or two in Rails often take HUNDREDS in Java & <insert popular JS framework>, and be a nightmare to keep square with strong typing that's so popular with Typescript now. So go ahead, cast aspersions on Rails. I'll be over here, happily cranking out features as fast as my users request them, while the corporate IT departments at my Fortune 250 take 6 months to even put a request on their schedule. EDIT: As an example, I once rewrote a web app for a department. The original was all Java/Struts. It took a team of outsourced developers 2.5 years to write. It took me 4 months to rewrite it in Rails (having no access to the code), and mine did the main operation twice as fast, which meant that you could do it online, instead of having to wait for a backgrounded process to finish and send email.
- sanderjd 4y ago
  I totally agree that Rails is great at LOB CRUD apps. Apps like that don't get very large or complex, mostly do fairly simple transformations from a database, mostly have fairly simple validation and business logic, and can use a fairly small set of user interface components. I think the primary competitor to Rails in this space should be low/no-code frameworks that can do those things without requiring much or any code. I agree Java/Struts is worse for this, and that there is a huuuge amount of "dark matter" of apps like this out there to be written. But! Gitlab is not a LOB CRUD app. And I think a lot of people here have been burned by ending up working on bigger more complicated projects that started in Rails because it was convenient and then persisted with it because it never became clear that there was a positive ROI in migrating to something different. Some people who have had that experience tend to be skeptical of projects getting started with Rails, because it feels like starting to dig a hole that they know may be difficult to climb out of. But! You never really know whether some application is going to remain small and simple, or whether it is going to grow and become more complex. So everyone is just guessing based on very limited information about the future. My two cents is that I like services. Not micro-services, larger services with well-considered boundaries, but which are not a single monolith. If that structure or philosophy is in place, I worry a lot less about implementing the individual services with Rails, because the future path is much more clear. If a particular service grows too big for Rails' britches, it can be replaced with a different implementation, without reimplementing everything. I think services are an extremely useful hedge against the risk of path dependency leading to implementations that are not working well, but are very hard to fix.
thr0wawayf00 4y ago
> so we're just going to write an article about feeling good about where we're at. I've been doing rails for years now, I have yet to work for a rails shop that is living in denial about the state their app. The batteries-included nature of rails is easily worth the cost of no type validation in most companies I've worked for, and the teams I've worked with that lean into JS more tend to be much, much bigger with a lower developer throughput. IMO it's a much more sane world to be in than JS and React where best practices change every year or two but the company repos can't keep up. So you wind up digging for solutions to problems that React no longer considers to be a best practice and is therefore buried underneath a pile of Medium articles discussing the new right way to do things. There's no such thing as a free lunch.
quest88 4y ago
I'm more suspicious of companies that choose not to use it.

by brink 4y ago

develop7 4y ago

I mean, you have to justify being stuck somehow. While GitLab is certainly not an average Rails project technical debt-wise (I'm a tiny-time contributor to GitLab and my experience was quite amazing), but it's still Rails & Ruby all the way down there which could get you going only so much. You still have to write shitloads of tests, most of which are doing a sum-types-able programming language compiler's job over and over again. One day you realize this and that's the day Ruby is dead for you because there's no chance in hell you can persuade your peers to use measly dry-rb (dry-rb maintainers — no offense, I'm admiring your stellar work), not to mention moving to F#/Ocaml/Haskell/Rust.

malfist 4y ago

Also problematic is that gitlab really really cares what programming languages you've worked in before. I've applied and they've turned me down because I didn't have enough Ruby experience, nevermind that I have plenty of years of experience in development and learning another language isn't that big of a deal. Ruby has had it's heyday. It's 15 minutes of fame was a decade ago. If they persist in using Ruby and only hiring people with extensive Ruby experience, they're going to run out of talent AND have to pay over market rate to get people in their specialization. Like all the banks and governments forking over loads of cash for COBOL and Coldfusion consultants because the refused to modernize.

capableweb 4y ago
> Also problematic is that gitlab really really cares what programming languages you've worked in before. I've applied and they've turned me down because I didn't have enough Ruby experience, nevermind that I have plenty of years of experience in development and learning another language isn't that big of a deal. Yeah, I've come across this in loads of companies too. In the end, I think those sort of companies don't understand that once you grok 2-3 languages, the rest of them mostly look/work the same (except the really different ones), and they are just looking for "code-monkeys" to program with them for a year or two.
- ElectricalUnion 4y ago
  > grok 2-3 languages I don't think most people simply "accidentally grok" or use Smalltalk, Lisp or Raku; therefore I consider most people don't have what takes to grok Ruby either.
  - BlargMcLarg 4y ago
    Oh please, Ruby is not some arcane language. It's really not all that different from Python, JavaScript, Java and C# once you get used to your dev environment. Those languages alone cover way over half all the developers. People here are acting Ruby is anywhere on the same level of difficulty for a regular high-level OOP developer as C++ or Haskell.
    - ElectricalUnion 4y ago
      > It's really not all that different from Python, JavaScript, Java and C# I think that being able to dynamically replace behavior from almost anything at any point in your program is pretty much very different from Python, Java and C#. The only other mainstream language with this capacity is Erlang, and Erlang is not exactly what I would call mainstream language.
      - corrral 4y ago
        > I think that being able to dynamically replace behavior from almost anything at any point in your program is pretty much very different from Python, Java and C#. Javascript is pretty popular.
FpUser 4y ago
>"Also problematic is that gitlab really really cares what programming languages you've worked in before" I agree that for experienced developer requirement to have extensive experience with particular language may not be all that important. But rewriting perfectly working software just because developers knowing legacy language is too expensive is a big mistake. They would waste way way more trying to implement a perfect copy of the old system with "cheaper" developers.
latchkey 4y ago
It could also be that they didn't want to hire you because you aren't a 'believer' in the technology (in that you're not already experienced with it). They have doubled down on Rails, so if they hire people who aren't already in the ballgame, they will either be faced with people who want to change things (which creates conflicts) or have to train people to avoid the speed bumps in the existing system (which also pushes people to want to change things). I'm curious, was your position during the interview that you were beyond excited to pick up Rails as your next technology? Finally, you never know... their feedback might have also just been a kinder let down... maybe they didn't feel your programming chops were up to their required level. Who knows...
jaredcwhite 4y ago
> Ruby has had it's heyday Yep, it's right now. > It's 15 minutes of fame was a decade ago. Nope. Just as popular, if not more so, than ever. > If they persist in using Ruby and only hiring people with extensive Ruby experience, they're going to run out of talent The best time to become a Ruby programmer or run a bootcamp teaching Ruby was five years ago. The second best time is now. > Like all the banks and governments forking over loads of cash for COBOL and Coldfusion Ha. > learning another language isn't that big of a deal Actually Ruby has a very specific and long-standing style that is subtle and takes a while to pick up. Any Rubyist worth their salt can instantly spot code that's simply been "ported" over from some other language community. Ruby has a "Ruby way", which in large part inspired the "Rails way". It's frankly insulting to claim you can just pick up Ruby on a whim and it's no big deal. Sure, Ruby isn't hard to learn at first, and I encourage all beginners out there to give it a real try. You won't be disappointed. But Ruby is also a deep language with a rich vocabulary, and it will take you some time to master it. In some ways, if you're an experienced programmer from another language community, it'll take you longer—because you'll need to unlearn the habits you've picked up before that in Ruby might be considered a code smell. I suggest you spend some time gaining actual Ruby experience, and then next time you apply for a job asking for Ruby experience, you'll have some. :)
- BlargMcLarg 4y ago
  Ruby has been steadily going down as favorite language for years. I have absolutely no beef with Ruby, but GP is pretty clearly pointing out the disjunct between continuing to use a language with a dwindling userbase, and requiring that userbase to have professional experience. In its home country, GitLab is one of the few to use Ruby to begin with. >I suggest you spend some time gaining actual Ruby experience Which requires those people to get jobs. If they can't get jobs in the language, they can't get experience in the language. This is already an issue with the more popular languages which are converging to the same point.
- digitalsin 4y ago
  >if you're an experienced programmer from another language community, it'll take you longer—because you'll need to unlearn the habits you've picked up before that in Ruby might be considered a code smell. So much this :) I've been a C# developer for over 20 years and I also write quite a bit of Go. I recently decided to write my NFT app in RoR with backend / batch processes in pure Ruby, and having essentially minimal experience with Ruby it has taken a while to unlearn some of the things that are nearly instinctive to me with (particularly) C#. That said, so far I am really glad I did what I did. I love Ruby and I think it's incredibly underrated, especially vs Python (though Python is also a great language on its own). Once you really get a handle on Ruby (and Rails), it makes web dev a fun again.
corrral 4y ago
To be fair it takes a ton of memorization to be productive in a Rails codebase, between lack of static types and tons of runtime "magic". Requiring Ruby experience is silly if you've managed to write in several languages productively already—Rails experience, though, I could see requiring that. Recent Rails experience, even. Which is part of why I've pretty much sworn it off forever, after working on several Rails projects over the years. I never, ever want to onboard to a Rails project again, if I can help it.
ElectricalUnion 4y ago
> Like all the banks and governments forking over loads of cash for COBOL and Coldfusion consultants because the refused to modernize. COBOL itself it's actually very cheap and simple; in fact "so simple anyone can use it because it's just english" /s What banks and governments fork loads of cash for, it's a highly vertically scalable, performant and redundant system that works (and keeps working) under heavy load and concurrency. A SaaS cloud (including the ludicrous prices you pay for a SaaS when you need to scale your service...) before SaaS clouds were a thing. A mainframe computer with a support contract.

subpixel 4y ago

This isn't about truth-telling, it's about impressing enterprise prospects with the _relative_ and self-described simplicity of a basket they are considering putting some/most/all of their apples in.

andrew_ 4y ago
Astute observation (sincerely, this is not sarcasm). I hadn't considered that. It's a puff piece.
stakkur 4y ago
Given Gitlab's fairly transparent chronicling of what they've learned and how they work, I disagree. One of the things I like best about Gitlab (as an organization) is their ongoing effort to conduct business and process learnings in public, and share them.

Ataraxic 4y ago

I actually disagree that it's suspicious. I think there are often trends in programming that despite being touted as newer, better, and faster have failed to deliver on that. Ala the amazing amount of churn in JS frameworks in the earlier years of SPA's and such. An article saying y'know what "X is actually good enough" isn't any more suspicious than all the articles saying "Y is the new hot thing". I am biased here because with respect to the products that I've helped create the speed of ruby vs js, python, etc. has never been a dealbreaker. Even if porting an entire application wasn't a nightmare, why would you ever do it unless your organization was going to fail without? Porting entire applications needs to be justified by some critical requirement that (in this case) ruby/rails isn't meeting. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... -- Porting an entire application into a new language can easily be a rewrite and not a "port".

itake 4y ago
Organizations rarely port working code to new frameworks, but they launch new products and features with new frameworks. If you're developing and serving ML models, I'd be surprised if they chose to stick with Ruby over Python/Flask. Gitlab could keep everything "rails" and break out service into micro-rails services.

tmp_anon_22 4y ago

Rails has a lot of "magic". Which is fine if you only hire veteran Rails developers who know the magic, but over time it becomes organizationally exhausting because ultimately you will have to train people, you will have people leave the org, and you'll have people coming from other orgs with way less conceptual overhead that keep asking "why don't we just..." to methodologies outside the core rails ecosystem. Rails is perfectly fine but being perfectly fine is an unsatisfactory outcome over time.

sparker72678 4y ago
> Rails is perfectly fine but being perfectly fine is an unsatisfactory outcome over time. Perfectly fine over time feels like a tremendous accomplishment in software.
ipaddr 4y ago
What would replace Rails?

LordHeini 4y ago

Because Rails is a good technology for a lot of use cases. If you want to develop a simple crud style app, with user login, mail sending and all that stuff it is highly productive. Performance is okay and certainly good enough for the average web project. Just get rid of the weird parts like turbolinks (unnecessary and messes up a lot of js) and don't write APIs using it (can't even rename fields easily). There are similar Frameworks in other languages and they all have pros and cons. Imho when it comes to web frameworks there is way too much emphasis on the startup style company and the ones with huge traffic. Companies doing grunt work style web development don't waste their time on flavor-of-the-month.js. If you build a website for a niche company to sell odd machinery on, you have to get shit done and you will never need to scale. That means reliable, batteries included, highly standardized and easy to use. Rails ticks those boxes really well.

ravenstine 4y ago
> Imho when it comes to web frameworks there is way too much emphasis on the startup style company and the ones with huge traffic. That's exactly what is making web development decreasingly enjoyable as the years go on. ~99.5% of the web doesn't need the hyperscalable cool-tech du jour one typically reads about on HN. As long as developers don't fall for footguns, there's a lot that can be accomplished even with a language runtime like MRI. If scale becomes an issue, those things can be solved through horizontal scaling, optimizing database queries, not doing stupid shit that's memory-hogging, and moving expensive algorithms into another language. Ruby is perfectly adequate for serving HTTP requests. Whenever I've worked on a Rails app that everyone was frustrated with, the problems were almost always a compound of a bunch of dumbass shit that various developers piled on without much thought (otherwise I'd have seen them discussed in GitHub or Pivotal stories).
itake 4y ago
edit: to down voters: please educate me and not just down vote because you disagree with my question. --- Every tiny rails app that uses rspec ends up with +1hr test times due to tight coupling between activemodel and the db connections. Do you know of any good blog posts the describe how to do rails testing at scale? > Companies doing grunt work style web development don't waste their time on flavor-of-the-month.js. Rails devs have to deal with DHH's-flavor-of-the-month.coffee (coffeescript, asset pipeline, webpacker, import_maps)

ravenstine 4y ago

Companies justify using Rails publicly because it makes financial sense. There's this meme that Rails "just doesn't scale" and is "yesterday's software", but neither are necessarily true. Ruby isn't the fastest language, but it's now competitive enough that the same critics might as well throw Python under the bus while they're at it. There's things I don't like about both Ruby and Rails, but it's a perfectly viable and productive way to build websites. A very scant number of businesses need to be at the scale of Twitter or The Google, in which case Rails can be a great choice. But I imagine Rails is being increasingly dismissed by newbie developers as being obsolete and not-cool. Mature companies may realize it's in their best interest to communicate that their boring-tech works just fine and that they have no plan on changing to cool-tech. If it's true, then someone's got to say it, right? Someone needs to be interested in working with Rails. Not every business has the money to waste converting their old apps to cool-tech like Elixir or a React frontend with microservices.

dan_quixote 4y ago
> Not every business has the money to waste converting their old apps to cool-tech like Elixir or a React frontend with microservices. I always ask myself (and the team at large) "how much time/effort will it take to reach parity using the new tool-set?". The answer usually settles the debate immediately.
munificent 4y ago
> Ruby isn't the fastest language, but it's now competitive enough that the same critics might as well throw Python under the bus while they're at it. You say that like it's a point in support of Ruby, but, yes, absolutely, Python should be thrown under that same bus. Both languages are dramatically slower than other languages that are available. My little hobby programming language with a bytecode VM I wrote myself in a single C file is faster than Ruby and Python. It would be hard to design a language that isn't easy to make faster than Ruby and Python. They both pay an incredible runtime performance cost for their deep support for dynamic runtime metaprogramming and mutability. If you don't want those features, I don't think it makes sense to use those languages.
- 4y ago

sodapopcan 4y ago

> Anyone find it suspicious how many companies put so much effort into justifying how Rails is still a good tech for a mature company? No. I would imagine these articles are coming out as a response to people claiming Ruby is outdated tech when it's still perfectly viable. And I say this as someone who has happily moved on from it. And I would hardly consider a blog post or two "a ton of effort".

weatherlite 4y ago
> who has happily moved on from it What did you happily move to? I can't find happiness, not in Go at least. Go just doesn't care about developer experience.
- sodapopcan 4y ago
  Elixir. And it wasn't "because Elixir looks like Ruby"--in fact, I personally found having it look so much like Ruby detrimental at first since the similarities end at syntax. I had a growing interest in functional programming and in improving a multi-user web app we were building. Elixir's (really Erlang's) concurrency model is the first I've ever been comfortable with and able to build a clear mental picture of what's happening. The syntax (for creating concurrent processes) is a wee bit gnarly, of course. There's no perfect world :) As it stands, if I were to ever want to work in OO again, I would go back to Ruby. It's still my local-scripting language of choice for things that are too annoying to do in bash.
  - weatherlite 4y ago
    OK. Elixir is a no go for me, there's zero jobs where I live and I don't see this ever changing. It leaves Python, it was the second most enjoyable (to me) after Ruby, and Django is fine. Node is simply too hectic with new frameworks coming in every week and Go...oh boy.
    - sodapopcan 4y ago
      That's too bad. Not that you'd be for sure happy with Elixir. Where do you live?

dangus 4y ago

At least in Gitlab's case, I think this is spot on. My biggest complaint about it is that it's slow, and as of the last time I used it so many of its functionality didn't auto-update until you hit refresh. I don't know enough about web development to understand whether this was a Ruby on Rails problem or a Gitlab problem.

asaddhamani 4y ago
GitHub is also built using Rails and I haven't found it to be slow. Neither the zillions of Shopify stores out there.

weatherlite 4y ago

I don't get the case that Rails is not working out well for them which is implied in your answer. What is the "better and faster" tech here that would have made a big impact on their business?

gepardi 4y ago

TheRealDunkirk 4y ago

Counterpoint: I find it suspicious that so many people on this forum take the opportunity to bag on Ruby on Rails every time it comes up. It's almost like they hate the fact that it is, in fact, a perfectly valid choice of language and platform, and they're trying to justify the self-flagellation required to use Java for web apps. I've been around the block a couple of times now, and done projects in PHP, ASP, .NET, and Java. But I've been using Rails whenever possible to make LOB CRUD apps for almost 15 years now, and there's nothing that can even hold a candle to it for productivity. Still. Things that can take just a line or two in Rails often take HUNDREDS in Java & <insert popular JS framework>, and be a nightmare to keep square with strong typing that's so popular with Typescript now. So go ahead, cast aspersions on Rails. I'll be over here, happily cranking out features as fast as my users request them, while the corporate IT departments at my Fortune 250 take 6 months to even put a request on their schedule. EDIT: As an example, I once rewrote a web app for a department. The original was all Java/Struts. It took a team of outsourced developers 2.5 years to write. It took me 4 months to rewrite it in Rails (having no access to the code), and mine did the main operation twice as fast, which meant that you could do it online, instead of having to wait for a backgrounded process to finish and send email.

sanderjd 4y ago
I totally agree that Rails is great at LOB CRUD apps. Apps like that don't get very large or complex, mostly do fairly simple transformations from a database, mostly have fairly simple validation and business logic, and can use a fairly small set of user interface components. I think the primary competitor to Rails in this space should be low/no-code frameworks that can do those things without requiring much or any code. I agree Java/Struts is worse for this, and that there is a huuuge amount of "dark matter" of apps like this out there to be written. But! Gitlab is not a LOB CRUD app. And I think a lot of people here have been burned by ending up working on bigger more complicated projects that started in Rails because it was convenient and then persisted with it because it never became clear that there was a positive ROI in migrating to something different. Some people who have had that experience tend to be skeptical of projects getting started with Rails, because it feels like starting to dig a hole that they know may be difficult to climb out of. But! You never really know whether some application is going to remain small and simple, or whether it is going to grow and become more complex. So everyone is just guessing based on very limited information about the future. My two cents is that I like services. Not micro-services, larger services with well-considered boundaries, but which are not a single monolith. If that structure or philosophy is in place, I worry a lot less about implementing the individual services with Rails, because the future path is much more clear. If a particular service grows too big for Rails' britches, it can be replaced with a different implementation, without reimplementing everything. I think services are an extremely useful hedge against the risk of path dependency leading to implementations that are not working well, but are very hard to fix.

thr0wawayf00 4y ago

> so we're just going to write an article about feeling good about where we're at. I've been doing rails for years now, I have yet to work for a rails shop that is living in denial about the state their app. The batteries-included nature of rails is easily worth the cost of no type validation in most companies I've worked for, and the teams I've worked with that lean into JS more tend to be much, much bigger with a lower developer throughput. IMO it's a much more sane world to be in than JS and React where best practices change every year or two but the company repos can't keep up. So you wind up digging for solutions to problems that React no longer considers to be a best practice and is therefore buried underneath a pile of Medium articles discussing the new right way to do things. There's no such thing as a free lunch.

quest88 4y ago

I'm more suspicious of companies that choose not to use it.