5 ms·

We're still starting new greenfield projects in Rails every week, and I still believe it's the best foundation for SaaS products. It's great for developer speed

We're still starting new greenfield projects in Rails every week, and I still believe it's the best foundation for SaaS products. It's great for developer speed and efficiency, the ecosystem of gems is amazing, and we've been able to scale every project we've needed to. We're incorporating React and GraphQL more these days for complex components and APIs but they pair nicely with Rails.

mountainriver 4y ago
I work at a company with a large Ruby monolith and it’s a disaster. If you’re face deep in the Ruby ecosystem then I’m sure it makes sense, but trying to build services alongside it is truly awful. You want a scalable system that’s easy to write and will grow with you? Write basic Go services.
- gls2ro 4y ago
  Why is a disaster? I ask this genuinely as I am interested to see what pain point people have with Rails.
  - phillmv 4y ago
    in my experience, the main pain point people experience is: a) they don't like Ruby for whatever reason, b) they probably only deal in backend or only deal in frontend, and so don't understand the value of the bundled dev experience rails delivers, and therefore c) because of a + b they find the moderate learning curve to be extra painful, so they lash out. at the end of the day it's all just code. why would it be harder to integrate a service in Rails than in Go? of course it isn't.
  - ysavir 4y ago
    Two primary reasons: 1. Ruby is a very flexible language, and that has its ups and downs. While it makes it a very pleasurable easily modifiable syntax, it also leaves a lot of room for bad patterns. Ruby won't judge someone for taking an ill-advised approach to a problem, so it's easy for newcomers or novices to lay foundations that cause trouble later on. 2. Ruby is very prominent in startups, which are the companies most interested in immediate results. This often leads to favoring short-term advantages such as getting a feature out today to secure a deal rather than long-term advantages such as taking the time to keep a maintainable code base. Some startups with strict budgets will also hire people with less experience early on, leading this to pair with point 1 more often than we'd like. That said, I'm a Ruby dev and have no interest in working in any other language (other than JS on the frontend). It's a beautiful tool to those who treat it well and I'll happily use it for just about any project.
- inopinatus 4y ago
  I work at a company with a large Rails monolith and it's a delight, and so is the monolith.
- irvingprime 4y ago
  Rails does not have to be written as a monolith. Typically, junior programmers who are trying to move very fast do that. Most of the places where I have talked to people who have a monolith are looking for ways to split it into services. If you wrote a system in Go as a monolith, it would be hard to trim down, too. Architecture matters MUCH more than the implementation language.
  - kenhwang 4y ago
    Not sure Go is a very good example here, compiled languages have a huge maintainability advantage in monoliths (at the cost of compile time). Ruby/Rails' culture is a huge contributor to why Rails monoliths are so much more difficult to maintain compared to other dynamic languages. Things in Rubyland just love to be global and manipulate things globally and go out of their way to make that behavior hidden.
    - jaredcwhite 4y ago
      "Rails monoliths are so much more difficult to maintain" I question that assertion. I have plenty of anecdotes which are the exact opposite: a Rails monolith is much easier to maintain compared to similar approaches in other languages. "manipulate things globally" Not sure what you mean by that to be quite honest. If you mean monkey-patching, that's generally been frowned upon except at the framework-level in the Ruby community for quite a while now.
    - irvingprime 4y ago
      Global? In "Rubyland?" No. That's just not true. Not at all.
  - mountainriver 4y ago
    That's totally fair, it seems to trend toward a monolith though, just from what I've seen
- jaredcwhite 4y ago
  "trying to build services alongside it is truly awful" That makes no sense. It's very easy to build a REST API in Rails in which case you can connect to that API from services written in other languages. Conversely, you can easily call out to other services' APIs from Rails. In fact, I'll go so far as to say building a few choice services in particularly performant (lower-level) languages alongside a main Rails monolith is the best organizational pattern for larger applications and enterprise deployments. You get all the benefits of Ruby & Rails for most happy paths, as well as the benefits of "This goes to 11!!!" performance for the critical paths which need that.
  - mountainriver 4y ago
    Yup its just that everyone else needs to learn the spaghetti code in the monolith. Which is universally hated by everyone not in the rails ecosystem
- hiyer 4y ago
  A Go monolith would be just as hard to maintain as an RoR monolith. This is not a shortcoming of the framework.
  - mountainriver 4y ago
    Nope, Go is more opinionated and was designed to work on large teams and codebases with junior engineers. It enforces best practices where Ruby just lets you shoot yourself in the foot
    - hiyer 4y ago
      Ruby may not be opinionated but Rails is - convention over configuration is a core philosophy. It's one of the reasons it's so easy to get started with.
