How We Moved Our API from Ruby to Go and Saved Our Sanity(blog.parse.com)
blog.parse.com
How We Moved Our API from Ruby to Go and Saved Our Sanity
http://blog.parse.com/learn/how-we-moved-our-api-from-ruby-to-go-and-saved-our-sanity/
4 comments
https://news.ycombinator.com/item?id=9693743
As a card-carrying member of the Rails tribe, this makes excellent sense as an engineering decision for Parse, and broadly makes sense for many "build an API which serves massive volumes" tasks.
We're building a hybrid Rails/Golang app right now and it is, frankly, kicking my butt. Golang really excels at short, composable code, and when you write that you get a very nice deployment story (both in terms of hardware requirements and the actual mechanics of deployment -- compiled code, no dependency management, etc) and blistering speed relative to Ruby/Rails. Rails really excels at writing web apps. If you have never been exposed to writing a web app without a framework before and start trying it with Go, you will gain a new appreciation for how much stuff Rails (and the ecoystem) gets you for free, from session management to sensible dependency management to an ORM which actually works to ... that list, it gets long.
Also, and this is just personal comfort and having 50X more Rails experience than Go talking, but for a strings in strings out manipulation like you'll frequently be doing for web applications, I find Ruby more expressive and less painful to write.
Literally came up yesterday: https://gist.github.com/patio11/fe0abc1c18d09149e6c9
We're building a hybrid Rails/Golang app right now and it is, frankly, kicking my butt. Golang really excels at short, composable code, and when you write that you get a very nice deployment story (both in terms of hardware requirements and the actual mechanics of deployment -- compiled code, no dependency management, etc) and blistering speed relative to Ruby/Rails. Rails really excels at writing web apps. If you have never been exposed to writing a web app without a framework before and start trying it with Go, you will gain a new appreciation for how much stuff Rails (and the ecoystem) gets you for free, from session management to sensible dependency management to an ORM which actually works to ... that list, it gets long.
Also, and this is just personal comfort and having 50X more Rails experience than Go talking, but for a strings in strings out manipulation like you'll frequently be doing for web applications, I find Ruby more expressive and less painful to write.
Literally came up yesterday: https://gist.github.com/patio11/fe0abc1c18d09149e6c9
A difference in idiom between Ruby and Golang: Golang does not want you to overload strings as data structures. Ruby is OK with that. In this case, you're using String#gsub as a setter for the port attribute of a URL masquerading as a string.
Idiomatic Golang could would parse the URL out of the string and not touch the string again. You can, of course, do the same thing in Ruby. But Ruby makes the string futzing so easy that it feels natural to switch ports that way.
On the other hand, you picked kind of a great example, because Golang's net/url is obtuse in this regard: it exposes the host, but not the port directly (you change the port by appending it to the host). And it provides SplitHostPort --- in case strings.SplitN is too tricky? --- but returns the port as a string, not an integer.
Idiomatic Golang could would parse the URL out of the string and not touch the string again. You can, of course, do the same thing in Ruby. But Ruby makes the string futzing so easy that it feels natural to switch ports that way.
On the other hand, you picked kind of a great example, because Golang's net/url is obtuse in this regard: it exposes the host, but not the port directly (you change the port by appending it to the host). And it provides SplitHostPort --- in case strings.SplitN is too tricky? --- but returns the port as a string, not an integer.
I appreciate the performance benefits of Go; but I never want to deal with it. I just look at the code and I vomit a little in my mouth. I love what ruby does for me and I think i'd sooner reach for JS on the server than for Go.
That said, I appreciate their pragmatism. Rails got them started and they had to optimize things as they grew, and they found they outgrew rails; and I think that's fine. I think it would have been a mistake for them to try using Go from the start; a tempting takeaway some might have.
That said, I appreciate their pragmatism. Rails got them started and they had to optimize things as they grew, and they found they outgrew rails; and I think that's fine. I think it would have been a mistake for them to try using Go from the start; a tempting takeaway some might have.
It's felt like Rails has been falling out of favor for a while and apparently Google has the data to back it up: http://www.google.com/trends/explore#q=%2Fm%2F0505cl%2C%20%2...