3 ms·

Comparing technologies is a core part of the profession actually. What's worse is when people see a new tool or language and instantly dismiss it because it's n

Comparing technologies is a core part of the profession actually. What's worse is when people see a new tool or language and instantly dismiss it because it's not something they already know. A professional considers the technical capabilities in her tools and is willing to upgrade with the times. If there are use cases where Rails is a better fit than Go, than by all means make your argument and I'll make my rebuttal. Maybe we will both learn something, or maybe someone who reads the discussion will learn something. Not every tool is useful, and not every useful tool will be useful tomorrow.

bovermyer 8y ago
Alright, I'll bite. Hypothetical situation: a company has a large and complex Ruby on Rails application that is its primary revenue stream. All of its employees are well-versed in RoR. The operations team consistently reports performance to be within acceptable ranges, and customers are happy with the product. This scenario is common. Just replace "Ruby on Rails" with any other language/framework. Staying with the existing ecosystem is the ideal choice for the business, rather than rewriting everything in Go.
- ilovecaching 8y ago
  Rewrites are almost never the right call, I agree. The company knows this, but they also see how RoR has locked them in and that the web ecosystem has changed in a lot of ways that makes the RoR proposition not so great. So they task one or two engineers to learn Go. They learn Go in one or two days, and rewrite some scripts in Go. Big success, the scripts are much faster and are statically typed. Then they decide that for a new piece of functionality they'll write it as a service. Since Ruby and Go are both officially support grpc languages, it's easy to connect them using a protobuf schema, and have the RoR app call out to Go. Slowly over time, more new features are written as small Go services, until eventually everything in the RoR app is legacy, or can be replaced by any API gateway. Now if the company needs to switch again, they can just rewrite individual services in a different language.
  - bovermyer 8y ago
    But why would they need to move to Go, if what they have works? To put it another way - if my 2007 Honda Accord gets me to work reliably, why should I bother to buy a 2020 Tesla Model S?
    - ilovecaching 8y ago
      Businesses don't stand still, you're either actively working on a product, or you're building a new product and the old product is in maintenance mode. So to follow your analogy, a businesses is always trying to get itself into a new car. If electric cars are the future, they don't want to be in a gas powered Honda Accord while their competition is riding around in Teslas. In larger companies, spending less on gas can also save you a lot of money. If I can write a Go app that doesn't require as much AWS compute, or have a type system that lets me spend less time on bugs and more time on features, that's hitting my bottom line.
      - bovermyer 8y ago
        So what would you say to Basecamp, then? "Get thee to Go, heathen!" ?

bovermyer 8y ago

Alright, I'll bite. Hypothetical situation: a company has a large and complex Ruby on Rails application that is its primary revenue stream. All of its employees are well-versed in RoR. The operations team consistently reports performance to be within acceptable ranges, and customers are happy with the product. This scenario is common. Just replace "Ruby on Rails" with any other language/framework. Staying with the existing ecosystem is the ideal choice for the business, rather than rewriting everything in Go.

ilovecaching 8y ago
Rewrites are almost never the right call, I agree. The company knows this, but they also see how RoR has locked them in and that the web ecosystem has changed in a lot of ways that makes the RoR proposition not so great. So they task one or two engineers to learn Go. They learn Go in one or two days, and rewrite some scripts in Go. Big success, the scripts are much faster and are statically typed. Then they decide that for a new piece of functionality they'll write it as a service. Since Ruby and Go are both officially support grpc languages, it's easy to connect them using a protobuf schema, and have the RoR app call out to Go. Slowly over time, more new features are written as small Go services, until eventually everything in the RoR app is legacy, or can be replaced by any API gateway. Now if the company needs to switch again, they can just rewrite individual services in a different language.
- bovermyer 8y ago
  But why would they need to move to Go, if what they have works? To put it another way - if my 2007 Honda Accord gets me to work reliably, why should I bother to buy a 2020 Tesla Model S?
  - ilovecaching 8y ago
    Businesses don't stand still, you're either actively working on a product, or you're building a new product and the old product is in maintenance mode. So to follow your analogy, a businesses is always trying to get itself into a new car. If electric cars are the future, they don't want to be in a gas powered Honda Accord while their competition is riding around in Teslas. In larger companies, spending less on gas can also save you a lot of money. If I can write a Go app that doesn't require as much AWS compute, or have a type system that lets me spend less time on bugs and more time on features, that's hitting my bottom line.
    - bovermyer 8y ago
      So what would you say to Basecamp, then? "Get thee to Go, heathen!" ?