- likortera 4y ago
  I've been at a company that did this, they started migrating everything to Go because it was the new cool thing to do and everyone was in love with it. One year later it was a mess of network calls, no ORMs and nearly-raw queries because who needs an ORM, migrations run by SQL statements on bash scripts because who needs migrations. Validations were custom wrappers on some validation libraries and validation errors were of course not consistent across all of the microservices, not because of lack of agreement, but because new ideas and ways to "do it better" showed up all the time. Some of these "services" needed translations (for emails, hooks, and some html responses) so a custom "very simple" translation system was invented. It became an infinite mesh of proxy services on top of proxy services on top of proxy services on top of kubernetes.... and at the end of the day, guess what was paying the bills? guess what still had all the business logic and was the source of truth? The Rails application. if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided. Do you know why it went everything that way? Because management decided that if they blocked people from using Go then people would leave the company. I was one of the managers there, and pretty opposed to this as you can notice. But I think this is a huge reality around here. People want to play with new shiny, without even thinking of the drawbacks or if they do have a concurrency or raw cpu performance in their application. People want to make a CV in what they want to use in their next job. And Rails is not fashionable anymore so "the monolith is bad" and "Go microservices" are good. You're not google 99% of the time. Thankfully I left all that madness and now I'm in a more sane (although "not so cool" technologically) place where we focus on shipping product and keeping things maintainable, robust and secure.
  - weatherlite 4y ago
    This is so true. Now there's ORM for Go (Gorm), and maybe a few web frameworks, but it just feels like any other beginning ecosystem - not much on Stackoverflow if you run into problems, docs aren't that good yet, incomplete APIs, missing functionality. And it has the same Node mindset of not having a major framework to tie everything together like Rails does- which I hate. To go to your bosses and tell them you have to migrate from Ruby to Go to improve productivity is a blatant lie.
- weatherlite 4y ago
  > You want a scalable system that’s easy to write and will grow with you? Write basic Go service What's so easy about Go? I don't get it. Honestly. What's so hard for you to do in Ruby? And who's to say that in 15 years those shiny Go services you're working on won't become shit after dozens of changing devs had their way with them? Turning a codebase into shit takes time.
  - mountainriver 4y ago
    Go was designed to prevent this is why its great, Ruby was designed in a way that fosters bad dev practices
- aczerepinski 4y ago
  I've had great experiences with both Ruby and Go. Both are a joy to write, and can handle most use cases. When I'm writing Ruby I sometimes wish I had Go's type system and lightning fast test suites. When I'm writing Go, I sometimes wish there were more conventions so I didn't burn so much time thinking through the absolute perfect way to architect every little thing. Still, they're both wonderful languages that hopefully fade to the background of your consciousness so you can focus on the actual business goals at hand.
  - timuckun 4y ago
    Use Sorbet. It provides a better type system than the go typing system.
- boboroshi 4y ago
  Monoliths can be great or a disaster, as can total services setups. We took a monolith built by a small team into scores of services across 4 teams of 150 engineers, even implementing some of them in Scala (this was 2012ish). On the internal tools side, we created a gem and later a bower package (so vintage) that was a bootstrap-derived design system that worked across almost all 30 internal tools apps & services. I know other teams did the same (at least consumer and merchant), but I didn't work on those projects so I can't speak to them. I've seen great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts. After 20+ years, I often see that no one likes to refactor the smelly stuff until they're forced to, and we often end up working with a cool racketball of code covered in 2' of duct tape patches. Go is the new hotness, as was Rails at one point, and in the near future it will be something else. There's a strong neophillic bent to most developers. It's a lot more fun to work in something that's new and evolving and solving crazy problems than something that is stable. These are all tools in the tool kit. Use what lets you ship.
  - mountainriver 4y ago
    > n great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts. This is largely the problem, Go enforces good dev behavior, Ruby leaves it up to the dev
    - postmodern_mod3 4y ago
      How so? Go does not prevent you from writing a monolith. Furthermore, Go does not actually require that you check the err return value of functions.
- postmodern_mod3 4y ago
  You can write "complected" monoliths in any language. You can also write SOAs in any language. If you need native performance, Crystal is a better option, as it provides much of the same syntax, semantics, and stdlib as Ruby, but with Strong Typing. Go is a bit too simple.
