Go is a good target to move something to when one knows one's business domain and performance issues.<p>But I wouldn't recommend it to beginners trying to build a secure web application, because they will have to roll their own code when it comes user registration, authentication, authorization management, and i'm not even talking about writing thread safe libraries where one has to deal with mutexes and shared memory access.<p>If you need something highly concurrent and you know what you're doing, by all means. But Go is definitely not RAD for classic website development, and it's easy to shoot oneself in the foot with Go. It's by no mean a silver bullet.<p>I'm surprises Parse is coded in Rails,I assumed to was built on Nodejs, since it uses JS for cloud code.
Twitter never used Jruby in any significant capacity. Note that the article she cited ( <a href="http://www.infoq.com/articles/twitter-java-use" rel="nofollow">http://www.infoq.com/articles/twitter-java-use</a> ) said we were evaluating jruby, but chose not to use it because the tooling around MRI was much better (in substantial part due to the efforts of twitter's backend team at the time).<p>We probably could have made a great jruby memcached/MySQL/thrift client, but it wasn't clear that doing so would have much performance win, as jruby itself wasn't dramatically faster than MRI. It would have, however, made it really easy for us to offload intense bits of code to java code, which probably would have been a faster upgrade path than rewriting in scala as we did.
I'll add another data point. We're in the process of moving our entire API stack to Go from Python. First it was in Django, then Falcon, now more & more pieces are in pure Go, with a little cgo sprinkled for good measure. Apart from being a language that's easy to pick up if you're familiar with Python, Go is obviously a heckuva lot faster and way easier to deploy.<p>We cut down our EC2 instance usage by 2/3 with more improvements yet to come. One machine alone can handle 1000 API calls / second - and our API calls are performing complex calculations, not just disk I/O.<p>It also allows us to deploy our API within customer's networks if they choose, which we previously accomplished using Virtual Machines - which sucked.
Afaik, the jvm is often praised for being the gold standard in terms of vm, both performance wise and in terms of tools available to instrument it. I'm curious as to why the parse engineers were not looking forward to using it. I've always thought using it was a good point for a language...
Between this and Pivotal moving Cloud Foundry CLI tools to Go, I keep seeing more reasons to add Go to my CV. Ruby will always be fun, but I'm guessing there will be some serious $$ & interest in Go projects in the coming years (even more than currently).
“The MongoDB Go driver is probably the best MongoDB driver in existence, and complex interaction with MongoDB is core to Parse.”<p>It's also the only one that's not maintained by MongoDB Inc. Coincidental? :)<p>PS: And yes, `mgo` by Gustavo Niemeyer is pretty incredible.
I would love to know about Parse's stack's, please, consider sharing with us :) (<a href="http://stackshare.io/trending/tools" rel="nofollow">http://stackshare.io/trending/tools</a>)
The article makes some very good points, and I'm surprised you don't talk more about the deploy advantages for instance. But I was a bit annoyed by little things that I think are inexact:<p>- the "one-process-per-request" meme along the post applies only to some ruby app servers (there are event loop and threaded models too, think thin, puma, passenger in some modes) and I guess reading between the lines that it's mostly a problem of thread-safety and async support, because of the gems Parse used to have, right? I'm sure that limits options at some point anyway, but the statement is misleading and not really explained, I'd love to hear more details<p>- I don't understand how the comments in the little Go file snippet applies in any way to "ruby" ; it may be rails caching mechanisms, or a specific gem, but I have a hard time mapping those very specific details to something intristic to ruby, it seems more like grumpy ruby bashing, like you'd have done php bashing 5 years ago<p>As all rewrite stories, I think there's a part of envy/excitement over the new cool tech you want to use (and that's fair! pleasure give you huge productivity boosts), and also a part of success related to the fact you <i>know</i> the kind of things you failed in the first version, so you won't make the same mistakes the 2nd time.<p>I'd love to hear finer details on those points! Great article overall anyway
It's a decent article but the justification for rewriting is totally discredited by not even having tried JRuby. Many apps drop right in and get true concurrency, better GC, and faster performance for free. It sounds like JRuby wasn't even given a chance, and I know they never contacted the JRuby team to talk about it.
This bit jumped out at me: "200 API servers ... to serve 3000 requests per second". That's only 15 RPS per server. Is that normal for Rails?
Starting a business with rails makes sense and still do. And later moving to another technology that scales better makes sense too. After all, you will probably be a millionnaire at the time you need to scale your product so why worry ?
Rails does not require a process per a request model. It is great that you had success moving to Go, but you could have moved to a different model with rails and likely solved your problem.
> Stuff like doubly encoded URLs<p>Could you elaborate on this? It sounds a bit scary. Does this mean that Rails tries to decode a URL several times until it can't be decoded? If so, isn't this problematic if some (arguably crazy) person tries to send "%2F" literally, not "/"? I'm half sure I'm misinterpreting, so here to ask.
What tools are you using to do API management on top? Have you seen the Open-Source KONG? <a href="http://github.com/mashape/kong" rel="nofollow">http://github.com/mashape/kong</a>
"How We Moved Our API From Ruby to Go and Saved Our Sanity"... Right, so using Go will alleviate severe mental illness? Why isn't Golang all the buzz in professional psychologist and psychiatrist circles?