- waplot 4y ago
  Monolith vs microservices is not the problem. It's architecture and code design in most cases. When i hear "Rails monolith is a disaster" what it usually boils down to 8 out of 10 times is people putting their business logic inside models or controllers, when really it should live in its own set of classes, usually called services or service objects. Here's a guide https://codeclimate.com/blog/7-ways-to-decompose-fat-activerecord-models/ https://codeclimate.com/blog/7-ways-to-decompose-fat-activer...

mountainriver 4y ago

I work at a company with a large Ruby monolith and it’s a disaster. If you’re face deep in the Ruby ecosystem then I’m sure it makes sense, but trying to build services alongside it is truly awful. You want a scalable system that’s easy to write and will grow with you? Write basic Go services.

gls2ro 4y ago
Why is a disaster? I ask this genuinely as I am interested to see what pain point people have with Rails.
- phillmv 4y ago
  in my experience, the main pain point people experience is: a) they don't like Ruby for whatever reason, b) they probably only deal in backend or only deal in frontend, and so don't understand the value of the bundled dev experience rails delivers, and therefore c) because of a + b they find the moderate learning curve to be extra painful, so they lash out. at the end of the day it's all just code. why would it be harder to integrate a service in Rails than in Go? of course it isn't.
- ysavir 4y ago
  Two primary reasons: 1. Ruby is a very flexible language, and that has its ups and downs. While it makes it a very pleasurable easily modifiable syntax, it also leaves a lot of room for bad patterns. Ruby won't judge someone for taking an ill-advised approach to a problem, so it's easy for newcomers or novices to lay foundations that cause trouble later on. 2. Ruby is very prominent in startups, which are the companies most interested in immediate results. This often leads to favoring short-term advantages such as getting a feature out today to secure a deal rather than long-term advantages such as taking the time to keep a maintainable code base. Some startups with strict budgets will also hire people with less experience early on, leading this to pair with point 1 more often than we'd like. That said, I'm a Ruby dev and have no interest in working in any other language (other than JS on the frontend). It's a beautiful tool to those who treat it well and I'll happily use it for just about any project.
inopinatus 4y ago
I work at a company with a large Rails monolith and it's a delight, and so is the monolith.
irvingprime 4y ago
Rails does not have to be written as a monolith. Typically, junior programmers who are trying to move very fast do that. Most of the places where I have talked to people who have a monolith are looking for ways to split it into services. If you wrote a system in Go as a monolith, it would be hard to trim down, too. Architecture matters MUCH more than the implementation language.
- kenhwang 4y ago
  Not sure Go is a very good example here, compiled languages have a huge maintainability advantage in monoliths (at the cost of compile time). Ruby/Rails' culture is a huge contributor to why Rails monoliths are so much more difficult to maintain compared to other dynamic languages. Things in Rubyland just love to be global and manipulate things globally and go out of their way to make that behavior hidden.
  - jaredcwhite 4y ago
    "Rails monoliths are so much more difficult to maintain" I question that assertion. I have plenty of anecdotes which are the exact opposite: a Rails monolith is much easier to maintain compared to similar approaches in other languages. "manipulate things globally" Not sure what you mean by that to be quite honest. If you mean monkey-patching, that's generally been frowned upon except at the framework-level in the Ruby community for quite a while now.
  - irvingprime 4y ago
    Global? In "Rubyland?" No. That's just not true. Not at all.
- mountainriver 4y ago
  That's totally fair, it seems to trend toward a monolith though, just from what I've seen
jaredcwhite 4y ago
"trying to build services alongside it is truly awful" That makes no sense. It's very easy to build a REST API in Rails in which case you can connect to that API from services written in other languages. Conversely, you can easily call out to other services' APIs from Rails. In fact, I'll go so far as to say building a few choice services in particularly performant (lower-level) languages alongside a main Rails monolith is the best organizational pattern for larger applications and enterprise deployments. You get all the benefits of Ruby & Rails for most happy paths, as well as the benefits of "This goes to 11!!!" performance for the critical paths which need that.
- mountainriver 4y ago
  Yup its just that everyone else needs to learn the spaghetti code in the monolith. Which is universally hated by everyone not in the rails ecosystem
hiyer 4y ago
A Go monolith would be just as hard to maintain as an RoR monolith. This is not a shortcoming of the framework.
- mountainriver 4y ago
  Nope, Go is more opinionated and was designed to work on large teams and codebases with junior engineers. It enforces best practices where Ruby just lets you shoot yourself in the foot
  - hiyer 4y ago
    Ruby may not be opinionated but Rails is - convention over configuration is a core philosophy. It's one of the reasons it's so easy to get started with.
likortera 4y ago
I've been at a company that did this, they started migrating everything to Go because it was the new cool thing to do and everyone was in love with it. One year later it was a mess of network calls, no ORMs and nearly-raw queries because who needs an ORM, migrations run by SQL statements on bash scripts because who needs migrations. Validations were custom wrappers on some validation libraries and validation errors were of course not consistent across all of the microservices, not because of lack of agreement, but because new ideas and ways to "do it better" showed up all the time. Some of these "services" needed translations (for emails, hooks, and some html responses) so a custom "very simple" translation system was invented. It became an infinite mesh of proxy services on top of proxy services on top of proxy services on top of kubernetes.... and at the end of the day, guess what was paying the bills? guess what still had all the business logic and was the source of truth? The Rails application. if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided. Do you know why it went everything that way? Because management decided that if they blocked people from using Go then people would leave the company. I was one of the managers there, and pretty opposed to this as you can notice. But I think this is a huge reality around here. People want to play with new shiny, without even thinking of the drawbacks or if they do have a concurrency or raw cpu performance in their application. People want to make a CV in what they want to use in their next job. And Rails is not fashionable anymore so "the monolith is bad" and "Go microservices" are good. You're not google 99% of the time. Thankfully I left all that madness and now I'm in a more sane (although "not so cool" technologically) place where we focus on shipping product and keeping things maintainable, robust and secure.
- weatherlite 4y ago
  This is so true. Now there's ORM for Go (Gorm), and maybe a few web frameworks, but it just feels like any other beginning ecosystem - not much on Stackoverflow if you run into problems, docs aren't that good yet, incomplete APIs, missing functionality. And it has the same Node mindset of not having a major framework to tie everything together like Rails does- which I hate. To go to your bosses and tell them you have to migrate from Ruby to Go to improve productivity is a blatant lie.
weatherlite 4y ago
> You want a scalable system that’s easy to write and will grow with you? Write basic Go service What's so easy about Go? I don't get it. Honestly. What's so hard for you to do in Ruby? And who's to say that in 15 years those shiny Go services you're working on won't become shit after dozens of changing devs had their way with them? Turning a codebase into shit takes time.
- mountainriver 4y ago
  Go was designed to prevent this is why its great, Ruby was designed in a way that fosters bad dev practices
aczerepinski 4y ago
I've had great experiences with both Ruby and Go. Both are a joy to write, and can handle most use cases. When I'm writing Ruby I sometimes wish I had Go's type system and lightning fast test suites. When I'm writing Go, I sometimes wish there were more conventions so I didn't burn so much time thinking through the absolute perfect way to architect every little thing. Still, they're both wonderful languages that hopefully fade to the background of your consciousness so you can focus on the actual business goals at hand.
- timuckun 4y ago
  Use Sorbet. It provides a better type system than the go typing system.
boboroshi 4y ago
Monoliths can be great or a disaster, as can total services setups. We took a monolith built by a small team into scores of services across 4 teams of 150 engineers, even implementing some of them in Scala (this was 2012ish). On the internal tools side, we created a gem and later a bower package (so vintage) that was a bootstrap-derived design system that worked across almost all 30 internal tools apps & services. I know other teams did the same (at least consumer and merchant), but I didn't work on those projects so I can't speak to them. I've seen great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts. After 20+ years, I often see that no one likes to refactor the smelly stuff until they're forced to, and we often end up working with a cool racketball of code covered in 2' of duct tape patches. Go is the new hotness, as was Rails at one point, and in the near future it will be something else. There's a strong neophillic bent to most developers. It's a lot more fun to work in something that's new and evolving and solving crazy problems than something that is stable. These are all tools in the tool kit. Use what lets you ship.
- mountainriver 4y ago
  > n great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts. This is largely the problem, Go enforces good dev behavior, Ruby leaves it up to the dev
  - postmodern_mod3 4y ago
    How so? Go does not prevent you from writing a monolith. Furthermore, Go does not actually require that you check the err return value of functions.
postmodern_mod3 4y ago
You can write "complected" monoliths in any language. You can also write SOAs in any language. If you need native performance, Crystal is a better option, as it provides much of the same syntax, semantics, and stdlib as Ruby, but with Strong Typing. Go is a bit too simple.
waplot 4y ago
Monolith vs microservices is not the problem. It's architecture and code design in most cases. When i hear "Rails monolith is a disaster" what it usually boils down to 8 out of 10 times is people putting their business logic inside models or controllers, when really it should live in its own set of classes, usually called services or service objects. Here's a guide https://codeclimate.com/blog/7-ways-to-decompose-fat-activerecord-models/ https://codeclimate.com/blog/7-ways-to-decompose-fat-activer...